AVD + Teams = Bonnes pratiques

La mise en place d’Azure Windows Virtual Desktop s’accompagne de bonnes pratiques, dont plusieurs sont dédiées à Microsoft Teams. Dans cet article nous allons détailler l’installation de Microsoft Teams sur Azure Virtual Desktop, ainsi que la mise en pratique de quelques options pouvant améliorer l’expérience des utilisateurs.

Microsoft Teams Conference Call Bingo : MicrosoftTeams

Installation de Microsoft Teams

Une des premières bonnes pratiques concernant Azure Virtual Desktop est de travailler avec des images de l’OS. L’image de votre OS va vous permettre de maîtriser vos déploiements en les sécurisant et en les automatisant.

Il est donc conseillé d’installer Microsoft Teams sur votre image, avant de commencer le déploiement des ressources dédiées à AVD. Sachez que l’installation de Teams n’est pas comprise dans les images Windows 10 multisessions avec les applications Office 365, mises à disposition par Microsoft. Cette installation est donc systématiquement à part. Un lien vers la documentation Microsoft dédiée à ce sujet est toujours utile pour vous aider dans cette mise en place.

Etape 0 : Prérequis techniques Teams

Comme indiqué par Microsoft, il est nécessaire d’installer sur Teams sur une machine virtuelle ayant à minima les performances suivantes :

ParamètreSystème d’exploitation de station de travail
vCPU2 cœurs
Mémoire RAM4 Go
Stockage8 Go

Note : A contrario, il est également dit par Microsoft qu’Azure Virtual Desktop recommande des machines virtuelles à 4 coeurs.

Etape I : Activation de l’optimisation Teams pour AVD

Cette étape est essentielle dans l’installation de Teams dans un environnement Windows 10 multisessions. Les machines virtuelles d’AVD n’ont souvent peu de puissance graphique, ce qui signifie que l’exécution d’un chat vidéo entraînera une consommation élevée de CPU et conduira à des problèmes de performance.

Même en passant à un chat vocal, la qualité de l’appel peut encore être mauvaise et la consommation de CPU trop élevée. Les organisations déploient souvent AVD dans une capacité multi-utilisateurs. Cela signifie que plusieurs utilisateurs accèdent à une même machine virtuelle et qu’ils partagent donc un processeur. Les administrateurs informatiques peuvent aider à résoudre les problèmes liés à l’épuisement du processeur grâce à la redirection audiovisuelle (AV).

La redirection audiovisuelle utilise la puissance des appareils des utilisateurs finaux pour charger les chats vidéo et vocaux. Cela signifie que les utilisateurs s’appuieront sur le CPU et le GPU de leur appareil pour charger le chat et que la machine AVD n’aura plus une consommation CPU élevée. De plus, l’interface utilisateur sera considérablement améliorée car la qualité de l’audio-visuel sera presque la même que celle des équipes locales. Pour activer l’optimisation des médias pour Teams, ajouter la clé de registre suivante sur l’image AVD :

Exécuter cette commande PowerShell en administrateur.
reg add "HKLM\SOFTWARE\Microsoft\Teams" /v IsWVDEnvironment /t REG_DWORD /d 1 /f

Etape II : Installation de Teams

Vous pouvez déployer l’application de bureau Teams pour AVD en utilisant une installation par machine. Pour installer Microsoft Teams, le script ci-dessous va vous aider en installant les 3 composants suivants :

  • Installation de la composante C++ Runtime
  • Installation du service WebRTC
  • Installation de Microsoft Teams
#Variables
$CSource = "https://aka.ms/vs/16/release/vc_redist.x64.exe"
$RDWRedirectorSource = "https://query.prod.cms.rt.microsoft.com/cms/api/am/binary/RE4AQBt"
$TeamsSource = "https://statics.teams.cdn.office.net/production-windows-x64/1.4.00.8872/Teams_windows_x64.msi"
$Clocation = "C:\temp\vc_redist.x64.exe"
$RDWRedirectionLocation = "C:\temp\MsRdcWebRTCSvc_HostSetup_1.0.2006.11001_x64.msi"
$TeamsLocation = "C:\temp\Teams_windows_x64.msi"

