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 :

OptionValeur
RôleStorage File Data SMB Share Elevated Contributor
Assign access toGroup
Selectavd-admins
OptionValeur
Rôle Storage File Data SMB Share Elevated Contributor
Assign access toGroup
Selectavd-hosts
OptionValeur
Rôle Storage File Data SMB Share Reader
Assign access toGroup
Selectavd-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) :
  • 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 :

Utilisez un compte utilisateur d’AVD.

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 ). 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 😋

AVD + Azure AD Join

Attendu depuis longtemps par la communauté Azure Virtual Desktop, Azure AD Join est enfin là ! Lancé il y a seulement quelques jours en public preview, la possibilité de se passer d’un Active Directory pour environnement AVD permet d’envisager certains projets avec une architecture 100% Cloud. Dans cet article, nous allons voir ensemble cette fonctionnalité et les bénéfices apportés par cette dernière.

Point important : cette amélioration pose un souci pour l’utilisation de la gestion des profiles via FSLogix, car l’utilisation d’un partage de fichier nécessite une authentification SMB, non possible pour l’instant via la gestion des identités Azure AD.

Introduction

Gestion des identités sur Azure Virtual Desktop : Rappel de l’existant

Jusqu’à présent, un environnement Azure Virtual Desktop (anciennement Windows Virtual Desktop) nécessitait de joindre les machines virtuelles Azure à un domaine Active Directory. Ce domaine pouvait provenir d’un Windows Server, ayant le rôle d’Active Directory sur un machine virtuelle Azure, ou via le service de domaine managé Azure AD DS.

Merci à Dean pour cette explication claire sur la gestion des identités sous AVD.

Qu’est-ce qu’un périphérique joint à Azure AD ?

La jonction Azure AD est destinée aux organisations axées en priorité ou uniquement sur le cloud. Toute organisation peut déployer des appareils joints Azure AD, quels que soient leur taille et leur secteur d’activité. La jonction Azure AD fonctionne même dans un environnement hybride et permet l’accès aux applications et ressources locales et cloud

Documentation Microsoft

Attention, il est possible de joindre des machines en Windows 10 à Azure AD, à l’exception de Windows 10 Famille.

Cette jointure à Azure AD est prévu à l’origine pour des entreprises ne disposant pas d’une infrastructure Windows Server Active Directory locale.

Dans le cas contraire, il est malgré tout possible de fonctionner de manière hybride. L’avantage sera de protéger les appareils Windows 10, tout en conservant l’accès aux ressources locales qui nécessitent une authentification locale. Dans ce cas précis, nous parlerons alors des machines jointes à Azure AD hybride. Ces appareils sont joints à votre annuaire Active Directory local et à votre Azure AD.

Appareils joints Azure AD

Pourquoi se passer d’un contrôleur de domaine pour AVD ?

Le premier argument est le coût ! Beaucoup de projets Azure Virtual Desktop sont petits et concernent un petit nombre d’utilisateurs en Remote Desktop. L’ajout d’un domaine sur des VMs ou via un domaine managé augmente la facture environ plus une centaine d’euros par mois .

Enfin, la gestion des machines AVD peut également se faire via Intune (Endpoint Manager). Que vous utilisiez des machines virtuelles partagées ou individuelles pour AVD, Intune peut gérer les deux 😋Un précédent article en parle et explique le processus d’intégration sur Intune pour les machines AVD partagées ici.

Vue générale des fonctionnalités d’Intune (MEM + MAM).

Déploiement d’un AVD utilisant Azure AD

On y est ! On va détailler ici, étapes par étapes, la création d’un environnement Azure Virtual Desktop en ne disposant d’aucun domaine Active Directory en place. Pour rappel, à l’heure où ces lignes sont écrites, la fonctionnalité de jointure avec Azure AD est toujours en public preview.

Etape I : Création du réseau virtuel

Habituellement, le réseau virtuel hébergeant AVD est déjà présent par le domaine existant. Dans un environnement vide, il faut donc commencer la création de celui-ci en premier :

Je prends soin de choisir la région adaptée à mon architecture AVD.

La configuration de la plage réseau et des sous-réseaux ne change pas d’un projet classique AVD. Dans mon exemple rapide, on ira au plus simple :

Une fois la création du réseau virtuel terminée, je peux passer à la création de mon environnement Azure Virtual Desktop.

Etape II : Déploiement d’Azure Virtual Desktop

Comme pour un déploiement classique d’Azure Virtual Desktop, notre travail commence par déployer un pool d’hôtes. Vous trouverez ce dernier dans la barre de recherche d’Azure :

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

La procédure de départ reste identique au processus habituel pour AVD. Cependant, il est important de cocher la Validation environnement à OUI pour réussir la jointure avec Azure AD :

Dans mon exemple, j’ai choisi un host pool composé de VMs personnelles, il est possible de le faire avec des VMs partagées.

Note : l’assignement de type automatique dans le cadre de machines virtuelles individuelles va directement affecter ces dernières aux personnes se connectant à AVD dans la mesure où ces utilisateurs y sont autorisés.

Dans l’onglet des machines virtuelles, je défini les options relatives à ces dernières. Aucune particularité concernant la jointure avec Azure AD dans la première partie :

La copie d’écran ci-dessous concernant Azure AD et connaît une évolution sur deux points :

  • Type de domaine à joindre : il est maintenant possible de choisir 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, que ce soient des machines virtuelles dédiées ou partagées entre utilisateurs.
En sélectionnant Azure Active Directory, un certain nombre de champs disparaissent de la configuration de base.
Plus besoin ici de renseigner un login du domaine.

La création de l’espace de travail ne change pas par rapport aux environnements AVD classiques :

Une fois tous les champs correctement renseignés, il ne reste plus qu’à lancer la création des ressources :

Une fois la création terminée, nous pouvons constater les ressources suivantes dans notre groupe de ressources :

Etape III : Affectation des utilisateurs

Comme pour tout environnement Azure Virtual Desktop, il est nécessaire d’affecter des utilisateurs ou des groupes d’utilisateurs pour que ces derniers soient autorisés à se connecter aux machines virtuelles. Cela se passe par ici :

Etape IV : Ajout d’un argument RDP

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 font directement sur le pool d’hôtes d’AVD :

targetisaadjoined:i:1

Vous retrouverez ici la liste de toutes les options RDP possibles, dont seulement certaines sont compatibles avec Azure Virtual Desktop. Voici les arguments utilisés sur la copie d’écran ci-dessus :

drivestoredirect:s:;audiomode:i:0;videoplaybackmode:i:1;redirectclipboard:i:1;redirectprinters:i:1;devicestoredirect:s:;redirectcomports:i:1;redirectsmartcards:i:1;usbdevicestoredirect:s:*;enablecredsspsupport:i:1;use multimon:i:1;targetisaadjoined:i:1

Etape V : Ajout des rôles RBAC

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 font assigner directement 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

Etape VI : Test de la solution côté utilisateur via Remote Desktop

Une fois les étapes précédentes terminées, il ne reste plus qu’à tester le bon fonctionnent de la solution. Cela se fait en téléchargeant le client Remote Desktop PC dédié à Azure Virtual Desktop (téléchargeable ici), ou via l’accès web multi-plateformes (accessible )

Application Remote Desktop

Renseigner ici un compte Azure AD présent dans le groupe d’utilisateurs AVD.
L’écran de gestion du poste arrive dans la foulée, inutile de lier votre poste local à l’identité Azure AD.

L’écran ci-dessous nous emmène sur l’environnement Azure Virtual Desktop. Ici se trouvent tous les espaces de travail affectés à l’utilisateur, dans lesquels se trouvent toutes les applications (Remote Desktop ou Remote Apps) affectées à l’utilisateurs :

Ecran du Remote Desktop PC.

Une seconde demande d’authentification est affichée pour accéder à la machine virtuelle via le protocole RDP :

Le mot de passe peut être mémorisé pour éviter la ressaisie ultérieure.

Une fois le mot de passe saisi, l’ouverture d’une fenêtre RDP donne l’accès au bureau Windows 10 d’AVD. A noter que la jointure AVD apporte également le Seamless Sign on, rendant l’expérience utilisateur encore plus agréable :

Etape VII : Test de la solution côté utilisateur via HTML 5

Il est également possible de se connecter à Azure Virtual Desktop via un navigateur internet. Pour rappel, la page d’accès est la suivante : aka.ms/wvdarmweb :

Comme pour l’application Remote Desktop, l’authentification utilise le compte Azure AD.

On se retrouve alors, de la même manière que précédemment, sur une page donnant accès aux espaces de travail et aux applications :

Une seconde demande d’authentification est demandée pour accéder à la machine virtuelle.

Etape VIII : Vérifications Azure Virtual Desktop

Vérification de la jointure sur la machine virtuelle

Afin de regarder plus en détail cette jointure, la commande dsregcmd /status sur la machine virtuelle AVD nous en dit plus :

La jointure avec Azure AD est bien là mais aucune jointure à un domaine n’est faite.
Les informations relatives au tenant d’Azure AD.
Les informations relatives à l’activation de la fonctionnalité SSO.

Vérification de l’ajout des machines virtuelles dans Azure AD

Les machines virtuelles créées par Azure Virtual Desktop sont bien retranscrites dans la section Devices d’Azure AD. Cet ajout est réalisé lors de la jointure des machines virtuelles à Azure AD :

Vérification de l’ajout des machines virtuelles dans Intune

Comme j’ai coché la gestion des machines virtuelles AVD via la solution Intune, je retrouve bien mes machines virtuelles dans la console de cette dernière (lien ici)

Vérification du pool d’hôtes d’Azure Virtual Desktop

Comme cet exemple reposait sur un environnement AVD avec des machines virtuelles individuelles, je retrouve bien sur chacune un utilisateur assigné :

Etape IX : Gestion des erreurs liées à la jointure avec Azure AD

Il est possible de rencontrer des erreurs lors du déploiement de cet environnement AVD, en jointure avec Azure AD. Pour vous aider, Microsoft met à votre disposition cette page d’aide. Voici quelques exemples d’erreurs possibles :

Les machines virtuelles sont bien déployées, mais elles sont encore marquées comme indisponibles, plusieurs minutes après le déploiement d’AVD :

>> Avez-vous bien marqué à OUI la case de validation de l’environnement ?

