Microsoft a publié un outil faisant référence à l’ensemble des changements sur le schéma de l’annuaire Active Directory engendrés par Exchange Server lors de son installation. Il inclut les changements pour les versions suivantes : Microsoft Exchange Server 2010 SP1, Exchange Server 2010, Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007, and Exchange Server 2003.

Télécharger Exchange Server Active Directory Schema Changes Reference, June 2010

Microsoft vient de publier un analyseur de bonnes pratiques ou Best Practices Analyser (BPA) pour Forefront Unified  Access Gateway (UAG). Ces outils permettent d’analyser la configuration du serveur pour vérifier que celui-ci respecte les bonnes pratiques définies par Microsoft.  Il vérifie notamment les Objets DCOM, les classes WMI, la base de registre, le système de fichier, et les paramétrages DNS.

Télécharger Microsoft Forefront Unified Access Gateway (UAG) 2010 Best Practices Analyzer Tool

John Vintzel (Microsoft Corp) a publié sur le blog Inside_OSD un très bon post que je me dois de partager avec vous. Celui-ci traite du déploiement de système d’exploitation avec la fonctionnalité BranchCache. Le comportement par défaut du déploiement de système d’exploitation consiste à bloquer BranchCache car l’application des GPOs sont bloquées durant la phase de déploiement. John Vintzel donne les différentes étapes nécessaires à son utilisation :

·         S’assurer que l’architecture BranchCache est opérationnelle

·         Configurer BranchCache dans l’image de référence qui est déployée.

·         Ajouter l’action « Run Commande Line » dans la séquence de tâches après la tâche « Setup Windows and ConfigMgr ».
Dans cette ligne de commande, vous pouvez utiliser l’une des commandes suivantes :

o   « netsh branchcache set service mode=DISTRIBUTED » pour activer BranchCache dans un mode distribué

o   « netsh branchcache set service mode=HOSTEDCLIENT LOCATION=<Hosted Cache name> » pour activer BranchCache dans un mode hébergé.

Source : Inside Operating System Deployment for ConfigMgr

J’en parlais la semaine dernière, Microsoft a publié le Service Pack 2 d’Application Virtualization 4.5. Ce Service Pack apporte en autre le support d’Office 2010 et de SQL Mirroring. Il inclut aussi l’ensemble des correctifs disponibles dans la mise à jour cumulative 1. Aujourd’hui, c’est la documentation d’Application Virtualization qui est mise à jour pour prendre en considération ce Service Pack.

On retrouve ainsi le sujet « About Microsoft Application Virtualization 4.5 SP2 » et « App-V 4.5 SP2 Release Notes »

Ce nouvel outil gratuit de la famille des accélérateurs de solutions permet d’obtenir des rapports par le biais d’un tableau de bord. App-V Dashboard se base sur Sharepoint, ce qui donne des rapports plutôt sexy contrairement à ceux présents par défaut dans la console de gestion.

Il donne ainsi des données au travers des diagrammes, jauges sur le Top 5 des Applications utilisées, le Top 5 des utilisateurs, les Applications jamais utilisées, L'usage des applications pour un utilisateur spécifique...

Voici les prérequis :

Télécharger App-V DashBoard

Conclusion

Nous avons vu une technologie innovante au service des utilisateurs et de l’entreprise appelée Virtual Desktop Infrastructure (VDI). Microsoft au travers de Windows Server 2008 R2, de son hyperviseur, et de sa technologie de virtualisation de présentation (Remote Desktop Services), propose une solution arrivant enfin au niveau de ce qui est proposé par ses concurrents. L’arrivée prochaine du Service Pack 1 de Windows 7, Windows Server 2008 R2 et la technologie RemoteFX briseront les derniers freins à son intégration en entreprise en apportant la notion de multimédia et d’expérience utilisateur (Aero Glass). VDI reste une technologie chère et élitiste quel que soit l’acteur (Microsoft ou VMware) que vous choisirez. Les quelques avantages offerts par VDI et les attaques marketing fortes contre VMware en ce qui concerne les licences ne couvrent pas les différents frais (matériel et logiciel) engendrés pour l’implémentation de cette technologie. Microsoft couvre cependant les principaux scénarios en offrant la possibilité de créer des pools de machines virtuelles et des bureaux virtuels personnels. Les pools de machines virtuelles sont souvent mis en avant dans des scénarios de migration de système d’exploitation afin d’offrir une alternative quant aux problèmes de compatibilité applicative qui peuvent être rencontrés dans ce genre de projet. Les bureaux virtuels personnels sont souvent assimilés à une vision future du déploiement des postes de travail. Cette nouvelle approche offre la possibilité aux utilisateurs de se connecter aux bureaux virtuels quel que soit l’endroit, la machine, le système utilisé. Du côté des administrateurs, ce système offre une administration flexible et centralisée.

Revenir au plan : http://microsofttouch.fr/blogs/js/pages/microsoft-virtual-desktop-infrastructure-vdi-sous-tous-ses-angles.aspx

9. VDI : Les scripts supplémentaires

Microsoft et son équipe Remote Desktop ont mis au point un certain nombre de script aidant à l’administration d’une infrastructure VDI.
Parmi les scripts intéressants, on retrouve :

• Configure Guest OS for Microsoft VDI : permet de configurer l’ensemble des paramétrages nécessaire à l’utilisation d’une machine virtuelle dans une infrastructure VDI :
  • PowerShell
  • VB Script
• Diagnose connection issues in VDI deployment : permet de tester et debugger les problèmes de connexion dans un environnement VDI.
• Create virtual machines for VDI : permet de créer une machine virtuelle pour une infrastructure VDI en sélectionnant un disque VHD et l’ensemble des paramètres nécessaires à sa création.
• Verify virtual machine configuration for RDV doit être exécuté sur le serveur RD Virtualization Host afin de dépanner et vérifier la configuration des machines virtuelles.
• Assign Virtual Machines to users or pools : permet d’assigner une machine virtuelle à un utilisateur ou à un pool.
• Migrate virtual machines permet de migrer des machines virtuelles dans un cluster d’hôte Hyper-V
• Change state of the virtual machines permet le changement de l’état d’une ou plusieurs machines virtuelles d’un noeud de cluster Hyper-V.
• Query Virtual Machine assignment information affiche l’assignement pool/utilisateur d’une machine virtuelle par le serveur RD Connection Broker sur lequel est exécuté le script.
• VDI & RDSH : Monitor sessions permet de facilement superviser les connexions bureaux à distance dans un environnement VDI. Vous pouvez envoyer des messages aux utilisateurs ou obtenir des informations sur leur session
• Verify Redirection configuration vérifie la configuration du serveur RD Session Host dans un mode redirection pour l’infrastructure VDI.
• Verify RD Connection Broker configuration : permet de vérifier la configuration de votre serveur RD Connection Broker afin de s’assurer de son fonctionnement dans un environnement VDI.
• Verify RD WebAccess configuration  permet de vérifier la configuration de votre serveur RD WebAccess afin de s’assurer de son fonctionnement dans un environnement VDI.
• Verify Connection broker cluster configuration  permet de vérifier la configuration d’un cluster RD Connection Broker afin de s’assurer de son fonctionnement dans un environnement VDI.
• Verify RDV deployment configuration vérifie la configuration de l’ensemble des serveurs et composants nécessaire à l’infrastructure VDI.
• Create RD Redirection server clusters  permet la création d’un cluster à répartition de charge avec DNS Round-Robin pour des serveurs RD Session Host dans un mode redirecteur.
• Add RD Virtualization Host server(s) to Connection Broker fail-over cluster : permet d’ajouter des serveurs RD Virtualization Host à des serveurs RD Connection Broker en cluster ou non.
• Create deployment usage reports : Ce script utilise le journal d’événement du serveur RD Connexion Broker pour créer un rapport sur l’utilisation de l’environnement VDI

Retrouvez l’ensemble des scripts sur le Script Center de Microsoft : http://gallery.technet.microsoft.com/ScriptCenter/en-us/site/search?f%5B0%5D.Type=RootCategory&f%5B0%5D.Value=remotedesktopservices&f%5B0%5D.Text=Remote%20Desktop%20Services&f%5B1%5D.Type=SubCategory&f%5B1%5D.Value=remotevirtualization&f%5B1%5D.Text=Remote%20Desktop%20Virtualization&pageIndex=1

Revenir au plan : http://microsofttouch.fr/blogs/js/pages/microsoft-virtual-desktop-infrastructure-vdi-sous-tous-ses-angles.aspx

8. VDI : RemoteFX et Dynamic Memory

Nous en avons parlé plus tôt dans cet article, Microsoft introduit dans le Service Pack 1 de Windows Server 2008 R2 et Windows 7, un ensemble de technologies entièrement dédiées à VDI. Le but est de donner des arguments puissants en ce qui concerne la virtualisation des postes de travail mise à disposition au travers de centre de données et ce afin de clairement rivaliser avec son concurrent VMWare. Jusqu’à présent, lorsque vous virtualisiez un système d’exploitation, il n’était pas possible de bénéficier des fonctionnalités d’expérience utilisateur comme l’interface Aero. Avec l’arrivée du Service Pack 1, Microsoft introduit la fonctionnalité RemoteFX (issue du rachat de Calista en 2008) permettant de bénéficier des fonctionnalités de calculs graphiques du serveur à l’intérieur d’une machine virtuelle. L’utilisateur ne voit ainsi aucune différence entre une machine physique et virtuelle.

Le Service Pack 1 de Windows Server 2008 R2 introduit aussi une nouveauté dédiée à Hyper-V appelée Dynamic Memory. Cette fonctionnalité permet de configurer une machine virtuelle afin que la quantité de mémoire assignée à la VM s’ajuste en fonction de ses besoins pendant son exécution. Il y a donc une notion d’allocation dynamique de la mémoire au système d’exploitation. Ceci permet d’augmenter le nombre de machines virtuelles sur une machine physique. Le but est d’assurer que la mémoire est distribuée de façon optimale entre les différentes machines virtuelles.

 8.1 Installation du Service Pack 1

Cette partie est légèrement superflue étant donné le niveau requis pour installer un Service Pack, néanmoins je tiens à la détailler en rappelant certaines choses.
Avant d’appliquer le Service Pack, veillez à faire une sauvegarde de la machine. Ceci inclut une sauvegarde des données et du système au travers des différents outils mis à disposition par Microsoft. Pour sauvegarder les données de l’état utilisateur, vous pouvez utiliser Windows Easy Transfer (inclus dans Windows) ou User State Migration Tool (USMT). Vous pouvez effectuer une sauvegarde parla fonctionnalité Sauvegarde et Restauration de Windows. Pour le serveur, vous pouvez utiliser System Center Data Protection Manager.

Une fois la sauvegarde faite, procurez-vous le Service Pack 1 dans l’architecture souhaitée pour votre système par le biais du centre de téléchargement de Microsoft, de Windows Update, ou de WSUS.

Note : A l’heure où cet article est écrit, le SP1 n’est pas disponible. Il n’existe aucune version Bêta disponible au public.

Rappel : Depuis Windows Vista, les sources de Service Pack sont similaires pour la version cliente ou serveur du système d’exploitation concerné. Ainsi les sources du Service Pack 1 de Windows 7 fonctionnent aussi pour Windows Server 2008 R2.

Lancez ensuite l’installeur et lisez les recommandations. Acceptez ensuite le contrat de licence et lancez l’installation (vous pouvez choisir de laisser le processus redémarrer la machine quand il en a besoin)

Après de multiples redémarrages, l’installeur vous signale l’installation avec succès du service pack 1 du système d’exploitation.
Vous pouvez vérifier la version du système (Build 7601) par le biais de la commande winver ou du panneau de configuration « Système » :

 8.2 Implémentation de RemoteFX

Le but de RemoteFX (issue du rachat de Calista en 2008) est de permettre à la machine virtuelle de bénéficier des fonctionnalités de calculs graphiques du serveur.

Les pré requis nécessaires à l’implémentation de cette technologie sont lourds et importants. Il y a très peu de chance que vous puissiez mettre en place cette technologie en utilisant des postes de travail conventionnels.

Voici la liste des pré requis :

• Assurez-vous que le serveur qui héberge le rôle RD Virtualization Host (ainsi que le rôle Hyper-V) dispose d’un processeur Intel EPT ou AMD NPT ou disposant des capacités SLAT (Second Level Address Translation).
• Assurez-vous que le serveur qui héberge le rôle RD Virtualization Host (ainsi que le rôle Hyper-V) dispose d’un processeur graphique (GPU) qui est compatible avec DirectX 9.0 et qui dispose d’un minimum d’1 GB de RAM dédié à la vidéo. Microsoft estime que chaque machine virtuelle consomme approximativement 200MB de RAM de la carte vidéo. Le nombre de machines virtuellesisposant de la fonctionnalité RemoteFX dépend donc des capacités de la carte vidéo.
• Assurez-vous que le serveur qui héberge le rôle RD Virtualization Host dispose d’une carte vidéo à un seul processeur graphique (GPU). L’utilisation d’une carte graphique à plusieurs processeurs graphiques (GPU) n’est pas supportée dans cette version. Si le serveur dispose d’une carte vidéo embarquée, désactivez-la dans le BIOS.
• Assurez-vous d’avoir téléchargé et installé les derniers drivers pour la carte graphique de votre serveur RemoteFX. Microsoft déconseille l’utilisation des drivers inclus dans Windows Server 2008 R2
• Si vous utilisez une carte ATI, assurez-vous que le package Catalyst ou Crossfire n’est pas installé.
• Si vous utilisez une carte NVidia, n’utilisez pas le driver en version 196.75. Microsoft rappelle qu’une alerte a été émise par NVidia concernant cette version.
• Assurez-vous que la fonctionnalité Hyper-threading est activé sur le serveur hébergeant le rôle RD Virtualization Host.
• Si vous utilisez une machine virtuelle Windows 7 SP1 x86, vous devez allouer au minimum 1024MB de mémoire pour pouvoir bénéficier de RemoteFX. Pour une machine virtuelle Windows 7 SP1 x64, vous devez lui attribuer 2048 MB de mémoire.
• Le système d’exploitation de la machine virtuelle doit bien entendu utiliser le client RemoteFX. Pour cela, vous devez lui installer le Service Pack 1 de Windows 7.
• Enfin, assurez-vous que la connexion réseau entre le client et le serveur hébergeant le rôle RD Virtualization Host est une connexion 10Mbps minimum avec un temps de latence inférieur à 20ms afin d’assurer la fluidité des effets graphiques.