#log store
[string]$temPAth = 'C:\temp\'

#Folder Creation
if (!(Test-Path -Path $temPAth))
{
    $paramNewItem = @{
        Path      = $temPAth
        ItemType  = 'Directory'
        Force     = $true
    }

    New-Item @paramNewItem
}

#Download C++ Runtime
invoke-WebRequest -Uri $Csource -OutFile $Clocation
Start-Sleep -s 5
#Download RDCWEBRTCSvc
invoke-WebRequest -Uri $RDWRedirectorSource -OutFile $RDWRedirectionLocation
Start-Sleep -s 5
#Download Teams 
invoke-WebRequest -Uri $TeamsSource -OutFile $TeamsLocation
Start-Sleep -s 5

#Install C++ runtime
Start-Process -FilePath $Clocation -ArgumentList '/q', '/norestart'
Start-Sleep -s 10
#Install MSRDCWEBTRCSVC
msiexec /i $RDWRedirectionLocation /q /n
Start-Sleep -s 10
# Install Teams
msiexec /i $TeamsLocation /l*v teamsinstall.txt ALLUSER=1 ALLUSERS=1 /q
Start-Sleep -s 10
Merci à Alexandre pour ce script 😉.

L’installation de Teams se termine et aucun redémarrage n’est nécessaire après l’exécution de ce script. Vous devriez pouvoir vous connecter directement à Teams et cliquer sur votre image pour vérifier sa bonne installation AVD.

Fix WVD Teams Optimization Stopped Working After Windows 10 In-place  Upgrade Windows Virtual Desktop HTMD Blog
Ce contrôle de l’optimisation Teams pourra se faire directement via un utilisateur dans l’environnement AVD.
Comme à chaque fois, merci à Dean pour ses vidéos bien pratiques.

Etape III : Optimisations possibles sur Teams

Certaines optimisations post-installation sur Teams peuvent intéressantes selon les souhaits de configuration ou si un manque de performances est constaté par vos utilisateurs.

Désactivation de l’accélération matérielle

Dans certains cas, il a été constaté que la désactivation de l’accélération matérielle augmentait les performances vidéo de Teams. Cette fonctionnalité est désactivable directement depuis les paramétrage de l’outil client, via une clé de registre ou encore via un règle GPO :

Un redémarrage de Teams est nécessaire après avoir coché la case dans les paramètres.

Seconde méthode, la clef de registre ci-dessous va désactiver la fonction quand sa valeur est égale à 1 :

HKEY_CURRENT_USER\Software\Microsoft\Office\nn.0\Common\Graphics
DWORD: DisableHardwareAcceleration
Value: 1

Dernière méthode, la création de GPO pour FSLogix nécessite la récupération des fichiers ADMX et ADML. Vous pouvez effectuer cette étape d’installation via ce lien.

Image

Désactivation du « receive segment coalescing » RSC sur la partie réseau

Dans d’autres cas, il a été constaté que la désactivation de l’option de recombinaison des paquets réseaux rétablissait les performances vidéo de Teams. Cette fonctionnalité est désactivable directement via une ligne de commande PowerShell :

Get-NetAdapterRSC
# Chercher le nom de l'adaptateur réseau primaire utilisé par AVD
Disable-NetAdapterRSC -Name "Nom de l'adaptateur réseau"

Redirection du cache Teams hors du profil utilisateur FSLogix

Note : Cette fonctionnalité n’est possible que si vous avez installé FSLogix au préalable sur votre image. Suivez l’étape ci-dessous si ce n’est pas encore le cas dans votre environnement. Si FSLogix est déjà en place et fonctionnel, passez à la suite.


Le script PowerShell ci-dessous installe et configure FSLogix. Vous pouvez retrouver toutes les options de la solution FSLogix ici. La variable $connectionString doit reprendre le nom du compte de stockage et le nom du file share. Voici un exemple dans un environnement où ebgkhbywivnfzjy est le nom de mon compte de stockage et profiles le nom de mon file share :

