Conditions préalables pour Azure Virtual Desktop

Vous devez effectuer quelques opérations pour commencer à utiliser Azure Virtual Desktop. Vous trouverez ici les conditions préalables à remplir pour fournir des applications et des postes de travail à vos utilisateurs.

À un niveau élevé, vous avez besoin des éléments suivants :

  • Un compte Azure avec un abonnement actif
  • un fournisseur d’identité pris en charge ;
  • Un système d’exploitation pris en charge pour les machines virtuelles hôtes de session
  • Licences appropriées
  • Connectivité réseau
  • Un client Bureau à distance

Compte Azure avec un abonnement actif

Vous avez besoin d’un compte Azure avec un abonnement actif pour déployer Azure Virtual Desktop. Si vous n’en avez pas déjà un, vous pouvez créer un compte gratuitement.

Pour déployer Azure Virtual Desktop, vous devez affecter les rôles de contrôle d’accès en fonction du rôle (RBAC) Azure appropriés. Les exigences spécifiques au rôle sont traitées dans chacun des articles relatifs au déploiement d’Azure Virtual Desktop, qui sont répertoriés dans la section Étapes suivantes.

Vérifiez également que vous avez inscrit le fournisseur de ressources Microsoft.DesktopVirtualization pour votre abonnement. Pour case activée les status du fournisseur de ressources et inscrire si nécessaire, sélectionnez l’onglet correspondant à votre scénario et suivez les étapes.

Importante

Vous devez avoir l’autorisation d’inscrire un fournisseur de ressources, ce qui nécessite l’opération */register/action . Ceci est inclus si votre compte a le rôle de contributeur ou de propriétaire affecté sur votre abonnement.

  1. Connectez-vous au Portail Azure.

  2. Sélectionnez Abonnements.

  3. Sélectionnez le nom de votre abonnement.

  4. Sélectionnez Fournisseurs de ressources.

  5. Recherchez Microsoft.DesktopVirtualization.

  6. Si le status est NotRegistered, sélectionnez Microsoft.DesktopVirtualization, puis Register.

  7. Vérifiez que le status de Microsoft.DesktopVirtualization est Inscrit.

Identité

Pour accéder aux bureaux et aux applications à partir de vos hôtes de session, vos utilisateurs doivent pouvoir s’authentifier. Microsoft Entra ID est le service d’identité cloud centralisé de Microsoft qui active cette fonctionnalité. Microsoft Entra ID est toujours utilisé pour authentifier les utilisateurs d’Azure Virtual Desktop. Les hôtes de session peuvent être joints au même locataire Microsoft Entra ou à un domaine Active Directory à l’aide des services de domaine Active Directory (AD DS) ou de Microsoft Entra Domain Services, ce qui vous offre un choix d’options de configuration flexibles.

Hôtes de session

Vous devez joindre des hôtes de session qui fournissent des postes de travail et des applications au même locataire Microsoft Entra que vos utilisateurs, ou à un domaine Active Directory (AD DS ou Microsoft Entra Domain Services).

Remarque

Pour Azure Local, vous pouvez uniquement joindre des hôtes de session à un domaine de services de domaine Active Directory. Vous pouvez uniquement joindre des hôtes de session sur Azure Local à un domaine de services de domaine Active Directory (AD DS). Cela inclut l’utilisation de la jonction hybride Microsoft Entra, où vous pouvez bénéficier de certaines des fonctionnalités fournies par Microsoft Entra ID.

Pour joindre des hôtes de session à Microsoft Entra ID ou à un domaine Active Directory, vous avez besoin des autorisations suivantes :

Utilisateurs