Erreur de mot de passe de l’ouverture de la session RDP : « The logon attempt failed »

J’ai passé du temps sur cette erreur 😎.

>> 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 :

Cette option est également configurable via GPO. la commande rsop.msc vous permet de voir cela.

Conclusion

Comme à chaque fois, Dean de l’Azure Academy nous met à disposition une vidéo très explicative sur tout le processus de cette nouvelle fonctionnalité d’Azure Virtual Desktop :

On attend bien évidemment avec impatience 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 😋

AVD + FSLogix = Bonnes pratiques

La mise en place d’Azure Virtual Desktop s’accompagne de bonnes pratiques, dont une concerne tout particulièrement la gestion des profils utilisateurs. Dans cet article, nous allons détailler l’installation de la solution FSLogix sur Azure Virtual Desktop, avec différentes options possibles pouvant améliorer l’expérience utilisateur.

Les profils des utilisateurs Windows

Un profil utilisateur contient des éléments de données sur une personne, notamment des informations de configuration comme les paramètres du poste de travail, les connexions réseaux persistantes ou les paramètres d’application. Par défaut, Windows crée un profil utilisateur local qui est étroitement intégré au système d’exploitation. Dans le cadre d’un environnement multiutilisateurs, il est important de rappeler l’importance des profils utilisateurs Windows :

  • Profil utilisateur : Un profil utilisateur Windows est un ensemble de paramètres qui personnalisent l’environnement de l’utilisateur. Chaque compte utilisateur dispose d’un profil qui inclut un ensemble de fichiers et de dossiers qui leurs sont propres, comme le bureau, les documents, les téléchargements, la musique, les images, …
  • Profil itinérant : Un profil itinérant est une fonctionnalité qui permet aux utilisateurs, à partir d’un poste implémenté dans un domaine, de se connecter à n’importe quel ordinateur du même réseau du même domaine et de retrouver leur environnement « personnalisé » décrit ci-dessus. Sans la fonctionnalité de base des profils itinérants, les utilisateurs perdraient leurs paramètres et leurs documents locaux lorsqu’ils se connecteraient à différents ordinateurs du domaine.

Les produits Microsoft fonctionnent avec plusieurs technologies pour les profils utilisateurs distants, notamment :

  • Profil utilisateur itinérants (RUP, Roaming user profiles)
  • Disque de profil utilisateur (UPD, User profile disks)
  • Enterprise State Roaming (ESR)

UPD et RUP sont les technologies les plus fréquemment utilisées pour les profils utilisateur dans les environnements Hôte de session Bureau à distance (RDSH) et Disque dur virtuel (VHD).

La solution FSLogix

Azure Virtual Desktop recommande les conteneurs de profil FSLogix. FSLogix est société acquise par Microsoft en novembre 2018. Elle propose une solution de conteneurisation des profils utilisateurs en itinérance, utilisable dans une large gamme de scénarios sous format VHD ou VHDX. Avec FSLogix, vous allez pouvoir réaliser les actions suivantes pour vos utilisateurs :

  • Centralisation des profils utilisateurs Azure Virtual Desktop
  • Dissociation possible entre les conteneurs Office365 avec les conteneurs profils utilisateurs
  • Gestion des applications visibles ou non via la fonction AppMasking
  • Contrôle des versions JAVA
  • Customisation de l’installation via de nombreuses règles ou via GPO
  • Sans les conteneurs de profil FSLogix, OneDrive Entreprise n’est pas pris en charge dans les environnements RDSH ou VDI non persistants
Merci à Dean pour cette vidéo explicative 😎

Scénarios de stockage FSLogix

Comme toute donnée devant être migrée ou installée dans le Cloud, plusieurs scénarios techniques sont possibles pour héberger ces dernières. Dans le cadre des profils FSLogix , nous pourrions envisager les solutions suivantes :

  • Stockage sur un compte de stockage partagé
  • Stockage sur un serveur de fichiers
  • Stockage sur un NetApp File
Intégration des profils utilisateurs d’AVD, stockés sur un Azure File share.

Peu importe la solution choisie, vous devez également décider du format du profil : VHD / VHDX.

Au travers de cette vidéo, Dean nous montre comment estimer la taille du stockage FSLogix.

OS compatibles avec FSLogix

FSLogix est compatible avec une gamme étendue de systèmes d’exploitation, en 32 ou 64 bit :

  • Windows 7 ou plus récent
  • Windows Server 2008 R2 ou plus récent

Licences FSLogix

Il n’existe pas de licence spécifique pour FSLogix mais un droit d’utilisation intégré dans un grand nombre de licence Microsoft 365. Voici la liste des licences comprenant cette éligibilité :

  • Microsoft 365 E3/E5
  • Microsoft 365 A3/A5/ Student Use Benefits
  • Microsoft 365 F1/F3
  • Microsoft 365 Business
  • Windows 10 Enterprise E3/E5
  • Windows 10 Education A3/A5
  • Windows 10 VDA per user
  • Remote Desktop Services (RDS) Client Access License (CAL)
  • Remote Desktop Services (RDS) Subscriber Access License (SAL)

Expérience utilisateur

Lors de la connexion de l’utilisateur, un conteneur est dynamiquement attaché à l’environnement en utilisant le disque dur virtuel et le disque dur virtuel Hyper-V, pris en charge nativement. Le profil utilisateur est donc immédiatement disponible et apparaît dans le système exactement comme un profil utilisateur local.

Installation de la solution FSLogix

Comme indiqué précédemment, l’installation de la solution FSLogix est possible sur plusieurs système de stockage. Dans cet article, nous allons nous intéresser à l’installation de la solution sur un compte de stockage Azure. Avant d’aller plus loin, l’installation de la solution FSLogix va légèrement différer selon le type de domaine mis en place pour votre environnement Azure Virtual Desktop. A ce jour, la solution fonctionne avec 2 types de domaine :

  • 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.
Azure Virtual Desktop reposant sur une gestion d’identité gérée par Azure AD et synchronisé avec Azure AD DS.
  • 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.
Azure Virtual Desktop reposant sur une gestion d’identité gérée par AD DS et synchronisé avec Azure AD.

Etape I : Création du compte de stockage

Peu importe l’architecture d’identité choisie, le création d’un compte de stockage est identique dans les deux cas. Plusieurs options existent lors sa création dans un objectif d’augmenter sa résilience :

  • Redondance sur la région Azure paire (GRS)
  • Utilisation de la fonctionnalité Cloud cache via la création de 2 comptes de stockage dans des régions Azure différentes
Attention à la longueur du nom du compte de stockage !
Celui-ci doit être inférieur à 15 caractères, au risque de bloquer la jointure du compte au domaine AD DS.

La sécurité a toute sa place dans un projet Azure Virtual Desktop. Je vous conseille donc de limiter la porter de votre compte de stockage au seul réseau v-net de votre architecture.

Etape II : Ajout du compte de stockage au domaine

Une fois la création de votre compte de stockage terminée, vous allez pouvoir le paramétrer pour le joindre à votre domaine. Juste avant cette configuration, pensez également à ajouter votre adresse IP publique dans la configuration réseau du compte de stockage, afin de ne pas être bloqué par la suite :

Comme nous avons filtré la méthode de connectivité, nous devons rajouter notre adresse IP publique comme exception d’accès au compte de stockage.

En fonction du type de domaine présent dans votre projet, je vous invite à suivre la procédure de configuration correspondante à votre cas :

  • Scenario A : domaine managé Azure AD DS
  • Scenario B : domaine Active Directory Domain Services (AD DS)
Dans mon exemple, deux comptes de stockage sont créés pour vous montrer le paramétrage pour les 2 types de domaine.

Scenario A : Azure AD DS

Il s’agit de la jointure la plus facile à réaliser, puisqu’elle peut se faire directement depuis le portail Azure. Pour cela, vous n’avez qu’à rentrer dans votre compte de stockage et vous rendre sur l’option suivante :

Quelques secondes après l’activation de l’option, tout est bon 😋

Une fois le compte de stockage associé au domaine managé, il ne reste qu’à ajouter les rôles RBAC Azure et les droits NTFS Windows aux utilisateurs d’AVD. Pour cela, nous allons procéder de la façon suivante :

  • Azure RBAC : droits d’accès via le rôle Storage File Data SMB Share Contributor via le portail Azure
  • Windows NTFS : droits de modification via la commande icacls

L’ajout de rôle RBAC se fait assez facilement via le portail Azure ou aussi via des commandes en PowerShell. Voici les rôles nécessaires sur le partage de fichier fslogix du compte de stockage :

L’ajout des droits NTFS demande un peu plus d’effort et doit se réaliser obligatoirement via des commandes depuis une machine jointe au domaine Azure AD DS. Pour cela, il est nécessaire de créer une machine virtuelle sur Azure et de la joindre au domaine Azure AD DS. A terme cette machine virtuelle peut être éteinte et conservée pour gérer d’autres options du domaine managé.

Une fois la machine virtuelle créée et jointe, Alexandre nous simplifie la vie avec son script ici. Pour vous aider, je vous ai préparé une découpe de ce dernier en dessous :

Rappel Important concernant le script d’ajout des droits NTFS

  • Avoir créé au préalable un domaine managé Azure AD DS
  • Avoir joint le compte de stockage au domaine managé Azure AD DS
  • Avoir ajouté au préalable un partage de fichier sur le compte de stockage
  • Disposer d’un compte ayant des droits de propriétaire sur la souscription Azure
  • Lancer le script depuis un compte administrateur local aussi présent dans le domaine Azure AD DS

Script PowerShell

La partie 1 du script sert à initialiser un certain nombre de variables pour la suite des prochaines commandes PowerShell. Certains éléments sont à créer manuellement avant de pouvoir les renseigner :

  • $SubscriptionId : ID de la souscription Azure
  • $ResourceGroupName : nom du groupe de ressources du compte de stockage
  • $StorageAccountName : nom du compte de stockage
  • $AzufileShareName : nom du partage de fichier créé pour FSLogix
  • $StorageAccountKey : clef d’accès du compte de stockage
  • $ADDSname : nom du domaine managé Azure AD DS
  • $UserGroupName : nom du groupe d’utilisateurs d’AVD
  • $AdminGroupName : nom du groupe d’administration d’AVD
  • $DirectoryID : chemin local du sous-répertoire dans le partage de fichier fslogix
  • $Directory : sous-répertoire dans le partage de fichier fslogix