Note : Il n’est pas nécessaire d’installer le Service Pack 1 sur le reste de l’infrastructure comme sur les serveurs Remote Desktop Web Access ou Remote Desktop Connexion Broker ou Remote Desktop Session Host.

Installation du service RemoteFX

Dès lors que le Service Pack 1 est installé sur les machines virtuelles servant dans le pool de bureaux virtuels ou dans les bureaux virtuels personnels ainsi que sur le serveur hébergeant le rôle RD Virtualization Host, connectez-vous sur ce serveur et ouvrez la console Server Manager. Dirigez-vous dans l’arborescence « Roles => Remote desktop Services ». Dans la partie « Role Services », on peut observer l’apparition d’un nouveau service « RemoteFX ».

Cliquez sur « Add Role Services » pour ouvrir l’assistant d’ajout. Cliquez ensuite sur la case « RemoteFX » et passez à l’écran de confirmation.

L’installation de ce composant ne nécessite pas le redémarrage de la machine. Une fois l’installation terminée, on peut observer l’apparition d’un service « VmHostAgent » ou « Remote Desktop Virtualization Host Agent » :

Activation de la RemoteFX sur la machine virtuelle

Une fois le composant serveur correctement installé, ouvrez la console « Hyper-V Manager ». Ouvrez ensuite les propriétés de la machine virtuelle sur laquelle vous souhaitez activer la fonctionnalité. Pour rappel, celle-ci doit disposer d’un client RemoteFX incluant l’utilisation de Windows 7 SP1 ou plus récent. Cliquez ensuite sur « Add Hardware ». Sélectionnez « RemoteFX 3D Video Adapter » et cliquez sur « Add » pour ajouter la carte graphique virtuelle.

Une fois ajoutée, vous pouvez configurer la résolution ainsi que le nombre d’écrans maximum supportés. Vous pouvez autoriser l’utilisation de 4 écrans simultanés. La résolution est limitée à 1920*1200.

Notez qu’il n’est possible d’attribuer qu’un nombre d’écran limité pour une résolution spécifique :

Si vous tentez d’attribuer un nombre supérieur d’écran à la limite définie pour la résolution, ceci résulte en une erreur.

Lorsqu’on tente de se connecter à une machine virtuelle disposant du client RemoteFX, on peut voir que l’interface Aero Glass est activée (barre de tâches transparente) :

RemoteFX répond ainsi aux attentes du marché en offrant un système d’exploitation virtuel disposant des capacités complètes que l’on peut retrouver sur une machine physique. Cette fonctionnalité risque d’encourager l’adoption de la technologie VDI de Microsoft en entreprise

 8.3 Configuration de la fonctionnalité Dynamic Memory

L’autre nouveauté apportée par le Service Pack 1 de Windows Server 2008 R2 est Dynamic Memory. Cette fonctionnalité concerne l’hyperviseur : Hyper-V. Elle permet de configurer une machine virtuelle afin que la quantité de mémoire assignée à la VM s’ajuste en fonction de ses besoins pendant son exécution. Il y a donc une notion d’allocation dynamique de la mémoire au système d’exploitation. Ceci permet d’augmenter le nombre de machines virtuelles sur une machine physique. Le but est d’assurer que la mémoire est distribuée de façon optimale entre les différentes machines virtuelles. Le système d’exploitation virtuel doit aussi être en capacité de gérer cette arrivée de mémoire alors qu’il est en cours d’exécution. Les systèmes d’exploitation supportant cette fonctionnalité sont les suivants :

• Windows Server 2008 R2 Edition Entreprise (32-bit et 64-bit)
• Windows Server 2008 R2 Edition Datacenter (32-bit et 64-bit)
• Windows 7 Edition Intégrale (32-bit et 64-bit)
• Windows 7 Edition Entreprise (32-bit et 64-bit)
• Windows Server 2008 Edition Entreprise (32-bit et 64-bit)
• Windows Server 2008 Edition Datacenter (32-bit et 64-bit)
• Windows Vista Edition Intégrale (32-bit et 64-bit)
• Windows Vista Edition Entreprise (32-bit et 64-bit)
• Windows Server 2003 R2 Edition Entreprise (32-bit et 64-bit)
• Windows Server 2003 R2 Edition Datacenter (32-bit et 64-bit)
• Windows Server 2003 Edition Entreprise (32-bit et 64-bit)
• Windows Server 2003 Edition Datacenter (32-bit et 64-bit)

Avant d’activer la fonctionnalité « Dynamic Memory » sur une machine virtuelle, vous devez vous assurer que celle-ci dispose des derniers composants d’intégration Hyper-V.

Pour activer « Dynamic Memory », ouvrez la console Hyper-V Manager. Ouvrez ensuite les propriétés de la machine virtuelle sur laquelle vous souhaitez activer la fonctionnalité. Cliquez ensuite sur « Memory ». Vous pouvez utiliser l’attribution de mémoire classique et antérieure au SP1 de Windows Server 2008 R2 en utilisant l’allocation Statique.
Pour activez DM, cochez « Dynamic ». On distingue ensuite quatre paramétrages :

• Initial memory ou “Startup RAM”. Ceci représente le montant de mémoire requis pour démarrer la machine virtuelle (voir tableau ci-dessous). Cette valeur doit être assez importante pour permettre au système virtuel  de démarrer mais aussi bas que possible pour permettre des performances optimales avec l’allocation dynamique de mémoire.  La machine virtuelle ne se verra jamais assigner un niveau de mémoire inférieur à la valeur de démarrage.
• Maximum memory ou “Maximum RAM”. La machine virtuelle ne sera pas autorisée à utiliser plus de mémoire que le montant spécifié dans ce champ. Vous pouvez décider d’allouer jusqu’à 64 GB de mémoire à une machine virtuelle.
• Memory buffer. Le tampon de mémoire (pourcentage) indique combien de mémoire doit être assigné à la machine virtuelle comparé au montant de mémoire nécessaire aux applications, services, et charge de travail de la machine virtuelle. Le buffer n’est pas maintenu s’il n’y a plus assez de mémoire disponible sur le serveur pour donner à chaque machine virtuelle la mémoire demandée.
• Memory priority. Cette valeur reflète comment la mémoire sera distribuée entre les machines virtuelles s’il n’y a plus assez de mémoire physique disponible sur le serveur pour donner à chaque machine virtuelle la mémoire demandée. Une machine virtuelle disposant d’une priorité importante se verra attribuée plus de mémoire qu’à une machine virtuelle avec une priorité plus faible avec les paramétrages similaires. En augmentant la priorité de mémoire d’une machine virtuelle permettra d’assurer que la mémoire physique disponible assignée à la machine virtuelle le sera avant qu’elle en ait besoin.

Pour chaque système d’exploitation, Microsoft recommande les données suivantes :

Une fois le système démarré, on remarque qu’il démarre avec le montant de mémoire spécifié. Deux nouvelles colonnes sont apparues :

• « Current Memory » affiche la quantité de mémoire attribuée à un instant donné.
• « Memory Available » affiche le pourcentage de mémoire disponible sur le système d’exploitation de la machine virtuelle.

Après avoir fait varier les paramètres « Memory Buffer » et « Memory Priority », on remarque que la quantité de mémoire allouée à la machine virtuelle passe de 512MB à 2048MB.

Customization de Dynamic Memory pour de meilleures performances

Microsoft donne quelques recommandations et customisations, si vous avez active Dynamic Memory et que vous n’êtes pas satisfait des performances :

• Augmenter la taille du fichier de pagination du système d’exploitation de la machine virtuelle.
• Augmenter le paramètre Memory Buffer de la machine virtuelle. L'augmentation de la mémoire tampon se traduira par plus de mémoire attribuée à la machine virtuelle par rapport à la quantité de mémoire réellement nécessaire par les applications et les services en cours d'exécution dans la machine virtuelle. 
• Augmenter le montant initial de mémoire (Initial Memory) pour la machine virtuelle.
  Certaines applications attribuent des montants fixes de la mémoire basés sur la quantité de mémoire disponible lorsque l'application démarre pour la première. Ces applications fonctionnent mieux avec des valeurs plus élevées pour la mémoire initiale.

Revenir au plan : http://microsofttouch.fr/blogs/js/pages/microsoft-virtual-desktop-infrastructure-vdi-sous-tous-ses-angles.aspx

7. VDI : La virtualisation de l'état utilisateur

La technologie VDI de Microsoft est innovante mais nous n’avons pas jusqu’à maintenant abordé la notion de virtualisation de l’état utilisateur (UserState Virtualization). La virtualisation de l’état (paramètres) utilisateur est utilisé pour permettre aux utilisateurs de travailler avec ses données et son profil personnel à partir de n’importe quel ordinateur de l’entreprise. Le but est d’apporter de la souplesse, de réduire les risques de pertes des données en les centralisant sur des zones sécurisées de l’entreprise. Cette notion est un projet à part entière qui doit faire l’objet d’une étude approfondie. La virtualisation de l’état utilisateur prend tout son sens lors de l’implémentation de VDI puisque l’utilisateur doit avoir accès à ses données lors de l’utilisation des pools de machines virtuelles ou de son bureau virtuel personnel. Ces technologies existent depuis la sortie de Windows 2000 et ont évolué au fil des années pour s’adapter aux différentes attentes des utilisateurs de nos jours. Aujourd’hui, Microsoft proposent trois méthodes assimilées à la virtualisation de l’état utilisateur :

• La fonctionnalité Offline Files permet aux utilisateurs non connectés au réseau, de manipuler des fichiers réseau comme s’ils étaient connectés. L’utilisateur synchronise ses fichiers entre son poste et un serveur de fichiers. Ceci peut être pratique si un utilisateur doit avoir accès à des documents partagés à partir de bureaux appartenant à un pool de machines virtuelles. Nous n’aborderons pas cette fonctionnalité dans cet article, nous vous renvoyons vers la documentation officielle de Microsoft
• Les profils Itinérants (Roaming User Profiles) permettent aux utilisateurs de conserver leurs documents, paramètres et environnements de travail, quel que soit le poste de travail qu’ils utilisent. Cette méthode synchronise une copie locale du profil utilisateur avec un point de stockage central comme un serveur de fichier.
• La redirection de dossiers (Folder Redirection) permet de rediriger automatiquement les dossiers d'un utilisateur vers un dossier nouvellement créé pour chaque utilisateur sur un serveur de fichier.

Nous aborderons rapidement les deux dernières technologies dans cet article. Notez qu’il est possible de mixer ces technologies afin de mieux les adapter à vos besoins.

 7.1 Les profils Itinérants

Les profils Itinérants (Roaming User Profiles) permettent aux utilisateurs de conserver leurs documents et paramètres, quel que soit le poste de travail qu’ils utilisent. Cette méthode synchronise une copie locale du profil utilisateur avec un point de stockage central comme un serveur de fichier. Lorsque l’utilisateur ouvre sa session, il synchronise une copie de son profil utilisateur stocké sur un serveur sur le poste de travail qu’il utilise. Lors de la fermeture de session, l’ordinateur resynchronise le profil avec la copie sur le serveur afin de reporter les changements opérés. Cette technologie est intéressante mais peut être contraignante si les profils utilisateurs sont lourds. En effet, la synchronisation lors de l’ouverture et de la fermeture de session peut prendre un temps conséquent et immobilisant le poste de travail de l’utilisateur.

Avant de commencer la configuration de cette technologie, vous devez identifier un serveur de fichiers qui fera office de point de stockage central des profils itinérants. Créez un dossier et partagez-le aux utilisateurs avec les permissions adéquates. Il est conseillé de rendre ce dossier caché des utilisateurs en utilisant le signe $ à la fin de son nom. Créez ensuite un sous dossier pour chaque utilisateur en lui attribuant les droits nécessaires.

Ouvrez ensuite la console « Active Directory Users and Computer », sélectionnez le compte utilisateur de la personne cible et ouvrez les propriétés du compte. Cliquez sur l’onglet « Profile » et entrez le chemin réseau (UNC) vers le dossier qui stockera le profil itinérant de l’utilisateur : 

Lorsque l’utilisateur se connectera, le processus créera les fichiers nécessaires.
Notez que cette technologie engendre des problèmes de compatibilité entre les systèmes Windows XP et Windows 2000 et les systèmes Windows Vista et Windows 7. Ainsi si un utilisateur utilise des machines équipées de systèmes d’exploitation différents, ce système utilisera des profils itinérants différents en créant deux types de dossier. Pour les systèmes postérieurs à Windows Vista, le système créera un dossier « Repertoire_de_stockage_du_profil.V2 ». Ceci est issu des changements opérés entre Windows XP et Windows Vista concernant l’arborescence et l’organisation des profils utilisateurs.

Cet inconvénient s’ajoute aux longueurs engendrées par la synchronisation de profils lourds à l’ouverture et fermeture de session.

 7.2 La redirection de dossiers

La redirection de dossiers (Folder Redirection) permet de rediriger automatiquement les dossiers d'un utilisateur vers un dossier nouvellement créé pour chaque utilisateur sur un serveur de fichier. Ainsi lorsqu’un utilisateur accède à ses documents, ceux-ci pointent sur un dossier du serveur de fichiers.

Avant de commencer la configuration de cette technologie, vous devez identifier un serveur de fichiers qui fera office de point de stockage central des profils itinérants. Créez un dossier et partagez-le aux utilisateurs avec les permissions adéquates. Il est conseillé de rendre ce dossier caché des utilisateurs en utilisant le signe $ à la fin de son nom. Pour configurer la redirection de dossiers, Créez et Editez une nouvelle stratégie de groupe.

 Ouvrez l’arborescence « User Configuration => Policies => Windows Settings => Folder Redirection » de la console d’administration des stratégies de groupe (GPMC). Une fois l’arborescence ouverte, on distingue l’ensemble des dossiers que l’on peut retrouver dans un profil utilisateur :

