Azure Virtual Desktop Hybride

Pendant longtemps, faire de l’AVD ailleurs que dans Azure, c’était soit du AVD on Azure Local, soit… rien. Pour ceux qui n’avaient pas encore investi dans le HCI mais qui avaient déjà du Hyper-V, du VMware ou du Nutanix qui tournait depuis dix ans en datacenter, l’équation était la même : reverse-proxy + RDS + bricolage maison. Microsoft vient enfin d’ouvrir la porte avec Azure Virtual Desktop Hybrid, en Public Preview depuis le 4 mai 2026.

Cette préversion est le fruit d’un travail continu de la part de Microsoft avant même l’annonce officielle de la fonctionnalité lors du Microsoft Ignite de 2025 à San Francisco.

Today, we’re excited to announce Azure Virtual Desktop for hybrid environments, a new capability for bringing the power of cloud-native desktop virtualization to existing on-premises infrastructure. With this update, on-premises Arc-Enabled Servers can be configured as AVD session hosts. This expands Azure Virtual Desktop’s hybrid capabilities beyond Azure Local to Microsoft Hyper-V, Nutanix AHV, VMware vSphere, physical Windows Servers, or anywhere Arc-Enabled Servers can be deployed on-premises.

Microsoft Tech Coommunity

Et la philosophie de fonctionnement est élégante : Azure Arc enrôle vos VMs on-prem, une extension AVD les transforme en session hosts, et le service AVD continue de vivre dans le cloud comme d’habitude. Bref, pas de nouvelle stack à apprendre, juste une nouvelle case à cocher.

Pour vous guider plus facilement dans cet article, voici des liens rapides :

Quelle est la nouveauté ?

Comme annoncé en introduction, Microsoft a publié le 4 mai 2026 la préversion publique d’Azure Virtual Desktop Hybrid. Le principe est simple : on prend une VM Windows qui tourne déjà chez vous (sur Hyper-V, VMware, Nutanix ou même un serveur physique), on l’enrôle dans Azure Arc, on lui pose une extension AVD, et hop, elle devient un session host AVD à part entière. L’utilisateur se connecte via la Windows App, exactement comme s’il attaquait un host pool 100 % Azure.

With Azure Virtual Desktop Hybrid, customers can run Azure Virtual Desktop session hosts on-premises using their existing hardware and preferred hypervisor connected through Microsoft Azure Arc. The Azure Virtual Desktop service remains in Azure, while session hosts can be deployed anywhere on-premises Azure Arc-enabled servers are supported. Users can access their desktops through the familiar Windows App.

This matters because it gives customers a phased, lower-risk path to cloud adoption:

Modernize legacy VDI environments at their own pace, preserving investments in datacenters, hardware, and operational tools.

Adopt cloud-managed desktops incrementally, with a clear path to migrate session hosts to Azure when the time is right.

Keep existing partner integrations for virtual machine management and provisioning.

Microsoft Tech Community

Pour rappel, jusqu’ici, faire tourner AVD ailleurs que dans Azure imposait soit AVD on Azure Local (anciennement Azure Stack HCI). Cela exigeait d’investir dans une stack HCI Microsoft – soit de partir sur du bon vieux RDS on-prem, en sacrifiant tout l’écosystème AVD (FSLogix moderne, app groups, Insights, Windows App).

Avec AVD Hybrid, ce dilemme s’efface : la documentation Microsoft Learn confirme que les VMs on-prem se comportent comme de vrais session hosts AVD pilotés depuis le portail Azure.

C’est un vrai changement de philosophie : historiquement, AVD c’était « tu déplaces ta VDI dans Azure, et après on en reparle ». Aujourd’hui, c’est « tu gardes ton hyperviseur, on apporte juste le control plane AVD chez toi ».

Ça ouvre AVD à toute une population qui en avait été tenue à l’écart pour des raisons de souveraineté, de coûts d’egress ou tout simplement parce qu’ils avaient déjà payé leur datacenter.

Est-ce la même chose qu’AVD sur Azure Local ?

C’est le même esprit, mais pas la même mécanique. AVD on Azure Local exige une infrastructure HCI Microsoft certifiée, avec ses nœuds, ses switches, son cluster, son réseau SDN. AVD Hybrid, lui, ne demande qu’une chose : une VM Windows qui peut joindre Azure Arc. Le reste, c’est votre hyperviseur qui le gère, peu importe lequel.

Autrement dit :

Pas besoin de hardware certifié Azure Local
Pas besoin de cluster spécifique – une simple VM Windows suffit
Le control plane AVD reste dans Azure (le service est rendu par Microsoft, comme pour AVD classique)
Les session hosts vivent chez vous, et c’est Azure Arc qui sert de pont

Si vous avez déjà déployé des serveurs Azure Arc-Enabled (par exemple pour bénéficier d’Azure Policy, Defender for Cloud ou Update Manager sur du on-prem), vous êtes déjà à 80 % du chemin. Il ne reste plus qu’à poser l’extension AVD et à brancher le session host sur un host pool.

Quels hyperviseurs sont supportés ?

La réponse de Microsoft est volontairement large : tout endroit où Azure Arc peut s’installer. Concrètement, c’est confirmé pour :

Microsoft Hyper-V (Windows Server, Hyper-V Server)
VMware vSphere (ESXi 7.x / 8.x)
Nutanix AHV
Serveurs Windows physiques (oui, vous pouvez transformer un poste rack en session host)

C’est ce que dit explicitement l’annonce officielle :

On-premises Arc-Enabled Servers can be configured as AVD session hosts. This expands Azure Virtual Desktop’s hybrid capabilities beyond Azure Local to Microsoft Hyper-V, Nutanix AHV, VMware vSphere, physical Windows Servers, or anywhere Arc-Enabled Servers can be deployed on-premises.

Microsoft Tech Community

Côté partenaires de lancement, Microsoft a explicitement nommé Nerdio, ControlUp, LoginVSI et Nutanix comme étant déjà alignés avec la Preview. Si vous utilisez Nerdio Manager for Enterprise, la fonctionnalité est intégrée dès aujourd’hui.

Quels OS et quelles licences sont éligibles ?

C’est le tableau qu’il faut imprimer et coller à côté de l’écran. Voici la matrice officielle issue de la documentation Microsoft Learn :

OS	Déploiement supporté	Licences éligibles
Windows Server 2016 / 2019 / 2022 / 2025	VMs et serveurs physiques	RDS CAL avec Software Assurance, ou RDS User Licenses en souscription
Windows 11 / Windows 10 Enterprise mono-session	VMs uniquement (pas de PC physique)	M365 E3/E5/A3/A5/F3, M365 Business Premium, Windows Enterprise E3/E5, Windows Education A3/A5, Windows VDA per user
Windows 11 / 10 Enterprise multi-session	Non supporté hors Azure	n/a

Le piège classique pour ceux qui font de l’AVD depuis longtemps : Windows 11 Enterprise multi-session n’est PAS supporté en hybride. Cette SKU reste exclusive à Azure. Si vous voulez du multi-utilisateur sur du on-prem, il faudra repasser sur du Windows Server avec le rôle Remote Desktop Session Host. C’est cohérent avec la philosophie multi-session, qui est historiquement liée à un avantage Azure-only.

Concernant la fameuse licence « Windows Cloud Hybrid » annoncée pour la GA : elle n’est PAS exigée pendant la Public Preview. Vous pouvez tester avec vos licences existantes. À la GA, Microsoft annoncera les conditions tarifaires définitives.

Entra Join ou jointure de domaine ?

Tous les modes sont supportés, et c’est une très bonne nouvelle. Mes propres tests le confirment :

Microsoft Entra Join pur : la VM s’enregistre directement dans le tenant. Idéal pour les machines Windows 11 mono-session, surtout dans une logique zéro-trust. Pas besoin de contrôleur de domaine joignable depuis la VM.

Active Directory (jointure de domaine traditionnelle) : fonctionne parfaitement, surtout pour des Windows Server qui ont besoin de Kerberos pour attaquer des serveurs de fichiers SMB on-prem ou des bases SQL avec authentification intégrée.

Active Directory + Microsoft Entra Connect (jointure de domaine traditionnelle, synchronisée vers Entra) :

Mon retour terrain :

Pour Windows 11 mono-session, l'Entra Join pur est plus rapide à mettre en place et évite tout le pataquès du DC à rendre joignable depuis le réseau de l'hyperviseur. 

Pour Windows Server, j'ai gardé le domain-join classique, parce que dans les vrais projets, le serveur de fichiers SMB est très souvent encore en AD on-prem et qu'on veut éviter de mixer les modèles. Les deux cas marchent du premier coup, je le détaillerai plus loin dans les cas pratiques.

Quels sont les prérequis à respecter ?

Avant de se lancer, il faut cocher quelques cases. Voici le récap :

Prérequis	Détail
Souscription	Une souscription Azure active
Resource providers	`Microsoft.HybridCompute`, `Microsoft.HybridConnectivity`, `Microsoft.GuestConfiguration`, `Microsoft.DesktopVirtualization`
RBAC	Azure Connected Machine Onboarding + Desktop Virtualization Contributor
Identité	Microsoft Entra ID (Entra Join ou AD synchronisé)
Réseau	Sortie TCP 443 vers Azure Arc + endpoints AVD
OS	Windows Server 2016+ ou Windows 11/10 Enterprise mono-session
Hyperviseur	Hyper-V, VMware, Nutanix AHV, ou serveur physique
Host pool	Validation host pool obligatoire pendant la Preview

Le piège classique : oublier le resource provider Microsoft.HybridConnectivity, qui est nécessaire pour la connectivité SSH/RDP via Arc. Si vous l’oubliez, l’enrôlement Arc passe, mais certaines opérations downstream peuvent silencieusement échouer. Croyez-en quelqu’un qui a passé une bonne demi-heure à se demander pourquoi 🙃.

Qu’est-ce qu’un « validation host pool » ?

Un validation host pool est un host pool AVD marqué comme environnement de validation (case à cocher dans le portail). Microsoft le réserve aux features en preview, et c’est actuellement le seul mode supporté pour AVD Hybrid pendant la Public Preview. La documentation est explicite :

Azure Virtual Desktop Hybrid is currently in Public Preview and is only supported with validation host pools. If you deploy a production host pool then you will need to redeploy once Windows Cloud Hybrid is Generally Available.

Microsoft Learn

Ne mettez pas en prod votre validation host pool. Servez-vous-en pour piloter, valider votre architecture, former l’équipe, mais prévoyez le redéploiement quand la GA sortira.

Quelles fonctions ne sont PAS supportées en Preview ?

Comme toute préversion qui se respecte, il y a des trous dans la raquette. Microsoft liste explicitement :

Power management dans le portail Azure (start/stop/deallocate sur les VMs)
Auto-Scale
Start VM on Connect
Session Host Configuration

C’est logique : ces fonctions reposent toutes sur le control plane Azure pour piloter les VMs (les démarrer, les arrêter, les redimensionner). Or, en hybride, c’est votre hyperviseur qui contrôle l’alimentation et le lifecycle des VMs. Microsoft ne peut pas démarrer une VM Hyper-V chez vous… à moins de passer par des extensions Arc dédiées, ce qui n’est pas encore en place.

Attention : l’absence d’Auto-Scale signifie que vous devez prévoir vous-même la scalabilité (provisioning manuel ou via votre orchestrateur d’hyperviseur). Pour des populations de plusieurs centaines d’utilisateurs, ce sera vite un bloqueur si vous comptiez sur AVD pour faire ça à votre place.

Combien ça coûte pendant la Preview ?

Pendant la Public Preview, vous payez :

Vos licences Windows / RDS CAL / M365 (rien de neuf, ce sont les mêmes qu’avant)
L’enrôlement Azure Arc (gratuit pour les serveurs Arc-Enabled de base, payant pour certaines features Defender / Update Manager / Policy avancées)
Le service AVD lui-même (pas de coût supplémentaire spécifique au mode hybride à ce stade)

À la GA, une licence Windows Cloud Hybrid sera très probablement requise pour les session hosts hybrides. Microsoft n’a pas encore communiqué les tarifs définitifs, mais le pattern habituel sur les « extensions cloud d’AVD » laisse penser à un modèle per user / month aligné sur les RDS User License Souscriptions.

Étape 0 : rappel des prérequis

Avant tout test, assurez-vous que :

Vous avez une souscription Azure active
Votre VM on-prem (Hyper-V, VMware, Nutanix…) est installée, à jour, et joignable en TCP 443 sortant vers Internet
Votre identité (Entra Join ou jointure AD) est déjà configurée avant l’enrôlement Arc
Que vous disposiez du rôle Azure Connected Machine Onboarding pour créer et gérer les ressources Azure Arc :

Que vous disposiez du rôle Contributeur à la virtualisation des postes de travail pour la gestion des pools d’hôtes Azure Virtual Desktop.

Étape 1 : enregistrer les resource providers

Sur la souscription cible, ouvrez Subscriptions > [votre sub] > Resource providers, puis vérifiez ou enregistrez si nécessaire :

Microsoft.HybridCompute
Microsoft.HybridConnectivity
Microsoft.GuestConfiguration
Microsoft.DesktopVirtualization

Vous pouvez aussi le faire en PowerShell :

'Microsoft.HybridCompute','Microsoft.HybridConnectivity','Microsoft.GuestConfiguration','Microsoft.DesktopVirtualization' | ForEach-Object { Register-AzResourceProvider -ProviderNamespace $_ }

Étape 2 : valider la readiness AVD

C’est l’étape clé documentée par Microsoft. L’objectif : confirmer que votre pool d’hôtes AVD de test peut être utilisé pour le test :

Ouvrez le portail Azure.
Cherchez Azure Virtual Desktop dans la barre.
Allez dans Host pools > Create.
Dans l’onglet Basics, cochez « Validation environment: Yes »

Attention : ne confondez pas validateavd (l’onglet sur la doc Microsoft, qui parle bien d’AVD) avec validatearc. Ce sont deux choses différentes : validateavd est ce qu’on cherche ici. La validation côté Arc (vérifier les resource providers, les rôles RBAC) se fait en parallèle.

Si vous ne disposez pas encore d’un pool d’hôtes AVD, veuillez le créer dans l’étape 3.

Étape 3 : créer le validation host pool, le workspace et l’application group

Si le pool d’hôtes AVD n’est pas encore créé dans votre environnement Azure, commencez par la base via l’assistant de création du host pool AVD :

Basics : nom (par exemple HP-AVDHybrid-Lab), région du metadata (dans mon cas Europe), type Pooled ou Personal selon votre besoin, et validation environment: Yes.
Virtual machines : choisir « No, I’ll add VMs later ». Les VMs seront ajoutées via l’enrôlement Arc + extension AVD, pas par le wizard Azure.
Workspace : créez-en un nouveau (par exemple WS-AVDHybrid-Lab) ou attachez-en un existant.
Tags et Review + create : validez.

Si cela n’est pas déjà le cas non plus, créez ensuite un application group (Desktop ou RemoteApp) et liez-le au workspace. C’est ce qui sera publié à l’utilisateur :

Étape 4 : onboarder la VM on-prem dans Azure Arc

Sur la VM on-prem, on va installer l’agent Azure Connected Machine, qui est le pont entre votre datacenter et Azure :

Dans le portail Azure, allez dans Azure Arc > Machines > Add.
Choisissez « Add a single server » (pour le lab) ou « Add multiple servers » (pour générer une clé partagée).
Renseignez la souscription, le group de ressources, la région.
Téléchargez le script d’onboarding PowerShell généré automatiquement.
Exécutez-le en administrateur sur la VM on-prem.

Le script télécharge l’agent (AzureConnectedMachineAgent.msi), l’installe, puis lance azcmagent connect avec les paramètres de votre tenant.

Au bout de 2 à 5 minutes, la VM apparaît dans Azure Arc > Machines avec un statut Connected.

Attention : la VM doit être déjà jointe à votre identité cible (Entra Join OU jointure de domaine) avant l’enrôlement Arc. Si vous changez de modèle d’identité après coup, il faut désinstaller l’agent Arc et tout recommencer. Ne sautez pas cette étape.

Étape 5 : installer l’extension AVD Azure Arc et enregistrer le session host

C’est ici que les deux mondes se rejoignent, et c’est l’étape qui m’a le plus surpris. Contrairement à ce qu’on pourrait croire, l’enregistrement du session host hybride ne se fait pas via le bouton « + Add » du host pool dans le portail.

Il faut exécuter manuellement un script PowerShell, qui va poser l’extension Microsoft.AzureVirtualDesktop.CloudDeviceExtension sur le compte Arc de la machine. C’est cette extension et non l’agent AVD classique qui réalise l’enregistrement.

Pré-requis : il faut avoir installé soit l’extension Azure CLI desktopvirtualization, soit le module PowerShell Az.DesktopVirtualization. Microsoft documente le détail dans Use the Azure CLI and Azure PowerShell with Azure Virtual Desktop. Personnellement, j’ai utilisé PowerShell, donc voici la séquence que j’ai jouée.

D’abord, installez les modules suivants :

Install-Module -Name Az.DesktopVirtualization
Install-Module -Name Az.ConnectedMachine

Ensuite, connectez-vous à Azure et basculer explicitement sur la bonne souscription :

Connect-AzAccount
Set-AzContext -Subscription '<SubscriptionId>'

Attention : si vous oubliez le Set-AzContext et que votre compte est rattaché à plusieurs souscriptions, le New-AzConnectedMachineExtension ira chercher la VM Arc dans la mauvaise souscription et vous tombera sur une erreur « machine not found » très peu parlante. Toujours vérifier avec Get-AzContext avant d’enchaîner.

Générez une clé d’enregistrement du pool d’hôtes AVD via ce script PowerShell :

$HostPoolRG = "AVD_HostPool_RG"
$HostPoolName = "avd-hybrid-hp3"

$expiresUtc = (Get-Date).ToUniversalTime().AddHours(24).ToString("yyyy-MM-ddTHH:mm:ss.fffffffZ")
$regInfo    = New-AzWvdRegistrationInfo -ResourceGroupName $HostPoolRG -HostPoolName $HostPoolName -ExpirationTime $expiresUtc
$token      = $regInfo.Token

Enfin, lancez l’extension AVD sur la machine Arc :

# Settings
$settings          = @{ isCloudDevice = $false }
$protectedSettings = @{ registrationToken = $token }
$ResourceGroupName = "Arc_Servers_RG"
$MachineName = "WIN-8C8AQIS3DUL"
$Region = "westeurope"

# Install extension
New-AzConnectedMachineExtension `
    -Name 'Microsoft.AzureVirtualDesktop.CloudDeviceExtension' `
    -ResourceGroupName $ResourceGroupName `
    -MachineName $MachineName `
    -Location $Region `
    -Publisher 'Microsoft.AzureVirtualDesktop' `
    -ExtensionType 'CloudDeviceExtension' `
    -Setting $settings `
    -ProtectedSetting $protectedSettings

Quelques précisions utiles :

$token = la registration key générée a une durée de vie limitée (max 27 jours), donc générez-la juste avant de jouer le script
ResourceGroupName et MachineName = ceux de la ressource Arc dans Azure (pas le hostname Windows brut, mais le nom sous lequel la VM apparaît dans Azure Arc > Machines)
Location = la région Azure du resource group de la machine Arc (francecentral, westeurope, etc.), pas la « localisation physique » de votre datacenter
isCloudDevice = $false est essentiel : c’est ce flag qui dit à l’extension qu’on est en mode hybride, et pas sur une VM Azure native
La registration key passe en protectedSettings, elle n’apparaîtra donc pas en clair dans la définition de l’extension

L’extension met 3 à 5 minutes à se déployer :

En coulisses, elle installe les composants AVD nécessaires (équivalent de l’agent et du bootloader sur les VMs Azure natives) et enregistre la machine auprès du host pool grâce au token.

Au bout de quelques minutes, la VM apparaît dans la liste Session hosts du host pool, avec un statut Available. Du point de vue d’AVD, c’est une VM « comme les autres » et c’est tout l’intérêt de la mécanique d’Azure Arc.

Comme pour les machines AVD hébergées dans Azure, des contrôles réguliers sont appliquées afin de vérifier leur disponibilité :

Un échec dans les contrôles AVD rendra la machine indisponible pour recevoir de nouvelles sessions utilisateurs :