$SubscriptionId = ""
$ResourceGroupName = ""
$StorageAccountName = ""
$AzufileShareName = ""
$StorageAccountKey = ""
$ADDSname = ""
$UserGroupName = ""
$AdminGroupName = ""
$DirectoryID = "T:\Profiles"
$Directory = "Profiles"

Le partie 2 monte un lecteur réseau dans l’explorateur en utilisant une clef du compte de stockage comme identifiant. Si votre session utilisateur n’est pas administrateur, je vous conseille de lancer cette commande via une fenêtre PowerShell non-administrateur également, sous peine de ne pas voir apparaitre le lecteur réseau dans votre explorateur de fichier :

$connectTestResult = Test-NetConnection -ComputerName "$StorageAccountName.file.core.windows.net" -Port 445
if ($connectTestResult.TcpTestSucceeded)
{
  net use T: "\\$StorageAccountName.file.core.windows.net\$AzufileShareName" /user:Azure\$StorageAccountName $StorageAccountKey
} 
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."
}

La partie 3 créée le sous-dossier dédié aux profils et ajoute les droits NTFS pour que FSLogix puisse travailler correctement :

New-Item -Path $DirectoryID -ItemType Directory

icacls \\$StorageAccountName.file.core.windows.net\$AzufileShareName\$Directory /inheritance:d
icacls \\$StorageAccountName.file.core.windows.net\$AzufileShareName\$Directory /remove "Creator Owner"
icacls \\$StorageAccountName.file.core.windows.net\$AzufileShareName\$Directory /grant 'CREATOR OWNER:(OI)(CI)(IO)(M)'
icacls \\$StorageAccountName.file.core.windows.net\$AzufileShareName\$Directory /remove "Authenticated Users" 
icacls \\$StorageAccountName.file.core.windows.net\$AzufileShareName\$Directory /remove "Builtin\Users"
icacls \\$StorageAccountName.file.core.windows.net\$AzufileShareName\$Directory /grant $ADDSname\"$UserGroupName":M
icacls \\$StorageAccountName.file.core.windows.net\$AzufileShareName\$Directory /grant $ADDSname\"$AdminGroupName":F

Scenario B : Active Directory Domain Services (AD DS)

Vous l’aurez compris si vous avez lu le paragraphe précédent, cette jointure nécessite un peu plus de manipulations et ne peut se faire directement depuis le portail Azure. Vous trouverez le lien vers la documentation officielle ici. Au final, les commandes d’ajout vont se faire en PowerShell. Pour aller plus vite, Alexandre nous a encore préparé un script PowerShell, disponible sur son GitHub. Ce script est téléchargeable ici, il effectue les actions suivantes :

  1. Téléchargement et installation et lancement du module Azure
  2. Téléchargement et installation et lancement du module Azure AD
  3. Connection à Azure et Azure AD
  4. Téléchargement, extraction et installation et lancement du module AzFilesHybrid
  5. Jointure du compte de stockage au domaine AD DS
  6. Ajout des rôles Azure RBAC sur le partage de fichier FSLogix
  7. Ajout des droits NTFS sur le partage de fichier FSLogix

Rappel important le script ci-dessous

  • Avoir synchronisé au préalable votre domaine à Azure AD via l’installation d’Azure AD Connect
  • Disposer d’un compte ayant des droits de propriétaire sur la souscription Azure
  • Rajouter au prélable un partage de fichier sur le compte de stockage
  • Lancer ce script sur un compte de domaine AD DS et disposant des droits administrateur local

Script PowerShell

La partie 1 du script sert à initialiser les variables pour les prochaines commandes PowerShell. Certains éléments sont à créer manuellement avant de pouvoir les renseigner dans les variables :

  • $SubscriptionId : ID de la souscription hébergeant le compte de stockage
  • $ResourceGroupName : nom du groupe de ressources hébergeant le compte de stockage
  • $StorageAccountName : nom du compte de stockage
  • $AzufileShareName : nom du partage de fichier créé pour FSLogix
  • $StorageAccountKey : clef d’accès du compte de stockage
  • $domainname : nom du domaine AD DS
  • $OrganizationalUnitDistinguishedName : nom de l’OU du domaine AD DS
  • $UserGroupName : nom du groupe d’utilisateurs d’AVD
  • $AdminGroupName : nom du groupe d’administration d’AVD
  • $DirectoryID : chemin local du sous-répertoire dans le partage de fichier fslogix
  • $Directory : sous-répertoire dans le partage de fichier fslogix
$SubscriptionId = ""
$ResourceGroupName = ""
$StorageAccountName = ""
$AzufileShareName = ""
$StorageAccountKey = ""
$domainname = ""
$OrganizationalUnitDistinguishedName = ""
$folder = "C:\AzFileHybrid"
$UserGroupName = ""
$AdminGroupName = ""
$DirectoryID= "T:\Profiles"
$Directory= "Profiles"

La partie 2 du script télécharge, installe et lance les modules PowerShell Azure avec l’identifiant Azure AD :

Install-Module AZ
Import-Module AZ
Install-Module azuread
Import-Module azuread
Connect-AzAccount
Select-AzSubscription -SubscriptionId $SubscriptionId
Connect-AzureAD

La partie 3 télécharge les éléments de jointure depuis GitHub et prépare les variables de rôles RBAC :

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
$AzFileSource = "https://github.com/Azure-Samples/azure-files-samples/releases/download/v0.2.3/AzFilesHybrid.zip"
$locationAzFiledownload = "C:\AzFilesHybrid.zip"
$ObjectIDGroupUser = (Get-AzADGroup -DisplayName $UserGroupName).id
$ObjectIDGroupAdmin = (Get-AzADGroup -DisplayName $AdminGroupName).id
$rolenameAdmin = "Storage File Data SMB Share Elevated Contributor"
$rolenameUser = "Storage File Data SMB Share Contributor"
$AccountType = "ComputerAccount"

La partie 4 décompresse l’archive ZIP et importe le module de jointure AzFilesHybrid :

Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Scope CurrentUser
New-Item -Path $folder -ItemType Directory

Invoke-WebRequest -Uri $AzFileSource -OutFile $locationAzFiledownload
Expand-Archive C:\AzFilesHybrid.zip -DestinationPath C:\AzFileHybrid
cd C:\AzFileHybrid
.\CopyToPSPath.ps1
Import-Module -Name AzFilesHybrid

La partie 5 effectue la commande de jointure du compte de stockage avec le domaine AD DS :

Join-AzStorageAccountForAuth `
-ResourceGroupName $ResourceGroupName `
-Name $StorageAccountName `
-DomainAccountType $AccountType `
-OrganizationalUnitDistinguishedName $OrganizationalUnitDistinguishedName
Cette commande est THE commande du script 😉.
Copie d’écran d’un compte de stockage correctement joint au domaine AD DS.

La partie 6 affecte les rôles RBAC d’Azure sur le partage de fichier du compte de stockage avec les 2 groupes d’utilisateurs créés pour AVD :

$FileShareContributorRole = Get-AzRoleDefinition $rolenameAdmin 

$scope = "/subscriptions/$SubscriptionId/resourceGroups/$ResourceGroupName/providers/Microsoft.Storage/storageAccounts/$StorageAccountName/fileServices/default/fileshares/$AzufileShareName"

New-AzRoleAssignment -ObjectId $ObjectIDGroupAdmin -RoleDefinitionName $FileShareContributorRole.Name -Scope $scope

$FileShareContributorRole = Get-AzRoleDefinition $rolenameUser

$scope = "/subscriptions/$SubscriptionId/resourceGroups/$ResourceGroupName/providers/Microsoft.Storage/storageAccounts/$StorageAccountName/fileServices/default/fileshares/$AzufileShareName"

New-AzRoleAssignment -ObjectId $ObjectIDGroupUser -RoleDefinitionName $FileShareContributorRole.Name -Scope $scope

La partie 7 utilise la clef d’accès du compte de stockage pour monter un disque réseau. Cela sert à appliquer les droits NTFS juste après.

$connectTestResult = Test-NetConnection -ComputerName "$StorageAccountName.file.core.windows.net" -Port 445
if ($connectTestResult.TcpTestSucceeded)
{
  net use T: "\\$StorageAccountName.file.core.windows.net\$AzufileShareName" /user:Azure\$StorageAccountName $StorageAccountKey
} 
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."
}

La partie 8 utilise la commande ICACLS pour modifier les droits en adéquation avec les besoins FSLogix :

New-Item -Path $DirectoryID -ItemType Directory

icacls \\$StorageAccountName.file.core.windows.net\$AzufileShareName\$Directory /inheritance:d
icacls \\$StorageAccountName.file.core.windows.net\$AzufileShareName\$Directory /remove "Creator Owner"
icacls \\$StorageAccountName.file.core.windows.net\$AzufileShareName\$Directory /grant 'CREATOR OWNER:(OI)(CI)(IO)(M)'
icacls \\$StorageAccountName.file.core.windows.net\$AzufileShareName\$Directory /remove "Authenticated Users" 
icacls \\$StorageAccountName.file.core.windows.net\$AzufileShareName\$Directory /remove "Builtin\Users"
icacls \\$StorageAccountName.file.core.windows.net\$AzufileShareName\$Directory /grant $domainname\"$UserGroupName":M
icacls \\$StorageAccountName.file.core.windows.net\$AzufileShareName\$Directory /grant $domainname\"$AdminGroupName":F

Etape III : Installation de la solution FSLogix

Peu important le type de jointure faite durant l’étape II, l’installation de la solution FSLogix sur Windows 10 reste la même. Cette installation est généralement lancée sur une machine virtuelle servant d’image pour votre environnement Azure Virtual Desktop. Il faut donc créer, au prélable de ce script d’installation, une nouvelle machine virtuelle sur Azure avec l’OS Windows 10 multisessions.

Script PowerShell

Le script PowerShell ci-dessous installe et configure FSLogix sur votre Windows 10. Comme à chaque fois, vous pouvez lancer le script d’un seul bloc ou partie après partie. La partie 1 du script sert à initialiser les variables pour la suite des prochaines commandes PowerShell. Seule la variable ci-dessous est à renseigner :

  • $connectionString : Il s’agit ici du chemin complet du partage de fichier créé sur le compte de stockage. Il se découpe toujours de la façon suivante :