Ouvrez les propriétés d’un dossier.
L’onglet « Target » permet de paramétrer la redirection du dossier. On distingue trois types de paramétrages :

• « Not Configured » : Aucune redirection de dossiers n’est paramétrée pour ce dossier.
• « Basic – Redirect everyone’s folder to the same location » permet de rediriger le dossier vers une destination quel que soit l’utilisateur. L’encadrée « Target Folder location » permet de spécifier la façon dont sera stockée le dossier. On distingue les options suivantes :
  • « Create a folder for each user under the root path » permet de spécifier un chemin qui stockera un ensemble de répertoire portant le nom de chaque utilisateur et contenant les fichiers du dossier redirigé.
  • « Redirect to the following location » permet de rediriger le répertoire de tous les utilisateurs vers un chemin spécifié. (Il vous est possible de spécifier une variable comme %username%...)
  • « Redirect to the local user profile location » permet de redonner le comportement par défaut dans l’absence de redirection. Ceci permet de ne pas rediriger les dossiers.
  • « Redirect to the user’s home directory ». Elle permet de rediriger le dossier si vous avez renseigné le dossier de base (Home Folder) à l’utilisateur.
  • « Follow the Documents folder » : Ce paramètre sert uniquement pour les dossiers Pictures, Videos, Music.  Ceci permet de résoudre les problèmes de compatibilité entre Windows Vista et les systèmes d’exploitation antérieurs. Ce comportement est le même si vous configurez l’option « Also apply redirection policy to Windows 2000, Windows 2000 Server, Windows XP, and Windows Server 2003 operating systems »

• « Advanced – Specify locations for various user groups »  permet de spécifier des chemins de stockage en fonction de groupe de sécurité Active Directory. Il est ainsi possible de stocker les répertoires utilisateurs pour un groupe sur un serveur et les répertoires utilisateurs d’un autre groupe sur un autre serveur.

L’onglet « Settings » permet de spécifier des paramétrages supplémentaires à la redirection de dossiers. Cet onglet offre les paramètres suivants :

• « Grand the user exclusive rights to Documents » permet de ne donner les droits nécessaires qu’à l’utilisateur concerné par la redirection de dossier.
• « Move the contents of <Répertoire> to the new location » permet de déplacer le contenu du dossier rediriger dans la nouveau répertoire de stockage.
• « Also apply redirection policy to Windows 2000, Windows 2000 Server, Windows XP, and Windows Server 2003 operating systems » permet d’appliquer la redirection de dossiers aux systèmes d’exploitation antérieurs à Windows Vista. Il est possible d’appliquer ce paramétrage pour les dossiers « Application Data, Desktop, My Documents, My Pictures, et Start Menu »
• L’encart « Policy Removal » permet de configurer le comportement de la redirection de dossiers lorsque la stratégie de groupe n’est plus appliquée :
  • « Redirect the folder back to the user profile location when policy is removed » : Le dossier anciennement redirigé est copié sur le profil local de l’utilisateur. L’utilisateur utilise son profil local et a pleinement accès à ses ressources.
  • « Leave the folder in the new location when policy is removed » : cette option permet à l’utilisateur de continuer à avoir accès au contenu du dossier redirigé. Il continue à être redirigé vers le dossier spécifié.

Après avoir configuré les dossiers, on peut attester avoir correctement accès aux fichiers que l’on se connecte à notre poste Windows 7 ou à une machine virtuelle du pool de bureaux virtuels Windows XP :

La virtualisation de l’état utilisateur est une notion importante dans l’implémentation de votre infrastructure VDI. Vous serez amené à revoir la stratégie que vous avez mis en place ou à en construire une afin d’apporter la meilleure expérience utilisateur possible.

Pour plus d’informations sur la virtualisation de l’état utilisateur, je vous renvoie vers un article du laboratoire : http://www.laboratoire-microsoft.org/articles/win/profil-redirection-quotas/
Vous pouvez aussi consulter le guide « Choosing an Appropriate User State Virtualization Solution » de Microsoft : http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=fd01ed7a-c603-4f7c-8a60-8e4872b58bdf

Revenir au plan : http://microsofttouch.fr/blogs/js/pages/microsoft-virtual-desktop-infrastructure-vdi-sous-tous-ses-angles.aspx

6. VDI : Test de l’infrastructure

Il existe plusieurs moyens d’accès aux bureaux virtuels :

• Accès direct
• Accès au travers du portail Remote Desktop Web Access
• Accès au travers d’une passerelle Remote Desktop Gateway
• Accès au travers de l’ « agrégateur de flux » : Connexions aux programmes RemoteApp et aux services Bureau à distance de Windows 7

Nous aborderons l’accès par le portail et par l’agrégateur de flux.

 6.1 Configurer une connexion avec Connexions aux programmes RemoteApp et aux services Bureau à distance

L’outil « Connexions aux programmes RemoteApp et aux services Bureau à distance » est un agrégateur de flux au format RSS disponible à partir du portail Remote Desktop Web Access permettant l’accès des ressources RemoteApp ou bureaux virtuels à partir du menu démarrer du poste de travail. L’utilisateur n’est donc pas obligé d’accéder au portail RD Web Access pour accéder à ses ressources. Avant de configurer une connexion sur l’ordinateur client, assurez-vous d’avoir mis à disposition des ressources à l’utilisateur et de les avoir publiées.

Sur le client, ouvrez le panneau de configuration et sélectionnez « Connexions RemoteApp et Bureau à distance ». Dans le volet gauche, cliquez sur « Configurer une nouvelle connexion avec les connexions RemoteApp et Bureau à distance ».
L’assistant de création d’une connexion s’ouvre, entrez l’url de connexion de la forme « https://<FQDN_du_serveur_RD_WebAccess>/RDWeb/Feed/webfeed.aspx » :

Attention : Le certificat du portail Remote Desktop Web Access doit être approuvé par le client.

Validez les informations pour ajouter la connexion :

Après la création de la connexion, il synchronise les informations afin de les rendre disponibles au travers du menu Démarrer => Tous les Programmes => connexions RemoteApp et Bureau à distance :

 6.2 Accès au pool de machines virtuelles

Lancez un navigateur et connectez-vous au serveur RD Web Access en utilisant son nom d’hôte, un FQDN ou une adresse Internet. Entrez vos identifiant de connexion :

Sur le portail, cliquez sur « RemoteApp Programs » pour voir la liste des programmes et bureaux virtuels auxquels vous avez accès. Cliquez sur l’icône du pool de bureaux virtuels que nous avons configuré précédemment dans cet article :

Une connexion bureau à distance s’ouvre, on peut observer que l’on pointe sur le serveur Remote Desktop Session Host qui lui-même est configuré dans un mode Redirection vers le serveur RD Connexion Broker. On peut observer les paramétrages d’accès aux ressources (Imprimantes, presse-papier…)  que l’on a souhaité activé sur le serveur RD Connexion Broker.

Une fois que vous avez cliqué sur le bouton « Connexion », le protocole RDP établit la connexion et la sécurise en vérifiant les identifiants de connexion. Une fois la vérification faite, le serveur RD Connexion Broker réveille la machine virtuelle éteinte.

Une fois la connexion établie, nous avons accès à un poste Windows XP disposant des applications que nous avons souhaité mettre à disposition de l’utilisateur. Dans notre cas, l’utilisateur a accès à la suite Office 95 et notamment Excel. Ce scénario peut faciliter la migration d’un parc informatique vers un nouveau système d’exploitation lorsque certaines applications utilisées ne peuvent être utilisées sur le nouveau système d’exploitation.

Dès lors que l’utilisateur ferme la session RDP, le serveur RD Virtualization Host est prévenu par le serveur RD Connexion Broker et opère une restauration (rollback) de la machine virtuelle dans son état initial capturé par l’administrateur lors de l’élaboration du Snapshot RDV_Rollback. Dans le cas contraire, l’état de la machine virtuelle reste inchangé.

 6.3 Accès au bureau virtuel personnel

Nous allons ici tester le second scénario à savoir la mise à disposition d’un bureau virtuel personnel à un utilisateur. Dans le cadre de ma mise en pratique, ce scénario prend son sens dans la mise à disposition des ressources nécessaires (à savoir un système d’exploitation Windows 7) à un ensemble d’utilisateurs externes membres d’une société partenaire.
Pour cela, nous allons utiliser l’outil « Connexions aux programmes RemoteApp et aux services Bureau à distance ».

Notez que les utilisateurs externes ont plutôt tendance à accéder aux ressources par le portail RD Web Access. A contrario, il est préférable de mettre à disposition les pools de bureaux virtuels aux utilisateurs internes au travers de l’outil Connexions aux programmes RemoteApp et aux services Bureau à distance.

Ouvrez le menu Démarrer => Tous les Programmes => connexions RemoteApp et Bureau à distance et sélectionnez « My Desktop » pour initier une connexion bureau à distance au bureau virtuel personnel attribué à l’utilisateur.

Une fois la connexion établie, nous avons accès à la machine virtuelle attribuée à l’utilisateur :

Revenir au plan : http://microsofttouch.fr/blogs/js/pages/microsoft-virtual-desktop-infrastructure-vdi-sous-tous-ses-angles.aspx

5. VDI : Ajout des machines virtuelles à l’infrastructure

Maintenant notre infrastructure est quasiment prête, il ne reste plus qu’à associer les machines virtuelles à un pool ou à un utilisateur en fonction du scénario que vous souhaitez mettre en œuvre.
Pour rappel dans le cadre de ma mise en pratique, je prends en compte les deux scénarios.
Dans un cas, je mets à disposition de tous les utilisateurs un pool de machines virtuelles Windows XP incluant Office 95. Dans l’autre cas, je mets à disposition d’utilisateurs externes, un bureau virtuel personnel sous Windows 7.

 5.1 Ajout de bureaux virtuels à un pool

Pour créer un pool de bureaux virtuels, connectez-vous au serveur Remote Desktop Connexion Broker. Ouvrez la console d’administration « Remote Desktop Connexion Manager » (Start => All Programs => Administration Tools => Remote Desktop Services => Remote Desktop Connexion Manager).

La console ouverte, cliquez droit le nœud « Remote Desktop Connexion Manager » et sélectionnez « Create Virtual Desktop Pool… ». L’assistant de création d’un pool de machines virtuelles s’ouvre. Lisez l’écran de bienvenue. Celui-ci vous avertit que la création d’un pool implique :

• Que toutes les machines virtuelles ajoutées au pool soient identiques (même configuration et applications)
• Que vous devez avoir préalablement ajouté le serveur RD Virtualization Host (ajouté dans la partie 3.4)

Sur l’écran « Select Virtual Machines », l’assistant liste l’ensemble des machines virtuelles disponibles sur les serveurs RD Virtualization Host ajoutés au serveur RD Connexion Broker.
Sélectionnez les machines virtuelles qui feront parties du pool. Maintenez la touche CTRL pour pouvoir bénéficier de la sélection multiple :

Sur la page « Set Pool Properties », définissez le nom du pool tel qu’il apparaitra aux utilisateurs et le numéro d’identification du pool (celui-ci n’accepte pas les caractères spéciaux) :

Conseil : Ne mettez pas de slash dans le nom du pool sous peine de perturber la récupération du flux RemoteApp and Remote Desktop Connections sur les clients Windows 7.

L’écran « Results » permet de valider les paramètres de configuration :

Une fois créée, la console « Remote Desktop Connexion Manager » affiche le pool, et les machines virtuelles incluses.

Cliquez sur « Change » en face de Virtual Desktop Pool Settings pour paramétrer le pool.
L’onglet « General » permet d’éditer le nom, l’identifiant. Vous pouvez aussi choisir d’afficher ou non le pool dans l’agrégateur de flux RemoteApp and Remote Desktop Connections de Windows 7.
Enfin, vous pouvez choisir d’opérer une sauvegarde automatique de la machine virtuelle si l’utilisateur est déconnecté ou a fermé la session

L’onglet « Common RDP Settings » permet de spécifier les paramètres RDP utilisés par le client lors de la connexion sur le bureau virtuel. Vous pouvez configurer les périphériques (imprimantes, périphériques Plug and Play…) et ressources (presse-papiers…)  que vous souhaitez attacher et partager au travers de la connexion au bureau virtuel. Il est possible de spécifier les paramètres d’affichage (couleurs, le comportement vis-à-vis d’un client disposant de plusieurs écrans…)

Enfin, l’onglet « Custom RDP Settings » permet de spécifier des paramètres additionnels. Vous pouvez par exemple désactiver le papier peint pour économiser la bande passante à l’aide du paramètre : « disable wallpaper :i :0 ».

Nous venons de créer et configurer notre pool de machines virtuelles Windows XP/Office 95.

 5.2 Assigner un bureau virtuel personnel à un utilisateur

Nous allons voir comment assigner une machine virtuelle à un utilisateur afin qu’il puisse s’en servir comme bureau virtuel personnel. Dans mon cas pratique, ceci doit servir aux utilisateurs externes pour accéder aux ressources (applications…) de l’entreprise.

Il existe deux moyens pour associer un utilisateur à un bureau virtuel personnel. Vous pouvez utiliser la console Active Directory Users and Computers ou Remote Desktop Connexion Manager.  

 5.2.1 Assigner un bureau virtuel personnel à un utilisateur

Connectez-vous au serveur Remote Desktop Connexion Broker. Ouvrez la console d’administration « Remote Desktop Connexion Manager » (Start => All Programs => Administration Tools => Remote Desktop Services => Remote Desktop Connexion Manager).

La console ouverte, ouvrez l’arborescence « Remote Desktop Connexion Manager => RD Virtualization Host Servers => Personnal Virtual Desktops » et sélectionnez « Assign a personnal virtual desktop » dans le panneau central. L’assistant d’assignation d’un bureau virtuel personnel s’ouvre. Sur le premier écran, lisez le rappel :