Vos utilisateurs ont besoin de comptes qui sont dans Microsoft Entra ID. Si vous utilisez également AD DS ou Microsoft Entra Domain Services dans votre déploiement d’Azure Virtual Desktop, ces comptes doivent être des identités hybrides, ce qui signifie que les comptes d’utilisateurs sont synchronisés. Vous devez garder à l’esprit les éléments suivants en fonction du fournisseur d’identité que vous utilisez :

  • Si vous utilisez Microsoft Entra ID avec AD DS, vous devez configurer Microsoft Entra Connect pour synchroniser les données d’identité utilisateur entre AD DS et Microsoft Entra ID.
  • Si vous utilisez Microsoft Entra ID avec Microsoft Entra Domain Services, les comptes d’utilisateur sont synchronisés dans un sens de Microsoft Entra ID vers Microsoft Entra Domain Services. Ce processus de synchronisation est automatique.

Importante

Le compte utilisateur doit exister dans le locataire Microsoft Entra que vous utilisez pour Azure Virtual Desktop. Azure Virtual Desktop ne prend pas en charge les comptes Microsoft personnels.

Lorsque vous utilisez des identités hybrides, le UserPrincipalName (UPN) ou l’identificateur de sécurité (SID) doit correspondre entre les services de domaine Active Directory Active Directory et Microsoft Entra ID. Pour plus d’informations, consultez Identités et méthodes d’authentification prises en charge.

Scénarios d’identité pris en charge

Le tableau suivant récapitule les scénarios d’identité pris en charge actuellement par Azure Virtual Desktop :

Scénario d’identité Hôtes de session Comptes d’utilisateur
Microsoft Entra ID + AD DS Joint à AD DS Dans Microsoft Entra ID et AD DS, synchronisé
Microsoft Entra ID + AD DS Joint à Microsoft Entra ID Dans Microsoft Entra ID et AD DS, synchronisé
Microsoft Entra ID + Microsoft Entra Domain Services Joint à Microsoft Entra Domain Services dans Microsoft Entra ID et Microsoft Entra Domain Services, synchronisé
Microsoft Entra ID + Microsoft Entra Domain Services + AD DS Joint à Microsoft Entra Domain Services Dans Microsoft Entra ID et AD DS, synchronisé
Microsoft Entra ID + Microsoft Entra Domain Services Joint à Microsoft Entra ID dans Microsoft Entra ID et Microsoft Entra Domain Services, synchronisé
Microsoft Entra-only Joint à Microsoft Entra ID Dans Microsoft Entra ID (y compris les identités externes)

Pour plus d’informations sur les scénarios d’identité pris en charge, y compris l’authentification unique et multifacteur, consultez Identités et méthodes d’authentification prises en charge.

Conteneur de profil FSLogix

Pour utiliser le conteneur de profil FSLogix lorsque vous joignez vos hôtes de session à Microsoft Entra ID, vous devez stocker les profils sur Azure Files ou Azure NetApp Files et vos comptes d’utilisateur doivent être des identités hybrides. Vous devez créer ces comptes dans AD DS et les synchroniser avec Microsoft Entra ID. Pour en savoir plus sur le déploiement du conteneur de profil FSLogix avec différents scénarios d’identité, consultez les articles suivants :

Paramètres de déploiement

Vous devez entrer les paramètres d’identité suivants lors du déploiement d’hôtes de session :

  • Nom de domaine, si vous utilisez AD DS ou Microsoft Entra Domain Services.
  • Informations d’identification pour joindre des hôtes de session au domaine.
  • Unité d’organisation (OU), paramètre facultatif qui vous permet de placer des hôtes de session dans l’unité d’organisation souhaitée au moment du déploiement.

Importante

L’authentification multifacteur (MFA) ne peut pas être activée sur le compte que vous utilisez pour rejoindre un domaine.

Systèmes d’exploitation et licences

Vous avez le choix entre plusieurs systèmes d’exploitation (OS) que vous pouvez utiliser pour les hôtes de session afin de fournir des bureaux et des applications. Vous pouvez utiliser différents systèmes d’exploitation avec différents pools d’hôtes pour offrir de la flexibilité à vos utilisateurs. Nous prenons en charge les systèmes d’exploitation 64 bits et les références SKU répertoriées dans les listes de tableaux suivantes (les versions et les dates prises en charge sont conformes à la politique de cycle de vie Microsoft), ainsi que les méthodes de licence applicables à chaque objectif commercial :