\\ »nom du compte de stockage ».file.core.windows.net\ »nom du partage »\ »sous-dossier »

$LocalWVDpath = "c:\temp\wvd\"
$FSLogixURI  = "https://aka.ms/fslogix_download"
$FSInstaller = "FSLogixAppsSetup.zip"
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
$connectionString = "" 

Dans mon cas, la variable est la suivante :

\\jloaaddssa2.file.core.windows.net\fslogix\Profiles

La partie 2 créé l’arborescence temporaire pour installer FSLogix sur l’image Windows 10 :

if((Test-Path c:\temp) -eq $false) {
    Add-Content -LiteralPath C:\New-WVDSessionHost.log "Create C:\temp Directory"
    Write-Host `
        -ForegroundColor Cyan `
        -BackgroundColor Black `
        "creating temp directory"
    New-Item -Path c:\temp -ItemType Directory
}
else {
    Add-Content -LiteralPath C:\New-WVDSessionHost.log "C:\temp Already Exists"
    Write-Host `
        -ForegroundColor Yellow `
        -BackgroundColor Black `
        "temp directory already exists"
}
if((Test-Path $LocalWVDpath) -eq $false) {
    Add-Content -LiteralPath C:\New-WVDSessionHost.log "Create C:\temp\WVD Directory"
    Write-Host `
        -ForegroundColor Cyan `
        -BackgroundColor Black `
        "creating c:\temp\wvd directory"
    New-Item -Path $LocalWVDpath -ItemType Directory
}
else {
    Add-Content -LiteralPath C:\New-WVDSessionHost.log "C:\temp\WVD Already Exists"
    Write-Host `
        -ForegroundColor Yellow `
        -BackgroundColor Black `
        "c:\temp\wvd directory already exists"
}
Add-Content `
-LiteralPath C:\New-WVDSessionHost.log `
"
ProfilePath       = $connectionString
"

La partie 3 télécharge la dernière version de la solution FSLogix :

Add-Content -LiteralPath C:\New-WVDSessionHost.log "Downloading FSLogix"
Invoke-WebRequest -Uri $FSLogixURI -OutFile "$LocalWVDpath$FSInstaller"

La partie 4 extrait de l’archive FSLogix :

Add-Content -LiteralPath C:\New-WVDSessionHost.log "Unzip FSLogix"
Expand-Archive `
-LiteralPath "C:\temp\wvd\$FSInstaller" `
-DestinationPath "$LocalWVDpath\FSLogix" `
-Force `
-Verbose
cd $LocalWVDpath
Add-Content -LiteralPath C:\New-WVDSessionHost.log "UnZip FXLogix Complete"

La partie 5 lance l’installation de FSLogix :

Add-Content -LiteralPath C:\New-WVDSessionHost.log "Installing FSLogix"
$fslogix_deploy_status = Start-Process `
-FilePath "$LocalWVDpath\FSLogix\x64\Release\FSLogixAppsSetup.exe" `
-ArgumentList "/install /quiet" `
-Wait `
-Passthru

Presque toutes les options de configurations FSLogix se font via des clefs de registre. Vous pouvez retrouver toutes les options ici. Voici un script PowerShell reprenant les plus intéressantes :


Add-Content -LiteralPath C:\New-WVDSessionHost.log "Configure FSLogix Profile Settings"
Push-Location 
Set-Location HKLM:\SOFTWARE\
New-Item `
    -Path HKLM:\SOFTWARE\FSLogix `
    -Name Profiles `
    -Value "" `
    -Force
New-Item `
    -Path HKLM:\Software\FSLogix\Profiles\ `
    -Name Apps `
    -Force
Set-ItemProperty `
    -Path HKLM:\Software\FSLogix\Profiles `
    -Name "Enabled" `
    -Type "Dword" `
    -Value "1"
New-ItemProperty `
    -Path HKLM:\Software\FSLogix\Profiles `
    -Name "VHDLocations" `
    -Value $connectionString `
    -PropertyType MultiString `
    -Force
Set-ItemProperty `
    -Path HKLM:\Software\FSLogix\Profiles `
    -Name "SizeInMBs" `
    -Type "Dword" `
    -Value "30720"
Set-ItemProperty `
    -Path HKLM:\Software\FSLogix\Profiles `
    -Name "IsDynamic" `
    -Type "Dword" `
    -Value "1"
Set-ItemProperty `
    -Path HKLM:\Software\FSLogix\Profiles `
    -Name "VolumeType" `
    -Type String `
    -Value "vhdx"
Set-ItemProperty `
    -Path HKLM:\Software\FSLogix\Profiles `
    -Name "ConcurrentUserSessions" `
    -Type "Dword" `
    -Value "1"
Set-ItemProperty `
    -Path HKLM:\Software\FSLogix\Profiles `
    -Name "FlipFlopProfileDirectoryName" `
    -Type "Dword" `
    -Value "1" 
Set-ItemProperty `
    -Path HKLM:\Software\FSLogix\Profiles `
    -Name "SIDDirNamePattern" `
    -Type String `
    -Value "%username%%sid%"
Set-ItemProperty `
    -Path HKLM:\Software\FSLogix\Profiles `
    -Name "SIDDirNameMatch" `
    -Type String `
    -Value "%username%%sid%" 
New-ItemProperty `
    -Path HKLM:\SOFTWARE\FSLogix\Profiles `
    -Name "DeleteLocalProfileWhenVHDShouldApply" `
    -PropertyType "DWord" `
    -Value 1
Pop-Location

Enfin la partie 7 ci-dessous redémarre la machine virtuelle pour appliquer toute la configuration FSLogix.

Add-Content -LiteralPath C:\New-WVDSessionHost.log "Process Complete - REBOOT"
Restart-Computer -Force

Etape IV : Préparation de l’image + création d’AVD

Je ne passerai pas plus de temps du la gestion de l’image car ce n’est pas l’objectif principal de cet article. Néanmoins, les grandes étapes pour réutiliser cette image Windows 10 dans Azure Virtual Desktop sont :

  • Sysprep de l’image
  • Désallocation de la machine virtuelle
  • Capture de la machine virtuelle

L’article suivant, écrit par Robin Hobo explique tous les étapes l’ensemble du processus.

Etape V : Test de la solution FSLogix

Encore une fois, le fonctionnement de la solution FSLogix est identique, que vous soyez en domaine managé Azure AD DS ou en domaine AD DS. Un test de la solution est possible une fois l’image Windows 10 utilisée dans un environnement Azure Virtual Desktop.

Environnement de départ

La copie d’écran ci-dessous montre deux AVD : un géré par AADDS et l’autre par un AD DS.

Une fois l’environnement AVD déployé sur votre souscription Azure, vous pouvez assigner un groupe d’utilisateurs pour tester FSLogix :

L’assignement d’utilisateurs ou de groupes d’utilisateurs doit se faire pour chaque pool d’hôtes AVD, au niveau du groupe d’applications.

Une fois l’assignement effectué, le lancement du client Remote Desktop fait apparaitre le ou les environnements Azure Virtual Desktop :

Scenario A : Verifications Azure AD DS

Avant le premier lancement de la session utilisateur, un tour rapide dans le partage de fichier du compte de stockage ne montre aucun profil FSLogix :

FSLogix contenant aucun profil pour l’environnement Azure AD DS, avant l’ouverture de session.

Au moment où l’utilisateur AVD s’authentifie pour la première fois sur une machine virtuelle d’AVD, le dossier se créé automatiquement sur le compte de stockage :

FSLogix contenant le profil pour l’environnement Azure AD DS après l’ouverture de session.

Scenario B : Vérification AD DS

Avant le premier lancement de la session utilisateur, un tour rapide dans le partage de fichier du compte de stockage ne montre aucun profil FSLogix :

FSLogix contenant aucun profil pour l’environnement AD DS, avant l’ouverture de session.

Au moment où l’utilisateur AVD s’authentifie pour la première fois sur une machine virtuelle d’AVD, le dossier se créé automatiquement sur le compte de stockage :

FSLogix contenant le profil pour l’environnement AD DS, après l’ouverture de session.

L’ouverture du dossier montre bien le profil de profil de l’utilisateur au format VHDX :

Conclusion

Au final, FSLogix reste une solution pratique et performante pour la gestion des profils utilisateurs pour les environnements Azure Virtual Desktop. Sa relative facilité d’installation, ses performances et ses possibilités de personnalisation font le succès de cette solution dans un grand nombre de scénarios. Comme à chaque fois, pensez également à partager dans les commentaires vos propres expériences sur Azure Virtual Desktop 😋

Quickstart pour Azure Virtual Desktop

Première nouvelle, Windows Virtual Desktop change de nom ! De manière assez logique et cohérente, vous pourrez le retrouver sous AVD. Microsoft rebaptise donc son service « Windows Virtual Desktop » (WVD) en « Azure Virtual Desktop ».

Dans la foulée, Microsoft a annoncé la mise en place d’un Quickstart dans le but de faciliter le déploiement d’AVD sur des nouveaux environnements Azure, vierges ou ayant déjà éléments d’architecture.

Nous allons détailler ensemble dans cet article toutes les fonctionnalités de ce Quickstart, encore en preview à l’heure où ces lignes sont écrites.

Résumé du Quickstart d’AVD :

Voici dans ce lien les informations de départ concernant ce nouveau Quickstart. Dans ce billet de Stefan Georgiev, nous pouvons y apprendre quelques points importants :

  • Cette fonctionnalité est toujours en preview
  • Ce Quickstart apporte une création rapide d’un environnement AVD en seulement quelques clics
  • Il facilite grandement le déploiement d’un environnement AVD en prenant en charge les éléments de base suivants :
    • Création d’un domaine si inexistant
    • Création des composantes d’AVD
    • Création d’un compte de stockage pour les profils via FSLogix
    • Installation de FSLogix sur les machines virtuelles d’AVD
    • Création de groupes d’utilisateurs
    • Application des droits NTFS / RBAC pour le compte de stockage FSLogix