\\ebgkhbywivnfzjy.file.core.windows.net\profiles

######################
#    AVD Variables   #
######################

$LocalWVDpath = "c:\temp\wvd\"
$FSLogixURI  = "https://aka.ms/fslogix_download"
$FSInstaller = "FSLogixAppsSetup.zip"
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
$connectionString = "<your-share-path-here>" 

####################################
#    Test/Create Temp Directory    #
####################################

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"
}
New-Item -Path c:\ -Name New-WVDSessionHost.log -ItemType File
Add-Content `
-LiteralPath C:\New-WVDSessionHost.log `
"
ProfilePath       = $connectionString
"
#################################
#    Download AVD Componants    #
#################################

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

##############################
#    Prep for AVD Install    #
##############################
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"

#########################
#    FSLogix Install    #
#########################
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


#######################################
#    FSLogix User Profile Settings    #
#######################################
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

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

L’accès au file share aux les utilisateurs AVD va nécessiter l’application de droits RBAC et NTFS. L’opération dépend d’un certain nombre de facteurs, je vous conseille la documentation suivante pour un domaine Azure AD DS, et cette seconde documentation pour un domaine AD DS.


Une fois que Teams a été installé conformément aux directives d’installation et que l’utilisateur a démarré Teams pour la première fois, la taille du conteneur de profil augmente considérablement en quelques minutes.

Taille du profil avant l’ouverture de Teams.

Quelques minutes après l’ouverture de Teams montre que le profil grandit beaucoup !

Taille du profil après l’ouverture de Teams.

Il est alors possible d’appliquer une optimisation sur Teams pour exclure la prise en charge du cache Teams. La mise en place de cette fonction va nécessiter plusieurs actions :

  • Ajout d’un fichier de configuration XML sur le compte de stockage utilisé pour FSLogix
  • Ajout d’une règle de registre dans la configuration FSLogix sur les machines virtuelles AVD

Le script ci-dessous est assez complet et nécessite de remplir un certain nombre de variables :

  • Identifiant de la souscription
  • Nom du groupe de ressources du compte de stockage FSLogix
  • Nom du compte de stockage FSLogix
  • Nom du file share FSLogix
  • Clef primaire ou secondaire du compte de stockage
# Step 1
# Variable to Modify
$SubscriptionId = ""
$ResourceGroupName = ""
# The Ressource Group of your storage Account
$StorageAccountName = ""
$AzufileShareName = ""
$StorageAccountKey = ""


# Step 2
# Module and Connection
Install-Module AZ
Import-Module AZ
Install-Module azuread
Import-Module azuread
# Connection Needed for Azure 
Connect-AzAccount
Select-AzSubscription -SubscriptionId $SubscriptionId
# Connection Needed for Azure AD
Connect-AzureAD

# Step 3
# Variable to not modify"
$xmllocation= "\\$StorageAccountName.file.core.windows.net\$AzurefileShareName\$Directory"

# Step 4
#  Run the code below to test the connection and mount the share
$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."
}

# Step 4 Directory Creation for Teams Exclusion
# Variable to not modify
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
$DirectoryID= "T:\Teams"
$Directory= "Teams-Exclusion"
New-Item -Path $DirectoryID -ItemType Directory

# Step 5 Download the Xmlredirection
# Variable to not modify"
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Scope CurrentUser
$xmllocation= "\\$StorageAccountName.file.core.windows.net\$AzurefileShareName\$Directory"
$xmlurl= "https://raw.githubusercontent.com/Aldebarancloud/WVDCourse/main/redirections.xml"
$connectionString= "\\$StorageAccountName.file.core.windows.net\$AzurefileShareName\$Directory"

Invoke-WebRequest -Uri $xmlurl -OutFile $xmllocation
Un contrôle dans le compte de stockage permet de s’assurer la bonne présence du fichier de configuration XML.

Une fois le script lancé, il est nécessaire d’ajouter sur l’image AVD une règle de registre pour FSLogix appellant ce fichier XML de configuration. Il faut donc remplacer les xxx par le nom de votre compte de stockage dans cette commande PowerShell :