Étape 6 : assigner les utilisateurs AVD

Dernière ligne droite :

Ouvrez votre application group (Desktop ou RemoteApp).
Allez dans Assignments et ajoutez les utilisateurs ou groupes Microsoft Entra qui doivent pouvoir se connecter.

Étape 7 : test de connexion AVD

Côté utilisateur : ouvrez la Windows App (web ou client lourd) et connectez-vous avec le compte Entra ID assigné.
Le desktop publié par votre validation host pool hybride apparaît. Cliquez, c’est parti.

Et voilà : vous êtes connecté à un Windows qui tourne chez vous, mais piloté par AVD dans le cloud. Première fois que je l’ai vu marcher, ça m’a clairement fait sourire 😅

Cas n°1 : Hyper-V + Windows Server domain-joined

Premier cas testé dans mon lab : une VM Windows Server 2022 qui tourne sur un nœud Hyper-V standalone, jointe à mon AD on-prem (lui-même synchronisé vers Entra ID via Microsoft Entra Connect).

OS : Windows Server 2022 Standard
Hyperviseur : Hyper-V (Windows Server 2022)
Identité : jointure de domaine AD on-prem + sync Entra Connect
Licence : Windows Server + RDS CAL

Déroulé : enrôlement Arc nickel en 3 minutes, extension AVD posée en 5 minutes, session host visible Available dans le host pool. Connexion via la Windows App avec un user du domaine sync vers Entra : OK, RDP qui négocie en 2 secondes, le bureau s’affiche. Aucun ajustement particulier nécessaire. C’est le scénario le plus « facile » car on retrouve une cinématique classique RDS, juste branchée sur AVD.

Mon retour : c’est le scénario à privilégier pour migrer un parc RDS existant. Vous gardez votre AD, vos GPO, vos profils, votre serveur de fichiers SMB, et vous échangez juste votre broker / gateway / web access RDS contre AVD. Le gain est majeur : vous récupérez la Windows App, FSLogix moderne, l’intégration Entra ID, les Insights, sans toucher à votre infra serveur.

Cas n°2 : Hyper-V + Windows 11 mono-session Entra-joined

Deuxième cas, plus moderne et plus zéro-trust : une VM Windows 11 Enterprise mono-session qui tourne aussi sur Hyper-V, mais cette fois sans aucune jointure AD, uniquement Microsoft Entra Join.

OS : Windows 11 Enterprise 24H2 (mono-session)
Hyperviseur : Hyper-V
Identité : Microsoft Entra Join pur (pas d’AD)
Licence : Microsoft 365 Business Premium

Déroulé : avant tout, j’ai pris soin de faire l’Entra Join AVANT l’enrôlement Arc (via Settings > Accounts > Access work or school). Une fois la VM jointe au tenant, l’agent Arc s’installe normalement, l’extension AVD se pose, et le session host apparaît dans le host pool. Connexion via la Windows App avec un user Entra : OK, single sign-on transparent grâce à Entra Join.

Mon retour : c’est le scénario qui me plaît le plus pour des nouveaux projets. Pas de DC à exposer au réseau de l’hyperviseur, pas de Kerberos, pas de GPO – juste Entra ID, les policies Intune, et c’est tout. Pour des cabinets, des équipes projet, des labs, ou tout ce qui n’a pas besoin de Kerberos vers du legacy, c’est la voie royale. Pour rappel : Windows 11 multi-session reste interdit en hybride, donc pour cette population, c’est mono-session ou rien.

Cas n°3 : VMware vSphere + Windows Server

Troisième cas, et celui qui intéressera beaucoup d’entreprises encore très VMware-centric : une VM Windows Server 2025 sur VMware vSphere 8, jointe au domaine.

OS : Windows Server 2025 Standard
Hyperviseur : VMware vSphere 8 (ESXi 8.0 U2)
Identité : jointure de domaine AD on-prem
Licence : Windows Server + RDS CAL

Déroulé : identique au cas n°1, à 100 %. C’est exactement ça qui est bluffant. Du point de vue d’Azure Arc et d’AVD, qu’il y ait du Hyper-V ou du vSphere en dessous ne change strictement rien. Tant que l’agent Connected Machine s’installe et que la VM peut sortir en TCP 443, c’est jeu. J’ai posé l’agent Arc, lancé l’extension AVD, le session host est apparu en Available, et un utilisateur du domaine s’est connecté via la Windows App sans broncher.

Mon retour : c’est le cas le plus politique. Pour beaucoup de DSI, « passer chez Microsoft » voulait jusqu’ici dire « abandonner VMware ». AVD Hybrid permet exactement l’inverse : garder vSphere, ne pas refaire toute son infra, et bénéficier quand même du control plane AVD moderne. Pour les organisations qui ont investi dans vSphere récemment (et il y en a beaucoup, surtout après les bouleversements de licensing VMware), c’est un message fort de Microsoft : pas besoin de tout casser pour profiter d’AVD.

Le résumé visuel de mes trois cas :

Cas	Hyperviseur	OS	Identité	Résultat
1	Hyper-V	Windows Server 2022	AD domain-join	OK – idéal pour reprise RDS
2	Hyper-V	Windows 11 mono-session	Entra Join pur	OK – idéal pour green-field zéro-trust
3	VMware vSphere 8	Windows Server 2025	AD domain-join	OK – idéal pour parcs vSphere existants

Et la conclusion qui me semble importante : les trois cas suivent rigoureusement la même procédure. La doc Microsoft est tenue à la lettre, les scripts d’onboarding fonctionnent à l’identique, l’extension AVD se pose pareil. Aucune divergence d’OS ou d’hyperviseur n’a nécessité de bricolage particulier. C’est rare et c’est notable.

Les limitations et pièges à connaître

Parce qu’on est en Public Preview, il y a quelques verrues à garder en tête :

Limitation	Impact
Validation host pool obligatoire	Tout passage en prod nécessitera un redéploiement à la GA
Windows 11 multi-session non supporté hors Azure	Multi-utilisateur obligatoire = Windows Server
Auto-Scale absent	Provisioning manuel ou via votre orchestrateur d’hyperviseur
Start VM on Connect absent	Les session hosts doivent être déjà allumés côté hyperviseur
Power management Azure portal absent	Le start/stop se fait dans votre console d’hyperviseur, pas Azure
Session Host Configuration absent	Pas de « build automatique » du session host depuis le portail
Identité à fixer AVANT Arc	Changer d’identité après onboarding = désinstaller / réinstaller
Pas de date de GA annoncée	À tester en pilote, pas à passer en prod critique

Et comme toujours avec les previews Microsoft, la feature peut encore évoluer avant la GA (interface, intégrations supplémentaires, prise en charge du multi-session, modèle de licence Windows Cloud Hybrid). À surveiller de près.

Conclusion

C’est clairement l’une des évolutions que beaucoup de monde attendait, et pas juste les fans de la marque AVD (comme moi 😅). AVD Hybrid règle un vrai point bloquant : pour faire du AVD ailleurs que dans Azure, il fallait jusqu’ici passer par Azure Local et son hardware certifié, ce qui excluait de fait toutes les entreprises encore en VMware ou Nutanix. Avec cette préversion, Microsoft signe un geste d’ouverture rare : votre hyperviseur, peu importe lequel, peut héberger des session hosts AVD pilotés par Azure Arc.

Ce qui me plaît particulièrement : la cohérence de la procédure entre les trois cas que j’ai testés (Hyper-V Server domain-joined, Hyper-V Windows 11 Entra-joined, VMware vSphere domain-joined), la simplicité du branchement via Azure Arc (les admins qui pratiquent déjà Arc sur du Defender for Cloud ou de l’Update Manager seront en territoire connu), et le fait qu’on retrouve l’écosystème AVD complet (Windows App, Entra ID, FSLogix, Insights) plutôt qu’une version dégradée.

Ce qui mérite vigilance : le statut Public Preview qui impose des validation host pools, l’absence d’Auto-Scale qui peut bloquer pour les gros parcs, l’interdiction du multi-session hors Azure qui force à repenser certains designs, et le flou sur la licence Windows Cloud Hybrid qui arrivera à la GA. Je l’intègre dès maintenant dans mes projets PoC, mais avec un pilote propre avant toute généralisation.

En tout cas, si vous avez du Hyper-V, du VMware ou du Nutanix qui tourne en datacenter, foncez tester : Azure portal > Azure Virtual Desktop > Host pools > Create, cochez Validation environment: Yes, puis enrôlez vos VMs via Azure Arc et posez l’extension AVD.

La documentation officielle est claire et la procédure marche du premier coup. Et dites-moi dans les commentaires ce que vous en pensez, surtout si vous avez essayé sur un hyperviseur que je n’ai pas couvert (Proxmox ? KVM ? Hyper-V Azure Local ?), je suis curieux de vos retours !

Azure Virtual Desktop hybride + SSO

Azure Virtual Desktop est souvent présenté comme une solution offrant un Single Sign-On “natif”. Dès que l’on sort d’un environnement cloud-only pour entrer dans un contexte hybride, les mécanismes d’authentification deviennent toutefois plus complexes, et parfois déroutants. Entre Microsoft Entra ID, Active Directory, Kerberos, PRT, Seamless SSO et Cloud Kerberos Trust, il est facile de confondre des briques aux noms proches, mais qui n’interviennent ni au même moment ni au même niveau.

Dans un précédent article, j’avais détaillé la mise en place du SSO Azure Virtual Desktop dans un environnement cloud-only.

Dans cet article, j’ai volontairement changé de contexte pour travailler sur un environnement hybride. L’objectif de cet article est de répondre aux trois questions suivantes :

Clarifier les mécanismes d’authentification (PRT, Seamless SSO, Kerberos, etc.)
Montrer pas à pas pourquoi certaines étapes sont indispensables pour obtenir un SSO réellement transparent dans AVD.
A quoi sert le Seamless SSO disponible dans Entra Connect Sync ?

Avant d’aborder la configuration et les tests, il est utile de poser le cadre : comprendre quels mécanismes d’authentification sont utilisés, à quel moment, et pourquoi certains fonctionnent seuls alors que d’autres doivent être combinés.

Cette FAQ a pour objectif de lever les confusions les plus fréquentes autour des tokens, du Kerberos, et du Single Sign-On dans un environnement Microsoft Entra hybride.

Quels sont les tokens utilisés par Microsoft Entra ID ?

Microsoft Entra ID utilise plusieurs types de tokens, chacun ayant un rôle précis :

Primary Refresh Token (PRT)
- Jeton long terme
- Spécifique à l’appareil
- Sert à demander d’autres tokens
- Utilisé par Windows (WAM – Web Account Manager)

Access Token
- Jeton court terme
- Présenté aux applications (API, Office, AVD…)
- Contient les claims utilisateur

Refresh Token
- Permet de renouveler un Access Token
- Généralement géré automatiquement par le système

Qu’est-ce que le Primary Refresh Token (PRT) ?

Dans le monde de Microsoft, le PRT est un jeton émis par Microsoft Entra ID lorsqu’un appareil est Microsoft Entra Joined ou Microsoft Entra Hybrid Joined.

Un jeton d’actualisation principal (PRT) est un artefact clé de l’authentification Microsoft Entra dans les versions prises en charge de Windows, iOS/macOS, Android et Linux. Un PRT est un artefact sécurisé spécialement émis aux répartiteurs de jetons microsoft pour activer l’authentification unique (SSO) sur les applications utilisées sur ces appareils.

Microsoft Learn

Le PRT est stocké localement sur la machine et sert de jeton racine pour :

obtenir des tokens d’accès OAuth 2.0
s’authentifier automatiquement aux services cloud Microsoft
éviter toute ressaisie de mot de passe pour les applications modernes

Concrètement, le PRT permet :

l’ouverture automatique de session dans Edge
l’authentification transparente à Office, Teams, OneDrive
l’utilisation de Windows App / Azure Virtual Desktop web

Point important : le PRT n’est pas Kerberos et ne permet pas, à lui seul, d’ouvrir une session Windows sur une machine Active Directory.

Pourquoi le PRT ne suffit-il pas pour Azure Virtual Desktop en mode Hybride ?

Dans un environnement Azure Virtual Desktop en mode Hybride, il y a deux niveaux d’authentification distincts :

Accès au service AVD (broker / portail)
→ Authentification Microsoft Entra ID
→ Le PRT suffit
Ouverture de la session Windows sur le session host
→ Authentification Active Directory
→ Un TGT Kerberos est obligatoire

Dans un environnement Microsoft Entra Hybrid Joined, le PRT est présent, mais le TGT Kerberos n’est pas automatiquement délivré par Entra.

Cela permet de comprendre pourquoi une seconde authentification Active Directory est fréquemment observée dans de nombreux environnements AVD, après une première authentification Entra.

Qu’est-ce qu’un TGT Kerberos Active Directory ?

Le Ticket Granting Ticket (TGT) est un jeton Kerberos délivré par un contrôleur de domaine Active Directory.

Il est obtenu :

lors de l’ouverture de session Windows
après une authentification réussie auprès de l’AD

Le TGT permet ensuite :

d’accéder aux ressources Active Directory
d’obtenir des tickets de service (CIFS, LDAP, HTTP, etc.)
d’ouvrir une session Windows locale ou distante

Sans TGT Kerberos, l’ouverture d’une session Active Directory n’est pas possible.

Qu’est-ce que Microsoft Entra Kerberos (Cloud Kerberos Trust) ?

Microsoft Entra Kerberos est le mécanisme qui permet à Microsoft Entra ID de :

générer un TGT Kerberos Active Directory
à partir d’une authentification cloud
sans nécessiter ADFS

Techniquement :

un objet Kerberos spécial est créé dans l’Active Directory
les clés sont synchronisées avec Microsoft Entra ID
Entra devient capable d’émettre un TGT valide pour l’AD

C’est l’élément nécessaire pour obtenir un SSO complet dans AVD en environnement hybride.

Pourquoi la jointure hybride améliore l’expérience SSO ?

Avec Microsoft Entra Hybrid Join :

l’appareil est reconnu par Entra
un PRT est délivré
les applications cloud utilisent un SSO moderne

En ajoutant Microsoft Entra Kerberos :

Entra peut aussi délivrer un TGT AD
Windows peut ouvrir la session sans redemande de mot de passe

On comprend alors que la combinaison du PRT et d’un TGT Kerberos est nécessaire pour obtenir un SSO transparent dans Azure Virtual Desktop.

À quoi sert la case “Single sign-on” dans Entra Connect ?

La case Single sign-on dans Microsoft Entra Connect active ce qu’on appelle Seamless SSO.

Seamless SSO repose sur :

Kerberos
le compte AD AZUREADSSOACC
le site autologon.microsoftazuread-sso.com

Son objectif est volontairement limité :

éviter la saisie du mot de passe AD
lors d’une authentification navigateur vers Entra ID
sur une machine AD-only

Il est important de distinguer Seamless SSO des autres mécanismes :

ne crée PAS de PRT
ne remplace PAS Microsoft Entra Kerberos
ne supprime PAS tous les écrans de login

Pour se donner une meilleure idée de cette fonctionnalité SSO spécifique, nous la testerons dans la dernière étape de cet article.

Mais commençons d’abord par tester la mise en place du single sign-on complet pour un environnement AVD de mode hybride, dont les procédures officielles sont disponibles ici et là :

Etape 0 – Configuration de base :

Dans mon environnement de test, j’ai déjà configuré certains composants.

Un environnement Active Directory
Microsoft Entra Connect configuré avec
- Password Hash Synchronization (PHS)
- sans Single sign-on,
- avec Hybrid Joined pour les machines Windows 10/11
- Synchronisation de l’OU des utilisateurs AVD
- Synchronisation de l’OU des machines hôtes AVD

Un environnement Azure Virtual Desktop avec deux machines virtuelles jointes à AD :

Notre environnement AVD en mode hybride est en place, commençons par un premier test.

Etape I – Test sans configuration SSO :

Avant d’aller plus loin, j’effectue déjà un premier test de connexion d’un utilisateur AVD depuis le portail web :

Une authentification AD est demandée lors de l’ouverture de la session Windows, c’est un comportement normal à ce stade car rien n’est configuré :

La commande dsregcmd /status sert à afficher l’état d’enregistrement de l’appareil auprès d’Entra ID et, concernant le PRT (Primary Refresh Token), elle fournit des informations de diagnostic sur sa présence et son état :

AzureAdPrt : YES / NO : Indique si un PRT est présent sur la machine pour l’utilisateur
AzureAdPrtUpdateTime : Date/heure du dernier rafraîchissement du PRT
AzureAdPrtExpiryTime : Date/heure d’expiration du PRT
AzureAdPrtAuthority : Autorité qui a émis le token (généralement login.microsoftonline.com).

Concernant la partie des tickets, voici ce que l’on peut aussi en déduire :

OnPremTgt : NO : cela indique si la session utilisateur courante ne possède pas Ticket Granting Ticket Kerberos émis par un contrôleur de domaine AD.
CloudTgt : YES : indique la présence d’un TGT Kerberos cloud, émis par Entra ID.

Comme on peut le constater, le PRT émis via Entra fonctionne bien pour les services Cloud, mais l’ouverture de session et l’accès à certaines ressources gérées par l’AD pourraient être restreints dans la situation actuelle.

Commençons étape par étape les changements pour arriver à une configuration complète.

Etape II – Configuration SSO du pool d’hotes AVD :

Sur le portail Azure, comme l’indique la documentation Microsoft, j’effectue la configuration SSO du host pool Azure Virtual Desktop afin d’activer “Microsoft Entra authentication for single sign-on” :

J’effectue un nouveau test avec mon utilisateur :

À ce stade, une authentification AD est encore demandée lors de l’ouverture de la session Windows :

Etape III – Création d’un objet serveur Kerberos :

Sur le serveur AD, comme l’indique la documentation Microsoft, je commence par installer le module AzureADHybridAuthenticationManagement :

# First, ensure TLS 1.2 for PowerShell gallery access.
[Net.ServicePointManager]::SecurityProtocol = [Net.ServicePointManager]::SecurityProtocol -bor [Net.SecurityProtocolType]::Tls12

# Install the AzureADHybridAuthenticationManagement PowerShell module.
Install-Module -Name AzureADHybridAuthenticationManagement -AllowClobber

Pour créer l’objet Kerberos Server nécessaire au Cloud Kerberos Trust, j’ai choisi l’exemple 4 de la documentation Microsoft :

Cet exemple exploite l’authentification moderne basée sur le User Principal Name (UPN) sans exiger de mot de passe AD explicite.
Il s’intègre parfaitement dans un environnement hybride sécurisé avec MFA et politiques d’accès conditionnel
Il évite les écueils des méthodes utilisant NTLM ou des identifiants AD en clair.

# Specify the on-premises Active Directory domain. A new Microsoft Entra ID
# Kerberos Server object will be created in this Active Directory domain.
$domain = $env:USERDNSDOMAIN

# Enter a UPN of a Hybrid Identity Administrator
$userPrincipalName = "administrator@contoso.onmicrosoft.com"

# Create the new Microsoft Entra ID Kerberos Server object in Active Directory
# and then publish it to Azure Active Directory.
# Open an interactive sign-in prompt with given username to access the Microsoft Entra ID.
Set-AzureADKerberosServer -Domain $domain -UserPrincipalName $userPrincipalName

Je lance donc le script à la suite du précédent, en prenant soin de remplacer l’UPN par un administrateur général ou hybride :

Je vérifie le serveur Microsoft Entra Kerberos nouvellement créé à l’aide de la commande suivante :

# When prompted to provide domain credentials use the userprincipalname format for the username instead of domain\username
Get-AzureADKerberosServer -Domain $domain -UserPrincipalName $userPrincipalName -DomainCredential (get-credential)

Enfin je constate la présence krbtgt_AzureAD utilisé par les DC pour signer les TGT Kerberos. Il s’agit d’une séparation cryptographique claire avec krbtgt dans le cadre de Kerberos émis depuis Entra :

J’effectue un nouveau test avec mon utilisateur :

Une fois le Cloud Kerberos Trust et l’authentification RDP Microsoft Entra activés, la seconde authentification Active Directory disparaît et est remplacée par un simple message de consentement Allow Remote Desktop connection :

Entra veut un consentement explicite de l’utilisateur. Ce message ne correspond pas à une authentification supplémentaire, mais à une demande de confiance entre l’utilisateur et le session host :

