Premières armes sur Windows 365

Annoncé il y a plusieurs mois Windows 365, le nouveau service de bureau à distance proposé par Microsoft, est disponible depuis le 2 août dernier. Voici une courte vidéo d’introduction à la solution ainsi qu’un lien vers la documentation Microsoft :

Dans cet article, nous allons présenter Windows 365 Cloud PC en répondant à plusieurs interrogations et aussi en déployant plusieurs éditions de démonstration. Voici le lien vers la FAQ officielle de Windows 365.

Questions / réponses

Quelles sont les solutions de bureau à distance actuellement proposées par Microsoft Cloud ?

Actuellement, il existe 2 services proposant du bureau à distance via le Cloud Azure. Le choix de la solution se fait alors selon les besoins utilisateurs, du niveau de management et du mode de facturation :

Quelles sont les différences techniques entre les 2 solutions de bureau à distance ?

La principale technologie employée dernière ces 2 solutions est identique : Azure. Windows 365 se positionne comme une offre parallèle à Azure Virtual Desktop. Le tableau ci-dessous nous montre les principales différences techniques entre ces 2 services :

On peut en déduire que Windows 365 est un service managé par Microsoft qui ne requiert presque aucune compétence sur Azure.

Pourquoi proposer Windows 365 en version Business et en version Entreprise ?

Deux éditions de Windows 365 sont disponibles : Windows 365 Business et Windows 365 Entreprise.

  • Windows 365 Entreprise : conçu pour les grandes entreprises qui souhaitent déployer des Cloud PCs au sein de leur organisation, sans limitation de licences et via une gestion Intune
  • Windows 365 Business : apporte des Cloud PCs autonomes, facile à mettre en place sans exigence de management

Quelles sont les prérequis ou limites à ces 2 éditions ?

  • Windows 365 Entreprise : Les utilisateurs ayant un PC Windows Pro : Windows 10 Enterprise E3 + EMS E3 ou Microsoft 365 F3/E3/E5/Business Premium. Les utilisateurs n’ayant pas de PC Windows Pro : Windows VDA E3 + EMS E3 ou Microsoft 365 F3/E3/F5/Business Premium
  • Windows 365 Business : aucune licence préalable n’est nécessaire. Un maximum de 300 licences est possible par tenant

Quelles sont les coûts par utilisateur de Windows 365 ?

Contrairement à Azure Virtual Desktop, Windows 365 apporte un calcul et une prédiction des coûts plus simple à anticiper : cela va dépendre de la puissance allouée à l’utilisateur 😉.

Voici un extrait de la liste des prix publics publiée par Microsoft.
Voici une seconde liste comparant les 3 éditions disponibles.

Existe t-il des coûts de bande passante comme pour Azure Virtual Desktop ?

Dans le cas de Windows 365 Entreprise, des coûts supplémentaires sur Azure sont à prendre en compte :

Le schéma d’architecture indiqué plus bas montre des connexions réseaux indispensables à son fonctionnement. Cette liaison est utilisée pour connecter Windows 365 à Active Directory, elle apporte aux utilisateurs l’accès à des ressources locales. La tarification Azure est donc appliquée pour l’utilisation du réseau.

Comment bien dimensionner les Cloud PCs des utilisateurs ?

Comme pour Azure Virtual Desktop, Microsoft met à disposition des recommandations de puissance selon les besoins des utilisateurs :

Si le besoin de puissance de l’utilisateur venait à changer, il est toujours possible de revoir cela :

Qu’est-ce que Windows Hybrid Benefit ?

A ne pas confondre avec Azure Hybrid Benefit, Windows Hybrid Benefit est permet de réduire le coût des licences Windows 365 Business. Les utilisateurs disposant déjà d’une licence Windows 10 Professionnel peuvent souscrire à cette licence à prix réduit. En revanche, cette option n’est pas disponible en édition Entreprise.

Que se passe t-il pour le Cloud PC si la licence Windows 365 de l’utilisateur est retirée ?

Il existe une période de grâce. Elle s’étend sur 7 jours avant que l’utilisateur ne perde l’accès à son cloud PC. Re-licencier et/ou réaffecter l’utilisateur pour remettre le cloud PC dans un état Provisionné.

Comment se connecter à son Cloud PC ?