• Un utilisateur ne peut être assigné qu’à un seul bureau virtuel personnel à la fois.
• Une machine virtuelle ne peut être assignée qu’à un seul utilisateur à la fois.
• L’utilisateur et la machine virtuelle doivent bien entendu faire partie d’un domaine Active Directory de la forêt.
• Le nom de la machine virtuelle dans la console d’administration Hyper-V doit être le nom pleinement de domaine qualifié de la machine virtuelle (FQDN) sur le réseau (si besoin renommez-la)

Cliquez sur « Select User… » pour rechercher l’utilisateur auquel sera assigné la machine virtuelle. Dans la liste déroulante « Virtual machine », sélectionnez la machine virtuelle que vous souhaitez lui attribuer.

Sur l’écran suivant, confirmez les informations puis sur la page « Assignement Summary » vérifiez le succès de l’opération.

 5.2.2 Utilisation de la console Active Directory Users and Computers

Pour la console Active Directory Users and Computers, l’ajout ne peut se faire qu’au travers de la console apparentée à Windows Server 2008 R2.
Ouvrez la console « Active Directory Users and Computers » et les propriétés de l’utilisateur auquelles vous souhaitez assigner la machine virtuelle. Cliquez sur l’onglet « Personal Virtual Desktop ». Sur la page, cliquez sur « Browse » pour rechercher la machine ou entrez le FQDN.

Rappel : Le nom de la machine virtuelle dans la console d’administration Hyper-V doit être le nom de domaine pleinement qualifié de la machine virtuelle (FQDN) sur le réseau.

Revenir au plan : http://microsofttouch.fr/blogs/js/pages/microsoft-virtual-desktop-infrastructure-vdi-sous-tous-ses-angles.aspx

4. VDI : Préparation des machines virtuelles

La préparation des machines virtuelles est une étape importante lors de la mise en place d’une infrastructure VDI. Vous pouvez déployer les machines de plusieurs manières :

• Installer et paramétrer manuellement les X machines virtuelles que vous souhaitez mettre à disposition.  Cette méthode est de loin la plus longue et la moins pratique.
• Installer et paramétrer manuellement une machine virtuelle qui servira de modèle. Vous pouvez ensuite la syspreper pour la réutiliser pour les autres machines.

 4.1 Création de la machine virtuelle

Lors de l’élaboration des machines virtuelles, vous devez d’abord créer la machine sur la console Hyper-V. Lors de cette création vous devez lui donner un nom.

Conseil : Si vous souhaitez utiliser le mode VDI Bureaux virtuels personnels, entrez le nom de domaine pleinement qualifié de la machine comme nom de machine virtuelle.

Vous devez ensuite spécifier la mémoire allouée à la machine. Pour cela, je vous renvoie vers les recommandations de Microsoft. Ces recommandations sont à adapter en fonction de du scénario d’utilisation de la machine virtuelle. Si vous mettez à disposition des applications riches, il est conseillé d’allouer autant de mémoire que vous le feriez pour une machine physique.

Sur la configuration réseau, assurez-vous que la machine virtuelle soit en contact avec le reste de l’infrastructure incluant les clients, le serveur RD Connexion Broker, et le serveur RD Session Host.

Pour la configuration du disque vous pouvez adopter plusieurs stratégies :

• Attacher un disque virtuel de taille fixe : Cette solution est de loin la plus performante en matière d’I/O disque. Elle est cependant peu flexible puisque la taille est fixe et prise dès la création du disque. Ainsi une machine virtuelle n’utilisant que 3 GB d’un disque VHD de taille fixe 15 GB prendra bien la taille correspondante sur le disque dur de la machine. Notez qu’il est possible d’étendre manuellement le disque virtuel.
• Attacher un disque virtuel de taille dynamique, offre une solution flexible permettant d’assurer une marge à la machine virtuelle en terme d’espace disque offert. Ainsi, vous pouvez définir un disque de 50 GB pour une machine qui n’en utilisera pas plus de 30. 20 GB d’espace disque seront disponibles si nécessaire sans pour autant les allouer. Les disques virtuels dynamiques offrent cependant des performances d’entrées/sorties moins importantes que pour le disque de taille fixe. Certains experts déconseillent l’utilisation de ces disques pour des machines fortement sollicitées en environnement de production.
• Enfin la dernière solution permet d’économiser beaucoup d’espace disque. Le principe permet d’utiliser un disque différentiel. Ceci permet d’utiliser un disque virtuel en lecture seule comme base (ou parent) d’un ensemble de machines virtuelles et de répercuter les modifications opérées sur le disque  à un autre disque virtuel appelé disque différentiel. Le disque parent reste ainsi intact. Comme les fichiers du système d’exploitation restent communs à l’ensemble des machines ceci permet d’économiser un nombre significatif d’espace de stockage qui grossit exponentiellement en fonction du nombre de machines virtuelles utilisant un même disque. Si 5 machines utilisent un même disque de 3GB, c’est 12 GB d’économiser sur les deux autres scénarios. Cette méthode propose les moins bonnes performances I/O. Elle est donc dépréciée dans des environnements de production.

Une fois la machine virtuelle prête, installez le système d’exploitation souhaité par les différents moyens qui vous sont offerts (en utilisant le média d’installation, en utilisant une méthode de déploiement PXE…)

 4.2 Configuration des machines VDIs

L’utilisation de Microsoft VDI nécessite la configuration des machines virtuelles afin de permettre leurs accès aux utilisateurs.

1. Commencez déjà par installer les composants additionnels d’Hyper-V si vous mettez en place des machines Windows XP et Windows Vista.
   
   
2. Joignez le domaine Active Directory de votre entreprise. Notez que si vous souhaitez syspréper la machine et l’utiliser comme modèle pour d’autres machines, celle-ci ne doit pas être jointe au domaine. Vous pouvez la joindre pour opérer les différentes configurations puis la retirer du domaine pour la syspreper.
   
   
3. Installez les différentes mises à jour de sécurité relative à la politique de votre entreprise.
   
   
4. Importez ensuite le certificat SSL du serveur Remote Desktop Web Access précédemment exporté.
   Pour cela ouvrez la console d’administration de Microsoft (MMC) et chargez le composant « Certificates » pour l’ordinateur local. Vous pouvez aussi utiliser la commande « certmgr.msc ».
   Ouvrez l’arborescence « Certificates => Trusted Root Certification Authority => Certificates ». Cliquez droit et sélectionnez « All Tasks => Import … ». Importez le certificat en suivant l’assistant :
   
   





5. Activer ensuite la fonctionnalité de Bureau à distance. Cliquez sur le menu Démarrer et ouvrez le Panneau de Configuration. Ouvrez « Système » et dans le menu de gauche, sélectionnez « Paramètres d’utilisation à distance ». Sélectionnez :
   

   • « Autoriser les connexions des ordinateurs exécutant n’importe quelle version de Bureau à distance » pour autoriser toute personne utilisant une version quelconque de Bureau à distance (RDC) à se connecter à votre ordinateur. Ceci est à sélectionner si des ordinateurs Windows XP doivent se connecter à la machine et qu’ils ne disposent pas du client RDC 6.1.
     
   • « Autoriser uniquement les connexions provenant d’ordinateurs exécutant Bureau à distance avec authentification réseau » pour autoriser toute personne dont l’ordinateur exécute des versions de Bureau à distance avec authentification réseau  (RDC 6.1 ou plus) à se connecter à votre ordinateur. Cette option est plus sécurisée que la précédente puisqu’elle utilise NLA.



6. Activation de Remote Procedure Call (RPC) pour RDS. Ouvrez la base de registre en exécutant la commande « regedit ». Naviguez dans l’arborescence « HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TerminalServer ». Ajoutez ou modifiez l’entrée de registre « AllowRemoteRPC » de type DWORD et placez la valeur à 1.
   



7. Ajoutez des exceptions au firewall pour permettre la prise de contrôle de la machine.
   Pour cela sur Windows 7 et Windows Vista, ouvrez le panneau de configuration de la machine et sélectionnez « Outil d’administration ». Ouvrez le « Pare-feu Windows avec fonctions avancées de sécurité » ou « Windows Firewall with Advanced Security ».
   Ajoutez une règle entrante prédéfinie « Remote Service Management » :
   

   

   
   Confirmez les règles crées :
   
   

   

   
   Puis définissez l’action « Allow the connection » :
   
   

   

   
   Ajoutez aussi une règle entrante prédéfinie « Remote Desktop » avec une action « Allow the connection »  :
   
   

   

   
   Pour Windows XP, passez par le panneau de configuration et la fenêtre « Pare-feu Windows ». Autorisez les connexions Remote Desktop. Pour activer l’exception pour « Remote Service Management » communément appelé « Remote Administration », ouvrez une invite de commande et tapez la ligne de commande « netsh firewall set service type = remoteadmin mode = enable »
   Note : Vous pouvez aussi définir la majorité de ces paramètres par GPO.
   

1. Ajoutez ensuite les utilisateurs ou groupes d’utilisateurs autorisés à se connecter en bureau à distance au groupe local « Remote Desktop Users » de la machine virtuelle.
   Pour cela, ouvrez le panneau de configuration de la machine et sélectionnez « Outil d’administration » puis « Computer Management ». Dans la colonne de gauche, parcourez l’arborescence « Computer Management => System Tools => Local Users and Groups => Groups ». Ouvrez les propriétés du groupe de sécurité local « Remote Desktop Users ». Ajoutez les utilisateurs ou groupes d’utilisateurs autorisés à se connecter aux machines. Dans le cadre de mon organisation, j’ai défini deux groupes « External Users Group » et « WindowsTouch Users Group » :
   
   

   

2. Enfin, nous devons ajouter les permissions pour le protocole RDP au compte ordinateur du serveur Remote Desktop Virtualization Host. Il nécessite les permissions « WINSTATION_QUERY », « WINSTATION_LOGOFF », et « WINSTATION_DISCONNECT ». Ces permissions lui permettent de contrôler l’état de la machine.
   Pour cela sur Windows Vista et Windows 7, exécutez les lignes de commande suivantes :

   « wmic /node:localhost RDPERMISSIONS where TerminalName="RDP-Tcp" CALL AddAccount "contoso\rdvh-srv$",1 »

   « wmic /node:localhost  RDACCOUNT where "(TerminalName='RDP-Tcp' or TerminalName='Console') and AccountName='<NOM_DE_DOMAINE>\\<NOM_DU_SERVEUR_RDSVH>$'" CALL ModifyPermissions 0,1 »

   « wmic /node:localhost RDACCOUNT where "(TerminalName='RDP-Tcp' or TerminalName='Console') and AccountName=<NOM_DE_DOMAINE>\\<NOM_DU_SERVEUR_RDSVH>$'" CALL ModifyPermissions 2,1 »

   « wmic /node:localhost RDACCOUNT where "(TerminalName='RDP-Tcp' or TerminalName='Console') and AccountName=<NOM_DE_DOMAINE>\\<NOM_DU_SERVEUR_RDSVH>$'" CALL ModifyPermissions 9,1 »

   Où <NOM_DE_DOMAINE> correspond au nom de domaine (exemple : WINDOWSTOUCH) et <NOM_DU_SERVEUR_RDSVH> doit être remplacé par le nom d’hôte du serveur hébergeant le rôle Remote Desktop Virtualization Host (exemple : dans mon cas JS-PC-SERVER)

   
   
   

   

   
   Sur Windows XP, l’alias RDACCOUNT n’est pas connu. Vous devez donc utiliser le script VBS suivant :
    

    set objWMI = GetObject("winmgmts:\\.\root\cimv2")

   set colItems = objWMI.ExecQuery("Select * from Win32_TSPermissionsSetting")

   for each objItem in colItems

      intRC = objItem.AddAccount("%DOMAIN% \%ACCOUNT%", 1)

      if intRC then

         WScript.Echo "Error adding " & strAccount & " to " & _

                      objItem.TerminalName

      else

         WScript.Echo "Successfully added " & strAccount & " to " & _

                      objItem.TerminalName

      end if

   next

    

   set objWMI = GetObject("winmgmts:\\.\root\cimv2")

   set colItems = objWMI.ExecQuery ("Select * from Win32_TSAccount Where AccountName='%DOMAIN%\\%ACCOUNT%'")

   for each objItem in colItems

       intRC = objItem.ModifyPermissions(0,True)

       intRC = objItem.ModifyPermissions(2,True)

       intRC = objItem.ModifyPermissions(9,True)

       if intRC then

          WScript.Echo "Error setting permissions for " & strAccount

       else

          WScript.Echo "Set permissions for " & strAccount

       end if

   next

   
   Il suffit ainsi de remplacer %DOMAIN% par votre nom de domaine et %ACCOUNT% par le nom de la machine qui héberge le service Remote Desktop Virtualization Host.
   
   Redémarrez ensuite le service Remote Desktop en utilisant les commandes :
   « net stop termservice »
   « net start termservice »
   
   

   

1. Vous pouvez ensuite installer les différentes applications que vous souhaitez mettre à disposition de l’utilisateur. Dans mon cas, j’installe Office 95 sur les machines Windows XP et Office 2010 sur les machines virtuelles Windows 7.

La configuration de la machine virtuelle est entièrement faite, vous pouvez l’éteindre ou la syspréper pour s’en servir de modèle. N’oubliez pas que vous devez retirer la machine du domaine avant de la syspréper. Vous pouvez ensuite copiez le VHD dans un répertoire de sauvegarde ou alors capturer la machine sous la forme d’une image Wim déployable par un système de déploiement de système d’exploitation comme Windows Deployment Services et System Center Configuration Manager.

 4.3 Configuration automatique des machines VDIs

Il est possible d’automatiser l’ensemble des tâches de configuration du système d’exploitation de la machine virtuelle en utilisant un script créé par les équipes de Microsoft. Vous devez tout de même installer le système d’exploitation, le joindre au domaine, installer les différentes mises à jour de sécurité, et importer le certificat du serveur Remote Desktop Web Access.

