Attachement d’application et attachement d’application MSIX dans Azure Virtual Desktop
Il existe deux fonctionnalités dans Azure Virtual Desktop qui vous permettent d’attacher dynamiquement des applications à partir d’un package d’application à une session utilisateur dans Azure Virtual Desktop : l’attachement d’application et l’attachement d’application MSIX. Avec l’attachement d’application et l’attachement d’application MSIX, les applications ne sont pas installées localement sur des hôtes de session ou des images, ce qui facilite la création d’images personnalisées pour vos hôtes de session et réduit la surcharge opérationnelle et les coûts pour votre organisation. Les applications s’exécutent dans des conteneurs, qui séparent les données utilisateur, le système d’exploitation et d’autres applications, ce qui augmente la sécurité et facilite la résolution des problèmes.
Le tableau suivant compare l’attachement d’application MSIX et l’attachement d’application :
| Attachement d’application MSIX | Attachement d’application |
|---|---|
| Les applications sont fournies à l’aide de RemoteApp ou dans le cadre d’une session de bureau. Les autorisations sont contrôlées par l’affectation à des groupes d’applications, mais tous les utilisateurs de bureau voient toutes les applications d’attachement d’application MSIX dans le groupe d’applications de bureau. | Les applications sont fournies à l’aide de RemoteApp ou dans le cadre d’une session de bureau. Les autorisations sont appliquées par application par utilisateur, ce qui vous permet de mieux contrôler les applications auxquelles vos utilisateurs peuvent accéder dans une session à distance. Les utilisateurs de bureau voient uniquement les applications d’attachement d’application qui leur sont affectées. |
| Les applications peuvent s’exécuter uniquement sur un pool d’hôtes. Si vous souhaitez qu’elles s’exécutent sur un autre pool d’hôtes, vous devez créer un autre package. | Le même package d’application peut être utilisé sur plusieurs pools d’hôtes. |
| Les applications peuvent uniquement s’exécuter sur le pool d’hôtes dans lequel elles sont ajoutées. | Les applications peuvent s’exécuter sur n’importe quel hôte de session exécutant un système d’exploitation client Windows dans la même région Azure que le package d’application. |
| Pour mettre à jour l’application, vous devez supprimer et recréer l’application avec une autre version du package. Vous devez mettre à jour l’application dans une fenêtre de maintenance. | Les applications peuvent être mises à niveau vers une nouvelle version d’application avec une nouvelle image de disque sans qu’une fenêtre de maintenance soit nécessaire. |
| Les utilisateurs ne peuvent pas exécuter deux versions de la même application sur le même hôte de session. | Les utilisateurs peuvent exécuter deux versions de la même application simultanément sur le même hôte de session. |
| La télémétrie pour l’utilisation et l’intégrité n’est pas disponible via Azure Log Analytics. | La télémétrie pour l’utilisation et l’intégrité est disponible via Azure Log Analytics. |
Vous pouvez utiliser les types de package d’application et les formats de fichiers suivants :
| Type de package | Formats de fichier | Disponibilité des fonctionnalités |
|---|---|---|
| Offre groupée MSIX et MSIX | .msix.msixbundle |
Attachement d’application MSIX Attachement d’application |
| Offre groupée Appx et Appx | .appx.appxbundle |
Attachement d’application uniquement |
MSIX et Appx sont des formats de package d’application Windows qui fournissent une expérience d’empaquetage moderne aux applications Windows. Les applications s’exécutent dans des conteneurs, qui séparent les données utilisateur, le système d’exploitation et d’autres applications, ce qui augmente la sécurité et facilite la résolution des problèmes. MSIX et Appx sont similaires, la principale différence étant que MSIX est un surensemble d’Appx. MSIX prend en charge toutes les fonctionnalités d’Appx, ainsi que d’autres fonctionnalités qui le rendent plus adapté à une utilisation en entreprise.
Conseil
Sélectionnez un bouton en haut de cet article pour choisir entre l’attachement d’application et l’attachement d’application MSIX pour afficher la documentation pertinente.
Vous pouvez obtenir des packages MSIX à partir de fournisseurs de logiciels, ou vous pouvez créer un package MSIX à partir d’un programme d’installation existant. Pour en savoir plus sur MSIX, consultez Qu’est-ce que MSIX ?
Comment un utilisateur obtient une application
Vous pouvez affecter différentes applications à différents utilisateurs dans le même pool d’hôtes ou sur le même hôte de session. Pendant la connexion, les trois conditions suivantes doivent être remplies pour que l’utilisateur obtienne l’application appropriée au bon moment :
L’application doit être affectée au pool d’hôtes. L’affectation de l’application au pool d’hôtes vous permet d’être sélectif quant aux pools d’hôtes sur lesquels l’application est disponible afin de garantir que les ressources matérielles appropriées sont disponibles pour l’utilisation de l’application. Par exemple, si une application est gourmande en ressources graphiques, vous pouvez vous assurer qu’elle s’exécute uniquement sur un pool d’hôtes avec des hôtes de session optimisés par GPU.
L’utilisateur doit pouvoir se connecter aux hôtes de session dans le pool d’hôtes. Il doit donc se trouver dans un groupe d’applications Bureau ou RemoteApp. Pour un groupe d’applications RemoteApp, l’application d’attachement d’application doit être ajoutée au groupe d’applications, mais vous n’avez pas besoin d’ajouter l’application à un groupe d’applications de bureau.
L’application doit être affectée à l’utilisateur. Vous pouvez utiliser un groupe ou un compte d’utilisateur.
Si toutes ces exigences sont remplies, l’utilisateur obtient l’application. Ce processus permet de contrôler qui obtient une application sur quel pool d’hôtes et comment les utilisateurs d’un même pool d’hôtes ou même connectés à un même hôte de session multisession peuvent obtenir différentes combinaisons d’applications. Les utilisateurs qui ne répondent pas aux exigences ne reçoivent pas l’application.
Comment un utilisateur obtient une application
Vous pouvez affecter différentes applications à différents utilisateurs dans le même pool d’hôtes. Avec l’attachement d’application MSIX, vous ajoutez des packages MSIX à un pool d’hôtes et contrôlez l’affectation des applications à l’aide de groupes d’applications Bureau ou RemoteApp. Pendant la connexion, les conditions suivantes doivent être remplies pour que l’utilisateur obtienne l’application appropriée au bon moment :
L’utilisateur doit pouvoir se connecter aux hôtes de session dans le pool d’hôtes. Il doit donc se trouver dans un groupe d’applications Bureau ou RemoteApp.
L’image MSIX doit être ajoutée au pool d’hôtes.
Si ces exigences sont remplies, l’utilisateur obtient l’application. L’affectation d’applications à l’aide d’un groupe d’applications de bureau les ajoute au menu Démarrer de l’utilisateur. Les utilisateurs qui ne répondent pas aux exigences ne reçoivent pas l’application.
Images d’application
Avant de pouvoir utiliser vos packages d’application avec Azure Virtual Desktop, vous devez Créer une image MSIX à partir de vos packages d’application existants à l’aide de l’outil MSIXMGR. Vous devez ensuite stocker chaque image de disque sur un partage de fichiers accessible par vos hôtes de session. Pour plus d’informations sur les conditions requise pour un partage de fichiers, consultez Partage de fichiers.
Types d’images de disque
Vous pouvez utiliser CimFS (Composite Image File System), VHDX ou VHD pour les images de disque, mais nous vous déconseillons d’utiliser VHD. Le montage et le démontage des images CimFS sont plus rapides que les fichiers VHD et VHDX et consomment également moins de processeur et de mémoire. Nous vous recommandons uniquement d’utiliser CimFS pour vos images d’application si vos hôtes de session exécutent Windows 11.
Une image CimFS est une combinaison de plusieurs fichiers : un fichier a l’extension de fichier .cim et contient des métadonnées, ainsi qu’au moins deux autres fichiers, un commençant par objectid_ et l’autre commençant par region_ qui contiennent les données d’application réelles. Les fichiers qui accompagnent le fichier .cim n’ont pas d’extension de fichier. Le tableau suivant répertorie des exemples de fichiers que vous pourriez trouver pour une image CimFS :
| Nom de fichier | Taille |
|---|---|
MyApp.cim |
1 Ko |
objectid_b5742e0b-1b98-40b3-94a6-9cb96f497e56_0 |
27 ko |
objectid_b5742e0b-1b98-40b3-94a6-9cb96f497e56_1 |
20 Ko |
objectid_b5742e0b-1b98-40b3-94a6-9cb96f497e56_2 |
42 ko |
region_b5742e0b-1b98-40b3-94a6-9cb96f497e56_0 |
428 ko |
region_b5742e0b-1b98-40b3-94a6-9cb96f497e56_1 |
217 ko |
region_b5742e0b-1b98-40b3-94a6-9cb96f497e56_2 |
264 132 ko |
Le tableau suivant est une comparaison des performances entre VHDX et CimFS. Ces nombres sont le résultat d’une série de tests avec 500 fichiers de 300 Mo chacun par format et les tests ont été effectués sur une machine virtuelle Azure DSv4.
| Mesure | Disque dur virtuel (VHD) | CimFS |
|---|---|---|
| Temps de montage moyen | 356 ms | 255 ms |
| Temps de démontage moyen | 1615 ms | 36 ms |
| Consommation de mémoire | 6 % (de 8 Go) | 2 % (de 8 Go) |
| UC (nombre de pics d’utilisation) | Maximum atteint plusieurs fois | Aucun effet |
Inscription de l’application
L’attachement d’application monte des images de disque contenant vos applications à partir d’un partage de fichiers vers la session d’un utilisateur pendant la connexion, puis un processus d’inscription rend les applications accessibles à l’utilisateur. Il existe deux types d’inscriptions :
L’attachement d’application MSIX monte des images de disque contenant vos applications à partir d’un partage de fichiers vers la session d’un utilisateur lors de la connexion, puis un processus d’inscription rend les applications accessibles à l’utilisateur. Il existe deux types d’inscriptions :
À la demande : les applications ne sont que partiellement inscrites lors de la connexion et l’inscription complète d’une application est reportée jusqu’à ce que l’utilisateur démarre l’application. À la demande est le type d’inscription que nous vous recommandons d’utiliser, car il n’affecte pas le temps nécessaire pour se connecter à Azure Virtual Desktop. À la demande est la méthode d’inscription par défaut.
Blocage de la connexion : chaque application que vous affectez à un utilisateur est entièrement inscrite. L’inscription se produit lorsque l’utilisateur se connecte à sa session, ce qui peut affecter le temps de connexion à Azure Virtual Desktop.
Important
Tous les packages d’application MSIX et Appx incluent un certificat. Vous devez vous assurer que les certificats sont approuvés dans votre environnement. Les certificats auto-signés sont pris en charge avec la chaîne d’approbation appropriée.
L’attachement d’application ne limite pas le nombre d’applications que les utilisateurs peuvent utiliser. Vous devez prendre en compte votre débit réseau disponible et le nombre de descripteurs ouverts par fichier (chaque image) que votre partage de fichiers prend en charge, car cela peut limiter le nombre d’utilisateurs ou d’applications que vous pouvez prendre en charge. Pour plus d’informations, consultez Partage de fichier.
Important
Tous les packages d’application MSIX incluent un certificat. Vous devez vous assurer que les certificats sont approuvés dans votre environnement. Les certificats auto-signés sont pris en charge.
L’attachement d’application MSIX ne limite pas le nombre d’applications que les utilisateurs peuvent utiliser. Vous devez prendre en compte votre débit réseau disponible et le nombre de descripteurs ouverts par fichier (chaque image) que votre partage de fichiers prend en charge, car cela peut limiter le nombre d’utilisateurs ou d’applications que vous pouvez prendre en charge. Pour plus d’informations, consultez Partage de fichier.
État de l’application
Un package MSIX et Appx est défini comme actif ou inactif. Les packages définis sur actifs rendent l’application accessible aux utilisateurs. Les packages définis sur inactifs sont ignorés par Azure Virtual Desktop et ne sont pas ajoutés lorsqu’un utilisateur se connecte.
Un package MSIX est défini comme actif ou inactif. Les packages MSIX définis sur actif rendent l’application disponible pour les utilisateurs. Les packages MSIX définis sur inactifs sont ignorés par Azure Virtual Desktop et ne sont pas ajoutés lorsqu’un utilisateur se connecte.
Nouvelles versions d’applications
Vous pouvez ajouter une nouvelle version d’une application en fournissant une nouvelle image contenant l’application mise à jour. Vous pouvez utiliser cette nouvelle image de deux façons :
Côte à côte : créez une application à l’aide de la nouvelle image de disque et affectez-la aux mêmes pools d’hôtes et utilisateurs que l’application existante.
Sur place : créez une image où le numéro de version de l’application change, puis mettez à jour l’application existante pour utiliser la nouvelle image. Le numéro de version peut être supérieur ou inférieur, mais vous ne pouvez pas mettre à jour une application avec le même numéro de version. Ne supprimez pas l’image existante tant que tous les utilisateurs n’ont pas terminé de l’utiliser.
Une fois la mise à jour effectuée, les utilisateurs obtiendront la version actualisée de l’application lors de leur prochaine connexion. Les utilisateurs n’ont pas besoin de cesser d’utiliser la version précédente pour ajouter une nouvelle version.
Nouvelles versions d’applications
Avec l’attachement d’application MSIX, vous devez supprimer le package d’application, puis créer une application à l’aide de la nouvelle image de disque et l’affecter aux mêmes pools d’hôtes. Vous ne pouvez pas mettre à jour sur place comme vous pouvez le faire avec l’attachement d’application. Les utilisateurs obtiennent la nouvelle image avec l’application mise à jour la prochaine fois qu’ils se connectent. Vous devez effectuer ces tâches pendant une fenêtre de maintenance.
Fournisseurs d’identité
Voici les fournisseurs d’identité que vous pouvez utiliser avec l’attachement d’application :
| Fournisseur d’identité | État |
|---|---|
| Microsoft Entra ID | Prise en charge |
| Active Directory Domain Services (AD DS) | Prise en charge |
| Microsoft Entra Domain Services | Non pris en charge |
Voici les fournisseurs d’identité que vous pouvez utiliser avec l’attachement d’application MSIX :
| Fournisseur d’identité | État |
|---|---|
| Microsoft Entra ID | Non pris en charge |
| Active Directory Domain Services (AD DS) | Prise en charge |
| Microsoft Entra Domain Services (Azure AD DS) | Non pris en charge |
Partage de fichiers
L’attachement d’application nécessite que vos images d’application soient stockées sur un partage de fichiers SMB, qui est ensuite monté sur chaque hôte de session pendant la connexion. L’attachement d’application n’a pas de dépendances par rapport au type d’infrastructure de stockage utilisé par le partage de fichiers. Nous vous recommandons d’utiliser Azure Files étant donné qu’il est compatible avec Microsoft Entra ID ou Active Directory Domain Services, et qu’il offre une grande valeur ajoutée en termes de coûts et de surcharge de gestion.
Vous pouvez également utiliser Azure NetApp Files, mais cela nécessite que vos hôtes de session soient joints à Active Directory Domain Services.
L’attachement d’application MSIX nécessite que vos images d’application soient stockées sur un partage de fichiers SMB version 3, qui est ensuite monté sur chaque hôte de session pendant la connexion. L’attachement d’application MSIX n’a pas de dépendances par rapport au type d’infrastructure de stockage utilisé par le partage de fichiers. Nous vous recommandons d’utiliser Azure Files étant donné qu’il est compatible avec les fournisseurs d’identité pris en charge que vous pouvez utiliser pour l’attachement d’application MSIX et qu’il offre une grande valeur ajoutée en termes de coûts et de surcharge de gestion. Vous pouvez également utiliser Azure NetApp Files, mais cela nécessite que vos hôtes de session soient joints à Active Directory Domain Services.
Les sections suivantes fournissent des conseils sur les autorisations, les performances et la disponibilité requises pour le partage de fichiers.
Autorisations
Chaque hôte de session monte des images d’application à partir du partage de fichiers. Vous devez configurer les autorisations NTFS et de partage pour permettre à chaque objet de l’ordinateur hôte de la session d’accéder en lecture aux fichiers et au partage de fichiers. La manière dont vous configurez les autorisations correctes dépend du fournisseur de stockage et du fournisseur d’identité que vous utilisez pour votre partage de fichiers et vos hôtes de session.
Pour utiliser Azure Files lorsque vos hôtes de session sont joints à Microsoft Entra ID, vous devez affecter le rôle de contrôle d’accès en fonction du rôle Azure (RBAC) Lecteur et accès aux données aux principaux de service Azure Virtual Desktop et Azure Virtual Desktop ARM Provider. Cette attribution de rôle RBAC permet à vos hôtes de session d’accéder au compte de stockage à l’aide de clés d’accès. Le compte de stockage doit se trouver dans le même abonnement Azure que vos hôtes de session. Pour savoir comment attribuer un rôle RBAC Azure aux principaux de service Azure Virtual Desktop, consultez Attribuer des rôles RBAC aux principaux de service Azure Virtual Desktop.
Pour plus d’informations sur l’utilisation d’Azure Files avec des hôtes de session joints à Microsoft Entra ID, Active Directory Domain Services ou Microsoft Entra Domain Services, consultez Vue d’ensemble des options d’authentification basées sur les identités Azure Files pour l’accès SMB.
Avertissement
L’attribution du principal de serviceAzure Virtual Desktop ARM Provider au compte de stockage permet au service Azure Virtual Desktop d’accéder à toutes les données contenues dans le compte de stockage. Nous vous recommandons de stocker uniquement les applications à utiliser avec l’attachement d’application dans ce compte de stockage et de faire pivoter régulièrement les clés d’accès.
Pour Azure Files avec Active Directory Domain Services, vous devez attribuer le rôle de contrôle d’accès en fonction du rôle (RBAC) Azure Lecteur de partage SMB de données de fichier de stockage en tant qu’autorisation de niveau partage par défaut et configurer les autorisations NTFS pour accorder l’accès en lecture à l’objet ordinateur de chaque hôte de session.
Pour plus d’informations sur l’utilisation d’Azure Files avec des hôtes de session joints à Microsoft Entra ID, Active Directory Domain Services ou Microsoft Entra Domain Services, consultez Vue d’ensemble des options d’authentification basées sur les identités Azure Files pour l’accès SMB.
Pour Azure Files avec Active Directory Domain Services, vous devez attribuer le rôle de contrôle d’accès en fonction du rôle (RBAC) Azure Lecteur de partage SMB de données de fichier de stockage en tant qu’autorisation de niveau partage par défaut et configurer les autorisations NTFS pour accorder l’accès en lecture à l’objet ordinateur de chaque hôte de session.
Pour plus d’informations sur l’utilisation d’Azure Files avec des hôtes de session joints à Active Directory Domain Services ou Microsoft Entra Domain Services, consultez Vue d’ensemble des options d’authentification basées sur les identités Azure Files pour l’accès SMB.
- Pour Azure NetApp Files, vous pouvez créer un volume SMB et configurer des autorisations NTFS pour accorder un accès en lecture à l’objet ordinateur de chaque hôte de session. Vos hôtes de session doivent être joints à Active Directory Domain Services ou à Microsoft Entra Domain Services.
Vous pouvez vérifier que les autorisations sont correctes à l’aide de PsExec. Pour plus d’informations, consultez Vérifier l’accès au partage de fichiers.
Performances
Les exigences peuvent varier considérablement en fonction du nombre d’applications empaquetées stockées dans une image et vous devez tester vos applications pour comprendre vos besoins. Pour les images plus volumineuses, vous devez allouer davantage de bande passante. Le tableau suivant donne un exemple des exigences requises pour une image MSIX de 1 Go contenant une application par hôte de session :
| Ressource | Conditions requises |
|---|---|
| E/S par seconde d’état stable | Une seule IOP |
| Connexion au démarrage de l’ordinateur | 10 E/S par seconde |
| Latence | 400 ms |
Pour optimiser les performances de vos applications, nous vous recommandons de :
Votre partage de fichiers doit se trouver dans la même région Azure que vos hôtes de session. Si vous utilisez Azure Files, votre compte de stockage doit se trouver dans la même région Azure que vos hôtes de session.
Excluez les images de disque contenant vos applications des analyses antivirus, car elles sont en lecture seule.
Assurez-vous que votre infrastructure de stockage et de réseau peut fournir des performances adéquates. Vous devez éviter d’utiliser le même partage de fichiers avec les conteneurs de profil FSLogix.
Disponibilité
Tout plan de récupération d’urgence pour Azure Virtual Desktop doit inclure la réplication du partage de fichiers d’attachement d’application MSIX vers votre emplacement de basculement secondaire. Vous devez également vous assurer que votre chemin de partage de fichiers est accessible à l’emplacement secondaire. Par exemple, vous pouvez utiliser des espaces de noms DFS (Distributed File System) avec Azure Files pour fournir un nom de partage unique sur différents partages de fichiers. Pour en savoir plus sur la récupération d’urgence pour Azure Virtual Desktop, consultez Configurer un plan de récupération d’urgence et de continuité d’activité.
Azure Files
Azure Files a des limites sur le nombre de descripteurs ouverts par répertoire racine, répertoire et fichier. Lorsque vous utilisez l’attachement d’application ou l’attachement d’application MSIX, les images de disque VHDX ou CimFS sont montées à l’aide du compte d’ordinateur de l’hôte de session, ce qui signifie qu’un descripteur est ouvert par hôte de session par image de disque, plutôt que par utilisateur. Pour obtenir plus d’informations sur les limites et des conseils sur le dimensionnement, consultez Objectifs de scalabilité et de performance Azure Files et Instructions relatives au dimensionnement Azure Files pour Azure Virtual Desktop.
Certificats de package MSIX et Appx
Tous les packages MSIX et Appx nécessitent un certificat de signature de code valide. Pour utiliser ces packages avec l’attachement d’application, vous devez vous assurer que toute la chaîne de certificats est approuvée sur vos hôtes de session. Un certificat de signature de code a l’identificateur d’objet 1.3.6.1.5.5.7.3.3. Vous pouvez obtenir un certificat de signature de code pour vos packages à partir de :
Une autorité de certification (CA) publique.
Une autorité de certification autonome ou interne à l’entreprise, telle que les services de certificats Active Directory. Vous devez exporter le certificat de signature de code, y compris sa clé privée.
Un outil tel que l’applet de commande PowerShell New-SelfSignedCertificate, qui génère un certificat auto-signé. Vous devez uniquement utiliser des certificats auto-signés dans un environnement de test. Pour plus d’informations sur la création d’un certificat auto-signé pour les packages MSIX et Appx, consultez Créer un certificat pour la signature de package.
Une fois que vous avez obtenu un certificat, vous devez signer numériquement vos packages MSIX ou Appx avec ce certificat. Vous pouvez utiliser MSIX Packaging Tool pour signer vos packages lorsque vous créez un package MSIX. Pour plus d’informations, consultez Créer un package MSIX à partir de n’importe quel programme d’installation de bureau.
Pour vous assurer que le certificat est approuvé sur vos hôtes de session, il faut que vos hôtes de session approuvent toute la chaîne de certificats. La façon de procéder dépend de l’emplacement à partir duquel vous avez obtenu le certificat et de la façon dont vous gérez vos hôtes de session et le fournisseur d’identité que vous utilisez. Le tableau suivant fournit des conseils sur la manière dont vous pouvez vous assurer que le certificat est approuvé sur vos hôtes de session :
Autorité de certification publique : les certificats d’une autorité de certification publique sont approuvés par défaut dans Windows et Windows Server.
Autorité de certification interne à l’entreprise :
les hôtes de session joints à Active Directory, avec AD CS configuré comme autorité de certification interne à l’entreprise, sont approuvés par défaut et stockés dans le contexte de nommage de configuration d’Active Directory Domain Services. Quand AD CS est configuré en tant qu’autorité de certification autonome, vous devez configurer la stratégie de groupe pour distribuer les certificats racines et intermédiaires aux hôtes de session. Pour plus d’informations, consultez Distribuer des certificats sur des appareils Windows en utilisant une stratégie de groupe.
Pour les hôtes de session joints à Microsoft Entra ID, vous pouvez utiliser Microsoft Intune pour distribuer les certificats racines et intermédiaires aux hôtes de session. Pour plus d’informations, consultez Profils de certificat racine approuvé pour Microsoft Intune.
Pour les hôtes de session utilisant la jonction hybride Microsoft Entra, vous pouvez utiliser l’une des méthodes précédentes selon vos besoins.
Auto-signé : installez le certificat racine approuvé dans le magasin des Autorités de certification racines de confiance sur chaque hôte de session. Nous vous déconseillons de distribuer ce certificat à l’aide d’une stratégie de groupe ou d’Intune, car il ne doit être utilisé que pour les tests.
Important
Vous devez appliquer un timestamp à votre package pour que sa validité dépasse la date d’expiration de votre certificat. Sinon, une fois le certificat expiré, vous devez mettre à jour le package avec un nouveau certificat valide, puis vérifier à nouveau qu’il est approuvé sur vos hôtes de session.
Étapes suivantes
Découvrez comment Ajouter et gérer des applications d’attachement d’application dans Azure Virtual Desktop.