Evidement et vous l’avez compris, la simplicité de ce type de déploiement entraine la mise à l’écart de fonctionnalités spécifiques à votre déploiement. Je ne suis pas inquiet pour la suite, car ce Quickstart est encore en preview et va s’améliorer au fil des remontées des testeurs.

Il est donc possible de faire des remontées directes à Microsoft par ce lien.

Windows Virtual Desktop pour les entreprises - Azure Example Scenarios |  Microsoft Docs
Si seulement le Quickstart d’AVD pouvait faire tout ça d’un coup 😉

Etape 0 : Rappel des prérequis

Comme indiqué dans le billet de Stefan, certains prérequis sont nécessaires au déploiement de votre Quickstart. Il faut disposer au préalable de :

  • Souscription Azure active
  • Tenant Azure AD
  • Un compte avec le profil d’administrateur global sur Azure AD
  • Un compte disposant des droits de propriétaire sur la souscription active
  • Active directory déjà en place ? Avoir également un compte d’administration du domaine

Le Quickstart en détail

Avant tout, la fonctionnalité de Quickstart dans AVD n’est pas encore disponible dans le portail Azure de base, mais par le lien donné ici.

Une fois sur le bon portail Azure, vous pouvez chercher AVD dans la barre principale.
Le Quickstart est alors disponible sur le menu de gauche.

La création du Quickstart va demander à passer en revue plusieurs champs avant de pouvoir exécuter les différents scripts automatisés :

Premier onglet définissant les principales caractéristiques du déploiement d’AVD.
  • Souscription : Choisissez ici la souscription Azure devant héberger l’ensemble des ressources Azure, créées par le Quickstart.
  • Configuration de la souscription : Deux choix sont possibles et cela dépend de votre situation actuelle. Possédez-vous déjà un domaine Active Directory ? Il peut s’agir soit d’un domaine managé par Azure (Azure AD Domain Services) ou soit d’un domaine géré sur une machines virtuelle.
  • Préfixe des groupes de ressources : Plusieurs groupes de ressources seront créés selon les différents scénarios, cela permet d’identifier facilement le contenu de chacun d’eux.
  • Localisation : On choisit ici la région Azure utilisée pour la création des ressources. Ce qui est dommage actuellement, c’est que cette liste est pour l’instant incomplète car elle semble ne reprendre que la liste des régions disponibles pour les métadatas d’AVD. Nul doute que Microsoft va rajouter par la suite plus de régions Azure, ou bien rajouter un second champ de localisation pour choisir où héberger les machines virtuelles et le domaine managé.
  • Compte Azure : Compte exécutant les scripts de création du Quickstart. Il doit donc être administrateur global du tenant et propriétaire de la souscription indiquée plus haut. Pour éviter un blocage durant le déploiement du Quickstart, ce dernier doit être exempté de MFA le temps de l’opération.
  • Compte administrateur du domaine : Ce compte est utilisé pour joindre les machines virtuelles d’AVD au domaine Active Directory créé ou existant. Point important : si le domaine n’est pas créé sur votre environnement, ce compte ne doit pas exister ! A l’inverse, si un domaine Active Directory, managé ou non, est déjà présent : ce compte devra exister avant le lancement du Quickstart.
  • Identité : En fonction de la configuration de la souscription indiquée plus haut, vous avez un ou plusieurs choix disponibles. Le but ici est de savoir si le déploiement doit se faire sur un domaine managé (Azure AD Domain Services), existant ou non, ou sur un domaine Active Directory sur une machine virtuelle existante.

Remarques : Afin de vous éviter des erreurs dans le déploiement du Quickstart, je souhaite vous faire une remarque sur deux prérequis importants si vous choisissez de partir sur un domaine Active Directory existant sur machines virtuelles :

  • Le contrôleur de domaine VM ne doit pas déjà avoir d’extensions DSC de type Microsoft.Powershell.DSC.
  • Le contrôleur de domaine VM doit avoir Azure AD Connect d’installé et de configuré.

Machines virtuelles

Comme pour un déploiement AVD en dehors du Quickstart, les machines virtuelles AVD sont déployables dans la même façon.
  • Machines virtuelles partagées : cette option reprend la question posée dans un déploiement AVD classique. S’agit-il d’un environnement AVD partagé entre utilisateurs ou personnel (une machine virtuelle par utilisateur) ?
  • Image source + image : On retrouve ici la possibilité de bénéficier d’images gérées par Microsoft, ou propres et personnalisées par vos soins.
  • Taille des machines virtuelles : comme toujours, cela dépend du budget alloué et des ressources nécessaires aux utilisateurs. Voici un lien détaillant les bonnes pratiques préconisées par Microsoft.
  • Nombre de machines virtuelles : Faites-vous plaisir 🙂

Assignations aux utilisateurs

En fonction du scénario de configuration de la souscription, le nombre d’options de cet écran peut varier.
  • Création d’utilisateur de validation : Le Quickstart d’AVD se propose de créer automatiquement un utilisateur de test pour vérifier le bon fonctionnement de la solution.
  • Assignation d’utilisateurs existants : Cette option est disponible si un domaine Active Directory est déjà présent. Il permet d’assigner un groupe d’utilisateurs au groupe d’application d’AVD pendant le déploiement du Quickstart.

Afin de vous aider au mieux sur les différents scénarios possibles du Quickstart, nous allons détailler les 3 grands cas possibles.

Cas I : Souscription vide

Il s’agit du cas le plus simple, on va donc partir ici de … rien !

Le but est donc bien de créer un domaine Azure AD Domain Services. Ce service est directement managé par Microsoft. Pour rappel, ce vidéo explique bien de quoi il en retourne :

Voici un tableau détaillant les principales différences entre un domaine managé et non managé.

Voici donc les éléments renseignées lors de ma création :

Finalement, la seule erreur possible serait d’indiquer un compte de domaine existant 😉

En parlant d’erreur lors du déploiement via le Quickstart d’AVD, voici ce qui se passe si vous réutilisez un compte existant pour l’administration du domaine managé Azure AD DS :

L’erreur est, disons-le, très peu explicite.

{    "status": "Failed",    "error": {        "code": "DeploymentFailed",        "message": "At least one resource deployment operation failed. Please list deployment operations for details. Please see https://aka.ms/DeployOperations for usage details.",        "details": [            {                "code": "Conflict",                "message": "{\r\n  \"status\": \"Failed\",\r\n  \"error\": {\r\n    \"code\": \"ResourceDeploymentFailure\",\r\n    \"message\": \"The resource operation completed with terminal provisioning state 'Failed'.\"\r\n  }\r\n}"            }        ]    }}

Pourquoi cette erreur ? Pour ceux ayant déjà déployé par le passé un service Azure AD DS, il est connu que la synchronisation des mots de passe entre Azure AD et Azure AD DS ne se fait que lors des méthodes suivantes :

  • Réinitialisation du mot de passe des utilisateurs existants avant la création d’Azure AD DS
  • Création de nouveaux utilisateurs après la mise en service d’Azure AD DS

Les écrans suivants ne présentent peu d’intérêt :

La création du cas I du Quickstart AVD avec un nouvel Azure AD DS prend du temps :
1 heure et 38 minutes pour moi !

Une fois le déploiement terminé avec succès, vous pouvez retourner dans votre liste des groupes de ressources sur le portail Azure :

3 Groupes de ressources sont créées durant le processus de déploiement du Cas I d’AVD.
Le groupe de ressources « x-deployment » contient les runbooks servant au déploiement de la solution.
Le groupe de ressources « x-prerequisite » contient ici les ressources liées au domaine managé Azure AD DS.

Dans ce groupe de ressource, on remarque que le SKU employé par défaut pour Azure AD DS est la version « Enterprise ». Une option serait intéressante pour définir le SKU adapté au moment de la création du Quickstart.

La modification du SKU du service Azure AD DS est toujours possible après le déploiement.
Le script de déploiement Quickstart a aussi pensé à la modification des enregistrements DNS sur réseau virtuel, malin !
Le groupe de ressources « x-wvd » contient toutes les ressources nécessaires à l’exploitation d’AVD.

On retrouve donc dans ce groupe les ressources Azure suivantes :

  • Host Pool AVD
  • Application group AVD
  • Workspace AVD
  • X Machines virtuelles AVD
  • X Disques managés pour les machines virtuelles
  • X interfaces réseaux pour les machines virtuelles
  • Compte de stockage pour la gestion des profils utilisateurs FSLogix
  • Identité managée pour la mise en place des droits NTFS sur le file share

Ces ressources sont assez classiques dans un déploiement AVD. Les points vraiment intéressants sont les actions faites directement sur le compte de stockage :

  • Association du compte de stockage au domaine managé Azure AD DS
  • Création du file-share « profiles »
  • Ajout des droits RBAC « Storage File Data SMB Share Contributor » pour le groupe d’utilisateurs AVD
  • Ajout des droits NTFS « Modify » pour le groupe d’utilisateurs AVD

C’est bien sur ce dernier point que l’identité managée a été nécessaire. Elle a permis d’accéder au file share du compte de stockage via la clé du compte pour y rajouter les droits NTFS.

Au final, l’utilisateur de test peut donc ouvrir l’application Remote Desktop d’AVD afin de vérifier le bon fonctionnement du Quickstart :

PS : Pensez à faire un clic droit sur l’icône pour retirer l’option « tous les écrans », paramétrée par défaut.
L’ouverture de la session par l’utilisateur de test sur AVD créé bien le dossier du profil utilisateur sur le compte de stockage paramétré pour FSLogix.

Conclusion du cas I : Très facile à déployer malgré le temps long. On retrouve bien les avantages d’un Quickstart pour monter et démontrer la solution en quelques clics.

Cas II : Souscription disposant déjà d’un domaine managé Azure AD Domain Services

Peruvian Desert Oasis | The beautiful desert oasis of Huacac… | Flickr

Le second cas décrit dans cette section s’adapte pour un environnement ayant déjà déployé le service Azure AD DS. Quelques options sont donc à renseigner sur le premier onglet du Quickstart d’AVD :

Dans le cas II, le compte d’administration du domaine managé doit déjà exister, à l’inverse du compte dans le cas I.

Le cas II demande également de renseigner les éléments réseaux afin de permettre la jointure des machines virtuelles d’AVD au domaine Azure AD DS existant.

