Attachement d’application dans Azure Virtual Desktop

2025-06-20

App Attach vous permet d’attacher dynamiquement des applications d’un package d’application à une session utilisateur dans Azure Virtual Desktop. Les applications ne sont pas installées localement sur les hôtes de session ou les 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 de votre organization. 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 leur résolution des problèmes.

Voici quelques-uns des principaux avantages de l’attachement d’application :

Les applications sont fournies à l’aide de RemoteApp ou dans le cadre d’une session de bureau. Les autorisations sont appliquées par application et 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 App Attach qui leur sont attribuées.
Le même package d’application peut être utilisé sur plusieurs pools d’hôtes.
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.
Les applications peuvent être mises à niveau vers une nouvelle version d’application avec une nouvelle image disque sans avoir besoin d’une fenêtre de maintenance.
Les utilisateurs peuvent exécuter plusieurs 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é est disponible via Azure Log Analytics.

Vous pouvez utiliser les types de package d’application et les formats de fichier suivants :

Type de package	Formats de fichiers
Bundle MSIX et MSIX	`.msix` `.msixbundle`
Offre groupée Appx et Appx	`.appx` `.appxbundle`
App-V	`.appv`

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 leur résolution des problèmes. MSIX et Appx sont similaires, où la différence main est que MSIX est un sur-ensemble 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.

Microsoft Application Virtualization (App-V) pour Windows fournit des applications Win32 aux utilisateurs en tant qu’applications virtuelles. Les applications virtuelles sont installées sur des serveurs gérés de manière centralisée et remises aux utilisateurs en tant que service en temps réel et selon les besoins. Les utilisateurs lancent des applications virtuelles à partir de points d’accès familiers et interagissent avec elles comme si elles étaient installées localement.

Vous pouvez obtenir des packages MSIX auprès des 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. Lors de 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 pour vous assurer que les ressources matérielles appropriées sont disponibles pour être utilisées par l’application. Par exemple, si une application est gourmande en 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 pour GPU.
L’utilisateur doit être en mesure de 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 App Attach 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 conditions 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 il est possible pour les utilisateurs au sein d’un pool d’hôtes unique ou même connectés au même hôte de session multisession d’obtenir différentes combinaisons d’applications. Les utilisateurs qui ne répondent pas aux exigences n’obtiennent pas l’application.

Images d’application

Avant de pouvoir utiliser des packages d’application MSIX avec Azure Virtual Desktop, vous devez créer une image MSIX à partir de vos packages d’application existants. Vous pouvez également utiliser un package App-V à la place. Vous devez ensuite stocker chaque image MSIX ou package App-V sur un partage de fichiers accessible par vos hôtes de session. Pour plus d’informations sur la configuration requise pour un partage de fichiers, consultez Partage de fichiers.

Types d’images de disque

Pour les images de disque MSIX et Appx, vous pouvez utiliser CimFS (Composite Image File System),VHDX ou VHD, mais nous vous déconseillons d’utiliser le disque dur virtuel. Le montage et le démontage des images CimFS sont plus rapides que les images VHD et VHDX et consomment également moins de processeur et de mémoire. Nous vous recommandons d’utiliser CimFS uniquement 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 .cim de fichier et contient des métadonnées, avec au moins deux autres fichiers, l’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 .cim fichier n’ont pas d’extension de fichier. Le tableau suivant répertorie des exemples de fichiers que vous trouveriez 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 ont été 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.

Métrique	VHD	CimFS
Durée de montage moyenne	356 ms	255 ms
Temps de démontage moyen	1615 ms	36 ms
Consommation de mémoire	6 % (sur 8 Go)	2 % (sur 8 Go)
PROCESSEUR (pic de nombre)	Maxed out plusieurs fois	Aucun effet

Attention

Un problème affecte actuellement les images CimFS avec Windows 11, version 24H2, ce qui empêche le montage des images. Nous travaillons activement sur un correctif qui devrait être disponible en juin 2025. Les solutions de contournement sont d’utiliser des images VHDX à la place ou d’utiliser une version de Windows 11 antérieure à 24H2.

