Partager via

Prérequis pour Azure Virtual Desktop

  • Article

Plusieurs choses sont nécessaires avant de commencer à utiliser Azure Virtual Desktop. Vous trouverez ici les prérequis pour fournir à vos utilisateurs des bureaux et des applications.

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

  • 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
  • Client Bureau à distance

Compte Azure avec un abonnement actif

Vous devez disposer 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 attribuer les rôles Azure de contrôle d'accès en fonction du rôle (RBAC). Les exigences de rôle spécifiques sont abordées dans chacun des articles associés pour le déploiement d’Azure Virtual Desktop, répertoriés dans la section Étapes suivantes.

Assurez-vous également que vous avez enregistré le fournisseur de ressources Microsoft.DesktopVirtualization pour votre abonnement. Pour vérifier le statut du fournisseur de ressources et ’inscrire si nécessaire, sélectionnez l’onglet approprié pour votre scénario et suivez les étapes.

Important

Vous devez être autorisé à inscrire un fournisseur de ressources, ce qui nécessite l’opération */register/action. Cette autorisation est incluse si vous disposez du rôle de contributeur ou de propriétaire 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 l’état est NotRegistered, sélectionnez Microsoft.DesktopVirtualization, puis sélectionnez Inscrire.

  7. Vérifiez que l’état 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 permet de le faire. Les utilisateurs sont toujours authentifiés avec Microsoft Entra ID pour pouvoir utiliser Azure Virtual Desktop. Les hôtes de la session peuvent rejoindre le même locataire Microsoft Entra ou un domaine Active Directory en utilisant Active Directory Domain Services (AD DS) ou 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 fournissant des bureaux 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 ne pouvez joindre des hôtes de session qu’à un domaine Active Directory Domain Services. Vous ne pouvez joindre des hôtes de session sur Azure Local qu’à un domaine Active Directory Domain Services (AD DS). Cela inclut l’utilisation de la jointure hybride Microsoft Entra, où vous pouvez tirer parti 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 :

  • Pour Microsoft Entra ID, vous avez besoin d’un compte capable de joindre des ordinateurs à votre tenant. Si vous souhaitez obtenir plus d’informations, consultez Gérer les identités des appareils. Pour en savoir plus sur la jonction d’hôtes de session à Microsoft Entra ID, consultez Hôtes de session joints à Microsoft Entra.

  • Pour un domaine Active Directory, vous avez besoin d’un compte de domaine qui peut joindre des ordinateurs à votre domaine. Pour Microsoft Entra Domain Services, vous devez être membre du groupe Administrateurs AAD DC.

Utilisateurs

Vos utilisateurs ont besoin de comptes qui se trouvent 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’utilisateur sont synchronisés. Vous devez garder à l’esprit ce qui suit 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é des utilisateurs 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 de Microsoft Entra ID vers Microsoft Entra Domain Services. Ce processus de synchronisation est automatique.

Important

Le compte d’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, B2B ou B2C.

Lorsque vous utilisez des identités hybrides, l’UPN (UserPrincipalName) ou l’identificateur de sécurité (SID) doit correspondre à travers Active Directory Domain Services 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é actuellement pris en charge par Azure Virtual Desktop :

Scénario d’identité Hôtes de session Comptes d’utilisateur
Microsoft Entra ID + AD DS Joints à 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 uniquement Joint à Microsoft Entra ID Dans Microsoft Entra ID

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

Conteneur de profil FSLogix

Pour utiliser FSLogix Profile Container lors de la connexion de vos hôtes de la session à Microsoft Entra ID, vous devez stocker les profils sur Azure Files ou Azure NetApp Files et vos comptes d’utilisateurs 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 d’un conteneur de profils 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 la session :

  • Le 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 (UO), qui est un paramètre facultatif vous permettant de placer des hôtes de session dans l’UO désirée au moment du déploiement.

Important

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

Systèmes d’exploitation et licences