Dans mon exemple de cas II, j’ai réutilisé le domaine managé Azure AD DS créé via mon cas I.
J’ai également réutilisé le groupe d’utilisateurs d’AVD créé dans le cas I pour également l’assigner au groupe d’applications AVD créé par mon cas II.
La création du cas II du Quickstart d’AVD avec un Azure AD DS existant a été bien plus rapide que le cas I :
environ 20 minutes.

Une fois le déploiement terminé avec succès, vous pouvez retourner dans votre liste des groupes de ressources Azure :

3 Groupes de ressources sont créés durant le processus de déploiement du Cas II d’AVD.
Le groupe de ressources « x-AD-deployment » contient moins de runbooks que celui du cas I servant au déploiement de la solution.
Le groupe de ressources « x-ex-deployment » ne contient plus ici les ressources liées au domaine managé Azure AD DS, mais seulement les runbooks servant à s’associer avec ce dernier.
Le groupe de ressources « exi-wvd » contient toutes les ressources nécessaires à l’exploitation d’AVD.

Le même utilisateur de test dispose donc du second environnement AVD dans son application Remote Desktop.

Conclusion du cas II : Comme le cas I, celui-ci est aussi très facile à déployer. Malgré le fait que l’environnement de domaine est existant, le Quickstart recréé bien un second compte de stockage et y applique tous les éléments liés aux paramétrages FSLogix.

Cas III : Souscription disposant déjà d’un domaine Active Directory sur une machine virtuelle

DUBAI: PROJECTED INTO THE FUTURE [DAY 2 and 3] – FEDERICA DI NARDO

Remarques : Déjà indiqué plus haut dans cet article, deux prérequis sont importants si vous choisissez de partir sur un domaine Active Directory existant sur une machine virtuelle :

  • Le contrôleur de domaine VM ne doit pas avoir d’extensions DSC de type Microsoft.Powershell.DSC.
  • Le contrôleur de domaine VM doit avoir Azure AD Connect d’installé et de configuré.

En reprenant le parcours de configuration du cas III, seule la dernière option se retrouve modifiée par rapport au cas II :

De nouveaux champs apparaissent également sur la seconde page, dédiée aux machines virtuelles d’AVD :

  • Groupe de ressources du contrôleur de domaine
  • Machine virtuelle avec le rôle de contrôleur de domaine

Les points rappelés plus haut vous éviterons les erreurs de déploiements suivantes :

Erreur lors de l’exécution du Quickstart d’AVD car le contrôleur de domaine avait déjà une extension DSC d’installée.  » ‘Microsoft.Powershell.DSC’ with handler ‘Microsoft.Powershell.DSC’ already added »
Erreur lors de l’exécution du Quickstart d’AVD car le contrôleur de domaine n’avait pas AD Connect d’installé et de configuré. « The specified module ‘ADSync’ was not loaded because no valid »
La création du Quickstart d’AVD via le cas III a été un peu plus longue que sur le cas II :
27 minutes environ.
Le groupe de ressources « x-deployment » contient uniquement les runbooks servant au déploiement de la solution.
Le groupe de ressources « x-wvd » contient toutes les ressources nécessaires à l’exploitation d’AVD.

Conclusion du cas III : Comme le cas II, ce Quickstart s’adapte bien aux scénarios hybride avec un environnement de domaine non managé existant. Comme pour tous les Quickstarts, il recréé dans le cas III un nouveau compte de stockage et y applique tous les éléments liés au paramétrages FSLogix.

La jointure du domaine non managé se fait sans aucune difficulté dans le cas III.

Conclusion

Au final, cette première preview publique du Quickstart d’AVD fonctionne très bien et démontre un réel intérêt pour les déploiements rapides avec un paramétrage de base. Le gros du travail reste toujours sur la customisations de l’image servant aux machines virtuelles d’Azure Virtual Desktop.

Enfin et comme indiqué en début de cet article, n’hésitez pas à tester la solution et faites par de vos remarques ici 🙂

Comme à chaque fois, pensez également à partager dans les commentaires vos propres expériences sur Azure Virtual Desktop 😋

Pooled Azure Virtual Desktop VMs managées avec Intune

Enroll Windows Virtual Desktop to Intune – Mr T-Bone´s Blog

Attendu depuis plusieurs mois, il est maintenant possible de mettre en place un MDM via l’outil Intune pour des machines virtuelles partagées Azure Virtual Desktop. Il s’agit toujours d’une nouvelle feature en Preview, mais qui va à terme simplifier le maintien opérationnel de ce service de Remote Desktop proposé par Azure.

Pour vous re-situer dans le sujet, voici deux vidéos sélectionnées par mes soins sur qu’est ce qu’Intune et les différences et les synergies possibles avec Configuration Manager :

Points clefs d’Intune.
Merci à Jean-Sébastien 🙂

L’objectif de cet article est donc de vous parcourir avec vous toutes les étapes nécessaires à la mise en place de cette association.

Rappel :

Comme indiqué dans son article sur les machines virtuelles partagées, Microsoft nous explique que la prise en charge actuelle d’Intune est uniquement orientée sur la configuration des VMs. De ce fait et pour que l’application se fasse correctement, il sera donc nécessaire de cibler les polices sur des groupes de machines et non des groupes d’utilisateurs.

Etape 0 : Prérequis

Certaines conditions sont donc obligatoires pour profiter d’Intune sur un environnement Azure Virtual Desktop :

  • Windows 10 multisessions, version 1903 ou ultérieure
  • Azure Virtual Desktop host pool configuré en version partagé
  • Version de l’agent Azure Virtual Desktop égale ou supérieure à 2944.1400

L’une des exigences pour gérer votre environnement Windows 10 AVD avec Endpoint Manager est l’utilisation de la jointure hybride avec Azure AD. Lorsque vous configurez vos périphériques pour qu’ils rejoignent Azure AD, ces périphériques seront visibles et gérables à la fois dans votre AD sur site et dans Azure AD.

Etape I : Mise en place d’un serveur Active Directory sur une machine virtuelle

Comme rappelé plus haut, il est donc nécessaire de disposer d’un serveur Active Directory, géré sur une machine virtuelle et non pas via le service managé par Azure Active Directory Domain Services (AADDS). Vous devrez donc créer une machine virtuelle sous Windows Server et y installer le rôle Active Directory.

Vous pouvez mettre en place très facilement cet ensemble VM + DC via le template proposé par Microsoft juste ici.

Champs à renseigner pour déployer le custom template de domain (Microsoft)
Le déploiement complet de la machine virtuelle et du domain prend environ 20 minutes.
Le template modifie même le serveur DNS du réseau virtuel sur lequel il est déployé, la vie est belle !

Pensez également à créer dans votre AD un ou plusieurs utilisateurs de test pour la solution Azure Virtual Desktop.

Création d’une première OU pour les machines virtuelles AVD et d’une seconde OU pour les utilisateurs AVD.

Etape II : Installation d’AD Connect

Une fois déployé, nous allons mettre en place la liaison entre le serveur Active Directory et Azure AD. Pour cela, nous allons utiliser l’outil Azure AD Connect, téléchargeable directement ici. Idéalement installé sur une machine dédiée et jointe au domaine, vous pouvez l’installer directement sur votre contrôleur de domaine pour environnement de test.

Si vous souhaitez en savoir plus sur cet utilitaire et son installation, voici une vidéo proposée par l’Azure Academy :

Merci à Dean Cefola 😊
Synchronisation des 2 OUs précédemment créés sur le serveur Active Directory.
L’installation est terminée et la synchronisation se lance à l’issue de cette dernière. J’en ai profité pour activer le SSO, fonctionnel au sein de AVD.

Une fois déployé, vous devriez retrouver votre groupe et vos utilisateurs AVD créés sur l’AD directement sur Azure AD :

La mention DIRECTORY SYNCED vous indique que ces utilisateurs ne sont pas à l’origine créé par Azure AD.

Etape III : Mise en place de l’Hybrid Join via Azure AD Connect

Cet étape demande à retourner sur la configuration d’Azure AD Connect. En effet, il faut activer cette option dans un second temps :

  • Lancez Azure AD Connect et cliquez sur le bouton Configurer
  • Cliquez sur Configurer les options du dispositif dans la liste des tâches supplémentaires
  • Passez en revue la page et cliquez sur Suivant
  • Saisissez les informations d’identification d’un compte d’administrateur global Azure AD, puis cliquez sur Suivant
  • Sélectionnez Configure Hybrid Azure AD join et cliquez sur Next
  • Sélectionnez la configuration du système d’exploitation de l’appareil (Windows 10 actuel ou systèmes d’exploitation plus anciens de « niveau inférieur ») qui sera prise en charge et cliquez sur Suivant
  • Cliquez sur le bouton Modifier et saisissez vos informations d’identification d’administrateur d’entreprise, puis cliquez sur Suivant
  • Cliquez sur Configurer pour commencer le processus
  • Lorsque le message Configuration terminée s’affiche, vous pouvez quitter l’assistant

Etape IV : Activation de l’enrôlement automatique vers Intune

Pour que l’inscription soit automatique sur Intune et qu’ils soient managés par ce dernier, il est nécessaire de faire quelques vérifications de configuration sur Azure AD. Rendez-vous donc sur la page d’Azure AD :

Certains tenants peuvent avoir à la fois Microsoft Intune et Microsoft Intune Enrollment. Assurez-vous que vos paramètres d’inscription automatique sont configurés sous Microsoft Intune (et non Microsoft Intune Enrollment).
Vérifier l’URL de découverte MDM pour l’inscription automatique et assurez-vous que l’inscription automatique est activée pour les utilisateurs désirés.

Etape V : Création d’une GPO d’auto-enrôlement

À partir de Windows 10, version 1607, une fois que l’entreprise a enregistré un appareil Windows à son Active Directory local, cet appareil sera automatiquement enregistré dans Azure AD.

Une fois la stratégie de groupe créée et activée sur l’Active Directory local, une tâche est créée en arrière-plan pour lancer l’inscription à l’aide de la configuration existante du service MDM à partir des informations Azure AD de l’utilisateur, et sans son interaction. Effectuez les étapes ci-dessous pour configurer une stratégie de groupe afin d’inscrire un groupe d’appareils dans Intune :