Si l’utilisateur clique sur Oui, ce consentement sera conservé 30 jours et ne pourra pas mémoriser plus de 15 hôtes.

L’Étape suivante consiste donc à supprimer définitivement le popup en déclarant les session hosts comme appareils de confiance dans Microsoft Entra ID.

Etape IV – Activation de l’authentification Microsoft Entra pour RDP :

Commençons par autoriser Microsoft Entra dans l’authentification pour Windows sur le tenant. Pour cela, j’utilise Azure Cloud Shell depuis le portail Azure :

J’importe les deux modules Microsoft Graph suivants, puis je me connecte avec le compte au permissions appropriées :

Import-Module Microsoft.Graph.Authentication
Import-Module Microsoft.Graph.Applications

Connect-MgGraph -Scopes "Application.Read.All","Application-RemoteDesktopConfig.ReadWrite.All"

Je récupère l’ID d’objet pour le principal du service de connexion au Windows Cloud :

$WCLspId = (Get-MgServicePrincipal -Filter "AppId eq '270efc09-cd0d-444b-a71f-39af4910ec45'").Id

Je modifie la propriété isRemoteDesktopProtocolEnabled sur True :

If ((Get-MgServicePrincipalRemoteDesktopSecurityConfiguration -ServicePrincipalId $WCLspId) -ne $true) {
    Update-MgServicePrincipalRemoteDesktopSecurityConfiguration -ServicePrincipalId $WCLspId -IsRemoteDesktopProtocolEnabled
}

Je vérifie que la propriété isRemoteDesktopProtocolEnabled est correctement définie :

Get-MgServicePrincipalRemoteDesktopSecurityConfiguration -ServicePrincipalId $WCLspId

Afin de masquer la boîte de dialogue en configurant la liste des hôtes AVD approuvés, je créé un groupe dans Entra ID contenant les hôtes de sessions :

J’utilise une requête dynamique pour ajouter automatiquement mes prochains hôtes dans le groupe :

Enfin, toujours dans la même session d’Azure Cloud Shell, j’ajoute l’ID de groupe à une propriété sur le principal du service SSO Windows Cloud Login.

$tdg = New-Object -TypeName Microsoft.Graph.PowerShell.Models.MicrosoftGraphTargetDeviceGroup
$tdg.Id = "<Group object ID>"
$tdg.DisplayName = "<Group display name>"

New-MgServicePrincipalRemoteDesktopSecurityConfigurationTargetDeviceGroup -ServicePrincipalId $WCLspId -BodyParameter $tdg

Enfin, je vérifie la bonne assignation du groupe :

J’effectue un nouveau test avec mon utilisateur :

Cette fois l’authentification passe sans encombre. Un TGT Kerberos AD DS (on-premises) est maintenant présent dans la session.

Cela permet d’observer que :

La machine est Hybrid Entra ID Joined
Le PRT est valide
Le Kerberos cloud fonctionne
Le Kerberos AD DS fonctionne
Les deux mondes coexistent simultanément dans la même session

Cette sortie correspond à un état hybride cohérent, où les mécanismes cloud et on-premises coexistent.

Pour finir, je vous propose de tester l’impact du Seamless SSO présent et configurable dans Entra Connect Sync.

Etape V – Activation du SSO d’Entra Connect Sync :

Pour cela, je décide de rajouter une troisième machine AVD :

Celle-ci est bien présente dans l’Active Directory :

Mais elle n’est pas présente dans Entra ID :

Pour ne pas perturber mes tests, je décide donc de bloquer la connexion aux deux autres VMs AVD :

J’effectue un test avec mon utilisateur :

Comme aucune configuration hybride n’est en place pour cette machine AVD, il n’y a pas de ticket TGT Kerberos émis par Entra ID, donc la seconde authentification AD est logique :

Une fois dans la session Windows, dsregcmd nous affiche les informations suivantes :

La machine est jointe uniquement à Active Directory on-premises
Elle n’est pas jointe à Entra ID
Elle n’est pas Hybrid Join
Aucun PRT
Aucun SSO cloud
Aucune authentification Entra ID
Une tentative d’Entra ID Join / Hybrid Join a eu lieu
- Elle a échoué côté Entra ID
- La machine AVD n’existe pas ou n’est pas reconnu dans le tenant

L’ouverture de la page d’authentification d’Office 365 dans Microsoft Edge me montre d’ailleurs aucune connexion SSO :

Je décide donc d’activer la fonctionnalité SSO dans Entra Connect Sync :

Une fois la configuration terminée, je constate la création de AZUREADSSOACC en tant que compte ordinateur créé dans Active Directory :

Ce dernier est créé automatiquement lors de l’activation de Seamless Single Sign-On (Seamless SSO) avec Entra ID. Le compte est utilisé par Entra ID pour :

établir une relation de confiance Kerberos avec l’AD on-prem
permettre le SSO sans saisie de mot de passe depuis des postes domain-joined vers Entra ID

J’effectue donc un nouveau test avec mon utilisateur :

Dans ce contexte, il est logique que l’authentification AD soit toujours demandée :

Une fois la session Windows ouverte, comme Seamless SSO fonctionne via l’adresse autologon.microsoftazuread-sso.com, je décide de la rajouter en tant qu’URL de l’Intranet local.

Pour cela, j’ouvre inetcpl.cpl :

Je clique sur Site dans Intranet local :

Je clique sur Avancée :

Je rajoute l’URL suivante :

https://autologon.microsoftazuread-sso.com

Toujours dans Intranet Local, je coche Connexion automatique avec le nom d’utilisateur et le mot de passe actuels :

Quelques minutes plus tard, j’ouvre Microsoft Edge et je constate l’authentification automatique de mon compte Cloud correspondant :

La présence du ticket HTTP/autologon.microsoftazuread-sso.com dans le cache Kerberos confirme que le mécanisme Seamless SSO est bien actif. Ce ticket, émis par le contrôleur de domaine à destination de Microsoft Entra ID, permet une authentification navigateur sans saisie de mot de passe.

klist

Il est important de noter que ce mécanisme n’est pas celui utilisé pour l’ouverture de session Windows dans Azure Virtual Desktop, qui repose sur un TGT Kerberos distinct délivré via Microsoft Entra Kerberos (krbtgt_AzureAD).

Conclusion

À travers ces différents tests et configurations, on constate que le Single Sign-On dans Azure Virtual Desktop hybride ne repose pas sur un mécanisme unique, mais sur une combinaison cohérente de plusieurs briques d’authentification.

Le PRT permet une authentification fluide aux services cloud, mais il ne suffit pas à lui seul pour ouvrir une session Windows dans un contexte Active Directory. C’est bien l’association du Hybrid Join, du Cloud Kerberos Trust et de l’authentification Microsoft Entra pour RDP qui permet d’aligner les mondes cloud et on-premises, et d’obtenir une expérience utilisateur réellement transparente dans AVD.

Comprendre ces mécanismes permet non seulement d’éviter des configurations incomplètes, mais aussi d’expliquer pourquoi certains scénarios fonctionnent “presque”, tout en continuant à demander une authentification supplémentaire.

FSLogix pour Entra ID !

Depuis de longues années, la communauté Azure Virtual Desktop attendait la possibilité de déployer un environnement entièrement cloud, sans dépendance à un domaine Active Directory classique ou à une architecture hybride complexe. Cette évolution permet enfin d’envisager un modèle moderne, simplifié et résolument cloud-native.

Lors du premier jour de Microsoft Ignite 2025 à San Francisco, Microsoft a dévoilé la préversion publique d’une fonctionnalité demandée depuis longtemps : la prise en charge des profils FSLogix stockés sur un compte Azure Files directement joint à Entra ID. Une étape majeure dans la modernisation de l’environnement AVD.

Au-delà du progrès technique évident (principalement la simplification de l’infrastructure) cette nouveauté transforme aussi la manière d’aborder la gestion des accès distants et des profils utilisateurs.

Elle marque le passage d’un modèle traditionnel mêlant domaine Active Directory, synchronisation, et Kerberos hybride, vers un modèle entièrement cloud-only : plus léger, plus agile et parfaitement adapté aux organisations modernes, aux partenaires externes ou encore aux environnements projet éphémères.

Cette annonce fut d’ailleurs intégrée à celle des identités externes sur AVD et Windows 365 :

Pour offrir une expérience simplifiée dans un environnement mutualisé Azure Virtual Desktop pour les identités externes, vous pouvez créer un partage de fichiers dans Azure Files afin de stocker les profils FSLogix pour ces identités.

Cette fonctionnalité est désormais disponible en préversion publique. Pour créer un partage de fichiers SMB pour les profils FSLogix pour les identités externes :

Créez un nouveau compte de stockage et un nouveau partage de fichiers configurés pour utiliser l’authentification Microsoft Entra Kerberos.(Nouveau) Lorsque vous attribuez des autorisations pour le partage de fichiers, utilisez la nouvelle page Gérer l’accès pour attribuer des listes de contrôle d’accès (ACL) au groupe Entra ID contenant vos identités externes.

Microsoft Techcommunity

Microsoft illustre également cette nouveauté avec une copie d’écran montrant la gestion native des droits NTFS d’un partage Azure Files directement depuis le portail Azure, ce qui constitue une avancée très attendue :

Qu’est-ce qu’une identité cloud-only ?

Il s’agit d’un utilisateur géré uniquement dans Entra ID, sans représentation dans un Active Directory on-prem, ni synchronisation : idéal pour des contractors, partenaires, ou utilisateurs externes.

Est-ce que FSLogix fonctionne avec ces identités externes / cloud-only ?

Oui, le support FSLogix pour cloud-only & external identities est désormais en preview, ce qui permet de gérer les profils utilisateurs de façon identique à un utilisateur « classique ».

Que change concrètement pour un architecte cloud ou un administrateur ?

Cela signifie moins de dépendances à un AD on-prem, moins de complexité, une gestion simplifiée des utilisateurs externes ou contractors, et un modèle plus cloud-native.

Plusieurs vidéos sont également disponible pour vous aider à la tâche :

Pour y parvenir, plusieurs documentations sont disponibles afin de mettre en place toute la chaîne. Le premier guide Microsoft explique comment activer Kerberos Entra sur Azure Files, tandis que le second part de ce socle et donne seulement ce qu’il faut ajouter pour FSLogix :

Je vous propose donc de passer en revue, étape par étape, l’ensemble de la configuration permettant de tester cette nouvelle fonctionnalité encore en préversion.

L’objectif est de comprendre son fonctionnement réel, ses limites et les scénarios dans lesquels elle pourra s’intégrer :

Etape 0 – Rappel des prérequis :

Pour réaliser ce test FSLogix en mode 100% Cloud-only, il vous faudra disposer de :

Un abonnement Azure valide
Un tenant Microsoft

Afin d’être sûr des impacts de nos différentes actions, je vous propose de commencer par la création d’une nouvel utilisateur 100% Cloud, donc non synchronisé à un environnement Active Directory.

Etape I – Préparation de l’environnement :

Création d’un utilisateur cloud-only pour préparer l’environnement sans synchronisation AD :

Mise en place du réseau virtuel qui servira de base à l’environnement Azure Virtual Desktop :

Déploiement d’un compte de stockage Azure Files Premium pour accueillir les profils FSLogix :

Activation de l’identité Microsoft Entra directement sur le compte de stockage :

Activation du support Microsoft Entra Kerberos pour gérer l’authentification :

Application des permissions par défaut via le rôle Storage File Data SMB Share Contributor :

Création du partage de fichiers pour FSLogix, avec l’identité Microsoft Entra toujours active :

Recherche de l’application d’entreprise générée automatiquement pour ce compte de stockage :

Attribution du consentement administrateur global pour autoriser l’application

Validation de l’autorisation accordée à l’application d’entreprise :

Vérification des permissions héritées depuis l’admin consent sur l’application liée au stockage :

Ajout de la prise en charge des groupes dans le manifeste :

["kdc_enable_cloud_group_sids"],

Retrait du compte de stockage dans les polices d’accès conditionnel exigeant une MFA :

Création d’un environnement Azure Virtual Desktop avec deux machines virtuelles :

Activation du Single Sign-On directement dans les propriétés RDP :

Exécution du premier script PowerShell via Run Command pour activer la récupération du ticket Kerberos :


reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters" /v CloudKerberosTicketRetrievalEnabled /t REG_DWORD /d 1 /f

Confirmation que la clé de registre est bien apparue :

Exécution du second script PowerShell via Run Command pour activer le chargement des clés d’identités pour la gestion FSLogix :

reg add HKLM\Software\Policies\Microsoft\AzureADAccount /v LoadCredKeyFromProfile /t REG_DWORD /d 1

Vérification de la création de la clé de registre attendue dans Windows :

Application de la configuration complète FSLogix via les différentes clés de registre :

reg add "HKLM\SOFTWARE\FSLogix\Profiles" /v DeleteLocalProfileWhenVHDShouldApply /t REG_DWORD /d 1 /f
reg add "HKLM\SOFTWARE\FSLogix\Profiles" /v Enabled /t REG_DWORD /d 1 /f
reg add "HKLM\SOFTWARE\FSLogix\Profiles" /v FlipFlopProfileDirectoryName /t REG_DWORD /d 1 /f
reg add "HKLM\SOFTWARE\FSLogix\Profiles" /v LockedRetryCount /t REG_DWORD /d 3 /f
reg add "HKLM\SOFTWARE\FSLogix\Profiles" /v LockedRetryInterval /t REG_DWORD /d 15 /f
reg add "HKLM\SOFTWARE\FSLogix\Profiles" /v ProfileType /t REG_DWORD /d 0 /f
reg add "HKLM\SOFTWARE\FSLogix\Profiles" /v ReAttachIntervalSeconds /t REG_DWORD /d 15 /f
reg add "HKLM\SOFTWARE\FSLogix\Profiles" /v ReAttachRetryCount /t REG_DWORD /d 3 /f
reg add "HKLM\SOFTWARE\FSLogix\Profiles" /v SizeInMBs /t REG_DWORD /d 30000 /f
reg add "HKLM\SOFTWARE\FSLogix\Profiles" /v VHDLocations /t REG_MULTI_SZ /d "\\cloudonlysa.file.core.windows.net\profiles" /f
reg add "HKLM\SOFTWARE\FSLogix\Profiles" /v VolumeType /t REG_SZ /d "VHDX" /f

Vérification de la création des clés de registre attendues pour FSLogix :

Alternative via Intune pour gérer ces mêmes paramètres sans script :

!!! Redémarrage des machines virtuelles du host pool pour appliquer la configuration !!!

Etape II – Test de connexion AVD :

Attente du retour en ligne des machines dans l’environnement AVD :

Activation du mode de drainage sur la seconde machine pour préparer les tests :

Connexion avec l’utilisateur de test pour valider le fonctionnement :

Observation du démarrage du service FSLogix App Services à l’ouverture de session :

Création du dossier de profil FSLogix directement dans le file share :

Présence du fichier VHDx correspondant au profil utilisateur :

Impossibilité de supprimer le fichier VHDx car il est monté et en cours d’utilisation :

Confirmation dans les logs FSLogix que le profil VHDx est correctement chargé :

Inversion du mode de drainage sur les deux machines AVD :

Reconnexion avec l’utilisateur de test pour valider la bascule du profil :

Montage d’un partage réseau pour inspecter le contenu du partage de fichier Azure :

Vérification que la permission générée pour l’utilisateur de test est bien présente :

Afin de finaliser correctement la configuration des permissions pour les profils FSLogix, il est nécessaire de les restreindre pour plus de sécurité.

Etape III – Configurations des permissions NTFS Access Control Lists :

Depuis l’explorateur Windows, je constate que certaines permissions restent visibles, alors qu’elles ne devraient être retirées pour des questions de sécurité :

Je constate également l’impossibilité de modifier les permissions directement depuis Windows ou via une commande ICACLS :

Comme l’indique la documentation Microsoft ci-dessous, tout ne semble pas encore au point :

Travis Roberts rencontre d’ailleurs le même souci que moi :

Pour configurer les Windows ACLs, il sera donc nécessaire de passer par le menu Manage Access, visible depuis un portail Azure en préversion, comme le recommande Microsoft dans la documentation :

Le bouton Manage access est alors visible juste ici :

Ce menu n’est d’ailleurs pas visible dans le portail classique d’Azure :

L’affichage des permissions NTFS Access Control Lists configurées par défaut :

Les permissions pour FSLogix doivent alors être reconfigurées comme telles :

Cela donne ceci sur le partage de fichier FSLogix :

Les tests initiaux montrent que l’intégration fonctionne correctement entre FSLogix et Azure Virtual Desktop. Toutefois, quelques écarts apparaissent encore entre la documentation Microsoft et le comportement observé dans mon environnement, ce qui mérite d’être signalé dans le cadre de cette préversion.

Pour compléter mon analyse, il est intéressant de comparer les performances (IOPS et Throughput) entre plusieurs types de stockage, notamment ceux intégrés avec Entra ID.

Etape IV – Tests de performances :

J’ai souhaité comparé les performances entre différents types de stockage afin de bien comprendre l’impact ou non des performances avec cette jointure à Entra ID :

Partage de fichiers sur un compte de stockage Premium joint à Entra ID
Partage de fichiers sur un compte de stockage Premium non joint à Entra ID
Disque Premium SSD v2, configuré avec 30000 IOPS et 1200 de Throughput

Pour réaliser les mesures, nous utiliserons l’outil Diskspd :

DISKSPD est un outil que vous pouvez personnaliser pour créer vos propres charges de travail synthétiques. Nous utiliserons la même configuration que celle décrite ci-dessus pour exécuter des tests d’évaluation. Vous pouvez modifier les spécifications pour tester différentes charges de travail.

Microsoft Learn

Microsoft recommande d’utiliser l’utilitaire DiskSpd (https://aka.ms/diskspd) pour générer une charge sur un système de disques (stockage) et … pour mesurer les performances du stockage et obtenir la vitesse maximale disponible en lecture/écriture et les IOPS du serveur spécifique.

Windows OS Hub

Sur votre machine virtuelle de test, téléchargez l’exécutable via ce lien Microsoft, puis ouvrez l’archive ZIP téléchargée :

Copiez le contenu de l’archive dans un nouveau dossier créé sur le disque C :

L’exécutable se trouve dans le sous-dossier amd64 :

Les 2 étapes suivantes sont dédiées aux tests de performances des disques via l’application Diskspd. Microsoft met d’ailleurs à disposition un protocole similaire de tests juste ici :

Deux séries de tests sont conseillées pour exploiter le deux caractéristiques suivantes :
- IOPS
- Débit
Le changement entre ces deux séries se fera au niveau de la taille des blocs.

Commencez une première salve de tests pour déterminer les IOPS max pour chacun des espaces de stockage :

Partage de fichiers sur un compte de stockage Premium joint à Entra ID :

Partage de fichiers sur un compte de stockage Premium non joint à Entra ID :

Disque Premium SSD v2 configuré avec 30000 IOPS et 1200 de Throughput :

Ouvrez Windows PowerShell ISE, puis lancez les commandes des test suivantes, une à une ou à la chaîne, en modifiant les paramètres si besoin :

C:\SPD\amd64\diskspd.exe -d180 -r -w100 -F4 -o128 -b8K -Sh -L -c50G Y:\diskpsdtmp.dat > C:\SPD\amd64\IOPS-AvecEntraID.txt 

C:\SPD\amd64\diskspd.exe -d180 -r -w100 -F4 -o128 -b8K -Sh -L -c50G W:\diskpsdtmp.dat > C:\SPD\amd64\IOPS-SansEntraID.txt 

C:\SPD\amd64\diskspd.exe -d180 -r -w100 -F4 -o128 -b8K -Sh -L -c50G E:\diskpsdtmp.dat > C:\SPD\amd64\IOPS-PSSDv2.txt 

C:\SPD\amd64\diskspd.exe -d180 -r -w100 -F4 -o128 -b64K -Sh -L -c50G Y:\diskpsdtmp.dat > C:\SPD\amd64\Throughput-AvecEntraID.txt 

C:\SPD\amd64\diskspd.exe -d180 -r -w100 -F4 -o128 -b64K -Sh -L -c50G W:\diskpsdtmp.dat > C:\SPD\amd64\Throughput-SansEntraID.txt 

C:\SPD\amd64\diskspd.exe -d180 -r -w100 -F4 -o128 -b64K -Sh -L -c50G E:\diskpsdtmp.dat > C:\SPD\amd64\Throughput-PSSDv2.txt

Les arguments utilisés pour diskspd.exe sont les suivants :

-d900 : durée du test en secondes
-r : opérations de lecture/écriture aléatoires
-w100 : rapport entre les opérations d’écriture et de lecture 100%/0%
-F4 : nombre de threads max
-o128 : longueur de la file d’attente
-b8K : taille du bloc
-Sh : ne pas utiliser le cache
-L : mesure de la latence
-c50G : taille du fichier 50 GB
E:\diskpsdtmp.dat : chemin du fichier généré pour le test
> IOPS-AvecEntra.txt : fichier de sortie des résultats

Une fois tous les tests terminés, les résultats sont alors compilés pour les 3 stockages :

Scenario	IOPS	Bandwidth MB/s
Avec Entra ID	12,446.88	299.95
Sans Entra ID	15,032.54	341.17
Premium SSD v2	20,378.31	1,167.25

Les résultats montrent que le Premium SSD v2 délivre les meilleures performances dans ton environnement, avec le plus haut niveau d’IOPS et de bande passante, suivi par le scénario Sans Entra ID, puis par le scénario Avec Entra ID qui obtient systématiquement les valeurs les plus faibles.

La différence entre les scénarios avec et sans Entra ID pourrait s’expliquer par la présence d’une couche d’authentification et de gestion de profils qui ajoute des opérations supplémentaires lors des accès disque, en particulier si le système doit interroger un service distant, valider un token, ou maintenir une session d’identité pour chaque opération liée au profil utilisateur.

Même si cette charge reste faible en théorie, elle peut introduire une latence additionnelle dans un flux d’I/O intensif, ce qui réduirait mécaniquement les IOPS et la bande passante observées.

Conclusion

Le support des identités cloud-only et externes pour Azure Virtual Desktop, associé à l’intégration de FSLogix, représente une évolution majeure dans l’écosystème Microsoft. Cette approche permet désormais de déployer des environnements VDI complets sans aucune dépendance à Active Directory, tout en simplifiant considérablement l’architecture.

Cette modernisation apporte davantage de flexibilité, réduit les contraintes opérationnelles et ouvre la voie à de nouveaux scénarios cloud-native, adaptés aussi bien aux entreprises qu’aux équipes projet, partenaires ou prestataires externes.

Bien que la fonctionnalité soit encore en préversion, elle laisse entrevoir un futur où les environnements virtualisés seront plus simples, plus économiques et mieux intégrés à l’identité Microsoft Entra.

OneDrive & RemoteApp AVD

Azure Virtual Desktop intègre OneDrive depuis déjà quelques années, que ce soit via le bureau à distance ou les applications sous RemoteApp. Mais Microsoft améliore l’expérience utilisateur dans le cadre des applications lancées RemoteApp (publication d’applications sans bureau Windows).

En effet, il est possible de monter la ressource OneDrive liée au compte AVD automatiquement sur le poste local ! Concrètement, l’utilisateur ouvre son application RemoteApp et aura accès à OneDrive depuis son application ou son poste local.

Vous pouvez utiliser Microsoft OneDrive avec une RemoteApp dans Azure Virtual Desktop (preview), ce qui permet aux utilisateurs d’accéder à leurs fichiers et de les synchroniser lorsqu’ils utilisent une RemoteApp. Lorsqu’un utilisateur se connecte à une RemoteApp, OneDrive peut être lancé automatiquement en tant que compagnon de la RemoteApp.
Microsoft Learn

Cette fonctionnalité ajoutée il y a quelques jours est disponible en préversion publique, comme le dit l’annonce faite par Microsoft sur son Tech Community.

La documentation Microsoft spécifie les quelques ressources indispensables pour utiliser la fonctionnalité, à l’heure où ces lignes sont écrites :

L’environnement AVD doit être configuré comme environnement de validation
La version Windows 11 des VMs AVD doit être en version 22H2, Build 25905 ou ultérieure
Configuration OneDrive :
- OneDrive doit être installé en mode ALLUSER
- OneDrive doit être configuré en mode silencieux

Pour mes tests, je n’ai eu besoin d’installer FSLogix, mais nul doute que la dernière version de celui-ci doit être installée pour que la gestion des profils en itinérance se fasse correctement avec le nouveau comportement de OneDrive.

Afin d’en savoir un peu plus, je vous propose de réaliser un petit exercice ensemble :

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice sur OneDrive au travers Azure Virtual Desktop en mode RemoteApp, il vous faudra disposer de :

Un tenant Microsoft
Une souscription Azure valide

Etape I – Déploiement de l’environnement AVD :

Avant tout chose, nous avons besoin de créer un réseau virtuel Azure. Pour cela, rendez-vous dans le portail Azure, puis commencez sa création :

Une fois la validation Azure réussie, lancez la création du réseau virtuel, puis attendez environ 1 minute :

Une fois le déploiement terminé, cliquez-ici pour y déployer le service Azure Bastion :

Cliquez-ici pour déclencher le déploiement du service Azure Bastion :

Sans attendre la fin du déploiement d’Azure Bastion, créez une machine virtuelle en Windows 11 sur le même réseau virtuel, sans y configurer d’options particulières :

Cette VM de test va nous servir à simuler notre poste local où nous lancerons l’application AVD en RemoteApp.

Continuez avec le déploiement de l’environnement Azure Virtual Desktop en utilisant là encore la barre de recherche du portail Azure :

Cliquez-ici pour commencer la création du pool d’hôtes Azure Virtual Desktop :

Activez l’option Validation de l’environnement AVD, puis cliquez sur Suivant :

Choisissez dans la liste des images Microsoft l’image Windows 11, version 22H2 :

Indiquez le nombre de VMs AVD, puis réutilisez le réseau virtuel Azure créé précédemment :

Joignez vos VMs AVD à Entra ID, puis cliquez sur Suivant :

Créez un espace de travail AVD, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création des ressources puis attendez environ 10 minutes :

Une fois le déploiement d’Azure Virtual Desktop entièrement terminé, cliquez-ici pour continuer sa configuration :

Activez l’option de SSO dans les propriétés RDP, puis cliquez sur Sauvegarder :

Créez un nouveau groupe d’applications AVD pour effectuer le test de l’application ouverte en RemoteApp :

Renseignez les informations de base, puis cliquez sur Suivant :

Ajoutez une application accessible depuis le menu Démarrer de votre VM AVD, puis cliquez sur Suivant :

Inutile de renseigner des utilisateurs à notre groupe d’applications, cliquez sur Suivant :

Associez votre nouveau groupe d’applications à votre espace de travail AVD, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création du groupe d’applications AVD, puis attendez environ 1 minute :

Une fois le déploiement terminé, cliquez sur le groupe de ressources commun à tous les déploiements antérieurs :

Ajoutez-y les 2 rôles RBAC suivants à un ou plusieurs utilisateurs de test AVD :

Retournez sur la machine virtuelle de test simulant le poste local, puis ouvrez une session de bureau à distance via Azure Bastion, en utilisant les identifiants administrateurs renseignés lors de la création de celle-ci :

Depuis cette VM, téléchargez le client Remote Desktop depuis cette page officielle Microsoft, puis ouvrez l’application avec votre utilisateur de test AVD :

Lancez l’application configurée en RemoteApp :

Authentifiez-vous encore une fois avec un compte AVD de test :

Constatez l‘absence de configuration OneDrive dans l’application RemoteApp, mais aussi au niveau de la VM de test simulant le poste local :

Fermez l’application en RemoteApp.

Nous environnement de départ est en place. Nous allons pouvoir effectuer la configuration cible en commençant par l’installation de OneDrive.

Etape II – Configuration de OneDrive :

Depuis votre portail Azure, ouvrez une seconde session Bastion sur la VM AVD, en utilisant les identifiants administrateurs renseignés lors de la création celle-ci :

Sur la machine AVD, téléchargez OneDrive via la page officielle Microsoft :

Ouvrez une fenêtre PowerShell, en mode administrateur, puis exécutez-y la commande suivante dans le dossier de téléchargement de votre utilisateur :

.\OneDriveSetup.exe /allusers

Attendez que l’installation de OneDrive se termine :

Contrôler que l’installation de OneDrive est bien en mode ALLUSER par la présence de la clef de registre suivante :

Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\OneDrive

Retournez sur le portail Azure afin de récupérer le Tenant ID de votre tenant :

Retournez sur la fenêtre PowerShell de votre VM AVD, puis lancez le script suivant en prenant le soin de renseigner votre Tenant ID dans la variable $TenantGUID :

$HKLMregistryPath = 'HKLM:\SOFTWARE\Policies\Microsoft\OneDrive'##Path to HKLM keys
$DiskSizeregistryPath = 'HKLM:\SOFTWARE\Policies\Microsoft\OneDrive\DiskSpaceCheckThresholdMB'##Path to max disk size key
$TenantGUID = 'XXXXXXXXXXXXX'

if(!(Test-Path $HKLMregistryPath)){New-Item -Path $HKLMregistryPath -Force}
if(!(Test-Path $DiskSizeregistryPath)){New-Item -Path $DiskSizeregistryPath -Force}

New-ItemProperty -Path $HKLMregistryPath -Name 'SilentAccountConfig' -Value '1' -PropertyType DWORD -Force | Out-Null ##Enable silent account configuration
New-ItemProperty -Path $DiskSizeregistryPath -Name $TenantGUID -Value '102400' -PropertyType DWORD -Force | Out-Null ##Set max OneDrive threshold before prompting

Vérifiez la bonne exécution de celui-ci :

Sur la machine de test local, ouvrez une session de bureau à distance depuis l’application Remote Desktop AVD :

Acceptez la finalisation de la configuration SSO entre Entra ID et la VM AVD :

Vérifiez que l’authentification automatique de OneDrive fonctionne et que la synchronisation des fichiers OneDrive démarre bien :

Contrôlez également la présence des fichiers OneDrive depuis l’explorateur de fichiers Windows :

De retour sur la session administrateur de la VM AVD ouverte via Azure Bastion, lancez le script PowerShell suivant :

New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Run" -Name OneDrive -PropertyType String -Value '"C:\Program Files\Microsoft OneDrive\OneDrive.exe" /background' -Force

La commande effectuée va permettre de laisser fonctionner OneDrive en tâche de fond lorsque l’application en RemoteApp est démarrée :

La configuration de OneDrive sur notre machine virtuelle AVD est terminée.

Pour que tout fonctionne correctement, la version de Windows de la VM AVD doit être supérieure ou égale à la 25905.

Pour cela, nous avons besoin de rejoindre programme Windows Insider de Windows 11.

Etape III – Installation du Programme Windows Insider :

Sur la session administrateur de votre VM AVD, retournez dans les paramétrages Windows :

Cliquez-ici pour rejoindre le programme Windows Insider :

Avant de pouvoir rejoindre le programme Windows Insider, cliquez sur l’alerte afin d’activer la remontée de données de diagnostic :

Activez l’option, puis retournez sur la page principale des paramètres Windows :

Cliquez sur Commencer afin d’activer le programme Windows Insider :

Utilisez le compte de votre utilisateur AVD pour rejoindre le programme :

Renseignez ses identifiants :

Choisissez le canal Canary, puis cliquez sur Continuer :

Considérez si besoin les particularités du canal Canary, puis cliquez sur Continuer :

Cliquez sur Continuer pour accepter les conditions du programme liées à votre poste :

Redémarrez la VM de test AVD :

Retournez sur les paramètres Windows, puis constatez l’apparition de nouvelles mises à jour, dont celles-ci :

Une fois l’installation terminée, lancez une redémarrage de la VM AVD :

Quelques minutes plus tard, vérifiez via la session ouverte sur Azure Bastion que votre VM AVD est dans la bonne version de Windows 11 :

Notre environnement est enfin prêt et fonctionnel pour tester OneDrive en version RemoteApp.

Il ne nous reste plus qu’à effectuer des tests RemoteApp grâce à notre utilisateur AVD.

Etape IV – Test de OneDrive en RemoteApp :

Retournez sur la session ouverte sur la VM de test local ouverte via Azure Bastion, puis réouvrez l’application configurée en RemoteApp :

Constatez la présence du compte OneDrive depuis l’application WordPad :

Constatez l’apparition d’un second OneDrive ouvert localement, avec la mention Remote, puis cliquez-dessus :

Constatez l’ouverture de la fenêtre OneDrive comme une seconde application RemoteApp ouverte depuis le poste local :

Fermez l’application WordPad :

Quelques secondes plus tard, l’application OneDrive ouverte automatiquement en RemoteApp se ferme également :

Conclusion

Grâce à cette évolution, OneDrive fonctionne parfaitement avec RemoteApp créée dans un environnement Azure Virtual Desktop. Cela permet à vos aux utilisateurs d’accéder à leurs fichiers et de les synchroniser lorsqu’ils utilisent une RemoteApp de 2 manières, localement ou au travers de l’application RemoteApp.

Privatisez l’accès de votre AVD

Azure Virtual Desktop continue encore d’évoluer et s’associe maintenant avec un autre service réseau du cloud Microsoft : Azure Private Link. En ce début du mois de novembre, Microsoft vient de l’ouvrir en préversion publique pour tester cette fonctionnalité. L’idée est donc de sécuriser d’avantage, par une restriction encore plus poussée, l’accès au service Azure Virtual Desktop.

Pourquoi restreindre un service Cloud ?

Pour répondre à une demande provenant de certaines entreprises. Beaucoup d’entre-elles ont même des exigences légales et ne souhaitent donc pas faire passer un flux réseau à travers internet, quand bien même il s’agirait de communications en HTTPS.

Il paraissait donc important que Microsoft propose ce type de fonctionnalité pour permettre à au service à Azure Virtual Desktop d’être 100% en dehors du web.

Pour parvenir à la mise en place de cette fonctionnalité, Microsoft met déjà à disposition plusieurs documentations, disponibles uniquement en anglais pour l’instant :

Qu’est-ce qu’Azure Private Link ?

En deux mot, Azure Private Link vous permet d’accéder aux services Azure PaaS (par exemple du stockage Azure, compte le compte de stockage ou encore une base de données SQL) depuis votre réseau virtuel :

Voici une vidéo qui aborde le sujet dans son entièreté :

Comment va fonctionner Azure Virtual Desktop avec Private Link ?

Comme pour les autres services proposant cette association, le trafic entre le réseau virtuel et Azure Virtual Desktop transitera par le réseau « dorsal » de Microsoft, ce qui signifie que vous n’aurez plus besoin d’exposer votre AVD à l’Internet.

En termes de sécurité, transiter son trafic dans le réseau « connu » et sécurisé de Microsoft renforcera toujours un peu plus la protection de vos données.

A quel moment intervient le Private Link dans le chemin de connexion entre l’utilisateur et AVD ?

Il peut intervenir à plusieurs niveaux. En effet, la connexion est décomposée en différentes étapes et avec plusieurs composants. Il est alors possible de choisir quelles connexions ont le droit ou non de transiter par internet.

C’est d’ailleurs pour cela que plusieurs options sont présentes dans la configuration réseau d’AVD :

La première option se charge d’autoriser ou non l’accès au service AVD des utilisateurs depuis internet. Autrement la partie frontale de la connexion AVD.
La seconde option se charge d’autoriser ou non l’accès au service AVD des machines virtuelles AVD depuis internet. Autrement la partie arrière-plan de la connexion AVD.

Peut-on utiliser à la fois les fonctionnalités Private Link et RDP Shortpath ?

Durant cette phase de préversion, cela n’est pas possible. Pour rappel RDP Shortpath est une méthode habile d’Azure Virtual Desktop qui établit un transport direct basé sur le protocole UDP entre le client Remote Desktop et l’hôte de session. Tout y est expliqué ici.

Etape 0 – Rappel des prérequis

Pour arriver à la démonstration de l’association entre Azure Virtual Desktop et Private Link, je dispose d’un environnement comprenant des composants déjà en place :

Poste Windows 10 avec Azure VPN
Environnement AVD avec jointure Azure AD

On retrouve ainsi mon premier réseau virtuel comprenant :

La machine virtuelle faisant office de poste utilisateur distant sous Windows 10
Le service Azure Bastion pour m’y connecter plus facilement

J’ai également déployé un second réseau virtuel. Celui-ci comprend

Mon environnement Azure Virtual Desktop
Une passerelle VPN pour assurer la connection entre le poste Windows 10 et AVD

La connexion VPN Point à Site est bien fonctionnelle :

*L’accès direct à une des machines virtuelles AVD répond bien*.

Comme vous pouvez le voir sur la configuration d’Azure Virtual Desktop, une nouvelle section dédiée au réseau a fait son apparition :

Avant d’aller plus loin, il est donc nécessaire d’activer la fonctionnalité, encore en préversion à l’heure où ces lignes sont écrites.

Etape I – Activation de la fonction de préversion d’Azure Private Link

Comme beaucoup de fonctionnalités encore en préversion, il est nécessaire de l’activer depuis le portail Azure. Pour cela, effectuer l’opération suivante via ce lien :

N’oubliez pas de sélectionner la bonne souscription Azure.

Une fois enregistrée, attendez environ 15 minutes.

Retournez sur la section réseau de votre Azure Virtual Desktop pour constater le déblocage des fonctionnalités réseaux :

Dans cette configuration par défaut, avec les 2 cases de cochées, la connexion réseau transite via internet dans sa totalité :

Entre le client et le service Azure Virtual Desktop
Entre le service Azure Virtual Desktop et les machines virtuelles AVD

Un test, avec le VPN désactivé, montre que la connexion se fait toujours via internet :

Etape II – Restreindre la communication entre le service AVD et le pool d’hôtes au réseau virtuel Azure

La première étape consiste donc à restreindre la communication entre le service Azure Virtual Desktop et les machines virtuelles AVD au réseau virtuel. Pour cela décochez la case suivante et sauvegardez :

Un nouvel essai de connexion utilisateur vous montre le blocage immédiat de cette méthode en passant par internet :

*Comme dit plus haut, l’utilisateur n’en est pas responsable : Le service Azure Virtual Desktop est incapable de communique avec la machine virtuelle AVD.*

Pour arriver rétablir l’accès au service AVD, nous avons besoin de créer un premier private endpoint en cliquant sur le second onglet de la section réseau :

*Pour réactiver les connexions, vous devrez créer un private endpoint* pour chaque *pool d’hôtes AVD que vous souhaitez autoriser.*

Donnez-lui un nom, puis passez à l’onglet suivant :

Laissez cet onglet comme ceci avec le type connexion et passez sur le suivant.

Pour information, il existe différents types de sous-resource cible, ils auront une importance et seront utilisés par la suite :

Type de resource	Type de sous-resource	Quantité
Microsoft.DesktopVirtualization/workspaces	global	Un pour tous les déploiements Azure Virtual Desktop
Microsoft.DesktopVirtualization/workspaces	feed	Un par workspace
Microsoft.DesktopVirtualization/hostpools	connection	Un par pool d’hôtes

Renseignez le réseau / sous réseau de votre environnement Azure Virtual Desktop :

Pour votre information, plusieurs adresses IP privées seront alors allouées pour les services suivants :

Sur l’onglet suivant, une zone DNS privée va être créé pour le private endpoint :

Lancez la création puis attendez :

Une fois créé, la carte réseau du private endpoint nouvellement créé vous montre que chaque service dispose bien d’une adresse IP dédiée :

Important : Pour les gros environnement AVD, prévoir un second sous-réseau pour éviter un souci d’adressage.

Un redémarrage de machines virtuelles AVD plus tard : la connexion AVD depuis le poste client refonctionne sans souci :

Veuillez noter que la copie d’écran ci-dessus montre bien que le VPN d’Azure est toujours déconnecté. Cela montre bien que nous n’avons pas encore influencé la partie frontale du service AVD.

Pour bien comprendre ce qui s’est passé, un test intéressant est de

Créer un groupe de sécurité réseau (NSG)
Y ajouter une restriction d’accès au service publique d’Azure Virtual Desktop
L’associer au sous-réseau contenant les machines virtuelles AVD

Ce test créé une contrainte qui n’empêche pas notre test de fonctionner, car la connexion entre le service Azure Virtual Desktop et les machines AVD transite par le private endpoint nouvellement créé.

J’ai également fait un autre test de retirer le private endpoint. Les machines virtuelles AVD apparaissent alors bien comme étant injoignables pour le service Azure Virtual Desktop :

Maintenant, la seconde étape est de restreindre également l’accès au service Azure Virtual pour les postes connectés uniquement à internet.

Etape IIIa – Restreindre la communication entre le service AVD et les utilisateurs au réseau virtuel

La première étape consiste donc à restreindre la communication entre le service AVD et les utilisateurs via internet. Pour cela, décochez la case suivante et sauvegardez :

Un nouvel essai de connexion à AVD nous montre le blocage immédiat de cette méthode en passant par internet :

Un rafraichissement de l’espace de travail AVD montre maintenant un refus d’affichage de celui-ci :

Pour terminer la configuration, nous avons besoin de créer deux autres private endpoints.

Pour cela, allez sur l’espace de travail AVD, allez dans la section réseau, décochez la case et sauvegardez :

Comme précédemment, commencez par créer un private endpoint comme ceci :

Nommez-le différemment du premier private endpoint créé durant l’étape précédente :

Choisissez cette fois-ci la sous-resource cible de type Feed :

Renseignez le réseau / sous réseau où votre environnement Azure Virtual Desktop :

Là encore, des adresses IP privées seront allouées pour les services suivants :

Sur l’onglet suivant, la première zone DNS privée va être réutilisée pour le second private endpoint, rattaché à votre espace de travail :

Lancez la création puis attendez :

Une fois créé, retournez sur la page d’Azure Virtual Desktop pour créer le troisième private endpoint de type Global.

Etape IIIb – Restreindre la communication entre le service AVD et les utilisateurs au réseau virtuel

Microsoft conseille d’isoler ce private endpoint sur un espace de travail dédié au réseau. En effet, ce private endpoint unique de type Global pourrait service servir à tous les réseaux virtuels appairés.

Pour cela, créez un nouvel espace de travail AVD :

Nommez-le et lancez sa création :

Une fois créé, retournez-y, décochez là encore l’option réseau, puis sauvegardez.

Créez ici le troisième private endpoint et remplissez le premier onglet comme les 2 précédentes fois :

Choisissez le type de sous-resource cible Global :

Choisissez un réseau en relation directe avec votre environnement AVD :

Pour information, une adresse IP privée sera là-encore allouée pour le service suivant :

Sur l’onglet suivant, la première zone DNS privée va être réutilisée pour le troisième private endpoint, rattaché à ce nouvel espace de travail :

Lancez la création puis attendez :

Etape IV : Configuration du réseau on-premise

Pour que la connexion restreinte à Azure Virtual Desktop fonctionne bien, il est nécessaire d’apporter les enregistrements DNS créés précédemment sur le réseau on-premise.

Comme mon réseau on-premise est virtuellement créé sur Azure, j’ai choisi de créer une seconde zone DNS privée avec le même nom et de la rattacher à mon réseau on-premise :

*Reprenez tous les enregistrements présents dans la zone DNS créée par les private endpoints*.

Si comme moi votre réseau on-premise est dans Azure, associez cette zone DNS privée à celui-ci.

Etape V : Test de la connexion via Azure VPN Point à Site

Sur le poste on-premise de test, effectuez un premier test de connexion à l’URL d’Azure Virtual Desktop tout en ayant la connexion VPN de stoppée :

aka.ms/wvdarmweb

Constatez avant tout que la page n’est dorénavant plus joignable :

Démarrez votre connexion VPN grâce au client Azure VPN :

Recharger la page web du service Azure Virtual Desktop et renseignez vos identifiants de l’utilisateur de test :

Cliquez sur l’icône de bureau à distance :

Renseignez une seconde fois son mot de passe :

Et vus voilà dans votre session AVD !

Un test de déconnexion de la connexion VPN affectera immédiatement la session utilisateur d’AVD :

Réactiver la connexion VPN pour retrouver la session AVD.

Etape VI : Résumé des ressources Azure créées

Afin d’apporter plus de clarté à toutes ces opérations de déploiement, voici un récapitulatif du travail effectué dans cet article sur mon environnement Azure :

3 private endpoints :

3 cartes réseaux :

2 zones DNS privées :

1 second espace de travail AVD :

Etape VI : Aide à la résolution

Si l’installation s’est déroulée sans accro, mais que vous n’arrivez toujours pas à vous reconnecter à votre environnement Azure Virtual Desktop, voici quelques pistes qui peuvent vous aider :

*Absence du premier private endpoint sur le pool d’hôtes AVD.*

*Authentification correcte, mais absence d’enregistrements DNS www,* rdweb et client sur le réseau on-premise.

*Authentification correcte, mais absence d’enregistrements DNS .*rdweb sur le réseau on-premise.

*Authentification correcte, mais absence d’enregistrements DNS gateway sur le réseau on-premise.*

Conclusion

Par cette nouvelle fonctionnalité, Microsoft apporte encore plus de liberté dans la manière d’utiliser son environnement AVD, avec toujours plus d’exigences de sécurité. La possibilité de restreindre le service AVD à différents types de connexions sécurisées, comme les VPNs ou encore Azure ExpressRoute était attendue depuis longtemps.

Comme toujours, Dean de l’Azure Academy a préparé une vidéo très explicative de la mise en route ????

Augmentez la résilience de votre AVD

De manière générale, la grande majorité des services proposés par les principaux hébergeurs Cloud s’accompagnent d’un niveau de service (SLA). Ce Service-level agreement est un point d’accord concernant la disponibilité d’un service entre les utilisateurs et l’hébergeur Cloud. Une architecture entière dispose elle aussi de sa propre SLA. La SLA de ce produit final combine alors toutes les SLAs de ses sous-produits dont elle dépend.

Dans cet article, nous allons parcourir ensemble quelques mécanismes de résilience disponibles sur Azure. Nous testerons aussi ces méthodes dans le cadre de déploiement d’environnement AVD via le portail Azure.

Qu’est-ce que la SLA selon Microsoft ?

Les Contrats de Niveau de Service (« Service-level agreements », SLA) décrivent les engagements de Microsoft en termes de temps de disponibilité et de connectivité. Les SLA pour les différents services Azure sont énumérés ci-dessous.
SLA selon Microsoft

Azure élabore différentes SLAs pour chaque service qu’ils proposent. Certains services encore en préversion, destinés à du développement ou même gratuits peuvent être dépourvus de SLA. Tout naturellement, une SLA plus élevée apporte une meilleure disponibilité au service attendu.

Prenons en exemple la SLA des machines virtuelles créées sur Azure. Cette SLA dépend par exemple des performances des disques rattachés à la machine virtuelle :

Le choix de disques plus performant est une chose facile à comprendre et à mettre en place. Elle est donc la une première démarche à effectuer pour renforcer la résilience.

Quelle SLA dans le cadre d’un Azure Virtual Desktop ?

Azure Virtual Desktop s’appuie lui aussi sur des machines virtuelles Azure. Microsoft propose le un tableau comparant les cinq types de disques disponibles pour vous aider à choisir celui que vous allez utiliser selon votre scénario d’utilisation :

	Disque Ultra	SSD Premium v2	SSD Premium	SSD Standard	HDD Standard
Type de disque	SSD	SSD	SSD	SSD	HDD
Scénario	Charges de travail gourmandes en E/S, telles que le système SAP HANA, les bases de données de niveau supérieur (par exemple, SQL et Oracle), et autres charges de travail très lourdes en transactions.	Charges de travail de production et sensibles aux performances qui nécessitent systématiquement une latence faible, des IOPS et un débit élevé	Charges de travail de production et sensibles aux performances	Serveurs web, applications d’entreprise peu utilisées et Dev/Test	Sauvegarde, non critique, accès peu fréquent

Microsoft vous recommande donc de créer vos machines virtuelles AVD avec des disques Premium SSD, et cela pour trois raisons :

SLA de haut niveau, 99.9 %, indispensable pour environnement de production.
Performances élevées, bande passante et IOPS satisfaisantes.
Rapport qualité / prix en intégrant les coûts transactionnels dans son prix mensuel fixe.

Dans le cadre d’un pool de machines virtuelles AVD avec des disques Premium SSD, la SLA est alors à 99.9 % pour chacune d’elle.

Un autre paramètre rentre en ligne de compte pour renforcer la SLA de machines virtuelles : Nombre de machines virtuelles jouant un rôle identique :

Qu’est-ce qu’un Groupe à haute disponibilité ?

Un Groupe à haute disponibilité est un regroupement logique d’au moins deux machines virtuelles, de manière à fournir une application hautement disponible et à répondre aux exigences du niveau de 99,95 % inscrit dans les contrats de niveau de service Azure. Le groupe à haute disponibilité proprement dit ne vous coûte rien ; vous payez uniquement pour chaque instance de machine virtuelle que vous créez.
Microsoft Learn

Deux notions importantes sont alors configurables grâce à cette fonctionnalité d’Azure :

Domaine de mise à jour : regroupe des machines virtuelles pouvant être mises à jour et donc potentiellement redémarrées en même temps. Le redémarrage des domaines de mise à jour effectue un redémarrage que sur un seul un seul domaine à la fois. (Max 20 domaines de mise à jour par Groupe à haute disponibilité)
Domaine d’erreur : regroupe des machines virtuelles partageant une source d’alimentation et réseau en commune. Cela a pour effet de limiter l’effet des défaillances des équipements physiques, des pannes du serveur et des coupures d’électricité. (Max 3 domaines d’erreur par Groupe à haute disponibilité)

Autrement dit, Azure vous permet de positionner gratuitement vos machines virtuelles dans un Groupe à haute disponibilité, de telle sorte que si l’une d’entre-elles rencontre des difficultés ou une mise à jour Azure, une continuité de service de votre application est assurée via la disponibilité garantie des autres machines virtuelles.

Dans le cas d’un environnement Azure Virtual Desktop, certains services critiques peuvent alors être répartis sur plusieurs Groupes de disponibilité. Par exemple :

Groupe de disponibilité 1 : Les machines virtuelles dédiées au pool d’hôtes AVD
Groupe de disponibilité 2 : Les machines virtuelles dédiées au domaine AD

Qu’est-ce que les Zones de disponibilité ?

Un schéma est souvent plus clair que de longues explications. Voici un empilement hiérarchique du Cloud Microsoft. Chaque service Azure est défini par toutes ces strates ici présentes.

Les géographies d’Azure n’ont pas d’impact direct sur les architectures déployées dans le Cloud. Il faut juste garder en tête qu’une géographie Azure regroupe plusieurs régions Azure.

Le niveau le plus important à retenir est bien la Région Azure. Le Cloud de Microsoft est réparti sur environ une soixantaine de régions Azure. La plupart de ces régions Azure forment une paire de 2 régions. Cette liaison forte apporte des services spécifiques, comme le but d’accroitre les capacités de de reprise après sinistre.

Enfin, de plus en plus de régions Azure disposent de plusieurs Zones de disponibilité :

Les Zones de disponibilité Azure sont des emplacements physiquement séparés au sein de région Azure, qui sont tolérants aux défaillances de centre de données en raison de l’infrastructure redondante et de l’isolation logique des services Azure.
Microsoft Learn

L’intérêt de disposer de lieux géographiques séparés de plusieurs kilomètres, voir dizaines de kilomètres, est d’apporter une meilleure résilience que celle générée via les Groupes à haute disponibilité, toujours présent dans un seul site physique, pour faire face à des sinistres de grande envergure.

A titre d’information, les zones de disponibilité sont disponibles dans la région Azure Suisse Nord depuis mai 2022.

Afin de garantir un haut niveau de performance, Microsoft signale que l’impact sur la latence d’une architecture Azure répartie sur plusieurs Zones de disponibilité est minime voire nul, et cela grâce à une latence inférieure à deux millisecondes entre ces zones.

Il est possible de combiner les Zones de de disponibilité avec les **Groupes à haute** *disponibilit*é.

Microsoft met également à disposition un outil graphique intéressant sur les composantes de l’infrastructure Azure afin d’en savoir un peu plus :

Comme pour presque tous les articles dédiés Azure Virtual Desktop, voici différents tests pour en évaluer l’impact dans le déploiement de vos ressources.

Etape 0 : Rappel des prérequis

Des prérequis sont nécessaires pour réaliser ces démonstrations AVD :

Un tenant Microsoft
Une souscription Azure valide
Un réseau virtuel existant sur Azure

La mise en place d’une notion de disponibilité doit se faire lors de la création des machines virtuelles. Il n’est plus possible d’agir dessus une fois les machines virtuelles déployées. Cela est donc paramétrable uniquement :

Lors de la création du pool d’hôtes AVD
Lors de l’ajout de nouvelles machines virtuelles à un environnement AVD existant.

Test A : AVD + Groupe à haute disponibilité

Commencez par déployer un pool d’hôtes AVD grâce à la barre de recherche du portail Azure :

*Tapez « virtual desktop » dans la barre de recherche pour voir le service AVD apparaître.*

Remplissez le premier onglet sans spécificité particulière :

Continuez sur les éléments de base de vos machines virtuelles AVD :

L’option ci-dessous nous invite à préciser la notion de disponibilité voulue. Choisissez ici Groupe à haute disponibilité :

Cliquez comme ceci pour en créer un nouveau Groupe à haute disponibilité :

Spécifiez le nom et les nombres de domaines de mise à jour et d’erreurs voulus :

Terminez de remplir les informations de cet onglet sans spécificité particulière :

Créez également un workspace AVD :

Lancez la création de votre environnement Azure Virtual Desktop :

Attendez que votre déploiement AVD se termine :

Contrôlez plusieurs machines virtuelles et constatez le Groupe à haute disponibilité dont elles dépendent :

Consultez l’ensemble des informations de votre Groupe à haute disponibilité en recherchant directement cette ressource Azure depuis votre groupe de ressources :

Ses paramétrages de base ne sont malheureusement plus modifiables :

L’ajout de nouvelle machines virtuelles à votre pool d’hôtes AVD avec ce même Groupe à haute disponibilité est toujours accessible.

La répartition des machines virtuelles est toujours faite en round-robin (équitable)

Finalement, le déploiement d’un environnement Azure Virtual Desktop via le portail Azure prend bien en charge la répartition des machines virtuelles du pool d’hôtes dans un Groupe à haute disponibilité.

Continuons maintenant avec un second test dédié aux Zones de disponibilité.

Test B : AVD + Zones de disponibilité

Là encore, nous allons commencer par déployer un second pool d’hôtes AVD. Repartez depuis la barre de recherche du portail Azure pour accéder au service AVD :

Remplissez là encore le premier onglet sans spécificité particulière :

Continuez sur les éléments de base de vos machines virtuelles AVD :

Choisissez dans le même menu déroulant Zones de disponibilité, puis sélectionnez les 3 Zones disponibles dans la région Suisse Nord :

Terminez de remplir les informations de cet onglet sans spécificité particulière :

Créez là encore un workspace AVD :

Lancez la création de votre environnement Azure Virtual Desktop :

Attendez que votre second déploiement AVD se termine :

Contrôlez plusieurs machines virtuelles et constatez la Zone de disponibilité dont elles dépendent :

A l’inverse du Groupe à haute disponibilité, il n’existe pas de ressource Azure symbolisant la Zones de disponibilité. Là encore, plus aucun paramétrage n’est modifiable après création.

Ici aussi, le déploiement d’un environnement Azure Virtual Desktop via le portail Azure prend lui aussi en charge la répartition des machines virtuelles du pool d’hôtes dans plusieurs Zones de disponibilité.

Remarque importante

Une différence subtile existe les Groupes à haute disponibilité et les Zones de disponibilité. Le premier est bien un groupe dont sont associées plusieurs machines virtuelles, tandis que le second est une affectation d’une machine virtuelle à un datacenter (zone) spécifique.

Au final, pour que ces deux services Azure fassent sens dans votre architecture :

Je n’ai besoin que d’un seul groupe à haute disponibilité pour plusieurs VMs
J’ai besoin de plusieurs zones de disponibilité pour plusieurs VMs

Pourquoi cette précision ?

Car il arrive souvent qu’un doute s’installe sur lesquelles et combien de ces ressources (Groupe à haute disponibilité / Zones de disponibilité) sont nécessaires.

Conclusion

Azure Virtual Desktop continue de progresser en automatisation et en simplicité de déploiement. Le fait que de plus en plus de régions Azure disposent de Zones de disponibilité est une très bonne nouvelle pour la résilience des services Cloud. Enfin Dean de l’Azure Academy nous en reparle en détail dans cette vidéo ????????

Testez MSIX App Attach dans votre AVD

La conteneurisation applicative est accessible sur Azure Virtual Desktop depuis plusieurs mois. L’attachement via MSIX permet de fournir des applications à des machines virtuelles sans aucune installation locale. Cependant, Il est ici différent du format MSIX normal, car celui-ci est spécialement conçu pour AVD. Pour en savoir plus sur MSIX, consultez la page web Présentation de MSIX.

Pourquoi faire de la conteneurisation applicative pour Azure Virtual Desktop ?

Azure Virtual Desktop est principalement conçu pour délivrer une expérience utilisateur commune et partagée. Il arrive fréquemment que certains utilisateurs travaillent sur des applications spécifiques. Dans ce cas, il est possible de leur délivrer cet attendu de plusieurs manières :

Gestion de applications requises dans une image OS spécifiquement dédiée
Utilisation de solution de type Intune pour un déploiement distribué
Approvisionnement d’applications via des solutions tierces (Liquidware Flexapp, Citrix AppLayering)
Utilisation d’applications conteneurisées

Dans cet article, nous allons démontrer ensemble la dernière possibilité.

Etape 0 : Rappel des prérequis

Comme pour chaque déploiement réalisé sur ce blog, des prérequis sont nécessaires avant de pouvoir se concentrer sur MSIX AppAttach :

Un tenant Microsoft (AAD)
Une souscription Azure active
Un domaine Active Directory Domain Services (AD DS)
Un espace de stockage Azure joint au domaine AD DS
Un agent Azure AD Connect installé et synchronisé avec votre Azure AD
Un environnement Azure Virtual Desktop (Pool d’hôtes – Groupe d’application – Espace de travail – VMs)
Facultatif : un Azure Bastion pour faciliter les connexions RDP

Une fois votre environnement Azure en place, plusieurs étapes sont nécessaires pour arriver à la mise à disposition des applications conteneurisées.

Etape I : Déployer une nouvelle VM Azure Windows 10

Cette nouvelle machine virtuelle vous nous être utile pour créer différents composants nécessaires :

Création d’un certificat pour signature des packages MSIX
Création du package MSIX
Configuration des VMS AVD pour supporter la couche conteneur
Création de l’image VHD
Dépose de l’image VHD sur le partage de fichier

*J’ai ici repris la même image Windows 10 que celle utilisée pour AVD.*

*Pas besoin d’adresse IP publique dans mon cas grâce à Azure Bastion.*

Patientez quelques minutes une fois la création lancée :

Une fois cette VM créée, utilisez Azure Bastion pour vous connecter en RDP sur votre machine virtuelle :

Joignez cette machine virtuelle au domaine AD DS, puis redémarrez-là :

Etape II : Préparation du certificat

Reconnectez à votre VM MSIX via Azure Bastion, puis lancez Windows PowerShell ISE, en mode administrateur :

Exécutez les commandes PowerShell suivantes :

Schtasks /Change /Tn "\Microsoft\Windows\WindowsUpdate\Scheduled Start" /Disable
reg add HKLM\Software\Policies\Microsoft\WindowsStore /v AutoDownload /t REG_DWORD /d 0 /f
reg add HKCU\Software\Microsoft\Windows\CurrentVersion\ContentDeliveryManager /v PreInstalledAppsEnabled /t REG_DWORD /d 0 /f
reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\ContentDeliveryManager\Debug /v ContentDeliveryAllowedOverride /t REG_DWORD /d 0x2 /f
reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v EnableLUA /t REG_DWORD /d 0 /f
reg add HKLM\Software\Microsoft\RDInfraAgent\MSIXAppAttach /v PackageListCheckIntervalMinutes /t REG_DWORD /d 1 /f

Exécutez la commande PowerShell suivante pour générer un certificat auto-signé sur votre domaine (JLOUDEV), et stockez le dans le dossier Personal des certificats locaux :

New-SelfSignedCertificate -Type Custom -Subject "CN=Jloudev" -KeyUsage DigitalSignature -KeyAlgorithm RSA -KeyLength 2048 -CertStoreLocation "cert:\LocalMachine\My

Exécutez certlm.msc pour ouvrir la console des certificats locaux :

Lancez la commande d’Export sur ce nouveau certificat :

Cliquez sur Suivant :

Sélectionnez l’option Oui, exporter la clé privée, puis cliquez sur Suivant :

Cochez la case Exporter toutes les propriétés étendues, décochez la case Activer la confidentialité des certificats, puis cliquez sur Suivant :

Cochez la case Mot de passe, renseignez les deux champs dessous, puis cliquez sur Suivant :

Créez un nouveau dossier, par exemple celui-ci :

C:\MSIX

Renseignez le chemin de destination, puis cliquez sur Suivant :

Cliquez sur Terminer pour finaliser le processus :

Etape III : Déploiement du certificat sur les machines virtuelles AVD

Exécutez le script PowerShell suivant depuis votre fenêtre Windows PowerShell ISE, en mode administrateur, pour déployer le certificat nouvellement généré dans Trusted People des machines virtuelles AVD :

$avdhosts = 'avd-vm-0','avd-vm-1'
$cleartextPassword = 'Demo!pass123'
$securePassword = ConvertTo-SecureString $cleartextPassword -AsPlainText -Force
$localPath = 'C:\MSIX'
ForEach ($avdhost in $avdhosts){
  $remotePath = "\\$avdhost\C$\MSIX\"
  New-Item -ItemType Directory -Path $remotePath -Force
  Copy-Item -Path "$localPath\jloudev.tk.pfx" -Destination $remotePath -Force
  Invoke-Command -ComputerName $avdhost -ScriptBlock {
     Import-PFXCertificate -CertStoreLocation Cert:\LocalMachine\TrustedPeople -FilePath 'C:\MSIX\jloudev.tk.pfx' -Password $using:securePassword
  } 
}

Un tour rapide grâce à Azure Bastion sur une des machines virtuelles AVD nous confirme la bonne présence du certificat :

Etape IV : Téléchargements de l’application Mozilla Firefox

Dans notre démonstration, nous allons télécharger la dernière version de Mozilla Firefox. Nous prendrons l’installation au format MSI, disponible ici.

Lancez le téléchargement depuis la machine virtuelle MSIX comme ceci :

Copiez le fichier téléchargé dans le dossier C:\MSIX :

Etape V : Préparation avant création

Avant de lancer la création, exécutez le script PowerShell suivant depuis votre fenêtre Windows PowerShell ISE, en mode administrateur, pour désactiver le service de recherche de Windows :

$serviceName = 'wsearch'
Set-Service -Name $serviceName -StartupType Disabled
Stop-Service -Name $serviceName

Profitez-en également pour créer cette nouvelle arborescence :

New-Item -ItemType Directory -Path 'C:\MSIX\Firefox' -Force

Exécutez la commande PowerShell suivante pour supprimer le Zone.Identifier des fichiers d’installation téléchargés depuis Internet :

Get-ChildItem -Path 'C:\MSIX' -Recurse -File | Unblock-File

Etape VI : Création du package applicatif

Pour continuer, vous aurez besoin de MSIX Packaging Tool, que vous trouverez dans le Microsoft Store. Lancez le téléchargement de ce dernier, toujours depuis la machine virtuelle MSIX :

Une fois le téléchargement terminé, lancez l’application.

Sur la page d’accueil, sélectionnez Application package afin de lancer la création d’un nouveau paquet :

*Vous aurez peut-être besoin de redémarrer la machine pour continuer.*

Sur la page suivante, cochez la case Créer le paquet sur cet ordinateur, puis cliquez sur Suivant :

Attendez l’installation du pilote de l’outil de conditionnement MSIX, puis cliquez sur Suivant :

Sélectionnez Parcourir pour accéder au fichier d’installation de Firefox au format MSI :

C:\MSIX\Firefox Setup 95.0.msi

Dans la liste déroulante Préférence de signature, sélectionnez Signer avec un certificat (.pfx).

Recherchez le certificat C:\MSIX\jloudev.tk.pfx, saisissez le mot de passe Demo!pass123, puis cliquez sur Suivant :

Examinez et modifiez si besoin le nom du paquet, vérifiez que le nom de l’éditeur est défini sur CN=JLOUDEV, puis cliquez sur Suivant :

Cela déclenche alors l’installation de Mozilla Firefox de manière encapsulée :

Une fois l’installation terminée, vous retrouvez le message ci-dessous, cliquez sur Suivant :

Cliquez alors sur Suivant.

Lorsque le système vous demande Avez-vous terminé ?, sélectionnez Oui :

Vérifiez dans l’écran ci-dessous qu’aucun service n’est nécessaire, puis cliquez sur Suivant :

Changez le fichier et le dossier de destination :

C:\MSIX\Firefox\Firefox

Une fois la création terminée, cliquez sur Fermer :

Retrouvez les fichiers MSIX et XML suivants dans votre dossier C:\MSIX\Firefox :

Copiez seulement le fichier MSIX dans le dossier racine C:\MSIX :

Etape VII : Installation des fonctionnalités d’Hyperviseur

Maintenant, vous allez activer la fonctionnalité d’Hyperviseur sur l’ensemble des machines virtuelles Azure Virtual Desktop, mais également sur la machine MSIX :

Exécutez le script PowerShell suivant depuis votre fenêtre Windows PowerShell ISE, en mode administrateur, pour commencer l’activation sur les VMs AVD :

$avdhosts = 'avd-vm-0','avd-vm-1'
ForEach ($avdhost in $avdhosts){
  Invoke-Command -ComputerName $avdhost -ScriptBlock {
     Schtasks /Change /Tn "\Microsoft\Windows\WindowsUpdate\Scheduled Start" /Disable
     reg add HKLM\Software\Policies\Microsoft\WindowsStore /v AutoDownload /t REG_DWORD /d 0 /f
     reg add HKCU\Software\Microsoft\Windows\CurrentVersion\ContentDeliveryManager /v PreInstalledAppsEnabled /t REG_DWORD /d 0 /f
     reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\ContentDeliveryManager\Debug /v ContentDeliveryAllowedOverride /t REG_DWORD /d 0x2 /f
     reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v EnableLUA /t REG_DWORD /d 0 /f
     reg add HKLM\Software\Microsoft\RDInfraAgent\MSIXAppAttach /v PackageListCheckIntervalMinutes /t REG_DWORD /d 1 /f
     Set-Service -Name wuauserv -StartupType Disabled
  }
}

Exécutez le script PowerShell suivant depuis votre fenêtre Windows PowerShell ISE, en mode administrateur, pour installer Hyper-V et ses outils de gestion sur les VMs AVD :

$avdhosts = 'avd-vm-0','avd-vm-1'
ForEach ($avdhost in $avdhosts){
  Invoke-Command -ComputerName $avdhost -ScriptBlock {
     Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-All
  }
}

Chaque hôte AVD doit redémarrer pour prendre en compte les modifications : cliquez sur Oui :

Exécutez le script PowerShell suivant depuis votre fenêtre Windows PowerShell ISE, en mode administrateur, pour installer Hyper-V et ses outils de gestion sur la machine virtuelle MSIX :

Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-All

La machine virtuelle MSIX doit elle aussi redémarrer :

Reconnectez-vous sur machine virtuelle MSIX, avec le même compte utilisateur qu’utilisé précédement :

Etape VIII : Créer une image jointe à une application MSIX

Ouvrez Microsoft Edge et rendez-vous sur la page suivante pour télécharger msixmgr.zip.

Dans l’Explorateur de fichiers, accédez au dossier Téléchargements, ouvrez le fichier compressé et copiez le dossier x64 dans le dossier C:\MSIX :

Exécutez le script PowerShell suivant depuis votre fenêtre Windows PowerShell ISE, en mode administrateur, pour créer le fichier VHD qui servira d’image jointe de l’application MSIX :

New-Item -ItemType Directory -Path 'C:\MSIX\MSIXVhds' -Force
New-VHD -SizeBytes 256MB -Path 'C:\MSIX\MSIXVhds\Firefox.vhd' -Dynamic -Confirm:$false

Exécutez le script PowerShell suivant depuis votre fenêtre Windows PowerShell IS, en mode administrateur , pour monter le fichier VHD nouvellement créé :

$vhdObject = Mount-VHD -Path 'C:\MSIX\MSIXVhds\Firefox.vhd' -Passthru

Exécutez le script PowerShell suivant depuis votre fenêtre Windows PowerShell ISE, en mode administrateur, pour créer une nouvelle partition, la formater, et lui attribuer la première lettre de lecteur disponible :

$disk = Initialize-Disk -Passthru -Number $vhdObject.Number
$partition = New-Partition -AssignDriveLetter -UseMaximumSize -DiskNumber $disk.Number
Format-Volume -FileSystem NTFS -Confirm:$false -DriveLetter $partition.DriveLetter -Force

Cliquez sur Annuler pour ne pas formater à nouveau ce disque :

Le nouveau disque image est déjà présent dans l’explorateur de fichiers :

Exécutez le script PowerShell suivant depuis votre fenêtre Windows PowerShell ISE, en mode administrateur, pour créer une structure de dossier qui hébergera les fichiers MSIX :

$appName = 'Firefox'
New-Item -ItemType Directory -Path "$($partition.DriveLetter):\Apps" -Force
Set-Location -Path 'C:\MSIX'
.\x64\msixmgr.exe -Unpack -packagePath .\$appName.msix -destination "$($partition.DriveLetter):\Apps" -applyacls

Constatez la présences des fichiers dans le nouveau disque :

Exécutez le script PowerShell suivant depuis votre fenêtre Windows PowerShell ISE, en mode administrateur, pour démonter le fichier VHD qui servira d’image MSIX :

Dismount-VHD -Path "C:\MSIX\MSIXVhds\$appName.vhd" -Confirm:$false

Etape IX : Configurer le groupe Active Directory contenant les hôtes AVD

Retournez sur votre contrôleur de domaine via Azure Bastion :

Exécutez le script PowerShell suivant depuis votre fenêtre Windows PowerShell ISE, en mode administrateur, pour créer un groupe AD DS qui sera synchronisé avec Azure AD :

$ouPath = "OU=AVD-Devices,DC=jloudev,DC=tk"
New-ADGroup -Name 'avd-hosts' -GroupScope 'Global' -GroupCategory Security -Path $ouPath

Exécutez le script PowerShell suivant depuis votre fenêtre Windows PowerShell ISE, en mode administrateur, pour ajouter les machines virtuelles AVD en tant que membres du groupe que vous avez créé à l’étape précédente :

Get-ADGroup -Identity 'avd-hosts' | Add-AdGroupMember -Members 'avd-vm-0$','avd-vm-1$'

Exécutez le script PowerShell suivant depuis votre fenêtre Windows PowerShell ISE, en mode administrateur, pour redémarrer les VMs AVD :

$hosts = (Get-ADGroup -Identity 'avd-hosts' | Get-ADGroupMember | Select-Object Name).Name
$hosts | Restart-Computer

Ce nouveau groupe doit faire partie des synchronisations vers Azure AD. Pour cela, vérifiez dans votre configuration Azure AD Connect que cette OU est bien synchronisée :

Contrôlez après 30 minutes que le nouveau groupe remonte bien dans Azure AD :

Pour que les machines virtuelles Azure Virtual Desktop remontent bien dans ce groupe, il est nécessaire de reconfigurer également Azure AD Connect.

Retournez dans ce dernier pour activer la fonctionnalité Hybrid Azure AD Join :

Une fois les identifiants d’administrateur global renseignés, choisissez l’option ci-dessous :

Cochez la case pour remonter les machines Windows 10 et ultérieures :

Renseignez un compte Enterprise Administrator :

Une fois la configuration d’Azure AD Connect terminée :

Redémarrez les machines virtuelles AVD
Utilisez Azure Bastion pour vous connecter sur chaque VM AVD avec le compte avdadmin1@jloudev.tk
Retournez sur votre contrôleur de domaine via Azure Bastion (ou sur la machine virtuelle sur laquelle est installé Azure AD Connect), puis saisissez la commande PowerShell suivante en mode administrateur :

Start-ADSyncSyncCycle -PolicyType Initial

Attendez quelques minutes et contrôler la présence des machines virtuelles AVD dans le groupe AD sur Azure AD :

Etape X : Ajout des droits pour les VMs AVD sur le compte de stockage

Afin de mettre à disposition l’application packagée, nous allons créer un nouveau partage de fichier sur le compte de stockage existant.

Retournez sur votre portail Azure et rendez-vous sur le compte de stockage utilisé pour FSLogix :

Cliquez sur ce nouveau partage de fichier pour rajouter les 3 droits d’accès suivants :

Option	Valeur
Rôle	Storage File Data SMB Share Elevated Contributor
Assign access to	Group
Select	avd-admins

Option	Valeur
Rôle	Storage File Data SMB Share Elevated Contributor
Assign access to	Group
Select	avd-hosts

Option	Valeur
Rôle	Storage File Data SMB Share Reader
Assign access to	Group
Select	avd-group

Une fois les droits en place, retournez sur votre machine virtuelle MSIX avec le compte avdadmin1 via Azure Bastion, pour connecter ce nouveau partage de fichier grâce à la commande suivante :

$connectTestResult = Test-NetConnection -ComputerName jlosto.file.core.windows.net -Port 445
if ($connectTestResult.TcpTestSucceeded) {
    # Mount the drive
    New-PSDrive -Name Z -PSProvider FileSystem -Root "\\jlosto.file.core.windows.net\msixvhds" -Persist
} else {
    Write-Error -Message "Unable to reach the Azure storage account via port 445. Check to make sure your organization or ISP is not blocking port 445, or use Azure P2S VPN, Azure S2S VPN, or Express Route to tunnel SMB traffic over a different port."
}

Exécutez les commandes suivantes via le programme CMD pour accorder les permissions NTFS requises :

icacls Z:\ /grant JLOUDEV\avd-hosts:(OI)(CI)(RX) /T
icacls Z:\ /grant JLOUDEV\avd-group:(OI)(CI)(RX) /T
icacls Z:\ /grant JLOUDEV\avd-admins:(OI)(CI)(F) /T

Exécutez le script PowerShell suivant depuis votre fenêtre Windows PowerShell ISE, en mode administrateur, pour recopier le fichier VHD vers le partage de fichiers Azure :

New-Item -ItemType Directory -Path 'Z:\packages' 
Copy-Item -Path 'C:\MSIX\MSIXVhds\Firefox.vhd' -Destination 'Z:\packages' -Force

Un contrôle dans l’explorateur de fichier nous permet de vérifier la bonne présence de ce dernier :

Etape XI : Ajout de l’application MSIX sur l’environnement Azure Virtual Desktop

On arrive presque au bout ! Il ne nous reste maintenant qu’à rajouter notre application MSIX sur notre pool d’hôtes Azure Virtual Desktop. Pour cela, retournez sur votre portail Azure et cherchez votre pool d’hôtes, cliquez sur MSIX packages, puis sur Ajouter :

Saisissez le chemin suivant pour chercher le package nouvellement généré :

\\jlosto.file.core.windows.net\msixvhds\packages\Firefox.vhd

Renseignez les champs ci-dessous de la façon suivante, puis cliquez sur Ajoutez :

Vérifiez la bonne présence de votre application dans l’écran des applications :

Rendez-vous maintenant dans la section groupe d’applications, puis cliquez sur Ajouter :

Renseignez un nom à votre groupe d’applications, puis cliquez sur Suivant :

Sur le second onglet, cliquez sur Ajouter des applications :

Renseignez les champs ci-dessous, puis cliquez sur Sauvegarder et passez à l’onglet suivant :

Ajoutez votre groupe d’utilisateurs AVD puis passez sur l’onglet suivant :

Reprenez votre espace de travail existant puis validez les derniers onglets pour lancer la création :

Quelques minutes plus tard, la création se termine :

Etape XII : Test du package MSIX

Pour cela rien de plus simple, ouvrez l’application Remote Desktop. Voici le lien vers la page Microsoft si vous avez besoin de la télécharger :

Une fois installée, cliquez sur Souscrire :

Renseignez les identifiants d’un utilisateur présent dans votre groupe d’utilisateurs AVD :

Décochez la case et cliquez sur Non :

Constatez la présence de l’icône de bureau à distance et du nouvel icône pour Firefox :

Cliquez sur Firefox et renseignez le mot de passe de l’utilisateur AVD :

Firefox s’ouvre bien comme une application publiée sur votre poste local !!!

Le petit icône spécial dans la barre des tâches vous montre bien qu’il s’agit d’une application publiée et non locale :

Conclusion

Félicitations ! Vous avez réussi votre premier package applicatif via MSIX sur votre environnement Azure Virtual Desktop. On ne va pas se mentir, les premières opérations de mise en place demandent de la vigilance. Mais à force de pratiquer, les choses deviennent plus simples. Nul doute que tout cela peut vous faire gagner un temp considérable dans la mise à jour des applications dans de larges environnements Azure Virtual Desktop.

Comme toujours, faites part de vos remarques dans les commentaires ????

Associez FSLogix avec Azure AD

Microsoft vient tout juste de l’annoncer en préview : vous pouvez maintenant gérer les identités d’un partage de fichiers Azure PaaS directement avec Azure AD !

C’est une excellente nouvelle, attendue depuis plusieurs mois par de nombreux utilisateurs d’Azure Virtual Desktop, notamment pour mettre en place des solutions comme FSLogix, déjà utilisée pour la gestion des profils utilisateurs, sans serveur AD DS. Par contre, il y a encore une petite mauvaise nouvelle :

Cette fonctionnalité nécessite actuellement que les utilisateurs aient des identités hybrides, gérées dans Active Directory.
Documentation Microsoft

Quel est donc l’intérêt ?

Cette contrainte d’avoir un environnement hybride, qui sous-entend donc la présence d’un domaine AD, n’est pas forcément une mauvaise chose. Il s’agit ici d’une avancée technique intermédiaire. Nul doute que ce prérequis ne sera plus nécessaire à moyen terme.

Dans cet article, nous allons donc tester cette nouvelle fonctionnalité. Le but de tester cette préview de gestion des tickets Kerberos par Azure AD est de mesurer les avancées Microsoft. Vous pouvez suivre la documentation leur officielle ici.

Etape 0 : Rappel des prérequis

Comme vous allez travailler avec des tickets Kerberos spécifiques à Azure AD, il est obligatoire que les postes ayant accès au partage de fichiers PaaS disposent de l’un des OS suivants :

Windows 11 Enterprise mono ou multisession
Windows 10 Enterprise mono ou multisession, en version 2004 ou ultérieure avec la mise à jour KB5007253
Windows Server, version 2022 avec la dernière mise à jour KB5007254

Dans mon cas, j’ai utilisé l’environnement suivant :

une VM Windows Server 2022 pour jouer le contrôleur de domaine
Une environnement AVD composé de VMs en Windows 11 Enterprise multisession

Comme annoncé avant, les postes en accès au partage de fichier doivent donc être joints à Azure AD ou en mode hybride (Active Directory + Azure AD). Néanmoins, les utilisateurs doivent être « hybrides », il est donc nécessaire de passer par Azure AD Connect pour y arriver. Le choix du domaine managé Azure AD DS n’est donc pas possible ici :

Azure Active Directory Domain Services (Azure AD DS) : Azure AD DS fournit des services de domaine managé avec un sous-ensemble de fonctionnalités AD DS traditionnelles, comme la jonction de domaine, la stratégie de groupe, le protocole LDAP et l’authentification Kerberos/NTLM.
Active Directory Domain Services (AD DS) : serveur LDAP (Lightweight Directory Access Protocol) qui fournit des fonctionnalités clés telles que l’identité et l’authentification, la gestion des objets, la stratégie de groupe et les approbations.

Au final, les prérequis sont donc les suivants :

Un tenant Microsoft (Azure AD)
Des licences comprenant Windows 10 Entreprise pour vos utilisateurs AVD
Une souscription Azure active avec le rôle de propriétaire :

Un domaine Active Directory Domain Services (AD DS) :

Un agent Azure AD Connect installé et configuré pour l’hybridation (lire jusqu’à l’étape III)

Des utilisateurs AVD présents dans AD DS et synchronisés avec Azure AD :

Un environnement Azure Virtual Desktop déployé et lié à votre domaine AD DS :

Des machines virtuelles AVD jointes é la fois à votre AD DS et enrôlées dans votre Azure AD :

Une fois cela en place, déroulez les prochaines étapes d’installation depuis votre contrôleur de domaine.

Etape I : Création d’un nouveau compte de stockage

Sur votre portail Azure, commencez par créer votre nouveau compte de stockage :

Une fois créé, stockez l’ID de la souscription Azure, le nom du groupe de ressources et le nom du compte de stockage dans les variables suivantes :

$resourceGroupName = "<MyResourceGroup>"
$storageAccountName = "<MyStorageAccount>"
$Subscription = "<MySubscriptionID>"

Etape II : Configuration de l’authentification Azure AD

Vous allez utiliser plusieurs nouvelles fonctionnalités, il est donc préférable de réinstaller des modules PowerShell sur votre poste. Ouvrez PowerShell ISE en mode administrateur et lancez la commande suivante :

Install-Module -Name Az.Storage -AllowClobber
Install-Module -Name AzureAD -AllowClobber

Validez les messages d’avertissement si besoin :

L’activation de l’authentification via Azure AD passe elle aussi par une commande PowerShell :

Connect-AzAccount
$ApiVersion = '2021-04-01'

$Uri = ('https://management.azure.com/subscriptions/{0}/resourceGroups/{1}/providers/Microsoft.Storage/storageAccounts/{2}?api-version={3}' -f $Subscription, $ResourceGroupName, $StorageAccountName, $ApiVersion);

$json = 
   @{properties=@{azureFilesIdentityBasedAuthentication=@{directoryServiceOptions="AADKERB"}}};
$json = $json | ConvertTo-Json -Depth 99

$token = $(Get-AzAccessToken).Token
$headers = @{ Authorization="Bearer $token" }

try {
    Invoke-RestMethod -Uri $Uri -ContentType 'application/json' -Method PATCH -Headers $Headers -Body $json;
} catch {
    Write-Host $_.Exception.ToString()
    Write-Error -Message "Caught exception setting Storage Account directoryServiceOptions=AADKERB: $_" -ErrorAction Stop
}

Le lancement du script PowerShell vous demandera de vous authentifier en utilisant un compte propriétaire de la souscription Azure :

Le lancement réussi du script devrait vous donner le résultat suivant :

Constatez l’activation de la fonctionnalité en préview, directement sur le compte de stockage :

Il ne reste en plus qu’à générer une nouvelle clef pour le protocole Kerberos :

Set-azcontext -Subscription $Subscription
New-AzStorageAccountKey -ResourceGroupName $resourceGroupName -Name $storageAccountName -KeyName kerb1 -ErrorAction Stop

Cette clef n’est pas contre pas visible sur le portail Azure.

Etape III : Création d’une identité principal de service

L’activation des droits d’Azure AD sur le compte de stockage n’est pas encore possible via le portail Azure. Commencez par générer un mot de passe, basé sur la nouvelle clef Kerberos de votre compte stockage, et stocker le dans une variable grâce à la commande PowerShell suivante :

$kerbKey1 = Get-AzStorageAccountKey -ResourceGroupName $resourceGroupName -Name $storageAccountName -ListKerbKey | Where-Object { $_.KeyName -like "kerb1" }
$aadPasswordBuffer = [System.Linq.Enumerable]::Take([System.Convert]::FromBase64String($kerbKey1.Value), 32);
$password = "kk:" + [System.Convert]::ToBase64String($aadPasswordBuffer);

Lors d’une étape précédente, vous vous êtes déjà connecté à Azure. Connectez-vous maintenant à Azure AD :

Connect-AzureAD
$azureAdTenantDetail = Get-AzureADTenantDetail;
$azureAdTenantId = $azureAdTenantDetail.ObjectId
$azureAdPrimaryDomain = ($azureAdTenantDetail.VerifiedDomains | Where-Object {$_._Default -eq $true}).Name

Utilisez ici un compte administrateur global du tenant :

Préparer la génération du principal de sécurité :

$servicePrincipalNames = New-Object string[] 3
$servicePrincipalNames[0] = 'HTTP/{0}.file.core.windows.net' -f $storageAccountName
$servicePrincipalNames[1] = 'CIFS/{0}.file.core.windows.net' -f $storageAccountName
$servicePrincipalNames[2] = 'HOST/{0}.file.core.windows.net' -f $storageAccountName

Créez et chargez dans une variable les éléments nécessaires à la future Enregistrement d’applications :

$application = New-AzureADApplication -DisplayName $storageAccountName -IdentifierUris $servicePrincipalNames -GroupMembershipClaims "All";

Générez alors le principal de sécurité :

$servicePrincipal = New-AzureADServicePrincipal -AccountEnabled $true -AppId $application.AppId -ServicePrincipalType "Application";

Configurez le mot de passe stocké précédement pour celui-ci :

$Token = ([Microsoft.Open.Azure.AD.CommonLibrary.AzureSession]::AccessTokens['AccessToken']).AccessToken
$apiVersion = '1.6'
$Uri = ('https://graph.windows.net/{0}/{1}/{2}?api-version={3}' -f $azureAdPrimaryDomain, 'servicePrincipals', $servicePrincipal.ObjectId, $apiVersion)
$json = @'
{
  "passwordCredentials": [
  {
    "customKeyIdentifier": null,
    "endDate": "<STORAGEACCOUNTENDDATE>",
    "value": "<STORAGEACCOUNTPASSWORD>",
    "startDate": "<STORAGEACCOUNTSTARTDATE>"
  }]
}
'@
$now = [DateTime]::UtcNow
$json = $json -replace "<STORAGEACCOUNTSTARTDATE>", $now.AddDays(-1).ToString("s")
  $json = $json -replace "<STORAGEACCOUNTENDDATE>", $now.AddMonths(12).ToString("s")
$json = $json -replace "<STORAGEACCOUNTPASSWORD>", $password
$Headers = @{'authorization' = "Bearer $($Token)"}
try {
  Invoke-RestMethod -Uri $Uri -ContentType 'application/json' -Method Patch -Headers $Headers -Body $json 
  Write-Host "Success: Password is set for $storageAccountName"
} catch {
  Write-Host $_.Exception.ToString()
  Write-Host "StatusCode: " $_.Exception.Response.StatusCode.value
  Write-Host "StatusDescription: " $_.Exception.Response.StatusDescription
}

Etape IV : Définir les autorisations API sur l’application nouvellement créée

Comme indiqué dans la documentation Microsoft, la suite du processus peut se faire dans le portail Azure. Ouvrez votre portail Azure Active Directory :

Dans vos Enregistrement d’applications, cliquez sur Toutes les applications, puis enfin sélectionnez l’application dont le nom correspond à votre compte de stockage :

Dans les autorisations API dans le volet de gauche, ajoutez une autorisation comme ceci :

Sélectionnez Microsoft Graph, puis choisissez délégation des permissions :

Dans la section OpenID, sélectionnez Profile :

Descendez plus bas dans la liste pour retrouver la section User. Cochez alors User.Read et cliquez sur Ajouter :

Une fois sur retourné sur l’écran des permissions, cliquez ci-dessous pour ajouter le consentement global à tout votre tenant :

Constatez la bonne application de celui-ci grâce au statut à droite :

Etape V : Création du partage de fichier

Retournez sur votre compte de stockage pour créer un nouveau partage de fichier comme ceci :

Etape VI : Jointure du partage de fichier Azure au domaine Active Directory

Pour l’instant, le partage de fichier Azure nécessite encore l’attribution de droits RBAC aux utilisateurs Azure Virtual desktop. Dans votre cas cette fonctionnalité nécessite d’activer l’authentification AD DS sur le compte de stockage.

Commencez par télécharger sur GitHub la version la plus récente du module PowerShell AzFilesHybrid.zip :

Décompressez les fichiers sur le disque C sur une VM, jointe à votre domaine :

Démarrez Windows PowerShell ISE en tant qu’administrateur et exécutez ce qui suit pour supprimer le flux de données alternatif Zone.Identifier, qui a une valeur de 3, indiquant qu’il a été téléchargé à partir d’Internet :

Get-ChildItem -Path C:\AzFilesHybrid -File -Recurse | Unblock-File

Toujours en PowerShell, connectez-vous à Azure :

Connect-AzAccount

Lancez alors le script suivant en modifiant les paramètres, selon votre configuration :

.\CopyToPSPath.ps1
Import-Module -Name AzFilesHybrid
Join-AzStorageAccountForAuth `
  -ResourceGroupName 'aadjoin-rg' `
  -StorageAccountName 'jloaadjoin2' `
  -DomainAccountType 'ComputerAccount' `
  -OrganizationalUnitDistinguishedName 'OU=AVDJOIN-Devices,DC=jloudev,DC=ml'

Constatez le retour de commande suivant :

Vous pouvez aussi contrôler la bonne activation sur le compte de stockage :

Restez sur votre compte de stockage pour assigner le rôle Storage File Data SMB Share Contributor à votre utilisateurs Azure Virtual Desktop :

*Dans notre démonstration, nous allons seulement autoriser le groupe d’utilisateurs Azure Virtual Desktop.*

Etape VII : Attribution des autorisations

Pour empêcher les utilisateurs d’accéder aux profils utilisateurs d’autres utilisateurs, vous devez également attribuer des autorisations au niveau du répertoire.

Le système que vous utilisez pour configurer les permissions doit répondre aux exigences suivantes :

La poste a une version de Windows répond aux exigences des systèmes d’exploitation des prérequis
Le poste doit être joint à Azure AD ou à Hybrid Azure AD à Azure AD
Le poste est relié au contrôleur de domaine

Installez ou importez si besoin sur le poste le module PowerShell ActiveDirectory. Dans mon cas, je n’ai pas eu à faire cette opération car j’ai tout exécuté depuis mon contrôleur de domaine :

Import-module ActiveDirectory

Azure AD ne prenant pas actuellement en charge la configuration des listes de contrôle d’accès dans Shell, il doit s’appuyer sur Active Directory. Pour configurer Shell sur votre compte de stockage, exécutez la commande suivante dans PowerShell ISE en tant qu’administrateur :

function Set-StorageAccountAadKerberosADProperties {
    [CmdletBinding()]
    param(
        [Parameter(Mandatory=$true, Position=0)]
        [string]$ResourceGroupName,

        [Parameter(Mandatory=$true, Position=1)]
        [string]$StorageAccountName,

        [Parameter(Mandatory=$false, Position=2)]
        [string]$Domain
    )  

    $AzContext = Get-AzContext;
    if ($null -eq $AzContext) {
        Write-Error "No Azure context found.  Please run Connect-AzAccount and then retry." -ErrorAction Stop;
    }

    $AdModule = Get-Module ActiveDirectory;
     if ($null -eq $AdModule) {
        Write-Error "Please install and/or import the ActiveDirectory PowerShell module." -ErrorAction Stop;
    }	

    if ([System.String]::IsNullOrEmpty($Domain)) {
        $domainInformation = Get-ADDomain
        $Domain = $domainInformation.DnsRoot
    } else {
        $domainInformation = Get-ADDomain -Server $Domain
    }

    $domainGuid = $domainInformation.ObjectGUID.ToString()
    $domainName = $domainInformation.DnsRoot
    $domainSid = $domainInformation.DomainSID.Value
    $forestName = $domainInformation.Forest
    $netBiosDomainName = $domainInformation.DnsRoot
    $azureStorageSid = $domainSid + "-123454321";

    Write-Verbose "Setting AD properties on $StorageAccountName in $ResourceGroupName : `
        EnableActiveDirectoryDomainServicesForFile=$true, ActiveDirectoryDomainName=$domainName, `
        ActiveDirectoryNetBiosDomainName=$netBiosDomainName, ActiveDirectoryForestName=$($domainInformation.Forest) `
        ActiveDirectoryDomainGuid=$domainGuid, ActiveDirectoryDomainSid=$domainSid, `
        ActiveDirectoryAzureStorageSid=$azureStorageSid"

    $Subscription =  $AzContext.Subscription.Id;
    $ApiVersion = '2021-04-01'

    $Uri = ('https://management.azure.com/subscriptions/{0}/resourceGroups/{1}/providers/Microsoft.Storage/storageAccounts/{2}?api-version={3}' `
        -f $Subscription, $ResourceGroupName, $StorageAccountName, $ApiVersion);

    $json=
        @{
            properties=
                @{azureFilesIdentityBasedAuthentication=
                    @{directoryServiceOptions="AADKERB";
                        activeDirectoryProperties=@{domainName="$($domainName)";
                                                    netBiosDomainName="$($netBiosDomainName)";
                                                    forestName="$($forestName)";
                                                    domainGuid="$($domainGuid)";
                                                    domainSid="$($domainSid)";
                                                    azureStorageSid="$($azureStorageSid)"}
                                                    }
                    }
        };  

    $json = $json | ConvertTo-Json -Depth 99

    $token = $(Get-AzAccessToken).Token
    $headers = @{ Authorization="Bearer $token" }

    try {
        Invoke-RestMethod -Uri $Uri -ContentType 'application/json' -Method PATCH -Headers $Headers -Body $json
    } catch {
        Write-Host $_.Exception.ToString()
        Write-Host "Error setting Storage Account AD properties.  StatusCode:" $_.Exception.Response.StatusCode.value__ 
        Write-Host "Error setting Storage Account AD properties.  StatusDescription:" $_.Exception.Response.StatusDescription
        Write-Error -Message "Caught exception setting Storage Account AD properties: $_" -ErrorAction Stop
    }
}

