Windows Virtual Desktop

Windows Virtual Desktop 25

Nous l’attendions depuis longtemps. Microsoft annonce une version préliminaire publique de sa nouvelle solution de virtualisation de bureaux et d’applications. Cette nouvelle solution porte le nom de Windows Virtual Desktop. Dans cet article, nous aimerions vous apprendre comment créer la solution sur Azure.

Qu’est-ce que Windows Virtual Desktop?

On peut le décrire comme un serveur de terminal en tant que service, pour lequel il suffit de fournir l’image. Microsoft se charge de l’infrastructure, l’utilisateur devant uniquement s’occuper de l’image et de la maintenance. Cela réduira quelque peu les coûts d’un environnement de serveur de terminal dans Azure. En parallèle, Windows 10 devient multisessions et est optimisé pour l’utilisation d’Office 365. Avec son interface HTML 5 et Remote Desktop App pour Windows 10, la solution est prête à l’emploi et parfaitement intégrée. Une application pour appareils mobiles devrait suivre.

Création de Windows Virtual Desktop

Ce chapitre est consacré à la création d’un environnement Windows Virtual Desktop (WVD) sur Azure.

Situation initiale

Dans notre scénario, nous partons de la situation initiale suivante: Nous disposons d’un réseau virtuel sur Azure configuré pour la région ouest de l’Europe. Ce réseau comprend nos Azure Active Directory Domain Services (AAD DS) connectés à azureconstructionsite.onmicrosoft.com, notre Azure Active Directory (AAD).Le domaine constructionsite.tk est enregistré dans cet AAD. Nos AAD DS connectés à l’AAD mettent à disposition un domaine classique appelé csite.cloud. Important: Il ne faut pas utiliser les AAD DS sur les domaines non routables.

Enregistrement du WVD dans Azure Active Directory

Il faut commencer par créer et enregistrer une application WVD dans l’Azure Active Directory. Pour ce faire, l’Azure AD Tenant GUID ou le nom sont requis. Dans notre exemple, il s’agit de azureconstructionsite.onmicrosoft.com. Il faut ensuite naviguer sur le site https://rdweb.wvd.microsoft.com et procéder à l’enregistrement de Server App et de Client App.

Dans l’Azure Active Directory, nous ajoutons alors l’administrateur global ProjectManager sur l’application Windows Virtual Desktop que nous venons d’enregistrer et lui accordons les droits de TenantCreator.

L’association et l’enregistrement du service WVD avec l’Azure Active Directory sont désormais réussis.

Création du Windows Virtual Desktop Tenant (version préliminaire)

Une fois le module PowerShell installé et importé avec succès, on s’identifie vis-à-vis du Azure AD Tenant avec le TenantCreator (dans notre exemple: ProjectManager) et on crée un nouveau WVD Tenant.

Maintenant, un Windows Virtual Desktop (WVD) Tenant (locataire) est créé en plus de l’Azure Tenant existant. Ce locataire n’est pas visible dans le portail Azure et peut, au moment de l’élaboration de ce blog, être administré uniquement via PowerShell. Il faut pour cela installer un module PowerShell adapté.

Add-RDSAccount -DeploymentUrl “https://rdbroker.wvd.microsoft.com” New-RdsTenant -Name <TenantName> -AadTenantId <DirectoryID> -AzureSubscriptionId <SubscriptionID>

Création du Service Principal dans Azure Active Directory

Après avoir créé le WVD Tenant, nous restons dans PowerShell, mais nous passons à Azure Active Directory. Dans notre exemple, nous nous servons du script suivant. Il doit bien entendu être adapté avec les informations personnelles:

Import-Module AzureAD$aadContext = Connect-AzureAD$myTenantName = “<wvdtenantname> »$svcPrincipal = New-AzureADApplication -AvailableToOtherTenants $true -DisplayName “Windows Virtual Desktop Svc Principal”$svcPrincipalCreds = New-AzureADApplicationPasswordCredential -ObjectId $svcPrincipal.ObjectId New-RdsTenant -Name <TenantName> -AadTenantId <DirectoryID> -AzureSubscriptionId <SubscriptionID>

Le Service Principal créé est alors attribué à un rôle, puis inscrit, à l’aide du script suivant:

Add-RdsAccount -DeploymentUrl https://rdbroker.wvd.microsoft.comNew-RdsRoleAssignment -RoleDefinitionName « RDS Owner » -ApplicationId $svcPrincipal.AppId -TenantName $myTenantName$creds = New-Object System.Management.Automation.PSCredential($svcPrincipal.AppId, (ConvertTo-SecureString $svcPrincipalCreds.Value -AsPlainText -Force))Add-RdsAccount -DeploymentUrl « https://rdbroker.wvd.microsoft.com » -Credential $creds -ServicePrincipal -AadTenantId $aadContext.TenantId.Guid

Il faut maintenant vérifier via PowerShell les trois valeurs Password, Tenant ID et Application ID. Ces valeurs seront requises plus tard.

$svcPrincipalCreds.Value$aadContext.TenantId.Guid$svcPrincipal.AppId

Une fois cette procédure effectuée et les valeurs temporairement définies, nous quittons PowerShell et retournons dans le portail Azure. Voici ce à quoi ressemble maintenant notre environnement:

Création des ressources de pool d’hôtes sur Azure