Système d’exploitation
(64 bits uniquement)		 Méthode de licence
(Finalités commerciales internes)		 Méthode de licence
(Fins commerciales externes)
  • Microsoft 365 E3, E5, A3, A5, F3, Business Premium, Student Use Benefit
  • Windows Entreprise E3, E5
  • Windows Éducation A3, A5
  • Windows VDA par utilisateur
 Tarification des accès par utilisateur en inscrivant un abonnement Azure.
  • Services Bureau à distance (RDS) Licence d’accès client (CAL) avec Software Assurance (par utilisateur ou par appareil)
  • Licences d’abonnement utilisateur RDS.
 Non prise en charge. La tarification des accès par utilisateur n’est pas disponible pour les systèmes d’exploitation Windows Server.

Pour en savoir plus sur les licences que vous pouvez utiliser, y compris les tarifs d’accès par utilisateur, consultez Gestion des licences d’Azure Virtual Desktop.

Importante

Pour Azure, vous pouvez utiliser des images de système d’exploitation fournies par Microsoft dans la Place de marché Azure ou créer vos propres images personnalisées stockées dans une galerie de calcul Azure ou en tant qu’image managée. L’utilisation de modèles d’image personnalisés pour Azure Virtual Desktop vous permet de créer facilement une image personnalisée que vous pouvez utiliser lors du déploiement de machines virtuelles hôte de session. Pour en savoir plus sur la création d’images personnalisées, consultez :

Pour Azure Local, vous pouvez également utiliser des images de système d’exploitation à partir de :

Vous pouvez déployer une machine virtuelle à utiliser comme hôte de session à partir de ces images avec l’une des méthodes suivantes :

Si votre licence vous autorise à utiliser Azure Virtual Desktop, vous n’avez pas besoin d’installer ou d’appliquer une licence distincte. Toutefois, si vous utilisez la tarification des accès par utilisateur pour les utilisateurs externes, vous devez inscrire un abonnement Azure. Vous devez vous assurer que la licence Windows utilisée sur vos hôtes de session est correctement attribuée dans Azure et que le système d’exploitation est activé. Pour plus d’informations, consultez Appliquer une licence Windows aux machines virtuelles hôte de session.

Pour les hôtes de session sur Azure Local, vous devez activer et attribuer une licence aux machines virtuelles que vous utilisez avant de les utiliser avec Azure Virtual Desktop. Pour activer Windows 10, Windows 11 Entreprise à sessions multiples et Windows Server 2022 Datacenter : édition Azure, utilisez la vérification Azure pour les machines virtuelles. Pour toutes les autres images de système d’exploitation (telles que Windows 10 et Windows 11 Entreprise, et d’autres éditions de Windows Server), vous devez continuer à utiliser les méthodes d’activation existantes. Pour plus d’informations, consultez Activer des machines virtuelles Windows Server sur Azure Local.

Remarque

Pour garantir la continuité des fonctionnalités avec la dernière mise à jour de sécurité, mettez à jour vos machines virtuelles sur Azure Local vers la dernière mise à jour cumulative avant le 17 juin 2024. Cette mise à jour est essentielle pour que les machines virtuelles continuent à utiliser les avantages d’Azure. Pour plus d’informations, consultez Vérification Azure pour les machines virtuelles.

Conseil

Pour simplifier les droits d’accès utilisateur pendant le développement et les tests initiaux, Azure Virtual Desktop prend en charge la tarification des développements/tests Azure. Si vous déployez Azure Virtual Desktop dans le cadre d’un abonnement Azure Dev/Test, les utilisateurs finaux peuvent se connecter à ce déploiement sans droits de licence distincts afin d’effectuer des tests d’acceptation ou de fournir des commentaires.

Réseau

Vous devez respecter plusieurs exigences réseau pour déployer correctement Azure Virtual Desktop. Cela permet aux utilisateurs de se connecter à leurs bureaux et à leurs applications tout en leur offrant la meilleure expérience utilisateur possible.