Les utilisateurs peuvent accéder à leur Cloud PC de 2 manières différentes. Il s’agit ici des mêmes moyens de connexion que ceux disponibles via Azure Virtual Desktop :

Quelles sont les régions Cloud disponibles pour les Cloud PCs Windows 365 ?

Windows 365 est un service global. Mais le déploiement de Cloud PCs n’est disponible que dans certaines régions Azure. Vous trouverez la liste ici. Aucun doute que cette liste va s’agrandir dans le temps.

Quelles sont les possibilités de backup et de reprise d’activité avec Windows 365 ?

A date, on manque encore d’informations de la part de Microsoft sur ces 2 services déjà disponibles sur Azure Virtual Desktop.

Quels sont les liens possibles entre une infrastructure existante et Windows 365 ?

La réponse est : cela va dépendre de la licence Windows 365 choisie. Il existe une différence importante entre les éditions Business et Entreprise. Seule la seconde permet (et exige) d’établir une liaison “réseau à réseau”.

Cela est utile dans le cadre d’infrastructure existante dans Azure ou on-premise. Cette liaison est établie avant le premier déploiement des Cloud PCs. Ce lien réseau est utilisé pour :

  • Joindre les Cloud PCs à un domaine Active Directory existant
  • Permettre un accès réseau à des ressources locales via une passerelle Azure VPN ou autre

Pour approfondir le sujet, nous allons maintenant déployer 2 environnements pour Windows 365 :

  • Déploiement A : Edition Windows 365 Business
  • Déploiement B : Edition Windows 365 Entreprise

Déploiement A : Edition Windows 365 Business

Etape I : Achat d’une licence de démonstration Windows 365 Business

L’achat d’une licence de démonstration pour Windows 365 Business est possible depuis le centre d’administration de Microsoft 365. Vous retrouvez sur cette page 2 familles de produit Business :

  • Windows 365 Business
  • Windows 365 Business (avec Windows Hybrid Benefit)

3 plans de démo sont disponibles en essai gratuit pendant 60 jours. A noter que la quantité est 25 par défaut et grisée. Vous aurez donc et dans chacun des 3 plans qu’une seule licence Windows 365 Business affectable :

  • 2 vCPU, 4 GB, 128 GB
  • 2 vCPU, 8 GB, 128 GB
  • 4 vCPU, 16 GB, 128 GB

Vous pouvez rencontrer un souci lors de l’achat de licence d’essai avec le message d’erreur suivant :

Je n’ai pas encore d’information sur l’origine de cette erreur. Je pense que cela vient d’un nombre trop élevé de licences d’essai activées, dû à l’engouement pour Windows 365.

Etape II : Affectation de la licence Windows 365 Business à l’utilisateur

Une fois l’achat correctement terminé, il faut retourner sur la liste des utilisateurs du tenant pour affecter la licence d’essai Windows 365 Business à la personne de votre choix :

L’affectation de cette licence est aussi possible sur un groupe d’utilisateurs.

Et c’est bien tout ce qu’il faut faire pour la partie Windows 365 Business 😎! Une fois le déploiement du Cloud PC terminé, l’utilisateur peut directement s’y connecter.

Note : Déjà dit plus haut, le management des Cloud PCs sous cette licence est limité. Pas question ici de liaison réseau à réseau, ou de management via Intune.

Etape III : Connexion de l’utilisateur à Windows 365 Business

Comme indiqué dans le jeu de questions en début d’article, plusieurs méthodes de connexion à Windows 365 existent. Dans ce premier essai, nous allons utiliser ici la page web officielle de Windows 365 :

Tableau de bord montant à utilisateur son ou ses Cloud PCs.
L’interface web apporte également l’accès à certaines ressources locales du PC.
Comme pour l’accès à Azure Virtual Desktop, une seconde authentification est demandée pour ouvrir la session Windows de l’utilisateur.

Etape IV : Contrôles du déploiement de Windows 365 Business

Le premier contrôle s’effectue directement sur le Cloud PC. Nous en apprenons un peu plus ici sur la jointure effectuée par Windows 365 :

Une fois connecté sur le Cloud PC, la commande dsregcmd /status affiche la jointure à Azure AD, mais aussi l’absence de liaison avec un domaine Active Directory.

Comme attendu, la mention AzureAdJoined à YES indique que le Cloud PC est bien enregistré dans Azure AD :