Lancez alors la fonction précédente grâce à cette commande :

Connect-AzAccount
Set-StorageAccountAadKerberosADProperties -ResourceGroupName $resourceGroupName -StorageAccountName $storageAccountName

Cette commande fait alors rebasculer le statut Active Directory sur compte de stockage comme ceci :

Etape VIII : Création de la GPO

Toujours sur votre contrôleur de domaine, ouvrez le gestionnaire des polices :

Sous votre OU des postes AVD, créez une nouvelle police et éditez là :

Activer la police suivante :

Administrative Templates\System\Kerberos\Allow retrieving the Azure AD Kerberos Ticket Granting Ticket during logon

Ajoutez également une règle de registre sur cette même police :

reg add HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters /v CloudKerberosTicketRetrievalEnabled /t REG_DWORD /d 1

Redémarrez les VMs Azure Virtual Desktop pour la bonne prise en compte de la GPO :

Connectez-vous à une session Azure Virtual Desktop grâce à Windows Remote Desktop :

Une fois la session AVD ouverte, ouvrez une ligne de commande et tapez le code suivant :

dsregcmd /RefreshPrt

Verrouillez votre session AVD, puis déverrouillez-là :

Saisissez les deux lignes de commande suivantes :

klist purge
klist get krbtgt

Constatez la présence de :