Les utilisateurs qui se connectent à Azure Virtual Desktop établissent en toute sécurité une connexion inverse au service, ce qui signifie que vous n’avez pas besoin d’ouvrir de ports entrants. Le protocole TCP (Transmission Control Protocol) sur le port 443 est utilisé par défaut, mais RDP Shortpath peut être utilisé pour les réseaux gérés et les réseaux publics qui établissent un transport direct basé sur le protocole UDP (User Datagram Protocol).

Pour déployer avec succès Azure Virtual Desktop, vous devez répondre aux exigences réseau suivantes :

  • Vous avez besoin d’un réseau virtuel et d’un sous-réseau pour vos hôtes de session. Si vous créez vos hôtes de session en même temps qu’un pool d’hôtes, vous devez créer ce réseau virtuel à l’avance pour qu’il apparaisse dans la liste déroulante. Votre réseau virtuel doit se trouver dans la même région Azure que l’hôte de session.

  • Assurez-vous que ce réseau virtuel peut se connecter à vos contrôleurs de domaine et aux serveurs DNS appropriés si vous utilisez AD DS ou Microsoft Entra Domain Services, car vous devez joindre des hôtes de session au domaine.

  • Vos hôtes de session et utilisateurs doivent pouvoir se connecter au service Azure Virtual Desktop. Ces connexions utilisent également TCP sur le port 443 vers une liste spécifique d’URL. Pour plus d’informations, consultez Liste d’URL obligatoires. Vous devez vous assurer que ces URL ne sont pas bloquées par un filtre réseau ou un pare-feu pour que votre déploiement fonctionne correctement et soit pris en charge. Si vos utilisateurs ont besoin d’accéder à Microsoft 365, assurez-vous que vos hôtes de session peuvent se connecter aux points de terminaison Microsoft 365.

Tenez également compte des points suivants :

  • Vos utilisateurs peuvent avoir besoin d’accéder à des applications et des données hébergées sur différents réseaux. Assurez-vous donc que vos hôtes de session peuvent s’y connecter.

  • La latence aller-retour (RTT) du réseau du client vers la région Azure qui contient les pools d’hôtes doit être inférieure à 150 ms. Pour connaître les emplacements qui présentent la meilleure latence, recherchez l’emplacement souhaité dans les statistiques de latence aller-retour du réseau Azure. Pour optimiser les performances réseau, nous vous recommandons de créer des hôtes de session dans la région Azure la plus proche de vos utilisateurs.

  • Utilisez le Pare-feu Azure pour les déploiements Azure Virtual Desktop afin de verrouiller votre environnement et filtrer le trafic sortant.

  • Pour sécuriser votre environnement de bureau virtuel Azure dans Azure, nous vous recommandons de ne pas ouvrir le port entrant 3389 sur vos hôtes de session. Azure Virtual Desktop ne nécessite pas l’ouverture d’un port entrant ouvert. Si vous devez ouvrir le port 3389 à des fins de dépannage, nous vous recommandons d’utiliser l’accès juste-à-temps aux machines virtuelles. Nous vous recommandons également de ne pas attribuer d’adresse IP publique aux hôtes de votre session.

Pour plus d’informations, consultez Présentation de la connectivité réseau d’Azure Virtual Desktop.

Remarque

Pour assurer la fiabilité et l’évolutivité d’Azure Virtual Desktop, nous agrégeons les modèles de trafic et l’utilisation pour vérifier l’intégrité et les performances du plan de contrôle de l’infrastructure, en case activée. Nous regroupons ces informations à partir de tous les emplacements où se trouve l’infrastructure de service, puis les envoyons à la région États-Unis. Les données envoyées à la région États-Unis incluent des données nettoyées, mais pas des données client. Pour plus d’informations, consultez Emplacements de données pour Azure Virtual Desktop.

Gestion de l’hôte de session