Pour finir, nous ne retrouverons pas ce Cloud PC dans la section dédiée à Windows 365 du portail Intune :

Les éditions Windows 365 Business n’ont pas cette fonctionnalité.

Déploiement B : solution Windows 365 Entreprise

La Tech Community a déjà mis à disposition une aide au déploiement pour Windows 365 Entreprise. Vous pouvez la consulter ici.

Voici un déroulé étape par étape sur mon tenant de test :

Etape 0 : Rappel des prérequis

Contrairement à l’édition Windows 365 Business, celle-ci demande plusieurs prérequis pour déployer correctement les Cloud PCs:

  • Licences utilisateurs : Pour les utilisateurs ayant déjà un PC en Windows Pro : Windows 10 Enterprise E3 + EMS E3 ou Microsoft 365 F3/E3/E5/Business Premium. Pour les utilisateurs n’ayant pas de PC en Windows Pro : Windows VDA E3 + EMS E3 ou Microsoft 365 F3/E3/F5/Business Premium
  • Licence pour l’administrateur : Licencier le ou les administrateurs des Cloud PCs via une licence Intune Service Admin
  • Souscription Azure : Disposer d’une souscription Azure valide avec un rôle de propriétaire pour le réseau virtuel de Windows 365
  • Réseau virtuel Azure : Déployer un réseau virtuel sur la souscription Azure ci-dessus. Vérifier que la configuration DNS du réseau virtuel soit faite pour utiliser un domaine Active Directory
  • Domaine Active Directory : Disposer d’un domaine Active Directory accessible via le réseau virtuel ci-dessus. Ce domaine peut provenir d’une architecture on-premise ou hébergé dans Azure. A date, il n’est pas encore possible de faire fonctionner Windows 365 avec Azure AD Domain Services (Etape I)
  • Azure AD Connect : Synchroniser les identités Active Directory avec Azure AD, mais également activer la fonction Hybrid Azure AD Join (Etape II)

Test Azure Active Directory Domain Services -> KO

J’ai voulu faire un test de jointure entre Windows 365 et Azure AD DS. Voici le domaine managé correctement déployé :

Seulement l’absence d’Hybrid Join avec Azure AD DS provoque une erreur lors du provisionnement du Cloud PC :

Etape I : Activation de la fonction Hybrid Azure AD join via Azure AD Connect

L’outil Microsoft Azure AD Connect a été conçu pour vous permettre d’atteindre et de remplir vos objectifs en matière d’identité hybride. La dernière version est téléchargeable ici.

Dans mon domaine Active Directory, j’ai déjà préparé des utilisateurs pour mon futur environnement Windows 365.
Grâce à Azure AD Connect, je retrouve bien mes utilisateurs dans Azure AD.
Un retour dans la configuration d’Azure AD Connect permet d’activer la fonction. de jointure hybride.

Une fois tous les prérequis validés, l’étape suivante consiste à prendre des licences Windows 365 Entreprise pour les utilisateurs.

Etape II : Achat d’une licence de démonstration Windows 365 Entreprise

Comme pour l’édition Business, il est possible de prendre une licence de démonstration pour Windows 365 Entreprise. Cette opération est possible depuis le centre d’administration de Microsoft 365 :

De la même façon, Les 3 mêmes plans de démo sont disponibles en essai gratuit de 60 jours :

  • 2 vCPU, 4 GB, 128 GB
  • 2 vCPU, 8 GB, 128 GB
  • 4 vCPU, 16 GB, 128 GB

Comme pour l’édition Business, vous pouvez rencontrer un souci lors de l’achat de licence d’essai avec le message d’erreur suivant :

Même erreur que celle constatée lors de l’achat de licence d’essai Business.

Etape III : Affectation de la licence Windows 365 Entreprise à l’utilisateur

Une fois l’achat correctement passé, il faut retourner sur la liste des utilisateurs pour affecter la licence à la personne de votre choix :

L’affectation de cette licence est aussi possible sur un groupe d’utilisateurs.

L’affectation de la licence Windows 365 Entreprise à un utilisateur est directement visible dans la console Intune via le suivant :

L’ajout de la ligne dans cet écran est automatique et instantané.

Etape IV : Création de la connection vers le réseau on-premise