Set-ItemProperty `
-Path HKLM:\Software\FSLogix\Profiles `
-Name "RedirXMLSourceFolder" `
-Type String `
-Value "\\xxx.file.core.windows.net\profiles\Teams-Exclusion"

Une fois la configuration finie, il faut penser à supprimer le profil de l’utilisateur sur le compte de stockage FSLogix afin de repartir sur une base « propre ». L’utilisateur peut alors lancer sa session AVD et Teams. Un rapide contrôle sur le compte de stockage nous permet de vérifier l’évolution de la taille sur profil utilisateur

Ouverture de la session AVD et de la session Teams par un utilisateur de test.
La taille du profil utilisateur n’augmente plus au lancement de Teams.

Conclusion

Au final, Microsoft Teams reste un outil formidable de communication bien intégré dans la suite Office 365. Il mérite toute sa place dans Azure Virtual Desktop. 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 ! 😎

AVD – Démarrage des VMs à la demande

Annoncé fin mars 2021 pour les environnements personnels Azure Virtual Desktop, Azure Preview propose maintenant cette même fonction pour les environnements AVD mutualisés (Pooled).

Voici un petit rappel de la solution par Dean d’Azure Academy.

La vidéo de Dean met en oeuvre la solution sur un environnement AVD personnel, qui fonctionne aussi pour les environnements mutualisés, et applique les point suivants :

  • Activation de l’option « Start VM On Connect » sur le Host Pool
  • Création d’un rôle custom pour donner le droit à AVD de démarrer les VMs
  • Affectation du rôle custom à la souscription ou au groupe de ressources
  • Déconnexion des sessions inactives via GPO
  • Activation de l’arrêt automatique des machines virtuelles à une heure fixe

Mise en place : La mise en place de cette solution est bien expliquée dans la vidéo de Dean, vous pouvez aussi suivre la documentation de Microsoft juste ici.

Rappel : La fonction est encore en public preview pour les environnements AVD mutualisés, il faut donc utiliser le portail adéquat.

Testez vous-même

De mon côté, j’ai souhaité tester la solution sur différents cas de figure :

  • Test sur un AVD en mode personnalisé : OK
  • Test sur un AVD en mode mutualisé (Windows 10 multisession) : OK
  • Test sur un AVD en mode mutualisé (Windows Server 2019) : OK

J’ai aussi fait un test plus poussé dans le cadre d’un environnement AVD mutualisé comprenant plusieurs machines virtuelles :

  • Nombre de machines virtuelles : 2
  • Algorithme d’équilibrage de charge : Breadth-first
  • Nombre maximal de sessions : 5

Voici ce qui s’est passé au niveau des machines virtuelles :

Environnement de départ, toutes les VMs sont OFF.
Connexion du premier utilisateur, une seule VM s’allume.
Connexion du second utilisateur, la seconde VM ne s’allume pas car l’utilisateur se retrouve connecté à la première VM.

J’ai donc refait un autre test en modifiant le nombre maximal de sessions :

  • Nombre de machines virtuelles : 2
  • Algorithme d’équilibrage de charge : Breadth-first
  • Nombre maximal de sessions : 1

Les premières étapes n’ont pas changé, mais j’ai bien eu autre chose lorsque le second utilisateur a tenté de se connecter :

Le second utilisateur doit bien attendre le démarrage de la seconde VM pour s’y connecter.
Les deux VMs sont bien allumées dans ce cas.

Conclusion

Au final, la fonctionnalité est bien opérationnelle et s’adapte bien à différents cas d’architecture Azure Virtual Desktop. Seul petit bémol concernant la fonction Breadth-first qui demande encore quelques ajustements pour bien allumer les autres VMs afin de répartir les utilisateurs 😉

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 😊

Certification Windows Virtual Desktop (AZ-140)

AZ-140 Configuring and Operating Windows Virtual Desktop on Microsoft Azure  – My Tips – Mr T-Bone´s Blog