Microsoft met à disposition son script dans deux langages :

• VB Script : http://gallery.technet.microsoft.com/ScriptCenter/en-us/68462b23-0890-4dbd-95b6-8de5763e4f68
• PowerShell : http://gallery.technet.microsoft.com/ScriptCenter/en-us/bd2e02d0-efe7-4f89-84e5-7ad70f9a7bf0
  Note: vous devez installer le package PowerShell sur Windows XP si vous utilisez le script correspondant.

Ces scripts permettent de configurer (firewall, permissions RDP, activation de Remote Desktop, activation de RPC …) une machine cible en spécifiant son nom et les identifiants d’accès.

 4.4 Activation de la fonctionnalité Rollback

Une fonctionnalité intéressante de Microsoft VDI permet de restaurer les machines virtuelles mises à disposition des utilisateurs dans un état spécifique défini par l’administrateur. Cette fonctionnalité prend tout son sens dans le scénario de mise à disposition d’un pool de bureaux virtuels. En effet, dans ce cas précis, l’administrateur souhaite que les machines virtuelles restent semblables. Il est primordial de pouvoir s’assurer que toutes les opérations (création de documents …) effectuées par un utilisateur, ne seront pas disponibles lors de la connexion d’un autre utilisateur après la déconnexion du précédent.

Pour cela, après avoir opérer l’ensemble des configurations des machines virtuelles (installation d’applications, configuration pour VDI …), ouvrez la console d’administration Hyper-V.
Cliquez droit sur la machine virtuelle cible et sélectionnez « Snapshot ». Le Snapshot permet de créer  un cliché de l’état (configuration, mémoire …) de la machine virtuelle à un instant donné.
Dans le sous panneau central, cliquez droit sur Snapshot précédemment créé et renommez-le « RDV_Rollback » :

Attention : Vous êtes obligé d’utiliser le nom RDV_Rollback pour que le mécanisme automatique du serveur Remote Desktop Virtualization Host fonctionne.

Ainsi dans la pratique, une fois que l’utilisateur aura terminé ses opérations et qu’il se sera déconnecté de la session bureau à distance, le serveur Remote Desktop Virtualization Host appliquera ce snapshot afin de remettre la machine virtuelle dans son état avant la connexion de l’utilisateur.

 4.5 Automatisation de la création des machines virtuelles

Derrière la notion de VDI, il y a d’importants processus à mettre en œuvre et la gestion d’un parc de bureaux virtuels de plus de 100 machines peut vite devenir fastidieuse. Ainsi la simple opération de mettre à disposition une machine virtuelle disponible au travers d’un pool de bureaux virtuels ou d’un bureau virtuel personnel nécessite l’accès à la console d’administration Hyper-V du serveur sur lequel on souhaite créer la machine. Il est ensuite nécessaire de dérouler les différents assistants de création. Ces longues étapes ne représentent pas grand-chose quand il s’agit de provisionner une machine mais ceci devient différent quand on doit le faire pour 50 machines sur 5 serveurs différents. Pour cela, Microsoft offre différents outils d’administration comme System Center Virtual Machine Manager.

 4.5.1 Utilisation d’un script de création automatique

La première étape d’optimisation est l’utilisation d’un script permettant d’opérer simplement les tâches que l’on ferait au travers d’une interface graphique comme l’assistant de création d’une machine virtuelle Hyper-V. L’équipe Remote Desktop a donc mis à disposition un script permettant de créer une machine virtuelle pour l’infrastructure VDI.

Avant d’ajouter la machine, vous devez disposer d’un disque virtuel (VHD) sysprépé et configuré pour VDI comme spécifié précédemment.

Accéder au script Powershell « Create virtual machines for VDI » : http://gallery.technet.microsoft.com/ScriptCenter/en-us/904bd2c8-099d-4f27-83da-95f5536233bc

Vous pouvez ensuite utiliser le script avec les commutateurs suivants :
Create-Virtualmachine.ps1 -UserFile <String> -VHDTemplate <String> -OSVersion <String> -Pool <String> -VMCount <UInt32> -AdminPassword <String> -DomainJoinUsername <String> -DomainJoinPassword <String> [-MemorySize <UInt32>] [-NICNetwork <String>] [-VHDDestinationMapFile <String>] [-MachineNameFormat <String>] [-ProductKey <String>] [-HyperVServer <String[]>] [-SharedLogPath <String>] [-Inquire] [-Credential <PSCredential>] [<CommonParameters>]

 4.5.2 Gestion avec System Center Virtual Machine Manager 2008 R2

Le but de cette partie n’est pas de vous présenter System Center Virtual Machine Manager (SCVMM) 2008 R2 mais de vous montrer comment utiliser cet outil pour administrer une solution VDI. Par-delà ses fonctionnalités permettant de manager les différents hôtes et machines virtuelles de l’environnement, il offre aussi un portail en libre-service à destination des utilisateurs. Ce portail est en adéquation directe avec la notion de pool VDI.
Nous ne détaillerons pas l’installation du produit et de sa console. Je vous rappelle les pré requis d’installation :

 Pour cela, je vous renvoie vers la documentation de Microsoft : http://technet.microsoft.com/fr-fr/library/cc917964.aspx

Une fois le serveur VMM installé, ouvrez la console d’administration et ajoutez les différents hôtes Hyper-V à la console.

Ajout d’un modèle de machine virtuelle

Nous allons commencer par ajouter un modèle de machine virtuelle. Pour cela, cliquez sur la partie « Library » et ajoutez un profil de matériel en cliquant sur « New Hardware Profile »

Une fois l’assistant ouvert, entrez le nom du profil et le propriétaire. Puis ouvrez l’onglet « Hardware Settings ». Dans cet onglet, configurez la partie matérielle pour la création d’une machine virtuelle de type VDI. Entrez la mémoire, la carte réseau et le réseau nécessaire :

Une fois le profil matériel créé, cliquez sur « New Template » pour lancer la création d’un modèle de machine virtuelle.

Sur l’écran « Select Source », sélectionnez un disque VHD contenu dans la librairie (celui-ci doit être sysprépé) ou une machine virtuelle sur un hôte Hyper-V.

Attention : La machine virtuelle qui est utilisée pour créer le modèle, sera automatiquement détruite. SCVMM conseille de créer un clone de la machine avant de commencer la création.

A l’étape « Template Identity », entrez le nom du modèle, le propriétaire et une description :

Sur la page « Configure Hardware », sélectionnez le profil matériel précédemment créé.

Sur la page « Guest Operating System »,  entrez les informations d’identification, le mot de passe administrateur local, la clé produit, la zone de temps, le système d’exploitation de la machine, les informations de connexion à un domaine ou à un workgroup :

Enfin sélectionnez la librairie et le chemin de stockage du modèle :

Validez le résumé et lancez la création.

Installation du portail en libre-service

Vous devez commencer par installer les pré requis suivants :

• Pour Windows Server 2003, vous devez ajouter le composant Windows Server IIS 6.0.
• Pour Windows Server 2008 ou 2008 R2, vous devez ajouter le rôle Serveur Web (IIS), puis installer les services de rôle serveur suivants :
  • Compatibilité avec la méta base de données IIS 6
  • Compatibilité WMI d’IIS 6
  • Contenu statique
  • Document par défaut
  • Exploration de répertoire
  • Erreurs HTTP
  • ASP.NET
  • Extensibilité .NET
  • Extensions ISAPI
  • Filtres ISAPI
  • Filtrage des demandes

Ouvrez ensuite l’installeur de System Center Virtual Machine Manager 2008 R2 et sélectionnez « VMM Self-Service Portal » :

Passez les étapes de vérification des pré requis et spécifiez le chemin d’installation :

Paramétrez les informations liées au serveur Web (Nom du serveur VMM, port de communication, port de communication avec IIS…) :

Confirmez le résumé pour lancer l’installation. Une fois l’installation terminée, vérifiez que tout a eu lieu avec succès :

Création des rôles d’accès au portail

L’étape qui suit permet de créer les autorisations nécessaires d’accès au portail en libre-service.
Ceci va permettre de créer plusieurs niveaux d’authentification allant du niveau d’administration, d’administration déléguée, ou utilisateurs en libre-service.
Ouvrez la console d’administration de SCVMM et cliquez sur la partie « Administration ».
Choisissez ensuite d’ouvrir le nœud « User Role » et cliquez sur « New user role » :

Entrez le nom du rôle utilisateur et sélectionnez le profil adéquat. Dans notre cas, nous souhaitons donner l’accès aux utilisateurs VDI à un portail d’accès leur permettant de créer une machine virtuelle, sélectionnez donc « Self-Service User » :

Sur la page suivante, ajoutez les membres et groupes que vous souhaitez associer à ce rôle :

Sur la page « Select Scope », sélectionnez les groupes d’hôte sur lesquels les machines virtuelles des utilisateurs seront déployées :

Sur l’écran « Virtual Machine Permissions », sélectionnez les actions que vous souhaitez rendre disponible aux utilisateurs (Démarrer, Arrêter, Eteindre, Mettre en pause et résumer, créer et gérer des checkpoints, supprimer la machine, la connexion à distance, Donner les droits d’administrateur local) :

A l’étape « Virtual Machine Creation Settings », sélectionnez “Allow users to create a new virtual machines” pour permettre aux utilisateurs de créer eux même des machines virtuelles. Vous pouvez ajouter des modèles par rapport à ceux que vous avez créés. Enfin vous pouvez définir un quota afin de limiter la création. Le quota peut être commun à tous les utilisateurs faisant parti du rôle ou alors attribué à chacun des utilisateurs :

Enfin, sélectionnez « Allow users to store virtual machines in a library » pour stocker les machines virtuelles de l’utilisateur dans la librairie SCVMM.

Sur l’écran « Summary » , cliquez sur « Create » pour lancer le script Powershell et créer le rôle.

Expérimentation du portail en libre-service

Accédez à l’adresse Internet du serveur hébergeant le portail System Center Virtual Machine Manager. Connectez-vous à l’aide des identifiants d’un des utilisateurs appartenant au rôle (Self-Service Users) défini plus tôt :

Une fois le portail chargé, cliquez sur « Nouvel Ordinateur ».
La fenêtre de création s’ouvre, sélectionnez le modèle. Entrez les informations nécessaires comme le nom de l’ordinateur, le nom de la machine virtuelle, le mot de passe administrateur ou la clé produit. On peut aussi observer sur cette fenêtre le nombre de machines virtuelles disponibles en fonction du quota défini à l’utilisateur.

Une fois les informations entrées, cliquez sur « Créer » pour initier la création.

Une fois la création terminée (cette opération peut prendre plusieurs minutes), l’utilisateur peut démarrer la machine et opérer les différentes actions nécessaires à son utilisation :

Le but de cette partie était de vous présenter les différents moyens nécessaires à la création d’une machine virtuelle de manière plus ou moins automatique. L’utilisation du portail en libre-service de System Center Virtual Machine Manager est une bonne technologie puisqu’elle laisse la main à l’utilisateur ou aux opérateurs. On peut cependant regretter que VDI ne soit pas aussi bien intégré à la technologie. En effet une fois la machine virtuelle créée, celle-ci est associée à l’utilisateur dans SCVMM mais pas dans Active Directory et dans l’environnement VDI. Ainsi la machine virtuelle n’est pas réellement intégrée dans l’environnement VDI, ni associée comme bureau virtuel personnel de l’utilisateur (Il en est de même pour les pools de machines virtuelles).

Revenir au plan : http://microsofttouch.fr/blogs/js/pages/microsoft-virtual-desktop-infrastructure-vdi-sous-tous-ses-angles.aspx

3. VDI : Configuration des rôles

L’installation de tous les rôles étant terminée, nous allons pouvoir passer à la configuration de ceux-ci. Notez que certains rôles (RD Virtualization Host, RD Session Host) ne nécessitent pas de configuration particulière.

 3.1 Configuration du rôle Hyper-V

Commençons par la configuration de l’hyperviseur hébergeant les machines virtuelles.
Ouvrez la console Hyper-V Manager et sélectionnez dans la barre d’action « Hyper-V Settings ».
Configurez les répertoires de stockage des disques virtuels et des machines virtuelles (fichiers de configurations)

Vous pouvez aussi configurer les autres paramètres comme le raccourci de libération de la souris, ou les comportements vis-à-vis des informations d’authentification.

Toujours sur la console Hyper-V Manager, sélectionnez dans la barre d’action « Virtual Network Manager ». A l’aide de ce gestionnaire, créez les différents réseaux dont vous avez besoin pour l’infrastructure (externe, interne ou privé). Vous allez notamment devoir créer un réseau Externe pour que les machines virtuelles puissent communiquer avec le reste du réseau.

 3.2 Ajout des permissions au serveur Web Access sur le serveur Connexion Broker

Avant de continuer et ce afin que le serveur RD Web Access puisse interagir et configurer le serveur RD Connexion Broker, nous allons devoir ajouter le compte ordinateur du serveur RD Web Access au groupe de sécurité local TS Web Access Computers du serveur RD Connexion Broker.

Pour cela, connectez-vous au serveur RD Connexion Broker.
Ouvrez le panneau de configuration, choisissez « Administrative Tools » puis sélectionnez « Computer Management ».
La console « Computer Management », cliquez sur « Local Users and Groups » puis « Groups ».
Cliquez sur le groupe « TS Web Access Computers », ajoutez le compte ordinateur du serveur RD Connexion Broker :

 3.3 Configuration du rôle Remote Desktop Web Access

L’objectif de cette partie est de configurer le rôle Remote Desktop Web Access pour un fonctionnement dans le cadre de l’infrastructure VDI.

Avant de se lancer dans la configuration de RD Web Access, nous allons exporter le certificat de la machine afin que celui-ci puisse être ajouté sur les différents clients. Ceci permettra aux différents de clients d’approuver le portail RD Web Access. Néanmoins, ceci n’est pas à appliquer si vous avez choisi le scénario d’utilisation d’un certificat issue d’une autorité de certification publique ou si vous avez utilisé votre autorité de certification interne et approuvée par les clients.