Une connexion réseau est requise pour déployer des Cloud PCs Windows 365 Entreprise. La création de cette liaison entre Windows 365 et le réseau virtuel d’Azure se fait directement depuis le portail Intune :

Le rôle de propriétaire de la souscription Azure est nécessaire pour effectuer cette liaison.

Les éléments renseignés ci-dessous sont propres à votre domaine Active Directory :

Dans mon exemple, j’ai créé une OU spécifique pour les Cloud PCs. Cette OU est prise en compte dans la synchronisation via Azure AD Connect.
Il est possible de créer plusieurs connexions réseau Windows 365 dans un même tenant.
Une fois la création réseau lancée, un check est effectué afin de vérifier que tout est en ordre.

Le processus de check peut prendre plusieurs dizaines de minutes. Voici différents résultats possibles :

Tout est bon 😎.
Si la fonction Hybrid Azure AD join n’est pas activée chez vous, vous rencontrerez l’alerte ci-dessus.

Etape V : Création de la police de provisionnement

Une dernière étape de paramétrage est nécessaire dans Intune pour lier la connexion réseau avec les Cloud PCs Windows 365 Entreprise, grâce à une police de provisionnement :

Comme indiqué dans les prérequis, le compte utilisé pour créer cette police doit disposer du rôle Intune Service Admin.
La connection on-premise est obligatoire pour créer la police de Windows 365 Entreprise.
La police fait appel à des images personnalisées ou préconstruites.
Liste des images préconstruites par Microsoft.

L’assignation des utilisateurs à cette police doit être en cohérence avec les licences Windows 365 Entreprise précédemment affectées. Il est donc préférable dans les deux cas d’assigner via un seul et même groupe d’utilisateurs :

A ce stade, le status du Cloud PC Windows 365 Entreprise va automatiquement évoluer :

Le processus de provisionnement des Cloud PCs prend entre 20 et 30 minutes environ.

Après un laps de temps, les Cloud PCs sont provisionnés ou remontent en erreur :

Pour l’erreur sur le premier utilisateur, la fonction Hybrid Join n’a pas été correctement activée dans Azure AD Connect.

Pour le second utilisateur, tout est bon pour lui, l’étape suivante va consister à se connecter à Windows 365.

Etape VI : Connexion de l’utilisateur à Windows 365 Entreprise

Comme indiqué pour l’édition Business, plusieurs méthodes de connexion à Windows 365 sont possibles. Cette fois-ci, nous allons utiliser le client Windows Remote Desktop :

Une fois authentifié, le Cloud PC apparaît de la même manière qu’une machine d’Azure Virtual Desktop.
Comme pour Azure Virtual Desktop, une seconde authentification est demandée pour ouvrir la session Windows de l’utilisateur.

Etape VII : Contrôles du déploiement de Windows 365 Entreprise

Le premier contrôle s’effectue directement sur le Cloud PC. Nous en apprenons un peu plus ici sur la jointure effectuée par Windows 365 :

Une fois connecté sur le Cloud PC, la commande dsregcmd /status nous permet de constater la jointure à Azure AD et la liaison avec le domaine Active Directory.

Comme pour l’édition Business, la mention AzureAdJoined à YES indique que le Cloud PC est bien enregistré dans Azure AD :

Gestion des Cloud PCs via Intune.

Gestion des erreurs dans le déploiement

Microsoft met à disposition des aides concernant la résolution de souci de déploiement sur Windows 365. Vous pouvez retrouver cette documentation ici ou . En cas de doute, il faut ne pas hésiter à reprendre la documentation initiale de déploiement disponible .

Dean de l’Azure Academy nous propose cette vidéo très explicative sur le déploiement de l’édition Entreprise.

Conclusion

Windows 365 est une nouvelle approche de bureau à distance s’appuyant sur Azure. Nul doute que la solution va encore évoluer pour apporter encore plus de fonctionnalités et de simplicité. Faites part de vos remarques sur la solution Windows 365 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 :

Il faut compter une bonne quinzaine de minutes pour la création de cet environnement AVD et les 2 VMs.

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 :

L’affectation ne se fait pas au niveau du pool d’hôtes, mais bien sur le groupe d’applications créé durant le même processus.

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

La copie d’écran ci-dessus montre le paramétrages des options RDP possibles.

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

Test de la solution côté utilisateur :

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 :

Accès Web

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.

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

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 😋