Mon expérience sur l’examen Windows Virtual Desktop (AZ-140)

Fin mars 2021, une nouvelle certification Microsoft Azure a vu le jour et elle se consacre uniquement à seul produit : Windows Virtual Desktop. Pour rappel, Windows Virtual Desktop (aussi appelé WVD) est une plateforme lancée en septembre 2019 de type « Desktop-as-a-Service » (DaaS) sur Microsoft Azure qui offre la meilleure expérience virtuelle de Windows et de Microsoft Office. Voilà pour la définition officielle.

Comme pour la certification SAP sur Azure, le but de cette certification est de valider des connaissances sur les caractéristiques de WVD, mais aussi d’être en en mesurer déployer cette solution selon plusieurs scénarios et contraintes possibles :

  • Migration d’un environnement RDS existant en y simplifiant le management
  • Création d’un nouvel environnement de virtualisation sécurisé et moderne
  • Apporter de la continuité pour des applications “Legacy” qui fonctionne encore sur Windows 7
Microsoft-WVD-logo - Poppelgaard.com

Ayant passé cette certification début avril 2021, encore en version Beta, je vais vous partager mon retour d’expérience sur cet examen en attendant les résultats finaux, afin de vous aider au mieux sur le contenu à maitriser.

Pour rappel, le contenu exact est aussi disponible sur la page de la certification AZ-140 (ici). Vous pouvez aussi le télécharger au format PDF à partir de ce lien.

Free GED Study Guides - Magoosh GED Blog | Magoosh GED Blog

On va donc retrouver différents sujets dans cette certification, dont les principaux pourraient être :

  • Architecture on-premise existante : vous avez de fortes chances de vous retrouver avec un ou plusieurs use-cases. Ces derniers partiront certainement d’une architecture on-prem existante, avec des contraintes à respecter pour migrer sur WVD. Le cas assez classique pourrait être un multisites avec un siège et succursales ayant des besoins variés et des contraintes de distances.
Google Ethernet Cables Labeled With Cut Here To Activate Firewall
  • Connaissances des réseaux sur Azure : là encore c’est un grand sujet de presque toutes les certifications Azure. La maîtrise de la solution WVD passe par la mâitrise de ses exigences réseaux. Il n’est quand pas utile de connaître cette liste de ports et d’URLs par coeur ! Mais on va vous demander de bien connaître les réseaux utilisés, notamment pour la partie dédiée utilisateur (ex spécificité iOS). Vous pourrez également avoir des questions sur les accès par lien VPN ou le peering entre v-net.
  • Active Directory : Composante fondamentale d’un environnement Windows Virtual Desktop, vous pouvez être sûr que des questions vont concerner ce sujet. Les possibilités de monter environnement WVD sont variées concernant ce point et nécessite d’en avoir testé au préalable plusieurs. Attendez-vous aussi avoir des connections sur le très célèbre Azure AD Connect.
WVD Classic | Windows Virtual Desktop - #8 - WVD Azure ADDS - YouTube
L’utilisation d’un domaine managé, tel que d’AADDS est un moyen simple et rapide d’installer la solution pour des entreprises Cloud-only. Il comporte malgré tout quelques contraintes avant de le choisir.
How to add a session host to a Windows Virtual Desktop Host Pool ?
Autre cas avec un Active Directory hébergé dans une seconde région Azure.
A noter ici la présence d’un point of failure : Si la région Azure UK South devient inaccessible, les utilisateurs se connectant sur la région East US ne pourront qu’attendre qu’un rétablissement de service
  • Architecture Windows Virtual Desktop : il sera question de vérifier ici vos connaissances concernant les grandes notions techniques qui compose la ressource WVD : Host pool (Pooled / Personnal) – Workspace – Applications group. Savoir ce que chacun, savoir ce qu’il fait et connaître leurs principales options est évidement de rigueur.