Connectez-vous au serveur Remote Desktop Web  Access, ouvrez la console d’administration Microsoft (MMC). Ajoutez le composant enfichable « Certificates ». Choisissez d’administrer les certificats du compte ordinateur :

Le composant chargé, développez l’arborescence « Certificates => Personal => Certificates ».
Cliquez droit sur le certificat de la machine (portant son FQDN) et sélectionnez « All Tasks => Export … ».

L’assistant d’export du certificat s’ouvre, passez l’écran de bienvenue.
Passez l’écran « Export Private Key » en vous assurant que l’option « No, do not export the private key » est sélectionnée.

Sur la page « Export File Format », sélectionnez « DER encodaged binary X.509 (.CER) » et passez à l’étape suivante :

Sur l’écran « File to Export », sélectionnez le chemin et nom du certificat exporté. Puis terminez l’export en sélectionnant « Finish ».

Une fois le certificat exporté, gardez-le de côté pour la suite de l’implémentation.

Nous allons maintenant configurer une source pour le serveur Remote Desktop Web Access.

Cliquez sur Démarrer puis Administrative Tools, choisissez Remote Desktop Services et ouvrez Remote Desktop Web Access Configuration.
Internet Explorer s’ouvre avec l’accès au portail RD Web Access, cliquez sur Continue to this website (not recommended).

Entrez les identifiants de connexion de l’administrateur du domaine. Sur la page principale, sélectionnez l’onglet Configuration.
Sélectionnez ensuite « An RD Connection Broker server » et entrez dans le cadre « Source name » le nom NetBIOS ou de domaine pleinement qualifié de la machine hébergeant le rôle RD Connexion Broker.

Cliquez sur OK pour confirmer. Cette opération aura pour effet de configurer le portail d’accès mais aussi le serveur Remote Desktop Connexion Broker pour lui spécifier la machine servant de portail d’accès.

 3.4 Configuration du rôle Remote Desktop Connexion Broker

L’étape qui suit va nous permettre de configurer le rôle Remote Desktop Connexion Broker afin qu’il puisse opérer dans le cadre de bureaux virtuels offerts par Microsoft VDI.
Pour cela, connectez-vous au serveur hébergeant ce rôle et ouvrez la console d’administration « Remote Desktop Connexion Manager » (Start => All Programs => Administration Tools => Remote Desktop Services => Remote Desktop Connexion Manager).

La console ouverte, cliquez droit le nœud « Remote Desktop Connexion Manager » et sélectionnez « Configure Virtual Desktops… ».
L’assistant de configuration des bureaux virtuels s’ouvre, lisez attentivement l’écran « Before You Begin ».

A l’étape « Secify an RD Virtualization Host Server », entrez le nom d’hôte du serveur Hyper-V hébergeant le rôle Remote Desktop Virtualization Host et cliquez sur « Add » :

Ajoutez autant de serveurs Hyper-V qu’il faut pour votre infrastructure. Ceci dépend du nombre de bureaux virtuels que vous souhaitez mettre à disposition.

Sur l’écran « Configure Redirection Settings », nous devons entrer les informations sur le serveur servant à spécifier le serveur RD Session Host.
Avant de compléter cet écran, si vous souhaitez rendre disponible la fonctionnalité pour les clients utilisant Remote Desktop Connection (RDC) 6.1, nous allons devoir configurer un nom alternatif à ce serveur.

Pour cela, accédez à la console de votre serveur DNS (DNS Manager).
Ajoutez un enregistrement de type Alias (CNAME) pour le serveur Remote Desktop Session Host (dans mon cas WT-RDSSH) en spécifiant un nom alternatif. Personnellement, j’ai choisi WT-TSSH pour TerminalServerSessionHost.

Une fois cette configuration faite, revenez à l’assistant de configuration sur le serveur RD Connexion Broker. Dans le champ « Server Name », entrez le nom de domaine pleinement qualifié (FQDN) de votre serveur Remote Desktop Session Host.
Si vous disposez de clients utilisant Remote Desktop Connection (RDC) 6.1, cochez « Enable redirection for earlier RDC versions » et spécifiez le nom alternatif précédemment configuré.

Enfin dans le cadre « Automatic Configuration », assurez-vous que la case « Do not automatically configure » pour que l’assistant configure automatiquement le serveur Remote Desktop Session Host en mode redirection. Si vous souhaitez faire cette manipulation manuellement, je vous renvoie vers la documentation Technet.

Rappel : Notez qu’un serveur Remote Desktop Session Host servant dans le cadre de VDI en mode redirection ne peut pas servir des sessions d’accès aux applications hébergées sur ce même serveur.

L’étape « Specify an RD Web Access Server » ne nécessite aucune opération puisque la spécification du portail Web Access sur le serveur RD Connexion Broker a été opéré dans la sous partie précédente. Néanmoins, si vous n’avez pas suivi mes indications précédentes, vous pouvez spécifier le nom du serveur RD Web Access. Je vous invite aussi à vous reporter à la sous partie précédente pour configurer les permissions d’accès au serveur RD Web Access.

Enfin sur l’écran « Confirm Changes », confirmez la configuration en cliquant sur « Apply » 

Sur la page de résumé, assurez-vous que tous les paramétrages sont au vert et cliquez sur « Finish »

 3.5 Organisation de l’annuaire Active Directory

Faisons un point côté Active Directory, cette partie est purement écrite à titre informatif.
J’ai organisé la chose de la façon suivante :

Je dispose d’une unité d’organisation par site.
Chaque site contient un dossier Groups, Servers, Users, Workstations. Le dossier Servers contient un dossier RDS contenant tous les serveurs disposant d’un rôle RDS. Le conteneur Workstations contient une unité d’organisation « VDI VMs ». Ce même conteneur dispose de deux unités d’organisation pour chaque type de système d’exploitation. Le but est bien entendu de séparer les machines virtuelles VDI du reste des postes de travail en les différenciant par le système d’exploitation qu’elles proposent.

J’ai créé une GPO pour distribuer le certificat de la machine RD Web Access aux postes de travail de mon organisation afin qu’ils n’aient pas de problème avec le certificat lors de l’utilisation du portail.
J’ai aussi créé une GPO pour les machines virtuelles VDI afin d’autoriser les connexions Remote Desktop à travers le Firewall et ce pour le Firewall avancé de Windows 7 et le Firewall « classic » de Windows XP.

 3.6 Personnalisation de RD Web Access

Connectez-vous au serveur Remote Desktop Connexion Broker. Ouvrez la console d’administration « Remote Desktop Connexion Manager » (Start => All Programs => Administration Tools => Remote Desktop Services => Remote Desktop Connexion Manager).

La console ouverte, ouvrez l’arborescence « Remote Desktop Connexion Manager » et sélectionnez « Change » dans la partie « Properties » en face de « Display Name ». La fenêtre des propriétés de RemoteApp and Desktop Connection s’ouvre, changez le nom d’affichage en spécifiant le nom de votre entreprise :

Vérifiez que le nom de domaine pleinement qualifié (FQDN) est entré dans le champ « Connection ID ».

Dans l’onglet « RD Web Access », vérifiez que les serveurs Remote Desktop Web Access sont bien présents dans la liste. Vous pouvez ajouter des serveurs RD Web Access selon vos besoins pour pouvoir leur donner les informations nécessaires (pool de bureaux virtuels, bureaux virtuels personnels…) à l’accès des ressources.

 3.7 Configurations des bureaux virtuels

Nous allons voir comment configurer les différentes options concernant les bureaux virtuels.
Pour cela, connectez-vous au serveur Remote Desktop Connexion Broker. Ouvrez la console d’administration « Remote Desktop Connexion Manager » (Start => All Programs => Administration Tools => Remote Desktop Services => Remote Desktop Connexion Manager).

La console ouverte, ouvrez l’arborescence « Remote Desktop Connexion Manager => RD Virtualization Host Servers». Cliquez droit sur «RD Virtualization Host Servers » et sélectionnez « Create Virtual Desktop Pool ». La fenêtre de propriétés des bureaux virtuels s’ouvre.
Sur l’onglet « Redirection Settings », vérifiez que le nom de serveur correspond au nom de domaine pleinement qualifié du serveur RD Session Host. Vous pouvez aussi spécifier un nom alternatif pour permettre le support des clients RDC 6.1 ou moins.

L’onglet « RD Gateway Settings » permet de spécifier les paramètres liés à la passerelle Remote Desktop (RD Gateway). Vous pouvez détecter automatiquement les paramètres du serveur RD Gateway ou spécifier les paramètres manuellement :

Enfin, l’onglet « Digital Signature » permet de signer le fichier RDP communiqué aux clients (par le biais du portail Web Access ou de l’agrégateur de flux RemoteApp and Remote Desktop Connections). Ceci ajoute une sécurité supplémentaire à votre infrastructure. Vous devez ensuite ajouter l’empreinte digitale du certificat afin qu’elle soit approuvée par les clients du domaine.

Note : Pour ajouter l’empreinte digitale du certificat, vous pouvez utiliser le paramètre de stratégie de groupe « Specify SHA1 thumbprints of certificates representing trusted .rdp publishers » accessible par l’arborescence « Computer Configuration\Policies\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Connection Client » de la console d’administration des stratégies de groupe (GPMC)

Revenir au plan : http://microsofttouch.fr/blogs/js/pages/microsoft-virtual-desktop-infrastructure-vdi-sous-tous-ses-angles.aspx

2. VDI : Installation de l’infrastructure

Dans mon cas l’implémentation de l’infrastructure n’a pas été chose facile. Les différents besoins nécessaires à son installation m’ont demandé de jongler avec la seule et unique machine que j’avais à ma disposition. J’ai donc réussi à faire fonctionner tous les rôles sur une même machine.
Celle-ci était équipée de Windows Server 2008 R2 avec le rôle Hyper-V. Le but était ensuite de créer 7 machines virtuelles. Quatre m’ont servi à héberger les rôles nécessaires à l’infrastructure :

• WT-ADDHCP : héberge l’annuaire Active Directory, l’infrastructure DNS et DHCP.
• WT-RDSSH héberge le rôle Remote Desktop Services Session Host
• WT-RDSCB héberge le rôle Remote Desktop Services Connexion Broker
• WT-RDSWA accueille le rôle Remote Desktop Services WebAccess

Quatre autres machines virtuelles sont créées pour accueillir les bureaux virtuels :

• Deux machines virtuelles servant pour le pôle de machines Windows XP
• Deux machines virtuelles sous Windows 7 sont attribuées à des utilisateurs externes.

Enfin le dernier rôle Remote Desktop Services Virtualization Host est hébergé sur ma machine physique hébergeant aussi le rôle Hyper-V. Cette machine est reliée par une interface Loopback au reste de mon infrastructure sous environnement virtuel.

Note : Nous ne détaillerons pas l’installation de l’infrastructure Active Directory, DNS et DHCP.

 2.1 Considérations et pré requis

Microsoft VDI demande un certains nombres de pré requis nécessaire à son implémentation.
Vous devez par exemple bénéficier d’une machine physique suffisamment puissante pour pouvoir héberger les différentes machines virtuelles. Cette machine doit pouvoir supporter la virtualisation matérielle et l’exécution d’instruction de virtualisation.

D’un point de vue logiciel, nous vous conseillons l’utilisation de Windows Server 2008 R2 pour le rôle Hyper-V. Ceci vous permettra de suivre entièrement l’article et de bénéficier de la fonctionnalité Live Migration offerte par cette nouvelle version.

L’installation des différents rôles Remote Desktop Services nécessitent Windows Server 2008 R2. Terminal Services n’est donc pas supporté pour la mise en œuvre de Microsoft VDI.

Enfin si vous souhaitez mettre en œuvre un scénario de Bureau Virtuel Personnel (Personal Virtual Desktops), vous devez prendre en considération les pré requis Active Directory suivants :

• Le niveau fonctionnel de domaine doit être au minimum « Windows 2000 Server native mode ». Les niveaux fonctionnels « Windows 2000 Server mixed mode » et « Windows Server 2003 interim mode » ne sont pas supportés pour ce scénario.
• Si vous souhaitez pleinement bénéficier des fonctionnalités d’attribution des machines virtuelles le schéma de votre forêt Active Directory doit être au moins « Windows Server 2008 »

Note : le scénario pool de machines virtuelles n’est pas soumis à des prérequis Active Directory.

 2.2 Installation du rôle Hyper-V

La première brique de cette infrastructure est l’hyperviseur de Microsoft : Hyper-V.
Disponible avec Windows Server 2008 et Windows Server 2008 R2, il permettra de provisionner les environnements virtuels nécessaires à la mise à disposition des postes de travail.
Nous l’avons vu précédemment, le Service Pack 1 de Windows Server 2008 R2 apporte des nouveautés en relation avec la notion de VDI. Ainsi, il est conseillé d’implémenter le Service Pack 1 de Windows Server 2008 R2 dans votre infrastructure VDI pour donner accès à une expérience utilisateur évoluée et à une configuration plus fine des besoins en mémoire. Nous aborderons sa mise en œuvre plus tard dans l’article.

Installer le système d’exploitation de votre choix et configurez le serveur (nom, réseau) selon vos besoins.
Une fois ces configurations préliminaires opérées, ouvrez la console « Server Manager ».
Cliquez sur « Roles » et choisissez « Add Roles ».
L’assistant d’ajout d’un rôle s’ouvre, passez la première page et côchez ensuite le rôle « Hyper-V » :

Sur l’écran « Virtual Networks », sélectionnez les cartes réseaux que vous souhaitez utiliser pour permettre aux machines virtuelles de communiquer avec le reste de l’infrastructure.

Sur la page suivante, cliquez sur « Install » pour confirmer l’installation.
A l’issue de l’installation, un redémarrage est nécessaire.

 2.3 Installation du rôle Remote Desktop Session Host