Il faut maintenant créer le pool d’hôtes dans le portail Azure. Il se trouve dans Azure Marketplace.

Dans notre exemple, nous appelons le pool d’hôtes «Pooled_RemoteWorkers» et choisissons le type «Pooled» en conséquence. Cela signifie qu’un utilisateur ne reçoit pas une MV personnelle mais utilise Windows 10 multisessions et partage la MV avec d’autres utilisateurs. Pour la connexion, nous autorisons les utilisateurs «Bob» et «Wendy».

Nous arrivons maintenant à la partie essentielle. Nous devons choisir la famille et la taille de la MV que nous voulons créer. Azure est ici bien utile: On choisit le Usage Profil des utilisateurs et on indique combien d’entre eux y auront accès. Azure propose alors des MV et des tailles. Dans notre exemple, nous avons cependant adapté cette proposition et opté pour 2 MV B2ms.

À l’étape trois, nous choisissons une Image OS de la galerie. Nous sélectionnons Windows 10 Enterprise multisessions avec Office 365 ProPlus. On peut ici également créer sa propre image et la télécharger. Cependant, nous n’abordons pas cet aspect dans notre exemple. Les MV entrent alors dans le domaine (dans notre cas, AAD DS).

Pour la quatrième et dernière étape, nous avons seulement besoin des valeurs que nous avons choisies précédemment via PowerShell et les utilisons pour connecter le pool d’hôtes à notre Windows Virtual Desktop Tenant.

Après la création réussie du pool d’hôtes, le schéma ressemble à ce qui suit:

Notre environnement WVD est ainsi prêt à fonctionner et accessible par RDP à un Windows 10 complet, aussi bien par la console web via HTML 5 que par Remote Desktop App. Ce qui est intéressant, c’est qu’aucun port RDP (3389) ne doit être ouvert pour la connexion par les ressources Azure ou le pool WVD.

Création d’une application virtuelle

Comme notre environnement Windows Virtual Desktop est fonctionnel et que nous pouvons y accéder sur le bureau, nous nous consacrons maintenant à la publication d’une application virtuelle. Dans notre exemple, nous prenons PowerPoint.

ATTENTION: Au moment de l’élaboration de ce blog, il est impossible qu’un utilisateur se trouve dans plus d’un RdsAppGroup. Pour cette raison, ci-après, le nouveau groupe RemoteApp sera affecté à un autre utilisateur.

Création du RemoteApp Group

Il faut d’abord créer un groupe RemoteApp par le biais duquel il sera possible de publier ensuite l’application souhaitée. Dans cet exemple, le groupe s’appelle «Office 365 Apps». Il est important d’indiquer le bon WVD Tenant (ConstructionSite) et le nom du pool d’hôtes créé (Pooled – RemoteWorkers).

New-RdsAppGroup -ResourceType « RemoteApp »

Ensuite, on sélectionne l’application que l’on souhaite mettre à disposition comme application à distance. Ceci est également effectué à l’aide de PowerShell.

Get-RdsStartMenuApp <tenantname> <hostpoolname> <appgroupname>

L’application sélectionnée est maintenant ajoutée au groupe RemoteApp nouvellement créé. Pour ce faire, on a besoin de la commande PowerShell suivante:

Get-RdsRemoteApp <tenantname> <hostpoolname> <appgroupname> -Name <remoteappname> -AppAlias <appalias>

Il convient maintenant de valider la RemoteApp pour l’utilisateur correspondant afin qu’il puisse accéder à l’application. Pour ce faire, il convient d’utiliser la commande PowerShell suivante:

Get-RdsAppGroupUser <tenantname> <hostpoolname> <appgroupname> -UserPrincipalName <userupn>

Les applications sont ajoutées à l’utilisateur avec succès et celui-ci devrait les voir dans sa liste Remote Desktop App. Cela peut, par exemple, ressembler à ceci:

L’application s’ouvre en tant que RemoteApp par un double-clic. Dans la liste des tâches, cela est signalé par le petit logo Remote Desktop.

Conclusion

Windows Virtual Desktop suit une approche passionnante et suscite un grand intérêt. Beaucoup sont particulièrement enthousiasmés par la possibilité d’un Windows 10 multisessions. D’autres nouvelles options d’évolutivité et d’optimisation des coûts viennent s’ajouter. L’environnement fonctionne sur Microsoft Cloud Azure. Cela permet une configuration très flexible du nombre de MV dans un pool d’hôtes et un arrêt des ressources en cas de non-utilisation afin d’optimiser les coûts. Ici encore, il n’est facturé que ce qui a été consommé (Pay-as-you-go/paiement à l’usage).

Toutefois, Windows Virtual Desktop n’est encore qu’une version préliminaire publique, et c’est en partie encore perceptible. Les messages d’erreur lors du déploiement ne sont pas toujours pertinents, et on se retrouve dans une méthode de résolution des problèmes «essai-erreur». Toutefois, quand le déploiement a réussi, Windows Virtual Desktop tient ses promesses. Nous sommes très satisfaits du résultat et attendons déjà avec impatience la sortie officielle et toutes les nouvelles caractéristiques à venir.

Nous sommes là pour vous aider

Vous avez des questions? Vous avez besoin d’aide? Contactez-nous. Nous serons heureux de vous aider.

L’équipe de logiciels Tech Data
software@techdata.ch
+41 41 799 19 88

Dominic Benndorf