Inscription de l’application

App Attach monte des images disque ou des packages App-V contenant vos applications à partir d’un partage de fichiers vers la session d’un utilisateur lors de la connexion, puis un processus d’inscription met les applications à la disposition de l’utilisateur. Il existe deux types d’inscription :

À 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 à la connexion à Azure Virtual Desktop. À la demande est la méthode d’inscription par défaut.
Blocage de la connexion : chaque application que vous attribuez à un utilisateur est entièrement inscrite. L’inscription se produit lorsque l’utilisateur se connecte à sa session, ce qui peut affecter la durée de connexion à Azure Virtual Desktop.

Importante

Tous les packages d’application MSIX et Appx incluent un certificat. Il vous incombe de 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.

App Attach ne limite pas le nombre d’applications que les utilisateurs peuvent utiliser. Vous devez prendre en compte le débit réseau disponible et le nombre de handles 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 fichiers.

État de l’application

Les packages d’application sont définis comme actifs ou inactifs. Les packages définis sur actifs rendent l’application disponible pour les utilisateurs. Azure Virtual Desktop ignore les packages définis sur inactifs et ne sont pas ajoutés lorsqu’un utilisateur se connecte.

Nouvelles versions des 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 manières :

Côte à côte : créez une application à l’aide de la nouvelle image 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 fini de l’utiliser.

Une fois la mise à jour, les utilisateurs obtiennent la version mise à jour de l’application la prochaine fois qu’ils se connectent. Les utilisateurs n’ont pas besoin d’arrêter d’utiliser la version précédente pour ajouter une nouvelle version.

Fournisseurs d’identité

Voici les fournisseurs d’identité que vous pouvez utiliser avec App Attach :

Fournisseur d’identité	Statut
Identifiant Microsoft Entra	Pris en charge
Services de domaine Active Directory (AD DS) ;	Pris en charge
Microsoft Entra Domain Services	Non pris en charge

App Attach 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 lors de la connexion. App Attach n’a pas de dépendances sur le type d’infrastructure de stockage utilisé par le partage de fichiers. Nous vous recommandons d’utiliser Azure Files, car il est compatible avec Microsoft Entra ID ou services de domaine Active Directory, et offre une grande valeur entre les coûts et les frais de gestion.

Vous pouvez également utiliser Azure NetApp Files, mais cela nécessite que vos hôtes de session soient joints à services de domaine Active Directory.

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 des autorisations NTFS et de partage pour autoriser chaque objet d’ordinateur hôte de session à accéder en lecture aux fichiers et au partage de fichiers. La façon dont vous configurez l’autorisation appropriée dépend du fournisseur de stockage et du fournisseur d’identité que vous utilisez pour votre partage de fichiers et les hôtes de session.

Pour utiliser Azure Files lorsque vos hôtes de session sont joints à Microsoft Entra ID, vous devez attribuer le rôle RBAC (Lecteur et contrôle d’accès en fonction du rôle Azure d’accès aux données) aux principaux de service Azure Virtual Desktop et Fournisseur ARM Azure Virtual Desktop. 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 ou de Microsoft Entra.
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. Dans une prochaine mise à jour, vous n’aurez pas besoin d’affecter le principal de service du fournisseur ARM Azure Virtual Desktop .

Pour plus d’informations sur l’utilisation de Azure Files avec des hôtes de session joints à Microsoft Entra ID, services de domaine Active Directory ou Microsoft Entra Domain Services, consultez Vue d’ensemble de Azure Files options d’authentification basée sur l’identité pour l’accès SMB.

Avertissement

L’affectation du principal de service fournisseur ARM Azure Virtual Desktop au compte de stockage accorde au service Azure Virtual Desktop toutes les données à l’intérieur du compte de stockage. Nous vous recommandons de stocker uniquement les applications à utiliser avec App Attach dans ce compte de stockage et de faire pivoter les clés d’accès régulièrement.
Pour Azure Files avec services de domaine Active Directory, vous devez attribuer le rôle RBAC (Storage File Data Data SMB Share Lecteur) En fonction du rôle Azure comme autorisation par défaut au niveau du partage, et configurer des autorisations NTFS pour accorder un accès en lecture à l’objet ordinateur de l’hôte de chaque session.

