Installation des drivers (Integration Services) sur une VM Windows Server 2003 hébergée sur Hyper-V 2016

Bien qu’il puisse s’agir d’une faute professionnelle que de déployer à l’aube de 2019 des machines Windows Server 2003, dans le cadre du projet sur lequel je planche actuellement j’ai dû procéder à un tel crime de lèse-majesté.

Le hic, c’est qu’Hyper-V 2016, à la différence de 2012, ne supporte plus Windows Server 2003 (entre autres), ce qui signifie que le bon fonctionnement d’un tel OS n’est pas garanti et que les drivers (regroupés sous un pack nommé Integration Services, qui pourrait être comparé aux VMtools sous VMware) ne sont pas fournis ; si Hyper-V 2012 proposait ces drivers nativement, Hyper-V 2016 procède à leur installation par internet. Afin de les déployer sur une machine 2003 – avec toutes les précautions que cela comprend ainsi que le bon sens qui doit vous dicter de ne pas déployer cela en production si possible – il faut donc ruser un peu.

Une première solution : installer Hyper-V 2012 sur une machine et récupérer ces drivers ; ils sont situés dans C:\Windows\System32\vmguest.iso. Ensuite, monter cette image ISO sur la VM 2003 et procéder à l’installation sur le serveur 2003 des packages.

La deuxième solution est la plus simple : sur les forums de Microsoft, de nombreux sujets traitent du problème que rencontrent certains utilisateurs, et il est possible de trouver l’image ISO d’Integration Services. Je vous fais grâce de la recherche, puisque j’ai uploadé l’ISO sur le serveur de manière à ce qu’il soit disponible en téléchargement direct. Comme pour la première solution, il suffit de monter cette image sur la VM 2003 et de procéder à l’installation.

A noter qu’il faudra que le Service Pack 2 soit déployé sur la VM afin que les Integration Services s’installent. Plusieurs pilotes (dont le très important pilote de carte réseau !) vont s’installer et un redémarrage sera nécessaire.

Introduction à Hyper-V Server 2016

J’ai eu le luxe de pouvoir préparer aujourd’hui une petite plateforme de test basée sur Hyper-V Server 2016 avec quelques machines virtuelles. Je vais donc détailler dans cet article l’installation d’Hyper-V Server 2016 (à ne pas confondre avec un Windows Server 2016 ayant le rôle Hyper-V !), ses configuration côté OS et hyperviseurs, la mise en place d’un switch virtuel pour mettre les machines en réseau et enfin le déploiement de quelques machines virtuelles Windows.

Tout d’abord, il suffit de récupérer l’ISO d’Hyper-V Server 2016, disponible gratuitement. La phase de boot se déroule comme pour n’importe quel OS Windows usuel.

Il faut accepter le contrat de licence, partir sur une installation fraîche de Windows si jamais il existait déjà un OS Windows sur le serveur :

On en arrive au partitionnement. J’ai utilisé une configuration à 3 disques virtuels : le premier pour l’OS, le deuxième pour les données du serveur (images ISO, sauvegardes de fichiers de configuration, applications supplémentaires, scripts….) et le troisième pour les fichiers des VM (fichiers de configuration et disques virtuels des VM). En fonction de la configuration du RAID de la machine physique, il peut être malin de séparer système et données sur deux arrays différents.

Puis on lance l’installation. Une fois celle-ci terminée, le serveur redémarre et l’on arrive sur une interface en ligne de commande, identique à celle des serveurs installés sans GUI.

Choisissez un mot de passe, et ensuite, l’outil de configuration sconfig s’exécute.

Le management à distance est activé par défaut (ce qui signifie que le serveur sera attaquable par les consoles de management déployées sur les stations de travail), à l’inverse du RDP. Il faut ensuite s’occuper de la configuration réseau, renommer le serveur pour lui donner un nom lisible et si besoin effectuer la jonction au domaine. Une fois celle-ci réalisée, il peut être nécessaire de pousser un compte du domaine d’administration sur le serveur en tant qu’administrateur local pour que l’on puisse y accéder via la console de management Hyper-V. On choisira alors l’option 3 et saisira le nom du compte d’administration.

Côté OS, tout est prêt, tout se passe désormais sur la station de travail cliente. Il suffit d’installer la console de management Hyper-V, en allant dans le panneau de configuration et les options de fonctionnalités.