krbtgt/KERBEROS.MICROSOFTONLINE.COM @ KERBEROS.MICROSOFTONLINE.COM

Lancez enfin la commande net use pour monter le lecteur réseau et vérifiez le bon fonctionnement :

net use Z: \\jloaadjoin2.file.core.windows.net\avdfileshare

*Il arrive par moment que la commande échoue la première fois.*

On retrouve bien le disque réseau dans l’explorateur Windows :

En retournant sur les tickets Kerberos, un nouveau CIFS a fait son apparition :

Etape IX : Configuration de FSLogix

Une fois l’architecture en place, on peut combiner cette dernière pour la gestion des profils utilisateurs via FSLogix. Pour cela, il nous faut rajouter la configuration FSLogix et une règle de registre en plus pour Azure AD.

#Variables
$storageAccountName = "jloaadjoin2"
$filesharename = "avdfileshare"

#Create Directories
$LabFilesDirectory = "C:\LabFiles"

if(!(Test-path -Path "$LabFilesDirectory")){
New-Item -Path $LabFilesDirectory -ItemType Directory |Out-Null
}
if(!(Test-path -Path "$LabFilesDirectory\FSLogix")){
New-Item -Path "$LabFilesDirectory\FSLogix" -ItemType Directory |Out-Null
}

 #Download FSLogix Installation bundle
  if(!(Test-path -Path "$LabFilesDirectory\FSLogix_Apps_Installation.zip")){
       Invoke-WebRequest -Uri "https://experienceazure.blob.core.windows.net/templates/wvd/FSLogix_Apps_Installation.zip" -OutFile     "$LabFilesDirectory\FSLogix_Apps_Installation.zip"

 #Extract the downloaded FSLogix bundle
 function Expand-ZIPFile($file, $destination){
     $shell = new-object -com shell.application
     $zip = $shell.NameSpace($file)
     foreach($item in $zip.items()){
     $shell.Namespace($destination).copyhere($item)
     }
 }

 Expand-ZIPFile -File "$LabFilesDirectory\FSLogix_Apps_Installation.zip" -Destination "$LabFilesDirectory\FSLogix"

}
   #Install FSLogix
   if(!(Get-WmiObject -Class Win32_Product | where vendor -eq "FSLogix, Inc." | select Name, Version)){
       $pathvargs = {C:\LabFiles\FSLogix\x64\Release\FSLogixAppsSetup.exe /quiet /install }
       Invoke-Command -ScriptBlock $pathvargs
   }
   #Create registry key 'Profiles' under 'HKLM:\SOFTWARE\FSLogix'
   $registryPath = "HKLM:\SOFTWARE\FSLogix\Profiles"
   if(!(Test-path $registryPath)){
       New-Item -Path $registryPath -Force | Out-Null
   }

   #Add registry values to enable FSLogix profiles, add VHD Locations, Delete local profile and FlipFlop Directory name
   New-ItemProperty -Path $registryPath -Name "VHDLocations" -Value "\\$storageAccountName.file.core.windows.net\$filesharename" -PropertyType String -Force | Out-Null
   New-ItemProperty -Path $registryPath -Name "Enabled" -Value 1 -PropertyType DWord -Force | Out-Null
   New-ItemProperty -Path $registryPath -Name "DeleteLocalProfileWhenVHDShouldApply" -Value 1 -PropertyType DWord -Force | Out-Null
   New-ItemProperty -Path $registryPath -Name "FlipFlopProfileDirectoryName" -Value 1 -PropertyType DWord -Force | Out-Null
    
    reg add HKLM\Software\Policies\Microsoft\AzureADAccount /v LoadCredKeyFromProfile /t REG_DWORD /d 1

   #Display script completion in console