Après avoir mis en place l’hyperviseur qui nous servira d’hôte pour les machines virtuelles, nous allons mettre en place le rôle Remote Desktop Session Host. Pour rappel, son but est de gérer les sessions d’utilisateur. Il sera utilisé dans un mode redirection (redirecteur) afin de rediriger les connexions RDP aux machines virtuelles.

Installer Windows Server 2008 R2 sur la machine et configurez (nom d’hôte, réseau …) le serveur selon vos besoins.

Une fois ces configurations préliminaires opérées, ouvrez la console « Server Manager ».
Cliquez sur « Roles » et choisissez « Add Roles ».
L’assistant d’ajout d’un rôle s’ouvre, passez la première page et côchez ensuite le rôle « Remote Desktop Services » :

Sur l’écran permettant le choix des services à installer, choisissez « Remote Desktop Session Host » :

Passez l’écran « Application Compatibility », l’avertissement ne concerne pas VDI puisque le serveur sera dans un mode redirecteur.
Sur la page « Authentication Method » choisissez l’authentification qui vous convient. Pour des raisons de sécurité, il est vivement conseillé d’utiliser « Network Level Authentication ». Attention cette authentification n’est pas supportée nativement par les clients Windows XP. Ceux-ci doivent utiliser le client RDP 6.1 pour pouvoir en bénéficier.

Sur l’écran « Licensing Mode », laissez la case « Configure Later » et passez à l’étape suivante.

Passez l’étape « User Groups » et « Client Experience » qui ne nous concerne pas lors de l’utilisation du serveur Remote Desktop Session Host en mode Redirection.

Sur la page suivante, cliquez sur « Install » pour confirmer l’installation. A l’issue de l’installation, un redémarrage du serveur est nécessaire.

Une fois le redémarrage effectué, confirmez le résultat de l’installation :

 2.4 Installation du rôle Remote Desktop Connexion Broker

Le but du Connexion Broker est de faire l’intermédiaire entre les utilisateurs et le service final. Son rôle sert de conseillé pour les utilisateurs afin de leur proposer les services et de donner les informations nécessaires à son accès Il identifie les machines virtuelles pour les utilisateurs afin d’initier la connexion à distance.  

Pour procéder à son installation, préparez une machine en installant et configurant (nom d’hôte, réseau) Windows Server 2008 R2 ou utilisez le serveur hébergeant le rôle Remote Desktop Session Host.
Ouvrez ensuite la console « Server Manager » et cliquez sur « Roles » puis choisissez « Add Roles ».
L’assistant d’ajout d’un rôle s’ouvre, passez la première page et côchez ensuite le rôle « Remote Desktop Services ».
Sur l’écran permettant le choix des services à installer, choisissez « Remote Desktop Connexion Broker» :

Sur la page suivante, cliquez sur « Install » pour confirmer l’installation. Assurez-vous ensuite du résultat de l’installation :

 2.5 Installation du rôle Remote Desktop Virtualization Host

Sur la machine hébergeant le rôle Hyper-V, nous devons installer le rôle Remote Desktop Virtualization Host permettant de superviser les sessions de machines virtuelles et les reporter au serveur RD Connection Broker. Il prépare aussi la machine virtuelle pour la connexion bureau à distance quand une requête est faite par le serveur RD Connection Broker.

Pour cela sur le serveur Hyper-V,  ouvrez la console « Server Manager ».
Cliquez sur « Roles » et choisissez « Add Roles ».
L’assistant d’ajout d’un rôle s’ouvre, passez la première page et côchez ensuite le rôle « Remote Desktop Services ».
Sur l’écran permettant le choix des services à installer, choisissez « Remote Desktop Virtualization Host » :

Sur la page suivante, cliquez sur « Install » pour confirmer l’installation. Assurez-vous ensuite du résultat de l’installation :

 2.6 Installation du rôle Remote Desktop Web Access

Le dernier rôle nécessaire au fonctionnement de l’architecture pour des utilisateurs internes à l’entreprise est le portail Remote Desktop. Remote Desktop Web Access (RD Web Access) fournit aux utilisateurs une vue agrégée des applications distantes et des connexions de bureau à distance via un portail Web. En utilisant RD Web Access, un utilisateur peut voir toutes les applications distantes et bureaux virtuels qui lui sont attribués.

Pour procéder à son installation, préparez une machine en installant et configurant (nom d’hôte, réseau) Windows Server 2008 R2.
Ouvrez ensuite la console « Server Manager » et cliquez sur « Roles » puis choisissez « Add Roles ».
L’assistant d’ajout d’un rôle s’ouvre, passez la première page et côchez ensuite le rôle « Remote Desktop Services ».
Sur l’écran permettant le choix des services à installer, choisissez « Remote Desktop Web Access » :

En cliquant sur Next, l’assistant vous avertit qu’il doit installer d’autres rôles nécessaires à son exécution. Le serveur doit notamment disposer du serveur Web IIS et des outils d’administration à distance. Cliquez sur le bouton « Add Required Role Services ».

Sur l’écran suivant, l’assistant vous montre la liste des services du rôle Web Server (IIS) nécessaires au fonctionnement du portail. Cliquez sur « Next »

Sur la page suivante, cliquez sur « Install » pour confirmer l’installation. Assurez-vous ensuite du résultat de l’installation :

Notez que l’utilisation du rôle Remote Desktop Web Access nécessite un certificat. Par défaut, l’installation auto génère un certificat signé par la machine.
Dans le cadre d’une utilisation en production, vous pourrez :

• Soit associer au portail un certificat attribué par le système de distribution de certificats (PKI) de l’entreprise. L’autorité de certification qui a émise le certificat doit être approuvée par les clients.
• Soit utiliser un certificat délivré par une autorité de certification publique.
• Soit utiliser le certificat auto-signé (déprécié !!) de la machine qui doit être ajouté au catalogue des autorités de certifications approuvées. Nous verrons ce cas pour ne pas trop compliquer l’implémentation de la solution.

Si vous souhaitez publier le portail sur Internet à destination d’utilisateurs externes, il est conseillé d’utiliser un certificat délivré par une autorité de certification publique.

Revenir au plan : http://microsofttouch.fr/blogs/js/pages/microsoft-virtual-desktop-infrastructure-vdi-sous-tous-ses-angles.aspx

1. VDI : Aperçu

 1.1 Fonctionnement de l’infrastructure VDI de Microsoft

Microsoft Virtual Desktop Infrastructure (VDI) est une solution délivrant des postes de travail centralisés. Le but est de stocker les postes de travail, leur système d’exploitation, leurs applications, leurs données dans un environnement virtuel dans un Datacenter. Les utilisateurs bénéficient ensuite de la puissance du protocole de bureau à distance (RDP) pour accéder à ces environnements de travail. On assimile souvent le VDI comme une technologie d’optimisation des postes de travail tout comme App-V, MED-V …
La technologie VDI de Microsoft fait appel à différentes technologies mise en œuvre par Microsoft et notamment :

• Son offre de virtualisation de serveurs au travers de son hyperviseur : Hyper-V
• Son offre de virtualisation de présentation par le biais de Remote Desktop Services

Remote Desktop Services (anciennement Terminal Services) a longtemps eu mauvaise réputation. Microsoft a longuement laissé cette technologie vieillir sans y apporter de plus-value. Windows Server 2008 a commencé à enrayer cette vérité en introduisant de nouveaux rôles et de nouvelles fonctionnalités comme le support du Single Sign On (SSO). Windows Server 2008 R2 a permis d’apporter la transmission de l’expérience utilisateur d’Aero dans cette technologie. Il est aussi maintenant possible de pouvoir visualiser du contenu en haute définition par bureau à distance. Remote Desktop Services offre aussi la possibilité d’acquisition audio et de redirection DirectX 9, 10 et 11.

Présentation des rôles :

• Hyper-V est l’hyperviseur de Microsoft qui se chargera d’accueillir les environnements virtuels.
• Remote Desktop Connection Broker (RD Connection Broker) : Le but du Connexion Broker est de faire l’intermédiaire entre les utilisateurs et le service final. Son rôle sert de “conseiller” pour les utilisateurs afin de leur proposer les services et de donner les informations nécessaires à son accès. Il est le plus souvent contacté par la passerelle Remote Desktop (RD Gateway) ou par le portail d’accès Internet (RD Web Access) suite aux demandes des utilisateurs :
  • Il identifie les machines virtuelles pour les utilisateurs afin d’initier la connexion à distance.
  • Il prépare la machine virtuelle en contactant le serveur hébergeant les machines virtuelles au travers du rôle : Remote Desktop Virtualization Host server (Le but est par exemple de réveiller les machines virtuelles d’un état éteint ou en sauvegarder).
  • Il obtient l’adresse IP de la machine virtuelle en contact le rôle Remote Desktop Virtualization Host server.  L’adresse IP est ensuite renvoyée au rôle Remote Desktop Session Host server (anciennement Terminal Server) qui s’exécute dans un mode de redirecteur.   
  • Il supervise les sessions utilisateurs dans le scenario utilisant un pool de machines virtuelles.  Un utilisateur ayant ouvert une session toujours en exécution dans un pool est automatiquement redirigé sur la machine virtuelle correspondante.
• Remote Desktop Session Host (RD Session Host) server utilisant le mode redirection : Le but du serveur RD Session Host (anciennement Terminal Server) utilisé dans un mode redirection (redirecteur) est de solidement rediriger une connexion RDP à une machine virtuelle.
• Quand un utilisateur souhaite se connecter à une machine virtuelle, le serveur RD Session Host interroge le serveur RD Connection Broker.
• Le serveur RD Connection Broker à son tour provisionne une machine virtuelle pour l'utilisateur au travers du serveur RD Virtualization Host et renvoie son adresse IP pour le serveur RD Session Host. Le Serveur RD Session Host redirige ensuite le client RDP pour se connecter à la machine virtuelle en utilisant l’adresse IP.
• Microsoft recommande d’héberger les rôles  RD Connection Broker et RD Session Host sur la même machine. Cependant le scénario mettant en œuvre les deux rôles sur des machines séparées est aussi supporté ; c’est d’ailleurs ce que nous verrons dans cet article.
• Remote Desktop Virtualization Host (RD Virtualization Host) est un rôle Remote Desktop Services inclut dans Windows Server 2008 R2. RD Virtualization Host s’intègre avec Hyper-V pour fournir des machines virtuelles qui peuvent être utilisées comme pool de bureaux virtuels ou bureaux virtuels personnels.
  Le serveur RD Virtualization Host a les fonctions suivantes :
  • Superviser les sessions des machines virtuelles et les reporter au serveur RD Connection Broker.
  • Préparer la machine virtuelle pour la connexion bureau à distance quand une requête est faite par le serveur RD Connection Broker.
• Remote Desktop Web Access (RD Web Access) fournit aux utilisateurs une vue agrégée des applications distantes et des connexions de bureau à distance via un portail Web. En utilisant RD Web Access, un utilisateur peut voir toutes les applications distantes et bureaux virtuels qui lui sont attribuées.
• Remote Desktop Gateway (RD Gateway) est un rôle optionnel dans le déploiement d’une infrastructure Microsoft VDI. Son objectif est de router les connexions RDP sur Internet en toute sécurité et à travers un firewall. RD Gateway peut être couplé avec ISA Server/Forefront Threat Management Gateway 2010 ou Forefront IAG/Forefront UAG 2010 pour améliorer la sécurisation du processus d’accès aux ressources interne. Nous n’aborderons pas la mise en place de Remote Desktop Gateway dans cet article. Néanmoins le rôle est obligatoire pour rendre disponible les environnements virtuels aux utilisateurs externes. Pour cela, vous pouvez vous rapporter à d’autres sources sur Internet expliquant sa mise en œuvre : http://technet.microsoft.com/en-us/library/dd983941(WS.10).aspx

Microsoft VDI peut être couplé avec Application Virtualization pour facilement déployer les applications sur la base des groupes utilisateurs. App-V est donc une plus-value dans le scénario utilisant un pool de machines virtuelles pour des utilisateurs différents et ne disposant pas des mêmes besoins et applications. Pour plus d’informations sur App-V, nous vous renvoyons vers notre article sur le sujet : http://www.laboratoire-microsoft.org/articles/MDOP2009-Application-Virtualization/

Enfin l’utilisation de System Center Virtual Machine Manager (SCVMM) afin de facilement administrer les différents environnements virtuels est un bon complément à Microsoft VDI. Il devient ainsi possible de provisionner facilement et rapidement des machines virtuelles dans ce type d’environnement.

Maintenant que nous avons abordé les différents rôles, nous allons brièvement décrire les différents échanges entre ceux-ci.

1. Si l’on considère le scénario d’une connexion Interne au réseau de l’entreprise, les utilisateurs disposent de deux moyens pour se connecter. Ils peuvent utiliser le portail du serveur Remote Desktop Web Access (RD Web Access) ou les fonctionnalités de « RemoteApp and Desktop Connexion ».
2. Une fois la connexion au service établie (portail) et après authentification des utilisateurs auprès de l’annuaire, la demande est envoyée au serveur Remote Desktop Session Host.
3. Le serveur Remote Desktop Session Host utilisant un mode redirection, redirige la demande au rôle Remote Desktop Connection Broker pour provisionner une machine à l’utilisateur.
4. Le Serveur Remote Desktop Connection Broker interroge l’annuaire Active Directory pour savoir si l’utilisateur est habilité à accéder à cette ressource.
5. Le serveur Remote Desktop Connection Broker à son tour provisionne une machine virtuelle pour l'utilisateur au travers du serveur Remote Desktop Virtualization Host et son infrastructure Hyper-V
6. Le serveur Remote Desktop Virtualization Host effectue les différentes opérations (réveil, démarrage…) nécessaires à la mise en ligne de la machine virtuelle.
7. Le serveur Remote Desktop Connection Broker renvoie l’adresse IP de la machine au serveur Remote Desktop Session Host.
8. Le Remote Desktop Session Host redirige ensuite le client RDP pour se connecter à la machine virtuelle en utilisant l’adresse IP.
9. Le client est connecté.
10. Une fois que le client se déconnecte, le serveur Remote Desktop Session Host est informé. Il informe le serveur Remote Desktop Connection Broker afin de libérer les ressources. Dans le cadre du scénario de pool de machine virtuelle, la VM subit une restauration (rollback) à son état initial.