Attention à ne pas installer « Plateforme Hyper-V », qui installerait l’hyperviseur complet sur la station !

Une fois l’opération terminée, la console est accessible depuis le menu démarrer. Il est possible de se connecter au serveur Hyper-V fraîchement installé si tout s’est bien déroulé :

Si jamais cela ne fonctionne pas, pas de panique. Les 2 cas les plus fréquents de soucis de connexion à Hyper-V via la console de management sont l’authentification (la console n’a pas été exécutée avec un compte ayant les droits sur le serveur Hyper-V, d’où ma remarque plus haut sur un éventuel besoin d’ajouter un compte de domaine dans le groupe des administrateurs locaux), et la communication. Normalement, si le remote management est bien activé sur le serveur, les règles dans le pare-feu Windows ont été adaptées pour laisser les flux passer. Si malgré tout la console vous indique qu’elle est incapable de dialoguer avec le serveur, désactiver le pare-feu de l’Hyper-V pour voir si c’est cela qui pose problème est possible avec cette instruction à envoyer dans le cmd :

netsh advfirewall set currentprofile state off

Plusieurs choses à faire une fois que l’on a bien accès à l’hyperviseur. En premier, la création des répertoires. On peut monter les partages administratifs d$ et e$ (en fonction de votre partitionnement) sur la station locale si on ne veut pas créer les répertoires en cmd directement depuis le serveur. Dans mon cas, j’ai créé un répertoire iso sur D: et deux répertoires vms et disks sur E:. Je vais configurer ces répertoires dans les paramètres Hyper-V accessibles d’un clic droit sur le serveur.

Bien qu’il soit possible de tout placer dans le même répertoire, j’ai décidé de séparer configuration et disque.

En second, la création du switch virtuel pour que nos machines soient sur un réseau privé. Plusieurs options sont disponibles en fonction de ce qui est désiré ; dans mon cas, je souhaitais que les machines soient dans leur propre bulle sans interaction possible avec l’extérieur.

On lui donne un nom et on choisit à quoi raccorder ce switch virtuel. J’ai choisi l’option du réseau privé pour l’isolation.

On peut maintenant créer notre première VM. Dans cet exemple, je vais installer 2 machines Windows Server 2016, un contrôleur de domaine et un client. Comme spécifié plus haut, je vais copier mon ISO de Windows dans le répertoire dédié.

On peut passer à la création de la VM elle-même ; peu de surprises dans l’assistant, c’est similaire à ce qui existe dans les autres solutions de virtualisation. Pour cet exemple, une VM de deuxième génération fait l’affaire.

On raccorde la machine au switch virtuel qui a été créé avant.

On ne manquera pas de vérifier que les disques soient bien stockés dans le répertoire qui a été paramétré avant la création de la VM.

Une fois la VM créé, l’installation commence après le boot sur l’ISO.

Le réseau étant complètement isolé, la configuration est entièrement libre.

J’installe par la suite les rôles AD et DNS sur cette machine, puis je m’installe un deuxième serveur 2016, à qui j’affecte une autre adresse IP en mettant en passerelle mon serveur AD.

Cette seconde VM est donc placée sur le même réseau que la première sur notre switch virtuel, il est donc possible de réaliser la jonction au domaine et d’interagir avec d’autres VM sur le réseau.

Sur cette capture, j’ai ajouté mon deuxième DC installé en mode Core au server manager de mon 2016.

Voici donc comment se monter une petite plateforme de tests basée sur Hyper-V Server 2016 et mettre les machines en réseau sans qu’il n’y ait d’impact en dehors de cette bulle virtuelle. 😃

Erreur 1069 sur cluster Hyper-V 2008 R2

Aujourd’hui, j’ai été confronté à une prolifération d’erreurs 1069 dans le journal d’événements d’une machine Hyper-V sous Windows 2008 R2.

Cette erreur indique qu’un élément présent dans le cluster n’est pas joignable.

Un petit tour dans la console FailOver Cluster Management et je constate qu’en effet, certaines ressources sont indisponibles tandis que les disques attachés le sont toujours.

Etat d’une ressource du cluster

Après une petite recherche, il s’est avéré que les machines en question ont été éteintes dans le cadre d’un projet de démantèlement et que le cluster n’avait pas été nettoyé ; il ne m’a resté qu’à sélectionner chaque machine éteinte et démantelée et à la supprimer du cluster afin qu’il ne reste plus aucune référence.