Write-Host "Script Executed successfully"

L’ouverture d’une nouvelle session utilisateurs d’AVD vous affiche bien la mention FSLogix :

Un tour dans le partage de fichier du compte de stockage montre bien la présence du dossier du profil utilisateur géré par FSLogix :

Conclusion

La gestion des tickets Kerberos par Azure AD est une belle avancée. Bien évidemment, le processus de prise en charge complète d’un compte de stockage de manière native n’est pas encore là, mais nous y sommes en bonne voie ???? Comme à chaque fois, n’hésitez pas à utiliser les commentaires pour exprimer de vos retours ????

Windows 11 + AVD + Azure AD

Je vous avais déjà parlé il a quelque temps de la jointure possible entre des machines virtuelles Azure Virtual Desktop et Azure AD ici. Cela offre la possibilité de se passer d’un Active Directory pour environnement AVD et permet d’envisager certains projets avec une architecture 100% Cloud.

Avec l’arrivée prochaine de Windows 11, il me paraissait intéressant de tester cette combinaison avec le nouvel OS de Microsoft.

Point important : Comme précédemment, nous sommes toujours dans l’attente d’une prise en charge de FSLogix dans ce scénario. L’utilisation d’un partage de fichier nécessite une authentification SMB, non possible pour l’instant via la seule gestion des identités Azure AD.

Rappel des prérequis

Comme pour tout déploiement dans Azure, des prérequis sont nécessaires :

Un tenant Microsoft
Une souscription Azure
Un réseau virtuel
Des licences pour les utilisateurs AVD, comprenant Azure Virtual Desktop

La liste est donc beaucoup plus courte qu’avec un domaine classique ????.

Déploiement de la solution