Naviguer vers le dossier C:\Program Files (x86)\Microsoft Group Policy\Windows 10 May 2020 Update (2004) et copiez le dossier PolicyDefinitions dans F:\SYSVOL\domain\Policies.

Redémarrez le contrôleur de domaine pour rendre la police disponible.

Créez un objet de stratégie de groupe (GPO) et activez la stratégie de groupe Configuration de l’ordinateur > Stratégies > Modèles d’administration > Composants Windows > MDM > Activer l’inscription automatique au MDM en utilisant les informations d’identification Azure AD par device.
Dans le cadre d’un environnement AVD partagé, il est nécessaire de sélectionner « Device Credential ».

Important

Sur tous les Windows 10, versions 2004, 20H2 et 21H1, il y a actuellement un problème qui fait que les actions à distance dans Microsoft Endpoint Manager, comme la synchronisation à distance, ne fonctionnent pas correctement. En conséquence, l’application de toute politique en attente affectée à des périphériques peut prendre jusqu’à 8 heures. Pour résoudre ce problème, veuillez effectuer les étapes suivantes sur vos machines virtuelles avant de les inscrire dans Microsoft Endpoint Manager en utilisant dans votre GPO la clé de registre suivante :

  • Chemin : HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Server
  • Nom de la valeur : ClientExperienceEnabled
  • Type de valeur : REG_DWORD
  • Données de la valeur : 1
Vous pouvez faire l’opération dans la même GPO.
Une fois la GPO terminée, il ne vous reste qu’à rattacher celle-ci au groupe de machines virtuelles AVD.

Etape VI : Création de l’environnement Azure Virtual Desktop

Dans tous les cas, la création d’une environnement Azure Virtual Desktop nécessite une jointure à un domaine existant. Il peut être géré sur une machine virtuelle Windows Server, ou managé par Microsoft via le service AADDS. L’étape de création de AVD va s’occuper de générer les ressources Azure suivantes :

  • Host Pool AVD
  • Session hosts (machine virtuelles AVD)
  • Workspace
  • Application groupe

J’ai donc procédé à la création suivante pour Azure Virtual Desktop :

La première étape consiste à créer le host pool et à définir si ce dernier est partagé avec la règle de load balancing désirée.
Le second onglet se concentre sur les machines virtuelles créées et rattachées au Host Pool AVD.
La partie basse de l’onglet des machines virtuelles est dédiée à la jointure avec le domain existant et les comptes d’administration.
Une fois la création du workspace et les tags renseignés, comptez une dizaine de minutes pour retrouver l’environnement AVD entièrement déployé.

Une fois le déploiement AVD terminé, il vous faut retourner sur le service pour assigner à l’application group créé un groupe d’utilisateurs AVD :

Affecter ici le groupe d’utilisateurs créé dans Active Directory et synchronisé sur Azure AD via Azure AD Connect.

Etape VII : Affecter les VMs AVD au groupe de machines AD et forcer les GPO

Les machines virtuelles créées par le service Azure Virtual Desktop se trouvent dans la bonne OU mais doivent être encore affectées au groupe de machines AVD pour recevoir la GPO créée précédemment.

Un redémarrage des machines virtuelles AVD actualisera sur ces dernières les groupes et les GPO à appliquer. Vous pouvez vérifier que tout s’est bien passé avec un compte administrateur :

La commande GPRESULT /R /SCOPE COMPUTER vous permettra de vous assurer que la machine virtuelle applique ce qu’il faut.
La commande RSoP.msc vous permettra de vous assurer que la machine virtuelle applique ce qu’il faut.
Un tour dans le registre Windows vous montre également que la clef de registre a bien été correctement déployée grâce à la GPO.

Etape VIII : Synchronisation AD > Azure AD grâce à AD Connect

Azure AD Connect est configuré par défaut pour synchroniser les objets toutes les 30 minutes. Un tour dans le programme Synchronization Service Manager nous permet de voir la prochaine synchronisation :

Il est possible de forcer une synchronisation plus tôt, si cela est nécessaire.

Une fois la synchronisation effectuée vers Azure AD, vous devriez retrouver les machines virtuelles AVD dans la section Device votre Azure AD :

Il est possible que la colonne REGISTERED indique encore Pending pendant un certain temps.
15 minutes plus tard et sans rien faire, elles retrouvent bien un statut REGISTERED.

Dans certains cas, le statut peut perdurer en Pending. Voici un bon article qui explique comment s’en sortir. Quelques minutes plus tard, les choses comment aussi à bouger pour la colonne MDM :

Cette copie d’écran démontre que la machine virtuelle vm-2 est routée vers System Center Configuration Manager, ce qui n’est évidemment pas le cas.

Note :

Il sera possible que les choses changent quand un utilisateur se connecte aux machines virtuelles AVD. La copie d’écran ci-dessous montre que le tir est rectifié, comme vous pouvez le voir dans la colonne MDM : Intune.

OUF 😊
La seconde arrive !
All good.

Si cela ne se passe pas comment attendu dans votre environnement, vous pouvez consulter les messages d’erreur directement dans les logs d’Event Viewer ou consulter cette page de troubleshoot.

Pour vérifier cette erreur, recherchez l’ID d’événement 76 (message d’événement : Inscription automatique À la gestion des données de la gestion des données : Échec (code d’erreur Win32 inconnu : 0x8018002b)). Cet événement indique un échec d’inscription automatique.

Etape IX : Configuration des VMs AVD sur Intune :

Pour rappel, Intune est l’ancien nom pour Microsoft Endpoint Manager, vous pouvez vous connecter à l’admin center par ce lien. Si toutes les étapes précédentes se sont bien passées, vous devriez retrouver les machines virtuelles AVD dans la section Windows Devices :

Vous allez pouvoir configurer différents types de police. Vous devez créer une nouvelle stratégie de conformité et la cibler sur le groupe de périphériques contenant vos VM multisessions. Les configurations de conformité ciblées sur l’utilisateur ne sont pas prises en charge.

Polices de conformité et accès conditionnel

Vous pouvez sécuriser vos VM multisessions Windows 10 Enterprise en configurant des politiques de conformité et des politiques d’accès conditionnel dans le centre d’administration Endpoint Manager. Les politiques de conformité suivantes sont prises en charge sur les VM multisessions de Windows 10 Enterprise :

  • Version minimale du système d’exploitation
  • Version maximale du système d’exploitation
  • Constructions de système d’exploitation valides
  • Mots de passe simples
  • Type de mot de passe
  • Longueur minimale du mot de passe
  • Complexité du mot de passe
  • Expiration du mot de passe (jours)
  • Nombre de mots de passe précédents pour empêcher la réutilisation
  • Microsoft Defender Antimalware
  • Intelligence de sécurité Microsoft Defender Antimalware à jour
  • Pare-feu
  • Antivirus
  • Antispyware
  • Protection en temps réel
  • Version minimale de Microsoft Defender Antimalware
  • Score de risque Defender ATP
  • Toutes les autres politiques sont signalées comme non applicables.

Les politiques d’accès conditionnel prennent en charge les configurations basées sur les utilisateurs et les périphériques pour Windows 10 Enterprise multisession.

Déploiement d’applications

Toutes les applications Windows 10 peuvent être déployées sur Windows 10 Enterprise multisessions avec les restrictions suivantes :

  • Toutes les applications doivent être configurées pour s’installer dans le contexte système/appareil et être ciblées sur les appareils. Les applications Web sont toujours appliquées dans le contexte utilisateur par défaut, elles ne s’appliqueront donc pas aux VM multisessions
  • Toutes les applications doivent être configurées avec l’intention d’affectation Required ou Uninstall app. L’intention de déploiement Available apps n’est pas prise en charge sur les VM multisession
  • Si une application Win32 configurée pour être installée dans le contexte du système a des dépendances ou des relations de substitution avec toute application configurée pour être installée dans le contexte de l’utilisateur, l’application ne sera pas installée. Pour s’appliquer à une VM multisession Windows 10 Enterprise, créez une instance distincte de l’application du contexte système ou assurez-vous que toutes les dépendances de l’application sont configurées pour être installées dans le contexte système
  • Azure Virtual Desktop RemoteApp et l’attachement d’applications MSIX ne sont pas actuellement pris en charge par Microsoft Endpoint Manager

Déploiement de scripts

Les scripts configurés pour s’exécuter dans le contexte système sont pris en charge sur Windows 10 Enterprise multisessions. Cela peut être configuré sous Paramètres de script en définissant Exécuter ce script en utilisant les informations d’identification connectées sur Non

Mise à jour de Windows pour les entreprises

Les politiques de Windows Update for Business ne sont pas actuellement prises en charge pour Windows 10 Enterprise multisessions.

Actions à distance

Les actions à distance suivantes des périphériques de bureau Windows 10 ne sont pas prises en charge et seront grisées dans l’interface utilisateur et désactivées dans Graphique pour les VM multisessions Windows 10 Enterprise :

  • Réinitialisation du pilote automatique
  • Rotation des clés BitLocker
  • Nouveau départ
  • Verrouillage à distance
  • Réinitialisation du mot de passe
  • Effacer

Fin de vie

La suppression des VM d’Azure laissera des enregistrements de périphériques orphelins dans Microsoft Endpoint Manager. Ils seront automatiquement nettoyés selon les règles de nettoyage configurées pour le locataire.

Configurations supplémentaires qui ne sont pas prises en charge sur les VM multisessions de Windows 10 Enterprise.

L’inscription à Out of Box Experience (OOBE) n’est pas prise en charge pour Windows 10 Enterprise multisessions. Cette restriction signifie que :

  • Windows Autopilot et Commercial OOBE ne sont pas pris en charge.
  • La page d’état des inscriptions n’est pas prise en charge.

Conclusion

C’était un plaisir de tester cette nouvelle feature pour Azure Virtual Desktop. J’attends avec impatience que plus de polices soient disponibles pour les machines virtuelles en Windows 10 multisessions. Pensez à partager dans les commentaires vos autres sources d’apprentissage ! 😎

Mise en place d’un Azure Disaster Recovery sur un environnement Azure Virtual Desktop

Dans le cloud, il faut anticiper les pannes. Au lieu d’essayer d’empêcher toutes les défaillances, l’objectif est de réduire les répercussions d’une défaillance potentielle au niveau de chaque composant. Dans ce cas, les stratégies de sauvegarde et de récupération deviennent importantes.