Vous avez le choix entre plusieurs systèmes d’exploitation (OS) pour permettre aux hôtes de session 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 et références SKU 64 bits dans les listes suivantes (où les versions et dates prises en charge sont inline avec 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 gestion des licences
(Objectifs commerciaux internes)		 Méthode de gestion des licences
(Objectifs commerciaux externes)
  • Microsoft 365 E3, E5, A3, A5, F3, Business Premium, Student Use Benefit
  • Windows Entreprise E3, E5
  • Windows Éducation A3, A5
  • VDA Windows par utilisateur
  • Licence d’accès client (CAL) des services Bureau à distance (RDS) avec Software Assurance (par utilisateur ou par appareil)
  • Licences d’abonnement utilisateur RDS.
  • Licence d’accès aux abonnés (SAL) Bureau à distance (RDS) Windows Server.

Latarification de l’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, notamment la tarification par utilisateur, consultez Licences Azure Virtual Desktop.

Important

Pour Azure, vous pouvez utiliser les 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 Azure Compute Gallery, en tant qu’image managée. Les modèles d’images personnalisées dans Azure Virtual Desktop vous permettent de créer facilement une image personnalisée que vous pouvez utiliser lors du déploiement de machines virtuelles hôtes 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 des machines virtuelles à utiliser comme hôtes 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 de l’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 la 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ôtes de session.

Pour les hôtes de session sur Azure Local, vous devez obtenir une licence et activer les machines virtuelles que vous utilisez avant de les utiliser avec Azure Virtual Desktop. Pour activer Windows 10 et Windows 11 Enterprise multisession, et Windows Server 2022 Datacenter : Azure Edition, utilisez la vérification Azure pour les machines virtuelles. Pour toutes les autres images de système d'exploitation (comme Windows 10 et Windows 11 Enterprise, 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 veiller à une fonctionnalité continue avec le dernier correctif 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 indispensable pour que les machines virtuelles continuent à utiliser les avantages Azure. Pour obtenir plus d’informations, consultez Vérification Azure pour les machines virtuelles.

Conseil

Pour simplifier les droits d’accès utilisateur pendant les phases initiales de développement et de test, Azure Virtual Desktop prend en charge les tarifs Azure Dev/Test. Si vous déployez Azure Virtual Desktop dans un abonnement Azure Dev/Test, il se peut que les utilisateurs finaux se connectent à ce déploiement sans droits de licence distinct afin d’effectuer des tests d’acceptation ou de fournir des commentaires.

Réseau

Pour déployer correctement Azure Virtual Desktop, vous devez respecter plusieurs exigences relatives au réseau. Les utilisateurs peuvent alors se connecter à leurs bureaux et applications, mais aussi bénéficier de la meilleure expérience utilisateur possible.

Les utilisateurs qui se connectent à Azure Virtual Desktop établissent en toute sécurité une connexion inversée 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 managés et les réseaux publics qui établissent un transport UDP (User Datagram Protocol) direct.

Pour déployer correctement Azure Virtual Desktop, vous devez respecter les exigences réseau suivantes :

  • Vous avez besoin d’un réseau virtuel et d’un sous-réseau pour vos hôtes de la 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.

  • Vérifiez 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 les hôtes de la session au domaine.

  • Vos hôtes de session et vos 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 des URL requises. Vous devez vérifier que ces URL ne sont pas bloquées par un filtrage 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, vérifiez que vos hôtes de session peuvent se connecter aux points de terminaison Microsoft 365.

Tenez également compte des éléments suivants :

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

  • La latence aller-retour entre le réseau du client et la région Azure qui contient les pools d’hôtes doit être inférieure à 150 ms. Pour voir quels emplacements présentent la meilleure latence, recherchez celui de votre choix dans Statistiques de latence aller-retour 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 pour faciliter le verrouillage de votre environnement et le filtrage du trafic sortant.

  • Pour contribuer à sécuriser votre environnement Azure Virtual Desktop dans Azure, nous vous recommandons de ne pas ouvrir le port entrant 3389 sur vos hôtes de la session. Azure Virtual Desktop ne nécessite pas un port entrant pour être ouvert. Si vous devez ouvrir le port 3389 pour résoudre des problèmes, nous vous recommandons d’utiliser un accès à la machine virtuelle juste-à-temps. Nous vous recommandons également de ne pas attribuer d’adresse IP publique à vos hôtes de la session.

Pour en savoir plus, consultez Comprendre la connectivité réseau d’Azure Virtual Desktop.

Remarque

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

Gestion des hôtes de session

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

  • Ne pas activer de stratégie ou de configuration désactivant Windows Installer. Si vous désactivez Windows Installer, le service ne peut pas installer les mises à jour de l’agent sur vos hôtes de la session, et vos hôtes de session ne fonctionnent pas correctement.

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

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

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

Régions Azure

Vous pouvez déployer des pools d’hôtes, des espaces de travail et des groupes d’applications dans les régions Azure suivantes. Cette liste de régions est l’emplacement où les métadonnées du pool d’hôtes peuvent être stockées. Toutefois, les hôtes de session pour les sessions utilisateur peuvent se trouver dans n’importe quelle région Azure et localement lors de l’utilisation d’Azure Virtual Desktop sur Azure Local, ce qui vous permet de déployer des ressources de calcul proches de vos utilisateurs. Pour plus d’informations sur les types de données et les emplacements, consultez Emplacements de données pour Azure Virtual Desktop.

  • Australie Est
  • Centre du Canada
  • Est du Canada
  • Inde centrale
  • USA Centre
  • USA Est
  • USA Est 2
  • Japon Est
  • Centre-Nord des États-Unis
  • Europe Nord
  • États-Unis - partie centrale méridionale
  • Sud du Royaume-Uni
  • Ouest du Royaume-Uni
  • Centre-USA Ouest
  • Europe Ouest
  • USA Ouest
  • USA Ouest 2
  • USA Ouest 3

Azure Virtual Desktop est également disponible dans des clouds souverains, tels que Azure pour le gouvernement des États-Unis 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 l’architecture et la résilience du service Azure Virtual Desktop.

Clients Bureau à distance

Vos utilisateurs ont besoin d’un client Bureau à distance pour se connecter à des bureaux et à des applications. Les clients suivants prennent en charge Azure Virtual Desktop :

Important

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

Pour connaître les URL que les clients utilisent pour se connecter et que vous devez autoriser via les pare-feux et les filtres Internet, consultez la liste des URL requises.

Étapes suivantes