Une fois votre réseau virtuel en place, la création de l’ensemble pourra se faire directement depuis Azure Virtual Desktop. Dans le cadre d’un environnement de production, la création d’une image en amont reste l’étape indispensable pour installer les applications nécessaires à vos utilisateurs !

Sur le portail Azure, recherchez Azure Virtual Desktop dans la barre de recherche et sélectionnez Azure Virtual Desktop dans les suggestions :

Sur l’écran d’Azure Virtual Desktop, choisissez Créer un Pool d’hôtes :

Renseignez les informations de base sur votre pool d’hôtes puis cliquez sur Suivant : Machines virtuelles :

Renseignez les principales caractéristiques de vos machines virtuelles AVD :

L’image de Windows 11 n’est pas forcément proposée dans la liste. Il vous faudra alors la chercher dans la marketplace Azure :

Renseignez les informations réseaux :

Prenez le temps de considérer les options concernant le domaine à joindre :

Type de domaine à joindre : Choisissez Azure Active Directory
Intune : il est également possible d’automatiser l’enrôlement des machines virtuelles AVD dans Intune. Cela permet de configurer ces dernières, qu’elles soient dédiées ou partagées entre utilisateurs

Il est toujours demandé de créer un compte administrateur local :

Cliquez sur Suivant et créez un nouvel espace de travail :

Enfin lancez la création quand Azure a validé votre configuration :

Environ 10-15 minutes plus tard, le déploiement doit se finir sur une note positive :

Contrôlez quelques minutes après la bonne disponibilité des machines virtuelles dans le pool d’hôtes AVD :

Pensez à assigner le groupe d’utilisateurs AVD sur l’application créée par le pool d’hôtes :

Pour que la connexion RDP avec l’identité utilisateur Azure AD se fasse bien, il est nécessaire d’ajouter un argument spécifique. La gestion des propriétés RDP se fait directement sur le pool d’hôtes d’AVD :

Afin d’autoriser les utilisateurs à se connecter aux machines virtuelles, l’attribution des rôles RBAC est nécessaire. Pour rappel, ces rôles sont différents de ceux dans Azure AD, puisqu’ils sont affectés au ressources d’Azure. Dans notre AVD, l’affectation de deux rôles RBAC est nécessaires et se fait directement sur le groupe de ressources AVD :

Virtual Machine Administrator Login : Groupe d’utilisateurs ayant les droits d’administrateur local sur les machines virtuelles AVD
Virtual Machine User Login : Affecter le rôle Virtual Machine User Login au même groupe d’utilisateurs que celui utilisé pour le groupe d’application AVD

Il ne reste plus qu’à tester la solution avec un utilisateur AVD. Cela se fait en téléchargeant le client Windows Remote Desktop PC dédié à Azure Virtual Desktop (téléchargeable ici), ou via l’accès web multi-plateformes (accessible là). J’ai choisi dans mon cas Windows Remote Desktop :

Une seconde demande d’authentification est affichée pour accéder à la machine virtuelle via le protocole RDP :

Une fois le mot de passe saisi, l’ouverture d’une fenêtre RDP donne l’accès au bureau Windows 11 d’AVD. A noter que la jointure AVD apporte également le Seamless Sign on, rendant l’expérience utilisateur encore plus agréable :

Regardez en détail cette jointure avec Azure AD grâce à la commande :

dsregcmd /status

Vérifiez que les machines virtuelles Windows 11 Azure Virtual Desktop sont bien présentes dans la section Devices d’Azure AD. Cet ajout est réalisé lors de la jointure des machines virtuelles à Azure AD :

Vérifiez, si vous avez coché Intune, que vous retrouvez bien mes machines virtuelles dans la console :

Si vous rencontrez des erreurs lors du déploiement, Microsoft met à votre disposition cette page d’aide. Voici une des erreurs possibles :

Erreur de mot de passe de l’ouverture de la session RDP : “The logon attempt failed”

Si vous rencontrez une erreur indiquant que la tentative de connexion a échoué à l’invite des informations d’identification de sécurité Windows, vérifiez les éléments suivants :

Vous êtes sur un appareil qui est joint à Azure AD ou à Azure AD hybride au même locataire Azure AD que l’hôte de session OU
Vous êtes sur un appareil exécutant Windows 10 2004 ou version ultérieure qui est Azure AD enregistré auprès du même locataire Azure AD que l’hôte de session
Le protocole PKU2U est activé à la fois sur le PC local et sur l’hôte de session

La dernière hypothèse est fortement probable dans ce cas. Il faut donc penser à vérifier cette option sur la machine locale ET sur la machine virtuelle AVD, grâce à la commande secpol.msc :

Conclusion

Windows 11 s’intègre de plus en plus dans l’environnement Azure. Azure Virtual Desktop va grandement bénéficier de ce nouvel OS pour accroitre son utilité dans les solutions de bureau à distance. Comme pour Windows 10, on attend toujours la prise en charge de la solution FSLogix dans ce scénario de jointure avec Azure AD.

Comme à chaque fois, pensez également à partager dans les commentaires vos propres expériences sur Azure Virtual Desktop ????

Windows 11 + Azure Virtual Desktop = 1

Ayant récemment abordé l’ajout d’images Windows 11 sous Azure ici, je me devais également de faire un nouvel article sur l’installation de machines virtuelles W11 au sein d’un environnement Azure Virtual Desktop.

Dans cet article nous allons tester différentes manières d’associer des machines virtuelles Windows 11 à AVD. Chaque méthode apporte des avantages et un niveau d’automatisation différent. Comme à chaque fois, il faut disposer au préalable d’un tenant et d’une souscription Azure sur laquelle vous déploierez les ressources Azure.

Etape 0 : Prérequis Licenses + Azure

A la différence d’un environnement RDS, Azure Virtual Desktop ne nécessite pas de licence côté serveur dans le cadre d’un environnement Windows 10/11. Cela n’est pas le cas si votre AVD est basé sur Windows Server. Vous pouvez accéder à Windows 10 et Windows 7 avec Azure Virtual Desktop si vous possédez l’une des licences suivantes par utilisateur :

Microsoft 365 E3/E5
Microsoft 365 A3/A5/Student Use Benefits
Microsoft 365 F3
Microsoft 365 Business Premium
Windows 10 Entreprise E3/E5
Windows 10 Éducation A3/A5
Windows 10 VDA par utilisateur

Comme indiqué précédemment, nous allons commencer les déploiements en partant des prérequis suivants :

Un tenant Microsoft
Une souscription Azure
Un réseau virtuel
Un contrôleur de domaine (VM AD + Azure AD Connect ou Azure AD DS)
Un compte de stockage, paramétré pour FSLogix
Un pool d’hôtes Azure Virtual Desktop
Un espace de travail Azure Virtual Desktop

*Voici une liste des ressources Azure déjà en place sur ma souscription, avant la mise en place de Windows 11.*

Les points listés sont les mêmes pour un environnement Azure Virtual Desktop en Windows 10. Une fois en place, nous allons déployer des machines virtuelles en Windows 11 via les méthodes suivantes :

Méthode 1 : Déploiement direct depuis le pool d’hôtes AVD
Méthode 2 : Création d’une VM, puis enrôlement manuel dans le pool d’hôtes AVD
Méthode 3 : Création d’une VM puis enrôlement automatique via une extension script
Méthode 4 : Utilisation d’un template entièrement automatique et hébergé GitHub

Méthode 1 : Déploiement depuis le host pool

Dans cette méthode, nous allons simplement créer et ajouter une machine virtuelle Windows 11 sur notre environnement Azure Virtual Desktop.

Sur le portail Azure, recherchez Azure Virtual Desktop dans la barre de recherche et sélectionnez Azure Virtual Desktop dans les suggestions :

Sur l’écran d’Azure Virtual Desktop, choisissez Pool d’hôtes puis cliquez sur celui déjà créé précédemment dans votre environnement :

Si vous avez créé le vôtre sans machine virtuelle comme le mien, vous devriez avoir le chiffre 0 dans le nombre total de machines virtuelles. Cliquez dessus pour en ajouter :

Cliquez sur Ajouter :

Le premier onglet est grisé, car ces informations sont dédiées au pool d’hôtes. Cliquez sur le bouton Suivant pour ajouter la machine virtuelle :

Après avoir renseigné les premiers champs, cherchez l’image de Windows 11 en cliquant pour voir toutes les images disponibles dans la marketplace Azure :

Utilisez la barre de recherche pour retrouver l’image Windows 11, puis choisissez l’image avec les applications Microsoft 365 Gen 2 :

*Cliquez ici pour obtenir plus d’information sur Windows 11 Gen 2 (bas de l’article)*.

Choisissez la puissance et le nombre de machines virtuelles ainsi que la performance du disque OS :

*Microsoft recommande toujours les disques Premium SSD pour les environnements AVD de production*.

Sélectionnez le réseau virtuel et le sous-réseau correspondant :

*Il est vivement conseiller de créer un sous-réseau propre à AVD.*

Continuez avec les informations du domaine :

Les éléments de jointure sont importants car ils peuvent faire échouer le déploiement Azure.
Prenez le temps de bien vérifier ces informations.

Finissez avec les informations d’administration des machines virtuelles, puis cliquez pour valider la création :

Une fois la validation passée, vous pouvez déclencher la création de la ou les machines virtuelles :

La création ne prendra alors que quelques minutes seulement :

Retournez sur votre pool d’hôtes pour bien constater l’apparition et la bonne disponibilité des VMs :

Enfin, pensez bien à affecter un groupe d’utilisateurs AVD, issu de votre domaine AD sur le groupe d’application de bureau à distance :

Lancez Windows Remote Desktop avec un utilisateur AVD pouvant lancer la session de bureau à distance :

Une dernière authentification est alors demandée pour ouvrir la session Windows 11 à l’utilisateur :

Ca y est, on dispose enfin de notre premier bureau Windows 11 sous AVD !!!

Il ne reste plus qu’à rajouter les informations de registre pour finaliser la configuration FSLogix :

#Variables
$storageAccountName = "fslogixjl"
$fileshare = "userprofiles"

#Create registry key 'Profiles' under 'HKLM:\SOFTWARE\FSLogix'
   $registryPath = "HKLM:\SOFTWARE\FSLogix\Profiles"
   if(!(Test-path $registryPath)){
       New-Item -Path $registryPath -Force | Out-Null
   }

#Add registry values to enable FSLogix profiles, add VHD Locations, Delete local profile and FlipFlop Directory name
New-ItemProperty -Path $registryPath -Name "VHDLocations" -Value "\\$storageAccountName.file.core.windows.net\$fileshare" -PropertyType String -Force | Out-Null
New-ItemProperty -Path $registryPath -Name "Enabled" -Value 1 -PropertyType DWord -Force | Out-Null
New-ItemProperty -Path $registryPath -Name "DeleteLocalProfileWhenVHDShouldApply" -Value 1 -PropertyType DWord -Force | Out-Null
New-ItemProperty -Path $registryPath -Name "FlipFlopProfileDirectoryName" -Value 1 -PropertyType DWord -Force | Out-Null

#Display script completion in console
Write-Host "Script Executed successfully"

Contrôlez alors dans votre partage de fichier créé pour FSLogix la présence du VHD :

En conclusion, la méthode habituelle de déploiement d’un Azure Virtual Desktop ne diffère en rien avec Windows 11. Nous allons nous intéresser à d’autres méthodes possibles de déploiement de Windows 11 pour AVD.

Méthode 2 : Création d’une VM puis enrôlement manuel

Quel que soit l’OS désiré, il est possible de créer une machine virtuelle par la méthode classique puis de l’enrôler manuellement via l’installation de la solution RD Agent.

Dans le cadre de l’installation de Windows 11 avec le Trusted Launch (encore en Preview), il faut alors utiliser ce portail Azure. La création de la machine virtuelle est alors des plus classiques :

Ajoutez provisoirement une adresse IP publique afin de pouvoir installer l’agent AVD :

Dans l’onglet Avancée, l’utilisation d’une image Gen 2 vous permet alors de profiter de toutes les fonctionnalités du Trusted Launch :

Connectez-vous en RDP sur la machine virtuelle nouvellement créée et suivez le processus suivant :

Joignez la machine virtuelle Windows 11 au domaine AD :

Téléchargez l’agent Azure Virtual Desktop et exécutez le programme d’installation
Lorsque le programme d’installation vous demande le jeton d’inscription, entrez la clef d’enregistrement disponible dans le pool d’hôtes AVD

*Retrouvez la clef d’enregistrement AVD directement sur le pool d’hôtes AVD.*

*Copiez la clef récupérée dans le programme d’installation d’AVD.*

Téléchargez l’agent de démarrage d’Azure Virtual Desktop et exécutez le programme d’installation
Télécharger et installez FSLogix puis ajoutez via PowerShell la configuration FSLogix :

#Variables
$storageAccountName = "fslogixjl"
$fileshare = "userprofiles"

#Create registry key 'Profiles' under 'HKLM:\SOFTWARE\FSLogix'
   $registryPath = "HKLM:\SOFTWARE\FSLogix\Profiles"
   if(!(Test-path $registryPath)){
       New-Item -Path $registryPath -Force | Out-Null
   }

#Add registry values to enable FSLogix profiles, add VHD Locations, Delete local profile and FlipFlop Directory name
New-ItemProperty -Path $registryPath -Name "VHDLocations" -Value "\\$storageAccountName.file.core.windows.net\$fileshare" -PropertyType String -Force | Out-Null
New-ItemProperty -Path $registryPath -Name "Enabled" -Value 1 -PropertyType DWord -Force | Out-Null
New-ItemProperty -Path $registryPath -Name "DeleteLocalProfileWhenVHDShouldApply" -Value 1 -PropertyType DWord -Force | Out-Null
New-ItemProperty -Path $registryPath -Name "FlipFlopProfileDirectoryName" -Value 1 -PropertyType DWord -Force | Out-Null

#Display script completion in console
Write-Host "Script Executed successfully"

Redémarrez la machine virtuelle

La nouvelle machine rejoint alors celle de la première méthode :

Testez la connexion à Azure Virtual Desktop via l’accès HTML 5 depuis cette URL :

Contrôlez sur le compte de stockage l’apparition du second profil utilisateur :

En conclusion, la seconde méthode de déploiement d’un Azure Virtual Desktop par la création d’une VM, puis son enrôlement fonctionne très bien Windows 11. Nous allons maintenant nous intéresser à la création d’une VM dans AVD par l’ajout d’un script en extension.

Méthode 3 : Création d’une VM puis enrôlement automatique via une extension script

La 3ème méthode est très proche de la seconde méthode, à savoir qu’elle se fait par le déploiement d’une machine virtuelle. La différence va porter par l’utilisation d’une extension, appelant un script en PowerShell. Nous devons ce script à Dean Cefola, de l’Azure Academy. Ce script a connu les évolutions suivantes :

# 09/15/2019                     1.0        Intial Version
# 09/16/2019                     2.0        Add FSLogix installer
# 09/16/2019                     2.1        Add FSLogix Reg Keys 
# 09/16/2019                     2.2        Add Input Parameters 
# 09/16/2019                     2.3        Add TLS 1.2 settings
# 09/17/2019                     3.0        Chang download locations to dynamic
# 09/17/2019                     3.1        Add code to disable IESEC for admins
# 09/20/2019                     3.2        Add code to discover OS (Server / Client)
# 09/20/2019                     4.0        Add code for servers to add RDS Host role
# 10/01/2019                     4.2        Add all FSLogix Profile Container Reg entries for easier management
# 10/07/2019                     4.3        Add FSLogix Office Container Reg entries for easier management
# 10/16/2019                     5.0        Add Windows 7 Support
# 07/20/2020                     6.0        Add WVD Optimize Code from The-Virtual-Desktop-Team
# 10/27/2020                     7.0        Optimize FSLogix settings - Remove Office Profile Settings
# 02/01/2021                     7.1        Add RegKey for Screen Protection
# 05/22/2021                     7.2        Multiple changes to WVD Optimization code (remove winversion, Add EULA, Add Paramater for Optimize All
# 06/30/2021                     7.3        Add RegKey for Azure AD Join

Renseignez les paramètres de la machine virtuelle de manière classique, et cliquez sur l’ajout d’une extension à installer dans l’onglet Avancé :

Cherchez dans la liste celle appelée Custom Script Extension :

Puis cliquez sur Créer:

L’extension doit être stockée sur un compte de stockage de type Blob, vous pouvez la chercher ici :

Sélectionnez un compte de stockage si vous en disposez d’un. Si non, il vous faudra en créer un :

Créez un nouveau container pour stocker le script PowerShell :

Nommez-le et cliquez sur Créer :

Rentrez dans celui-ci et cliquez sur Upload :

Renseignez l’URL suivante dans le nom du fichier et cliquez sur Ouvrir :

https://raw.githubusercontent.com/DeanCefola/Azure-WVD/master/PowerShell/New-WVDSessionHost.ps1

Cliquez ensuite sur Upload :

Enfin cliquez sur Sélectionner :

Vous devrez ensuite renseigner deux paramètres pour que l’extension fonctionne correctement :

Profilepath : nom du partage SMB où doivent être stockés les profiles FSLogix
RegistrationToken : Clef d’enregistrement des machines dans le pool d’hôtes Azure Virtual Desktop

Ce qui donne dans mon cas les paramètres suivants :

-ProfilePath \\fslogixjl.file.core.windows.net\userprofiles -RegistrationToken eyJhbGciOiJSUzI1NiIsImtpZCI6Ijk3NkE4Q0I1MTQwNjkyM0E4MkU4QUQ3MUYzQjE4NzEyN0Y2OTRDOTkiLCJ0eXAiOiJKV1QifQ.eyJSZWdpc3RyYXRpb25JZCI6IjY2N2RhOGUyLWMxMDAtNGU1Ni1hMTIyLWZmOGFkMTE3YjdmMyIsIkJyb2tlclVyaSI6Imh0dHBzOi8...

Pensez encore une fois à activer toutes les fonctionnalités du Trusted Launch sur le même onglet Avancé :

Lancez la création de la machine virtuelle. Quelques minutes plus tard, vous devriez constater l’apparition de la machine virtuelle dans votre pool d’hôtes Azure Virtual Desktop :

La machine restera en indisponible tant que cette dernière n’est pas jointe au domaine Active Directory. Pour cela, vous devrez vous connecter en RDP à cette dernière avec le compte administrateur renseigné lors de sa création. Une fois connecté il ne vous restera qu’à rejoindre le domaine :

Un redémarrage plus tard, vous devriez constater que la machine virtuelle est bien passée en Disponible dans Azure Virtual Desktop :

Un lancement d’une session AVD utilisera les paramètres FSLogix que vous avez renseigné et le dossier sera bien créé sur le compte de stockage :

En conclusion, cette 3ème méthode est pratique, mais demande encore quelques opérations manuelles. La dernière méthode de cet article, elle aussi créée par Dean, est encore plus automatisée.

Méthode 4 : Utilisation d’un template GitHub

Cette 4ème et dernière méthode nous amène sur GitHub et ses liens de déploiement vers Azure. La page GitHub de Dean se trouve ici. Sur cette page se trouve ce qui nous intéresse :

Cliquez sur ce lien pour emporter le template sur votre portail Azure. Renseignez les champs selon les paramètres de votre environnement AVD et Validez :

Le template va alors se déployer en quelques minutes :

Vérifiez alors la bonne jointure des VMs avec Azure Virtual Desktop via le pool d’hôtes :

Comme à chaque fois, un lancement d’une session AVD utilisera les paramètres FSLogix que vous aviez renseigné et le dossier sera bien créé sur le compte de stockage :

En conclusion, cette 4ème et dernière méthode est certainement la plus pratique de toutes et en plus très rapide, même si certaines options de machines virtuelles ne sont alors plus disponibles au moment de la configuration.

Conclusion

Windows 11 est maintenant bien présent sur Azure Virtual Desktop. Sa sortie très prochaine nous amène à considérer cet OS dans de futurs projets de bureau à distance. Je suis sûr que Microsoft continuera à nous apporter encore plus de fonctionnalités dans les mois qui viennent. Pour vous aider dans les tests de ces différentes méthodes, vous trouverez ci-dessous la vidéo YouTube mis en ligne par Dean sur ce sujet et qui m’a aidé à préparer mon article :

Enfin n’hésitez pas à faire part de vos remarques sur Windows 11 sur AVD dans les commentaires ????