Schéma de fonctionnement dans le cas d’une connexion externe au réseau de l’entreprise :

Source: Remote Desktop Services Team Blog

 1.2 Les deux scenarios offerts par VDI

Microsoft VDI propose deux scénarios d’utilisation :

• Le mode Bureau Virtuel Personnel (Personal Virtual Desktops) permet de mettre en œuvre des machines virtuelles qui sont assignées par l’administrateur à des utilisateurs de manière permanente. Ce scénario est assimilé à un mode statique.
• Le mode Pool (ou groupe) de Bureaux Virtuels (Virtual Desktop Pool) permet de regrouper des machines virtuelles configurées de manière identique et qui sont assignées temporairement aux utilisateurs par l’infrastructure VDI. Ce scénario est assimilé à un mode dynamique. Il est important de prendre en considération la gestion des profils utilisateurs. Nous aborderons ce sujet dans l’article.

Ces deux modes de fonctionnement s’adaptent à tous les scénarios de gestion des postes de travail envisageables.

 1.3 La haute disponibilité pour Microsoft VDI

Il ne fait aucun doute que dans ce genre de projet la notion de haute disponibilité de l’infrastructure est primordiale et ce afin d’assurer la meilleure continuité du service. L’article n’a pas pour vocation de traiter ce sujet. Néanmoins, vous devez prendre en considération les différentes bonnes pratiques en matière de haute disponibilité pour l’infrastructure de virtualisation Hyper-V.
Vous devez donc prévoir une redondance matérielle pour le stockage, les connectivités réseau … L’implémentation de la répartition de charge est essentielle pour pouvoir assurer la pérennité du service.

Vous pouvez aussi prévoir un cluster de serveur Remote Desktop Connexion Broker. Plus d’informations sur le livre blanc « Deploying Remote Desktop Connection Broker with High Availability » : http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=df3e1876-737e-4f81-9f29-828a67ebbf58

 1.4 Windows Server 2008 R2 SP1 et Windows 7 SP1 Better Together!

Le Service Pack 1de Windows 7 et Windows Server 2008 R2 est clairement dédié à la technologie VDI de Microsoft. Il intègre une nouvelle fonctionnalité appelée RemoteFX issue du rachat de Calista en 2008. Avec l’arrivée du Service Pack 1, Microsoft introduit la fonctionnalité RemoteFX permettant de bénéficier des fonctionnalités de calculs graphiques du serveur à l’intérieur d’une machine virtuelle. L’utilisateur ne voit ainsi aucune différence entre une machine physique et virtuelle.

Le Service Pack 1 de Windows Server 2008 R2 introduit aussi une nouveauté dédiée à Hyper-V appelée Dynamic Memory. Cette fonctionnalité permet de configurer une machine virtuelle afin que la quantité de mémoire assignée à la VM s’ajuste en fonction de ses besoins pendant son exécution. Il y a donc une notion d’allocation dynamique de la mémoire au système d’exploitation. Le système d’exploitation virtuel doit aussi être en capacité de gérer cette arrivée de mémoire alors qu’il est en cours d’exécution. Ceci permet d’augmenter le nombre de machines virtuelles sur une machine physique. Le but est d’assurer que la mémoire est distribuée de façon optimale entre les différentes machines virtuelles.

Nous verrons comment implémenter ces deux fonctionnalités plus loin dans l’article.

 1.5 VDI et le Licensing

Avant de commencer la présentation de la technologie VDI de Microsoft, nous allons vous présenter les avantages ou les inconvénients du Licensing afin que vous puissiez juger de l’attractivité de la solution.
Le but de VDI est de délivrer un bureau à la demande de l’utilisateur. Le concept est donc véritablement différent de celui appliqué aux machines physiques. De ce fait, Microsoft a établi un modèle de licence spécifique pour pallier aux insuffisances du modèle initial et refléter le nombre de licence utilisé par l’infrastructure VDI. VDI nécessite l’achat d’un certain nombre de licences nécessaires au fonctionnement des différents équipements :

• Les licences pour les serveurs (Windows Server 2008 R2) et l’hyperviseur
• Les licences pour les postes de travail virtuels.
• Les licences pour le produit d’administration des environnements virtuels : System Center Virtual Machine Manager 2008 R2 (Optionnel)
• Les licences pour le produit d’administration du parc informatique : System Center Configuration Manager 2007 R2 (Optionnel)
• Les licences pour le produit de supervision du parc informatique : System Center Operations Manager 2007 R2 (Optionnel)
• Les licences pour la virtualisation d’application permettant une meilleure flexibilité du provisionnement des applications aux utilisateurs par le biais d’Application Virtualization inclut dans MDOP. (Optionnel)
•  Un mécanisme de fourniture de bureaux comme celui offert par Citrix au travers de XenDesktop. (Optionnel)

Microsoft crée Windows Virtual Enterprise Centralized Desktop (VECD) pour répondre aux problématiques. VECD doit être souscrite quel que soit la technologie VDI utilisée (Microsoft ou non).

Microsoft introduit deux offres utilisant un mode de licence par périphérique client accédant à l’environnement VDI:

• Microsoft Virtual Desktop Infrastructure Standard Suite (VDI Standard Suite) inclut les licences :
  • La plateforme hyperviseur (Hyper-V Server 2008 R2).
  • Pour la suite d'administration : System Center Virtual Machine Manager 2008 R2, System Center Operations Manager 2007 R2 et System Center Configuration Manager 2007 R2.
  • La virtualisation d'applications avec Application Virtualization (App-V) et MDOP (Microsoft Desktop Optimization Pack).
  • Un agent de connexion via les services Bureau à distance de Windows Server 2008 R2.
• Microsoft Virtual Desktop Infrastructure Premium Suite (VDI Premium Suite) inclut toutes les fonctionnalités de la suite standard et ajoute :
  • La fonctionnalité complète des services Bureau à distance, y compris l'option de déployer des bureaux basés sur la session en plus des bureaux VDI.
  • Virtualisation Microsoft des applications pour les services Bureau à distance (App-V for Remote Desktop)

De plus, Microsoft et Citrix ont émis un partenariat fort et agressif envers VMWare (le principal concurrent). Ainsi, ils lancent une offre 500 licences gratuites à toute entreprise cliente de VMware et déçu de sa technologie VDI. Microsoft ne fait ainsi plus payer les licences VECD si l’entreprise a souscrite la Software Assurance (SA).

Plus d’informations sur le licensing de VDI sur : http://blogs.technet.com/virtualization/archive/2009/07/13/Microsoft_1920_s-new-VDI-licensing_3A00_-VDI-Suites.aspx

Pour plus d’informations sur le licensing de Windows : Volume Activation 2, vous pouvez lire notre article : http://www.laboratoire-microsoft.org/articles/VolumeActivation2_-_Presentation-Implementation/

L’implémentation de VDI ne permet pas de réduire les coûts d’exploitation des postes de travail car son installation nécessite des coûts matériels, logiciels, et de licences importants. Il permet cependant d’apporter une flexibilité dans l’administration du parc de poste de travail.

 1.6 Mise en pratique

Le but de cet article est de couvrir l’implémentation d’une telle infrastructure sans prendre en considération les notions de haute disponibilité qui pourrait découler d’un tel projet. Nous n’aborderons pas non plus les notions de dimensionnement matériel et de choix technologique lié à la mise en place d’une infrastructure Hyper-V. Ce sont néanmoins des paramètres à prendre en considération. Nous vous renvoyons pour cela vers les recommandations officielles émises par Microsoft et vers les différents articles techniques que vous pourrez trouver sur Internet.

Pour mettre en œuvre une telle architecture, nous allons prendre en compte des cas concrets d’utilisation de la technologie VDI.
VDI est souvent mise en avant comme une technologie de demain qui amènera les entreprises à centraliser la gestion des postes de travail en les virtualisant dans des datacenters. Idéalement cette approche prend tout son sens si on utilise les nouveautés émanant des technologies de Cloud Computing.
La mise en œuvre d’un changement aussi radical dans la gestion du parc informatique de l’entreprise est un projet sur plusieurs années et peu d’entreprises ont passé ce cap. C’est cependant la vocation première de la technologie.
VDI est souvent portée comme une solution technique liée aux difficultés rencontrées lors de déploiement et migration de systèmes d’exploitation. Prenez le scenario suivant, une entreprise souhaite migrer son parc Windows XP vers Windows 7. Lors de la phase d’étude, il ressort qu’un certain nombre d’applications métier ne peuvent être portées sur Windows 7. Il n’existe pas de mise à jour et l’éditeur n’a pas non plus sort de nouvelle version. Les diverses tentatives de réparer l’application en utilisant les Shims de Application Compatibility Toolkit ne permettent pas de faire fonctionner pleinement l’application. L’utilisation de la technologie de virtualisation de postes de travail Microsoft Enterprise Desktop Virtualization est envisageable mais le nombre restreint d’utilisateurs (moins de 20% de l’effectif) utilisant l’application ne permet pas un retour sur investissement de la technologie suffisant. L’entreprise est donc condamnée à investir dans MED-V ou à ne pas migrer vers le nouveau système d’exploitation. Néanmoins, VDI peut répondre simplement aux problématiques de migration. En effet, sa souplesse liée au provisionnement de machine virtuelle peut facilement adapter les besoins de l’entreprise. Elle peut donc utiliser la puissance d’Hyper-V pour mettre à disposition un pool de machines virtuelles sous Windows XP afin de rendre disponible l’application aux quelques utilisateurs tout en rendant possible la migration du parc informatique vers Windows 7.
Dans mon cas pratique, le but est de permettre la migration du parc vers Windows 7 tout en mettant à disposition Excel 95 au travers de la suite Office 95 pour les utilisateurs disposant de macro développé pour ce dernier. Nous verrons donc comment mettre à disposition ce pool de machines auprès des utilisateurs.

Le second cas pratique répondra aux attentes de certaines entreprises. Imaginez les scenarios suivants :

• Une entreprise rachète ou fusionne avec une autre entreprise. Les opérations de rachat sont souvent des opérations longues. Elles nécessitent du temps pour répercuter les changements et que l’aspiration ou la fusion soit totalement effective. Ceci affecte aussi le service informatique et son parc puisque la mutualisation des ressources nécessite des efforts considérables.
• Une entreprise signe des partenariats avec des prestataires externes. Cette entreprise a donc besoin de mettre à disposition certaines applications et ressources aux partenaires. Il est souvent très compliqué de mettre à disposition les applications à une entreprise externe. Il faut pour cela créer un pont entre les deux organisations (Active Directory Federations Services) et donner les autorisations nécessaires d’accès.

Dans ces deux scénarios la solution la plus simple peut être la mise en œuvre d’une infrastructure VDI donnant l’accès à l’entreprise/prestataire externe à des bureaux virtuels. Ces bureaux virtuels disposent de toutes les ressources et applications nécessaires au partenariat mise en œuvre.
Dans mon cas pratique, nous mettrons à disposition à une entreprise externe et ses utilisateurs, une série de postes de travail virtualités sous Windows 7 afin qu’ils puissent opérer les tâches nécessaires qui découlent de notre partenariat.

La mise en place de ces deux cas pratiques se fera conjointement sur la même infrastructure et répondra ainsi aux deux scénarios de pool de machines virtuelles et de bureaux virtuels personnels.

Revenir au plan : http://microsofttouch.fr/blogs/js/pages/microsoft-virtual-desktop-infrastructure-vdi-sous-tous-ses-angles.aspx

 J'en parle depuis quelques temps, le voici...

Ces dernières années ont clairement été placées sous le signe de la virtualisation. On entend la virtualisation « à toutes les sauces … » Avec par exemple l’hyperviseur de Microsoft Hyper-V pour la virtualisation de serveurs afin de consolider le matériel et opérer des économies sur le plan énergétique et matériel. On entend beaucoup parler de la virtualisation d’applications avec Microsoft Application Virtualization (App-V) pour accélérer la gestion du cycle de vie des applications. Microsoft a aussi introduit la virtualisation de postes de travail avec le concours de Microsoft Enterprise Desktop Virtualization (MED-V) pour résoudre les problèmes de compatibilité applicative lors des migrations de systèmes d’exploitation. Enfin, et ceci n’est pas nouveau ! On voit le terme Virtualisation de présentation ressortir avec le célèbre Terminal Services fraichement renommé Remote Desktop Services. La virtualisation répond ainsi à un nombre significatif de problématiques. Dans cet article nous allons aborder un nouveau concept pour Microsoft : Virtual Desktop Infrastructure (VDI) ou Infrastructure de Bureau Virtuel. Derrière ce terme obscur, il y a un concept auquel Microsoft n’a pas cru et s’est désengagé jusqu’à aujourd’hui. 2009 aura marqué un tournant majeur puisque Microsoft a revu sa politique vis-à-vis du VDI pour se lancer pleinement dedans. En Mars 2010, Microsoft et Citrix annonçait un accord sur les solutions VDI pour partager leurs technologies et travailler main dans la main. Aujourd’hui, Microsoft apporte au travers de Windows Server 2008 R2 et Windows 7, une véritable solution VDI pouvant concurrencer le célèbre VMware et les autres acteurs du marché comme Sun, ou HP. Cet article peut aussi vous servir à la préparation de la certification « 70-669 MCTS: Windows Server 2008 R2, Desktop Virtualization » comprenant une part importante de VDI.

Plan :

1. VDI : Aperçu
2. VDI : Installation de l’infrastructure
3. VDI : Configuration des rôles
4. VDI : Préparation des machines virtuelles
5. VDI : Ajout des machines virtuelles à l’infrastructure
6. VDI : Test de l’infrastructure
7. VDI : La virtualisation de l'état utilisateur
8. VDI : RemoteFX et Dynamic Memory
9. VDI : Les scripts supplémentaires
Conclusion