Pour plus d’informations sur l’utilisation de Azure Files avec des hôtes de session joints à Microsoft Entra ID, services de domaine Active Directory ou Microsoft Entra Domain Services, consultez Vue d’ensemble de Azure Files options d’authentification basée sur l’identité pour l’accès SMB.
Par 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 à services de domaine Active Directory 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 plus de bande passante. Le tableau suivant fournit un exemple des exigences d’une seule image de 1 Go ou d’un package App-V contenant une application requise par hôte de session :

Resource	Configuration requise
E/S par seconde à état stable	Une 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 :

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 disque contenant vos applications des analyses antivirus, car elles sont en lecture seule.
Assurez-vous que votre infrastructure de stockage et réseau peut fournir des performances adéquates. Vous devez éviter d’utiliser le même partage de fichiers avec les conteneurs de profils FSLogix.

Disponibilité

Tous les plans de récupération d’urgence pour Azure Virtual Desktop doivent inclure la réplication du partage de fichiers 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 continuité d’activité et de récupération d’urgence.

Azure Files

Azure Files limite le nombre de descripteurs ouverts par répertoire racine, répertoire et fichier. 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 handle est ouvert par hôte de session et par image disque, plutôt que par utilisateur. Pour plus d’informations sur les limites et les conseils de dimensionnement, consultez Azure Files objectifs de scalabilité et de performances et Azure Files de dimensionnement 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 App Attach, vous devez vous assurer que l’ensemble de la chaîne de certificats est approuvé 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 publique.
Une entreprise interne ou une autorité de certification autonome, telle que les services de certificats Active Directory. Vous devez exporter le certificat de signature de code, y compris sa clé privée.
Outil tel que l’applet de commande PowerShell New-SelfSignedCertificate qui génère un certificat auto-signé. Vous devez utiliser uniquement 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 le 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 d’un programme d’installation de bureau.

Pour vous assurer que le certificat est approuvé sur vos hôtes de session, vous devez que vos hôtes de session approuvent l’ensemble de la chaîne de certificats. La façon dont vos hôtes de session approuvent la chaîne de certificats dépend de l’emplacement où 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 façon de garantir 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 d’entreprise :
- Pour les hôtes de session joints à Active Directory, avec AD CS configuré en tant qu’autorité de certification d’entreprise interne, sont approuvés par défaut et stockés dans le contexte de nommage de configuration de services de domaine Active Directory. Quand AD CS est configuré en tant qu’autorité de certification autonome, vous devez configurer stratégie de groupe pour distribuer les certificats racine et intermédiaires aux hôtes de session. Pour plus d’informations, consultez Distribuer des certificats à des appareils Windows à l’aide de stratégie de groupe.
- Pour les hôtes de session joints à Microsoft Entra ID, vous pouvez utiliser Microsoft Intune pour distribuer les certificats racine et intermédiaires aux hôtes de session. Pour plus d’informations, consultez Profils de certificat racine approuvés pour Microsoft Intune.
- Pour les hôtes de session utilisant Microsoft Entra jointure hybride, vous pouvez utiliser l’une des méthodes précédentes, en fonction de vos besoins.
Auto-signé : installez la racine approuvée dans le magasin Autorités de certification racines approuvées sur chaque hôte de session. Nous vous déconseillons de distribuer ce certificat à l’aide de stratégie de groupe ou de Intune, car il ne doit être utilisé qu’à des fins de test.

Importante

Vous devez horodater votre package afin que sa validité puisse survivre à la date d’expiration de votre certificat. Sinon, une fois le certificat expiré, vous devez mettre à jour le package avec un nouveau certificat valide et vérifier une fois de plus que les hôtes de session approuvent la chaîne de certificats.

Étapes suivantes

Découvrez comment ajouter et gérer des applications App Attach dans Azure Virtual Desktop.