Merci à Dean Cefola qui anime sur YouTube la chaîne Azure Academy pour cet exemple d’architecture WVD multisites.
  • Estimation du coût de l’architecture : cette notion est présente dans cette certification, comme dans la certification « Microsoft Azure Architect Design » AZ-304. L’idée ici n’est pas de connaitre tous les prix en $ ou en €, mais d’avoir une idée des gammes de produits de des coûts potentiels. Vous penserez à cela quand la question comportera la remarque « La moins chère possible ». Petite anecdote : AD DF et « La moins chère possible » font rarement bon ménage !
Migration des Profils CITRIX UPM vers FSLOGIX en « oneshot » – Xavier  BIANCHI #SysAdmin
  • FSLogix : grand gagnant de l’architecture WVD, cette solution a montré ses qualités (souplesse de configuration, performances, facilité de management, …) et reste une valeur sûre dans le jeu de questions que vous pourrez avoir. Pour rappel, FSLogix a été acquis par Microsoft automne 2018. Il faut donc vous attendre à des questions sur son périmètre d’installation (type de storage, SKU, …) et ses principales fonctionnalités (Cloud cache , App masking, configuration Regedit, … ). Ne pas être surpris non plus d’avoir aussi des questions sur la gestion des droits (RBAC ou NTFS)
Tout savoir sur la pomme Golden | Potager City
  • Gestion des golden images : une bonne pratique a la mise en place d’un remote desktop passe par l’utilisation d’images préconfigurées et mises régulièrement à jour afin de gérer la solution WVD dans les conditions les plus sécurisées. On souhaite donc savoir ici si vous maîtriser le process de création des images (sysprep, capture, …) et leur gestion en exploitation (shared image galery et autres)
  • Connaissances des rôles WVD : De manière bien large, la construction de ressources sur Azure passe toujours par l’attribution des bons droits (ni trop, ni trop peu). Plusieurs roles WVD ont donc été créés dans le scope Azure RBAC, mais aussi d’autres liés à exploitations des autres ressources tels que les machines virtuelles ou encore les comptes de stockages. Ici donc, il faut aller plus loin que « Owner », « Contributor » et « Reader »
  • Sécurité : Comme les autres application SaaS, l’accès conditionnel d’Azure AD est aussi de la partie sur Windows Virtual Desktop. Il est en effet possible de créer des règles exigeant l’utilisation de postes « compliant » ou encore d’exiger l’autentification multifacteur. Profitez-en pour faire une piqûre de rappel sur cette partie, cela ne fait jamais de mal !
  • Expérience utilisateur : en relisant la liste des compétences mesurées pour l’AZ-140, je vois que l’on attendsde vous de savoir configurer Universal Print, MSIX App Attach, Teams AV Redirect et autres. Honnêtement, je n’ai pas souvenir d’avoir eu des questions sur ces points mais d’autres sont plus successible de tomber comme le timeout ou encore sur les propriétés RDP.
  • Sauvegarde : point capital dans toute architecture informatique, il faut savoir ce qui est capital de sauvegarder et ce qui ne l’est pas ! Prenez le temps de faire des tests sur ce chapitre. Recovery Services vault est un outil assez complet avec les backups et les fonctionnalités de DR intégrées.
  • PowerShell et Azure CLI : je pense que ce point est réduit puisque presque tous les commandes WVD sont aussi disponible dans le portail Azure. Néanmoins je pense encore que certaines actions, comme joindre un compte de stockage à un domain AD, sont toujours faisable uniquement via ligne de commande
  • Monitoring de la solution WVD : Plusieurs outils sont disponibles pour monitorer toute la solution. Comme à chaque fois, Azure est toujours généreux dans sauvegarde de logs et de métrics dans un Log analytics workspace ! Il s’agit aussi d’un sujet à lui tout seul, tellement l’espace et les possibilités sont grandes.

Au final et comme toujours, le passage par la case pratique est obligatoire pour réussir cette certification Windows Virtual Desktop. Pensez-à prendre en compte des variations de scénarios pour voir les différents cas de figure.

Voici quelques liens qui m’ont été utile pour préparer mes connaissances :

Pensez à partager dans les commentaires vos autres sources d’apprentissage, ou votre feedback sur l’examen 😉