Attachement d’application dans Azure Virtual Desktop

L’attachement d’application vous permet d’attacher dynamiquement des applications à partir 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 les frais généraux et coûts opérationnels 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 leur dépannage.

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 par utilisateur, ce qui vous donne un meilleur contrôle sur les applications auxquelles vos utilisateurs peuvent accéder dans une session à distance. Les utilisateurs de bureau ne voient que les applications d’attachement d’application qui leur sont affecté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 client Windows ou un système d’exploitation Windows Server pris en charge 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 sur l’utilisation et la santé est disponible via Azure Log Analytics.

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

MSIX et Appx sont des formats de packages d’applications Windows qui offrent une expérience de packaging 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 dépannage. MSIX et Appx sont similaires, la principale différence étant 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 sous forme d’applications virtuelles. Les applications virtuelles sont installées sur des serveurs centralisés et proposées en tant que service aux utilisateurs en temps réel et en fonction des besoins. Les utilisateurs lancent les 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 d’un fournisseur de logiciels ou créer un package MSIX à partir d’un programme d’installation existant. Pour en savoir plus sur MSIX, voir 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. Au moment de la connexion, les trois conditions suivantes doivent être remplies pour que l’utilisateur obtienne la bonne application 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 de sélectionner les pools d’hôtes sur lesquels l’application est disponible afin de vous assurer que les ressources matérielles appropriées sont disponibles pour l’application. Par exemple, si une application utilise de nombreuses ressources graphiques, vous pouvez vous assurer qu’elle ne s’exécute que sur un pool d’hôtes avec des hôtes de session optimisés pour le 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 Desktop 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 attribuée à l’utilisateur. Vous pouvez utiliser un compte de groupe ou 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 d’un seul pool d’hôtes 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 ne reçoivent 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 dans un partage de fichiers accessible par vos hôtes de session. Pour plus d’informations sur la configuration requise pour un partage de fichiers, voir Partage de fichiers.

Types d’image 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 VHD. 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 de fichier et contient des .cim métadonnées, ainsi qu’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 les fichiers d’exemple que vous trouverez pour une image CimFS :

Le tableau suivant est une comparaison des performances entre VHDX et CimFS. Ces numéros 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.

Inscription de l’application

L’attachement d’application 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 enregistrées à 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 méthode d’inscription à la demande est par défaut.

• Blocage de l’ouverture de session : chaque application que vous attribuez à un utilisateur est entièrement enregistrée. L’inscription se produit pendant que l’utilisateur se connecte à sa session, ce qui peut affecter le délai de connexion à Azure Virtual Desktop.

L’attachement d’application 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) pris en charge par votre partage de fichiers, car cela peut limiter le nombre d’utilisateurs ou d’applications que vous pouvez prendre en charge. Pour plus d’informations, voir Partage de fichiers.

État de l’application

Les packages d’application sont définis comme étant actifs ou inactifs. Les packages activés rendent l’application disponible pour les utilisateurs. Azure Virtual Desktop ignore les packages définis comme 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 nouvelle 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 mise à jour, les utilisateurs obtiennent la version mise à jour de l’application lors de leur prochaine connexion. 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 l’attachement d’application :

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 lors de la connexion. L’attachement d’application n’a pas de dépendances sur le type de structure de stockage utilisé par le partage de fichiers. Nous vous recommandons d’utiliser Azure Files, car il est compatible avec Microsoft Entra ID ou les services de domaine Active Directory, et offre un excellent rapport qualité-prix entre les coûts et les frais généraux de gestion.

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

Les sections suivantes fournissent des instructions 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 autoriser chaque objet 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 vos hôtes de session.

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

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

  Avertissement

  L’attribution du principal de service de fournisseur ARM d’Azure Virtual Desktop au compte de stockage accorde le service Azure Virtual Desktop à toutes les données du compte de stockage. Nous vous recommandons de ne stocker que les applications à utiliser avec l’attachement d’application dans ce compte de stockage et de changer régulièrement les clés d’accès.

• Pour Azure Files avec les services de domaine Active Directory, vous devez affecter le rôle de contrôle d’accès en fonction du rôle (RBAC) du lecteur de partage de fichier de stockage (RBAC) Azure 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, aux services de domaine services de domaine Active Directory ou aux Microsoft Entra Domain Services, consultez Vue d’ensemble de les options d’authentification basée sur l’identité d’Azure Files pour l’accès SMB.

• Pour Azure NetApp Files, vous pouvez créer un volume SMB et configurer les autorisations NTFS pour octroyer l’accès en lecture à l’objet ordinateur de chaque hôte de session. Vos hôtes de session doivent être joints aux services de domaine Active Directory Active Directory ou aux Microsoft Entra Domain Services.

Vous pouvez vérifier que les autorisations sont correctes à l’aide de PsExec. Pour plus d’informations, voir Vérifier l’accès au partage de fichiers.

Files de configuration de l’utilisateur et du déploiement

Pour les packages App-V fournis via App Attach, vous pouvez utiliser des fichiers de configuration dynamique App-V pour personnaliser le comportement de l’application. L’attachement d’application détecte automatiquement les fichiers de configuration standard qui respectent la convention d’affectation de noms attendue. S’ils se trouvent dans le même dossier que le package App Attach et que le xml est préfixé par le nom du fichier App-V, ces fichiers sont automatiquement associés au package d’application pendant le traitement. Si le chemin d’accès au fichier est \share\folder\filename.appv, les exemples ci-dessous seront automatiquement détectés et utilisés avec le package.