Tenez compte des points suivants lors de la gestion des hôtes de session :

  • N’activez aucune stratégie ou configuration qui désactive Windows Installer. Si vous désactivez Windows Installer, le service ne peut pas installer de mises à jour d’agent sur vos hôtes de session et vos hôtes de session ne fonctionneront pas correctement.

  • Si vous joignez des hôtes de session à un domaine AD DS et que vous souhaitez les gérer à l’aide d’Intune, vous devez configurer Microsoft Entra Connect pour activer la jonction hybride Microsoft Entra.

  • Si vous joignez des hôtes de session à un domaine Microsoft Entra Domain Services, vous ne pouvez pas les gérer à l’aide d’Intune.

  • Si vous utilisez la jointure Microsoft Entra avec Windows Server pour vos hôtes de session, vous ne pouvez pas les inscrire dans Intune, car Windows Server n’est pas pris en charge avec Intune. Vous devez utiliser la jonction hybride Microsoft Entra et la stratégie de groupe à partir d’un domaine Active Directory, ou une stratégie de groupe locale sur chaque hôte de session.

Régions Azure

Vous pouvez déployer des pools hôtes, des espaces de travail et des groupes d’applications dans les régions Azure suivantes. Cette liste de régions est l’endroit où les métadonnées du pool d’hôtes peuvent être stockées lorsque l’étendue du déploiement du pool d’hôtes est géographique.

Emplacement des données pour Azure Virtual Desktop pour obtenir la liste des régions pour le stockage des métadonnées du pool d’hôtes lorsque l’étendue du déploiement du pool d’hôtes est régionale.

Toutefois, les hôtes de session pour les sessions utilisateur peuvent être situés dans n’importe quelle région Azure et localement lorsque vous utilisez Azure Virtual Desktop sur Azure Local, ce qui vous permet de déployer des ressources de calcul à proximité de vos utilisateurs. Pour plus d’informations sur les types de données et les emplacements, consultez Emplacements des données pour Azure Virtual Desktop.

Importante

USA Ouest 3 n’est pas pris en charge pour les pools d’hôtes automatisés (pools d’hôtes qui utilisent la configuration d’hôte de session). En savoir plus sur la configuration de l’hôte de session dans Approches de gestion du pool d’hôtes.

  • Australie Est

  • Canada Centre

  • Canada Est

  • Centre de l’Inde

  • USA Centre

  • Asie Est

  • USA Est

  • USA Est 2

  • Japon Est

  • Japon Ouest

  • USA Centre Nord

  • Europe Nord

  • Nord de l’Afrique du Sud

  • USA Centre Sud

  • Asie Sud-Est

  • Sud du Royaume-Uni

  • Ouest du Royaume-Uni

  • USA Centre Ouest

  • Europe Ouest

  • USA Ouest

  • USA Ouest 2

  • USA Ouest 3

Azure Virtual Desktop est également disponible dans les clouds souverains, tels qu’Azure pour le gouvernement américain et Azure géré par 21Vianet en Chine.

Pour en savoir plus sur l’architecture et la résilience du service Azure Virtual Desktop, consultez Architecture et résilience du service Azure Virtual Desktop.

Connexion à une session à distance

Vos utilisateurs doivent utiliser application Windows ou le client Bureau à distance pour se connecter aux bureaux et aux applications. Vous pouvez vous connecter à partir de :

  • Windows
  • macOS
  • iOS/iPadOS
  • Système d’exploitation Android/Chrome
  • Navigateur web

Pour plus d’informations, voir Prise en main de l’application application Windows pour vous connecter à des appareils et des applications.

Importante

Azure Virtual Desktop ne prend pas en charge les connexions à partir du client Connexions RemoteApp et Bureau à distance (RADC) ou du client Connexion Bureau à distance (MSTSC).

Pour savoir quelles URL les clients utilisent pour se connecter et que vous devez autoriser via les pare-feu et les filtres Internet, consultez la liste des URL obligatoires.

Étapes suivantes

  • Dernière mise à jour :