Azure propose une solution de récupération d’urgence de bout en bout, simple, sécurisée, évolutive et rentable, qui peut être intégrée à des solutions locales de protection des données. Il est donc possible d’assurer une continuité de service par la réplication des ressources sur une seconde région.

Voilà pour la définition officielle côté Microsoft.

Je trouve cette image d’architecture assez parlante : le but d’un Disaster Recovery est bien de répliquer un site de production existante vers un second site, et d’assurer une synchronisation des données pour avoir une reprise d’activité des plus performantes.

Voici un exemple d’architecture Azure, redondée en totalité sur une seconde région Azure.

Contexte : Azure Virtual Desktop

Pour les architectures basées sur Azure Virtual Desktop, le fonctionnement est identique : je vais répliquer les services suivants dans une seconde région Azure :

  • Active Directory : ici Azure Active Directory Domain Services
  • Machine virtuelle : composant principal de AVD
  • Disque managé : utilisé pour OS
  • Compte de stockage : utilisé pour les profils utilisateurs via la solution FSLogix

Il est également possible de répliquer les ressources propres à Azure Virtual Desktop dans une seconde région, telles que :

  • Host Pool
  • Workspace
  • Applications groups

Je ne vais pas faire cette réplication globale dans ce billet, car je souhaite vous montrer ici le processus d’auto-enrôlement des machines virtuelles, issues du Test Failover, directement dans l’environnement Azure Virtual Desktop existant.

Je vais détailler de manière assez rapide la mise en place du premier environnement de production AVD, hébergé sur Suisse Nord. Cela reste un déploiement classique, car il ne nécessite pas de spécificités particulières pour la mise en place du Disaster Recovery, installé dans un second temps.

Etape I : Création d’un domaine Active Directory

La première étape consiste à la création du domaine. Cette solution est obligatoire pour la mise en place de tout environnement Azure Virtual Desktop.

Comme indiqué plus haut, j’ai choisi d’utiliser le service Azure Active Directory Domain Services. Pour rappel, il s’agit d’un domaine managé par Microsoft et c’est une ressource unique par Tenant :

What are the Differences Between Azure Active Directory and Azure Active  Directory Domain Services?

Alternative : Il est malgré tout possible de choisir un serveur Active Directory sur une machine virtuelle.

Voici une vidéo très explicative de Travis Roberts, qui montre les différences entre Active Directory, Azure Active Directory et Azure Active Directory Domain Services

Pour pouvoir répliquer mon service AADDS dans une seconde région Azure, j’ai choisi le SKU “Enterprise” car le SKU “Standard” ne permet pas d’utiliser la fonction Réplica Set. Pas de panique, ce SKU reste modifiable, même après la création du service AADDS et comme expliqué ici :

Merci à AnubhavinIT pour cette démonstration d’installation d’AADDS.

Etape II : Création d’une image pour les machines virtuelles

Encore une fois, je ne vais pas m’étendre en détail sur ce processus de création d’une image pour votre environnement Azure Virtual Desktop. A vrai dire, il ne diffère en rien de la préparation d’une image en dehors du cloud. L’idée générale ici est de créer un ensemble d’applicatifs et de configurations pour automatiser le processus de création de machines virtuelles dans votre environnement AVD.

La dernière vidéo complétement déjantée de Dean Cefola le montre très bien 😉.

Etape III : Création d’un environnement Azure Virtual Desktop

Une fois l’image “prête à l’emploi”, nous allons pouvoir créer notre environnement Azure Virtual Desktop. Cette création va mettre en place les ressources Azure suivantes :

  • Host pool
  • x machine(s) virtuelle(s)
  • Workspace
  • Applications groups
Pour être toujours complet dans le processus de création AVD, je vous conseille cette vidéo de Mike Rodrick sur cette étape.

Etape IV : Mise en place du compte de stockage FSLogix

Le service Azure Virtual Desktop recommande les conteneurs de profils FSLogix en tant que solution de profil utilisateur. FSLogix est conçu pour l’itinérance des profils dans des environnements informatiques à distance, comme Azure Virtual Desktop. Il stocke un profil utilisateur complet dans un seul conteneur.

Source : Microsoft
FSLogix on Twitter: "New Microsoft learn module: Separate user profiles  from virtual machines with FSLogix profiles within Windows Virtual Desktop.  Learn more here: https://t.co/LlzMPK43Oa… https://t.co/mRbliUqBIo"
L’idée générale de séparer le profil utilisateur de la VM permet faciliter la mise à jour des images, de laisser l’utilisateur se connecter sur une autre VM en y retrouvant toutes ses applications et ses datas.
Pour comprendre en détail son fonctionnement et son utilité dans notre architecture AVD, quoi de mieux que de demander encore une fois à Dean.

Point important : L’installation de FSLogix nécessite quelques étapes, notamment au niveau de l’application des droits utilisateurs sur le file share (NTFS + RBAC).

Une bonne vidéo vaut toujours que de longues explications, merci Travis Roberts.

Etape V : Mise en place du Disaster Recovery via Azure Site Recovery

Notre environnement de production de Azure Virtual Desktop est maintenant prêt, nous allons pouvoir commencer la mise en place de la solution de Disaster Recovery.

Pour vous assurer que les utilisateurs peuvent toujours se connecter pendant une panne de région, vous devez répliquer leurs machines virtuelles à un autre emplacement. En cas de panne, le site principal bascule vers les machines virtuelles répliquées dans l’emplacement secondaire. Les utilisateurs peuvent continuer à accéder aux applications à partir de l’emplacement secondaire sans interruption. En plus de la réplication de machine virtuelle, vous devez conserver les identités utilisateur accessibles à l’emplacement secondaire. Si vous utilisez des conteneurs de profils, vous devrez également les répliquer. Enfin, assurez-vous que vos applications d’entreprise qui reposent sur les données de l’emplacement principal peuvent basculer avec le reste des données.

Source : Microsoft

Dans mon cas, je vais utiliser le service Azure Site Recovery pour assurer la réplication des machines virtuelles. En effet ce service assure une réplication constante des données dans Azure.

Attention : pour faire un DR complet, il faudra aussi prendre en considération la réplication du compte de stockage utilisé pour les profils gérés par FSLogix.

Activer la réplication d’une machine virtuelle peut se faire directement depuis l’interface de la VM.

Je vais pouvoir choisir ma région de réplication et personnaliser certains paramètres de configuration. Il n’est pas obligatoire de localiser la réplication sur la région paire de la première. Des coûts de bande passante entre région seront évidemment facturés par Microsoft.

J’ai déjà créé au préalable un premier groupe de ressources et un premier réseau virtuel dans ma seconde région, j’ai donc pu les sélectionner sans souci.

On peut donc démarrer la réplication juste après :

Ce processus d’initialisation prend un peu de temps, mais peut-être suivi par les notifications Azure.
Une fois la première réplication entièrement terminée, nous retrouvons sur la machine virtuelle son état de DR et toutes les informations associées.
Voici les ressources Azure créées dans la seconde région Azure. Finalement, nous n’avons qu’un compte de stockage et qu’un réseau virtuel.

Avant de démarrer la bascule des VMs dans AVD vers la seconde région Azure, je souhaite vous montrer l’état d’environnement de Azure Virtual Desktop :

Le Remote Desktop est bien accessible aux utilisateurs via l’application AVD Remote Desktop ou l’accès WEB.

Pour vérifier le bon fonctionnement du Disaster Recovery, qui je le rappelle doit TOUJOURS être déclenché manuellement, nous allons utiliser la fonction “Test Failover” de ce dernier :

  • Je commence par éteindre les machines virtuelles AVD déjà présentes sur Suisse Nord.
  • Je déclenche le Test Failover sur la ou les VMs AVD.
Un DR, exercice ou non, doit TOUJOURS être déclenché manuellement.

Pourquoi cela ?

Cela tient à une propriété d’enrôlement automatique des machines virtuelles à AVD.

Du fait que les nouvelles machines virtuelles vont avoir le même nom de machine que les précédentes, je souhaite vous montrer ici l’interruption de service, puis la reprise d’activité avec les nouvelles machines dans la seconde région Azure :

L’arrêt des machines virtuelles entraîne un service indisponible dans Azure Virtual Desktop.

Une fois le failover déclenché sur les deux machines virtuelles de mon environnement AVD, on retrouve toutes les nouvelles ressources Azure, automatiquement créées dans la seconde région Ouest Europe :

Copie d’écran des ressource présentes dans le groupe de ressources ASR.
Copie d’écran de ma liste de VMs : on retrouve bien donc deux VMs allumées (Ouest Europe) et deux VMs éteintes (Suisse Nord).

Résultat constaté : quelques minutes plus tard, je retrouve donc un environnement Azure Virtual Desktop opérationnel, sans aucune action supplémentaire de ma part :

Attention une VM qui passe peut en cacher une autre !
On peut noter que la région indique toujours la Région Azure Suisse nord car l’enrôlement de la nouvelle machine virtuelle s’appuie toujours sur les propriétés de la machine originelle.

Côté utilisateur : les utilisateurs peuvent donc se reconnecter à Azure Virtual Desktop :

Aperçu utilisateur via l’application Remote Desktop dédiée à Azure Virtual Desktop.

Note : Une fois le test de Failover réussi, pensez à nettoyer les ressources créées pour l’occasion et rallumer les machines virtuelles de production :

Une fonctionnalité de nettoyage des ressources issues du test du DR est directement disponible ici.

Résultat attendu :

Une fois le nettoyage démarré et les VMs de production rallumées : les machines virtuelles de production reprendront leur place dans l’host pool de Azure Virtual Desktop :

Le statut des VMs dans le host pool AVD retourne en « Unvailable » lorsque je le nettoie les ressources issue du test du Failover.
Le statut des VMs de retourne en « Available » lorsque je redémarre les machines de productions dans Suisse Ouest.

Conclusion

J’espère avoir été assez claire dans ce billet pour vous permettre de faire votre propre test dans votre environnement Azure Virtual Desktop.

Attention rappel, je n’ai pas parlé de la réplication de compte de stockage pour FSLogix, lui aussi à prendre en compte dans une solution de disaster recovery complète.

N’hésitez pas à faire part de vos réactions ou questions dans les commentaires 😊