• \share\folder\filename_UserConfig.xml

• \share\folder\filename_DeploymentConfig.xml

$a = Get-AzWvdAppAttachPackage -SubscriptionId blahblah -ResourceGroupName blahblahrg -Name contosoPackage

$dependencyType = $a.GetType().Assembly.GetTypes() |
    Where-Object {
        $_.Name -eq 'MsixPackageDependencies' -and
        $_.Namespace -like '*DesktopVirtualization*'
    } |
    Select-Object -First 1

$newDependency = [System.Activator]::CreateInstance($dependencyType)
$newDependency.DependencyName = "FilePathToUserConfig"
$newDependency.Publisher = "Group Object Id"
$newDependency.MinVersion = 1
$dependencyList = $a.ImagePackageDependency
$dependencyList += $newDependency
Update-AzWvdAppAttachPackage -ImagePackageDependency $dependencyList -SubscriptionId blahblah -ResourceGroupName blahblahrg -Name contosoPackage

# Remove logic
$a = Get-AzWvdAppAttachPackage -SubscriptionId blahblah -ResourceGroupName blahblahrg -Name contosoPackage
$dependencyList = $a.ImagePackageDependency
$dependencyList  = $dependencyList | where-Object {$_.DependencyName -ne "FilePathToUserConfig"}
Update-AzWvdAppAttachPackage -ImagePackageDependency $dependencyList -SubscriptionId blahblah -ResourceGroupName blahblahrg -Name contosoPackage
 

Les fichiers de configuration utilisateur sont évalués au niveau de l’utilisateur, ce qui permet à différents utilisateurs de recevoir différents paramètres d’application. Les fichiers de configuration de déploiement, en revanche, sont appliqués au niveau de la machine et sont partagés par tous les utilisateurs de l’hôte de session. Pour l’instant, la configuration utilisateur est uniquement prise en charge sur les connexions de bureau, et non sur les connexions d’applications distantes.

Les scénarios avancés peuvent nécessiter plusieurs fichiers de configuration utilisateur pour la même application. Dans ce cas, les fichiers de configuration utilisateur supplémentaires doivent être explicitement associés au package d’application à l’aide de PowerShell.

L’attachement d’application vérifie l’objet de dépendance

• A un chemin spécifié dans le champ DependencyName qui se termine par UserConfig.xml

• Contient un champ Éditeur qui identifie le groupe de sécurité Microsoft Entra qui doit recevoir cette configuration. La valeur du champ Éditeur du package d’application doit être définie sur l’ID d’objet du groupe de sécurité cible.

Pendant la connexion, l’attachement d’application évalue les appartenances aux groupes de l’utilisateur et applique la configuration utilisateur appropriée en fonction du groupe associé.

Les administrateurs ne doivent utiliser plusieurs fichiers de configuration utilisateur que lorsque différentes populations d’utilisateurs nécessitent des paramètres d’application distincts ; Les déploiements standard peuvent continuer à s’appuyer sur le fichier de configuration d’utilisateur unique détecté automatiquement.

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 exigences. Pour les images de plus grande taille, vous devez allouer davantage de bande passante. Le tableau suivant donne un exemple des exigences requises pour qu’une seule image de 1 Go ou package App-V contenant une application soit requise par hôte de session :

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 être 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 réseau et de stockage peut fournir des performances adéquates. Vous devez éviter d’utiliser le même partage de fichiers avec des conteneurs de profil FSLogix.

Disponibilité

Les plans de reprise d’activité d’Azure Virtual Desktop doivent inclure la réplication du partage de fichiers vers votre emplacement de basculement secondaire. Vous devez également vous assurer que le chemin d’accès de votre partage de fichiers est accessible dans 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 d’Azure Virtual Desktop, consultez Configurer un plan de continuité d’activité et de récupération d’urgence.

Azure Files

Azure Files a des limites sur le nombre de handles ouverts par répertoire racine, répertoire et fichier. Les images 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 par image disque, plutôt que par utilisateur. Pour plus d’informations sur les limites et les instructions de dimensionnement, consultez les objectifs d’évolutivité et de performances d’Azure Files et les instructions de dimensionnement d’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 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 code de signature pour vos packages à partir de :

• Une autorité de certification publique (CA).

• Une autorité de certification interne ou autonome, 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 ne devez utiliser des certificats auto-signés que 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 l’outil d’empaquetage MSIX 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, vous avez besoin 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’endroit où vous avez obtenu le certificat, de la façon dont vous gérez vos hôtes de session et du fournisseur d’identité que vous utilisez. Le tableau suivant fournit des instructions sur la façon de s’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 d’entreprise interne :

  • Pour les hôtes de session joints à Active Directory, avec AD CS configuré en tant qu’autorité de certification interne de l’entreprise, ils sont approuvés par défaut et stockés dans le contexte d’appellation de configuration des services de domaine Active Directory. Lorsque AD CS est configuré en tant qu’autorité de certification autonome, vous devez configurer la 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 sur des appareils Windows à l’aide de la 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, voir Profils de certificat racine de confiance pour Microsoft Intune.

  • Pour les hôtes de session utilisant la jonction hybride Microsoft Entra, vous pouvez utiliser l’une ou l’autre des méthodes précédentes, en fonction de vos besoins.

• Auto-signé : installez la racine de confiance 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 de la stratégie de groupe ou d’Intune, car il ne doit être utilisé qu’à des fins de test.

Étapes suivantes

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