Un jour peut-être vous ferez partie de ces sysadmins et ingénieurs systèmes et réseaux qui voudront implémenter dans leur entreprise une infrastructure de bureaux virtuels, autrement connue sous le nom de VDI pour Virtual Desktop Infrastructure. Les solutions de VDI sont assez nombreuses dans le commerce, avec bien évidemment des leaders tels que VMware, Citrix, ou encore Microsoft, et aujourd'hui encore très peu de solutions libres.

Mais ne nous perdons pas dans un état de l'art (qui serait néanmoins intéressant) et concentrons-nous plutôt sur le cas où vous vous pencheriez sur une solution de VDI Microsoft, en particulier le cas où vous voudriez lancer environnement de test ou un labo.

Avant de vous lancer, il vous faudra vous assurer que vos services soient installés sur un environnement compatible. La VDI est une infrastructure assez capricieuse (et ce quelque soit le fournisseur) qui nécessitera que :

• l'hôte de machines virtuelles ne doit pas être dans une machine virtuelle (jusque là pas de surprises) ;
• le contrôleur de domaine et le fournisseur de machines virtuelles soient sur des machines hôtes différentes, c'est particulièrement tentant quand on est dans un labo assez restreint mais Windows n'aimera pas et ne vous le dira pas ;
• le service Brokeret le contrôleur de domaine devront être sur des machines différentes ;
• l'OU Computers du domaine dans lequel vous souhaitez approvisionner les VMs doit être préparé pour pouvoir enrôler automatiquement les nouvelles machines (cette manipulation peut être gérée depuis le MMC en agissant sur les paramètres par défaut des collections dans l'onglet principal du VDI) ;
• les machines virtuelles approvisionnées devront se trouver dans un réseau Hyper-V externe dans lequel elles pourront atteindre un serveur DHCP et le DC. Si le vSwitch n'est pas externe, le VDI ne pourra pas être publié et si les machines n'ont pas d'adressage dynamique et ne peuvent pas atteindre le DC vous ne pourrez même pas passer la création de collections.

Ces quatre points sont ceux sur lesquels, avec mon groupe d'études, nous avons eu le plus de mal à trouver des réponses, d'autant plus qu'aucune console Windows, qu'il s'agisse du MMC ou d'un terminal Powershell, ne voulait nous donner d'indications sur les problèmes.

Les trois premiers points sont assez faciles à résoudre, du moment où vous avez suffisamment de machines hôtes pour vous le permettre. Le quatrième point est expliqué dans la documentation et est assez simple. Quant au quatrième, si votre architecture se veut un peu particulière, avec des sous-réseaux qui s'entrecroisent en différents points, vous risquez de passer un grand moment, et le meilleur moyen d'y remédier est de procéder à des tests depuis la machine gold (celle qui servira de template) avant de la sysprep. D'une manière générale, ces tests consisteront à vérifier que votre machine, déployée avec une adresse dynamique, soit en mesure d'accéder à chacun des services qu'elle est destinée à atteindre, en particulier le DC (sans quoi vous ne pourrez pas créer la collection non-plus).

Ce billet mériterait peut-être un peu plus de schémas, à voir pour une édition prochaine plus explicite. En attendant voici quelques documents utiles :

• Guide de déploiement VDI pour 2500 utilisateurs
• Guide Technet de déploiement standard en pool (avec liens vers les autres modes de déploiement)
• Guide pas à pas de déploiement standard, avec autorisation à créer des machines dans AD

Bon déploiement !