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

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *