App koppelen in Azure Virtual Desktop

Met App Attach kunt u toepassingen uit een toepassingspakket dynamisch koppelen aan een gebruikerssessie in Azure Virtual Desktop. Toepassingen worden niet lokaal geïnstalleerd op sessiehosts of installatiekopieën. Hierdoor kunt u eenvoudiger aangepaste installatiekopieën maken voor uw sessiehosts en de operationele overhead en kosten voor uw organisatie verminderen. Toepassingen worden uitgevoerd in containers, waarin gebruikersgegevens, het besturingssysteem en andere toepassingen van elkaar worden gescheiden, waardoor de beveiliging wordt verbeterd en problemen gemakkelijker kunnen worden opgelost.

Hier volgen enkele van de belangrijkste voordelen van App Attach:

• Toepassingen worden geleverd met behulp van RemoteApp of als onderdeel van een bureaubladsessie. Machtigingen worden per toepassing per gebruiker toegepast, waardoor u meer controle hebt over welke toepassingen uw gebruikers kunnen openen in een externe sessie. Desktopgebruikers zien alleen de toepassingen App-koppeling die aan hen zijn toegewezen.

• Hetzelfde toepassingspakket kan worden gebruikt voor meerdere hostgroepen.

• Toepassingen kunnen worden uitgevoerd op elke sessiehost met een Windows-client of ondersteund Windows-serverbesturingssysteem in dezelfde Azure-regio als het toepassingspakket.

• Toepassingen kunnen worden bijgewerkt naar een nieuwe toepassingsversie met een nieuwe schijfkopie zonder dat er een onderhoudsvenster nodig is.

• Gebruikers kunnen meerdere versies van dezelfde toepassing tegelijk uitvoeren op dezelfde sessiehost.

• Telemetrie voor gebruik en status is beschikbaar via Azure Log Analytics.

U kunt de volgende typen toepassingspakketten en bestandsindelingen gebruiken:

MSIX en Appx zijn Windows-toepassingspakketindelingen die een moderne verpakkingservaring bieden aan Windows-toepassingen. Toepassingen worden uitgevoerd in containers, waarin gebruikersgegevens, het besturingssysteem en andere toepassingen van elkaar worden gescheiden, waardoor de beveiliging wordt verbeterd en problemen gemakkelijker kunnen worden opgelost. MSIX en Appx zijn vergelijkbaar, waarbij het belangrijkste verschil is dat MSIX een superset van Appx is. MSIX ondersteunt alle functies van Appx, plus andere functies die het geschikter maken voor zakelijk gebruik.

Microsoft Application Virtualization (App-V) voor Windows levert Win32-toepassingen aan gebruikers als virtuele toepassingen. Virtuele applicaties worden geïnstalleerd op centraal beheerde servers en in realtime en naar behoefte aan gebruikers geleverd als een service. Gebruikers starten virtuele applicaties vanaf vertrouwde toegangspunten en communiceren ermee alsof ze lokaal zijn geïnstalleerd.

U kunt MSIX-pakketten downloaden van softwareleveranciers of u kunt een MSIX-pakket maken van een bestaand installatieprogramma. Voor meer informatie over MSIX, zie Wat is MSIX?.

Hoe een gebruiker een toepassing ophaalt

U kunt verschillende toepassingen toewijzen aan verschillende gebruikers in dezelfde hostgroep of op dezelfde sessiehost. Tijdens het aanmelden moet aan alle drie de volgende vereisten worden voldaan om de gebruiker op het juiste moment de juiste toepassing te geven:

• De toepassing moet worden toegewezen aan de hostgroep. Als u de toepassing toewijst aan de hostgroep, kunt u selecteren in welke hostgroepen de toepassing beschikbaar is om ervoor te zorgen dat de juiste hardwareresources beschikbaar zijn voor gebruik door de toepassing. Als een toepassing bijvoorbeeld grafisch intensief is, kunt u ervoor zorgen dat deze alleen wordt uitgevoerd op een hostgroep met voor GPU geoptimaliseerde sessiehosts.

• De gebruiker moet zich kunnen aanmelden bij sessiehosts in de hostgroep, dus moeten ze deel uitmaken van een bureaublad- of RemoteApp-toepassingsgroep. Voor een RemoteApp-toepassingsgroep moet App Attach worden toegevoegd aan de toepassingsgroep, maar u hoeft de toepassing niet toe te voegen aan een bureaubladtoepassingsgroep.

• De toepassing moet worden toegewezen aan de gebruiker. U kunt een groeps- of gebruikersaccount gebruiken.

Als aan al deze vereisten is voldaan, krijgt de gebruiker de toepassing. Dit proces biedt controle over wie een toepassing op welke hostgroep ontvangt en ook hoe het mogelijk is voor gebruikers binnen één hostgroep of zelfs aangemeld bij dezelfde host voor sessies met meerdere sessies om verschillende toepassingscombinaties te krijgen. Gebruikers die niet aan de vereisten voldoen, krijgen de toepassing niet.

Afbeelding van toepassing

Voordat u MSIX-toepassingspakketten kunt gebruiken met Azure virtuele bureaublad, moet u een MSIX-installatiekopie maken van uw bestaande toepassingspakketten. U kunt ook een App-V-pakket gebruiken. Vervolgens moet je elke MSIX-installatiekopie of elk App-V-pakket opslaan op een bestandsshare die toegankelijk is voor je sessiehosts. Zie Bestandsshare voor meer informatie over de vereisten voor een bestandsshare.

Typen schijfkopieën

Voor MSIX- en Appx-schijfkopieën kunt u Composite Image File System (CimFS),VHDX of VHD gebruiken, maar we raden u af VHD te gebruiken. Het koppelen en ontkoppelen van CimFS-installatiekopieën gaat sneller dan VHD- en VHDX-installatiekopieën en verbruikt ook minder CPU en geheugen. We raden u aan CimFS alleen te gebruiken voor uw toepassingsinstallatiekopieën als uw sessiehosts Windows 11 uitvoeren.

Een CimFS-installatiekopie is een combinatie van verschillende bestanden: één bestand heeft de .cim bestandsextensie en bevat metagegevens en minimaal twee andere bestanden, het ene begint met objectid_ en het andere region_ met dat de daadwerkelijke toepassingsgegevens bevat. De bestanden die bij het .cim bestand horen, hebben geen bestandsextensie. De volgende tabel bevat een lijst met voorbeeldbestanden die u kunt vinden voor een CimFS-installatiekopie:

In de volgende tabel wordt de prestatie van VHDX en CimFS vergeleken. Deze getallen zijn het resultaat van een testrun met 500 bestanden van elk 300 MB per formaat en de tests zijn uitgevoerd op een DSv4 Azure virtuele machine.

Aanmelding

Met App Attach worden schijfkopieën of App-V-pakketten met uw toepassingen gekoppeld vanuit een bestandsshare aan een sessie van een gebruiker tijdens de aanmelding, waarna een registratieproces de toepassingen beschikbaar maakt voor de gebruiker. Er zijn twee soorten registraties:

• Op aanvraag: toepassingen worden slechts gedeeltelijk geregistreerd bij het aanmelden en de volledige registratie van een toepassing wordt uitgesteld totdat de gebruiker de toepassing start. On-demand is het registratietype dat we u aanraden te gebruiken, omdat dit geen invloed heeft op de tijd die nodig is om u aan te melden bij Azure Virtual Desktop. On-demand is de standaard registratiemethode.

• Logblokkering: elke applicatie die u aan een gebruiker toewijst, is volledig geregistreerd. Registratie vindt plaats terwijl de gebruiker zich aanmeldt bij de sessie, wat van invloed kan zijn op de aanmeldingstijd bij Azure Virtual Desktop.

Met App Attach worden er geen beperkingen ingesteld voor het aantal toepassingen dat gebruikers kunnen gebruiken. U moet rekening houden met de beschikbare netwerkdoorvoer en het aantal open ingangen per bestand (elke afbeelding) dat uw bestandsshare ondersteunt, omdat hierdoor het aantal gebruikers of toepassingen dat u kunt ondersteunen mogelijk beperkt is. Zie Bestandsshare voor meer informatie.

Status van toepassing

Toepassingspakketten worden ingesteld als actief of inactief. Als pakketten zijn ingesteld op Actief, wordt de toepassing beschikbaar gemaakt voor gebruikers. Azure Virtual Desktop negeert pakketten die zijn ingesteld op inactief en worden niet toegevoegd wanneer een gebruiker zich aanmeldt.

Nieuwe versies van toepassingen

U kunt een nieuwe versie van een toepassing toevoegen door een nieuwe installatiekopie met de bijgewerkte toepassing op te geven. U kunt deze nieuwe afbeelding op twee manieren gebruiken:

• Naast elkaar: maak een nieuwe toepassing met behulp van de nieuwe schijfkopie en wijs deze toe aan dezelfde hostgroepen en gebruikers als de bestaande toepassing.

• In-place: maak een nieuwe installatiekopie waarbij het versienummer van de toepassing verandert en werk vervolgens de bestaande toepassing bij om de nieuwe installatiekopie te gebruiken. Het versienummer kan hoger of lager zijn, maar u kunt een toepassing niet bijwerken met hetzelfde versienummer. Verwijder de bestaande afbeelding pas als alle gebruikers deze hebben gebruikt.

Na de update ontvangen gebruikers de bijgewerkte toepassingsversie wanneer ze zich de volgende keer aanmelden. Gebruikers hoeven niet te stoppen met het gebruik van de vorige versie om een nieuwe versie toe te voegen.

Id-providers

Hier volgen de id-providers die u kunt gebruiken met App Attach:

Bestandsshare

App Attach vereist dat uw toepassingsinstallatiekopieën worden opgeslagen op een SMB-bestandsshare, die vervolgens tijdens het aanmelden op elke sessiehost wordt gekoppeld. App Attach heeft geen afhankelijkheden op het type opslagfabric dat door de bestandsshare wordt gebruikt. We raden u aan Azure Files te gebruiken, omdat het compatibel is met Microsoft Entra ID of Active Directory Domain Services en veel waarde biedt tussen kosten en beheeroverhead.

U kunt ook gebruikmaken van Azure NetApp Files, maar daarvoor moeten uw sessiehosts zijn toegevoegd aan Active Directory Domain Services.

De volgende secties bevatten richtlijnen over de machtigingen, prestaties en beschikbaarheid die vereist zijn voor de bestandsshare.

Machtigingen

Elke sessiehost koppelt toepassingsafbeeldingen uit de bestandsshare. U moet NTFS- en sharemachtigingen configureren om elke sessie als hostcomputerobject leestoegang tot de bestanden en bestandsshare toe te staan. Hoe u de juiste machtiging configureert, is afhankelijk van de opslag- en id-provider die u gebruikt voor uw bestandsshare- en sessiehosts.

• Als u Azure Files wilt gebruiken wanneer uw sessiehosts deelnemen aan Microsoft Entra ID, moet u de rol Lezer en Data Access Azure op basis van rollen toewijzen aan zowel de Azure Virtual Desktop als de Azure Virtual Desktop ARM-providerservice-principals. Met deze toewijzing van de RBAC-rol hebben sessiehosts toegang tot het opslagaccount via toegangstoetsen of Microsoft Entra.

• Zie Assign RBAC roles to the Azure Virtual Desktop service principals, see Assign RBAC roles to the Virtual Desktop service principals, to learn how to assign an Azure RBAC role to the Azure Virtual Desktop service principals. In een toekomstige update hoef je de service-principal van de Azure Virtual Desktop ARM-provider niet toe te wijzen.

  Zie Overzicht van Azure Files voor meer informatie over het gebruik van Azure Files met sessiehosts die zijn gekoppeld aan Microsoft Entra ID, Active Directory Domain Services of Microsoft Entra Domeinservices identiteitsgebaseerde verificatie-opties voor SMB-toegang.

  Waarschuwing

  Als u de service-principal van de Azure Virtual Desktop ARM-provider toewijst aan het opslagaccount, wordt de Azure Virtual Desktop-service verleend voor alle gegevens in het opslagaccount. U wordt aangeraden alleen apps op te slaan voor gebruik met App-koppeling in dit opslagaccount en de toegangstoetsen regelmatig te draaien.

• Voor Azure Files met Active Directory Domain Services moet u de SMB-sharelezer voor opslagbestandsgegevens (RBAC) van Azure als de standaardmachtiging op shareniveau toewijzen en NTFS-machtigingen configureren om leestoegang te verlenen aan het computerobject van elke sessiehost.

  Zie Overzicht van Azure Files voor meer informatie over het gebruik van Azure Files met sessiehosts die zijn gekoppeld aan Microsoft Entra ID, Active Directory Domain Services of Microsoft Entra Domeinservices identiteitsgebaseerde verificatie-opties voor SMB-toegang.

• Voor Azure NetApp Files kunt u een SMB-volume maken en NTFS-machtigingen configureren om leestoegang te verlenen aan het computerobject van elke sessiehost. Uw sessiehosts moeten zijn aangesloten bij Active Directory Domain Services of Microsoft Entra Domeinservices.

U kunt met behulp van PsExec controleren of de machtigingen juist zijn. Zie Toegang tot bestandsshares controleren voor meer informatie.

User and Deployment Configuration Files

Voor App-V-pakketten die worden geleverd via App Attach, kunt u dynamische App-V-configuratiebestanden gebruiken om het gedrag van de toepassing aan te passen. Met App Attach worden automatisch standaardconfiguratiebestanden gedetecteerd die voldoen aan de verwachte naamgevingsconventie. Als ze zich in dezelfde map bevinden als het App Atta-pakket en de XML-code wordt voorafgegaan door de naam van het App-V-bestand, worden deze bestanden tijdens het verwerken automatisch gekoppeld aan het toepassingspakket. Als het bestandspad \share\map\bestandsnaam.appv is, worden de onderstaande voorbeelden automatisch gedetecteerd en samen met het pakket gebruikt.

• \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
 

Gebruikersconfiguratiebestanden worden geëvalueerd op gebruikersniveau, zodat verschillende gebruikers verschillende toepassingsinstellingen kunnen ontvangen. Configuratiebestanden voor de implementatie worden daarentegen toegepast op computerniveau en worden gedeeld door alle gebruikers op de sessiehost. Op dit moment wordt gebruikersconfiguratie alleen ondersteund op bureaubladverbindingen, niet op externe app-verbindingen.

Voor geavanceerde scenario's zijn mogelijk meerdere gebruikersconfiguratiebestanden voor dezelfde toepassing vereist. In deze gevallen moeten de aanvullende gebruikersconfiguratiebestanden expliciet worden gekoppeld aan het toepassingspakket met behulp van PowerShell.

App attach controleert het afhankelijkheidsobject

• Er is een bestandspad opgegeven in het veld DependencyName dat eindigt op UserConfig.xml

• Bevat een Publisher-veld dat de Microsoft Entra-beveiligingsgroep identificeert die die configuratie moet ontvangen. De waarde van het veld Publisher van het app-pakket moet worden ingesteld op de object-id van de doelbeveiligingsgroep.

Tijdens het aanmelden evalueert App Attach de groepslidmaatschappen van de gebruiker en past de juiste gebruikersconfiguratie toe op basis van de gekoppelde groep.

Beheerders mogen meerdere gebruikersconfiguratiebestanden alleen gebruiken wanneer verschillende gebruikerspopulaties verschillende toepassingsinstellingen vereisen; Standaardimplementaties kunnen blijven vertrouwen op het automatisch gedetecteerde configuratiebestand voor één gebruiker.

Prestatie

De vereisten kunnen sterk variëren, afhankelijk van het aantal softwarepakketten dat in een installatiekopie is opgeslagen en u moet uw toepassingen testen om inzicht te krijgen in uw vereisten. Voor grotere afbeeldingen moet u meer bandbreedte toewijzen. De volgende tabel geeft een voorbeeld van de vereisten voor een enkele afbeelding van 1 GB of een App-V-pakket met één toepassing per sessiehost:

Als u de prestaties van uw toepassingen wilt optimaliseren, raden we het volgende aan:

• Uw bestandsshare moet zich in dezelfde Azure regio bevinden als de sessiehosts. Als u Azure Files gebruikt, moet uw opslagaccount zich in dezelfde Azure regio bevinden als uw sessiehosts.

• Sluit de schijfkopieën met uw toepassingen uit van antivirusscans, omdat deze alleen-lezen zijn.

• Zorg ervoor dat uw opslag- en netwerkstructuur voldoende prestaties leveren. Vermijd het gebruik van dezelfde bestandsshare met FSLogix-profielcontainers.

Beschikbaarheid

Eventuele noodherstelplannen voor Azure Virtual Desktop moeten de replicatie van de bestandsshare naar uw secundaire failoverlocatie bevatten. U moet er ook voor zorgen dat het pad naar de bestandsshare toegankelijk is via de secundaire locatie. U kunt bijvoorbeeld DFS-naamruimten (Distributed File System) gebruiken met Azure Files om één sharenaam voor verschillende bestandsshares op te geven. Zie Een bedrijfscontinuïteits- en noodherstelplan instellen voor meer informatie over herstel na noodgevallen voor Azure Virtual Desktop.

Azure Files

Voor Azure Files gelden limieten voor het aantal open ingangen per hoofdmap, map en bestand. VHDX- of CimFS-schijfinstallatiekopieën worden gekoppeld met behulp van het computeraccount van de sessiehost, wat betekent dat er één ingang wordt geopend per sessiehost per schijfkopie, in plaats van per gebruiker. Zie de schaalbaarheids- en prestatiedoelen voor Azure Files en de richtlijnen voor de grootte van Azure Files voor Azure Virtual Desktop voor meer informatie over de limieten en richtlijnen voor de grootte van de grootte van Azure Files.

MSIX- en Appx-pakketcertificaten

Voor alle MSIX- en Appx-pakketten is een geldig code-ondertekeningscertificaat vereist. Als u deze pakketten wilt gebruiken met App Attach, moet u ervoor zorgen dat de hele certificaatketen wordt vertrouwd op uw sessiehosts. Een certificaat voor codeondertekening heeft de object-id 1.3.6.1.5.5.7.3.3. U kunt een code signing-certificaat voor uw pakketten aanvragen via:

• Een openbare certificeringsinstantie (CA).

• Een interne onderneming of zelfstandige certificeringsinstantie, zoals Active Directory Certificate Services. U moet het certificaat voor het ondertekenen van code exporteren, inclusief de bijbehorende persoonlijke sleutel.

• Een hulpprogramma zoals de PowerShell-cmdlet New-SelfSignedCertificate waarmee een zelfondertekend certificaat wordt gegenereerd. Gebruik zelfondertekende certificaten alleen in een testomgeving. Zie Een certificaat voor ondertekening van pakketten maken voor meer informatie over het maken van een zelfondertekend certificaat voor MSIX- en Appx-pakketten.

Zodra u een certificaat hebt verkregen, moet u uw MSIX- of Appx-pakketten digitaal ondertekenen met het certificaat. Je kunt de MSIX Packaging Tool gebruiken om je pakketten te ondertekenen wanneer je een MSIX-pakket aanmaakt. Zie Een MSIX-pakket maken vanuit een willekeurig desktopinstallatieprogramma voor meer informatie.

Om ervoor te zorgen dat het certificaat wordt vertrouwd op uw sessiehosts, moet u ervoor zorgen dat uw sessiehosts de hele certificaatketen kunnen vertrouwen. Hoe uw sessiehosts de certificaatketen vertrouwen, is afhankelijk van waar u het certificaat vandaan hebt en hoe u uw sessiehosts en de id-provider die u gebruikt, beheert. De volgende tabel bevat enkele richtlijnen over hoe u ervoor kunt zorgen dat het certificaat wordt vertrouwd op uw sessiehosts:

• Openbare certificeringsinstantie: certificaten van een openbare certificeringsinstantie worden standaard vertrouwd in Windows en op Windows Server.

• Interne ondernemingscertificeringsinstantie:

  • Voor sessiehosts die zijn toegevoegd aan Active Directory, waarbij AD CS is geconfigureerd als de interne bedrijfscertificeringsinstantie, worden standaard vertrouwd en opgeslagen in de configuratienaamgevingscontext van Active Directory Domain Services. Wanneer AD CS is geconfigureerd als een zelfstandige certificeringsinstantie, moet u groepsbeleid configureren om de basiscertificaten en tussenliggende certificaten te distribueren naar sessiehosts. Zie Certificaten distribueren naar Windows-apparaten met behulp van groepsbeleid voor meer informatie.

  • Voor sessiehosts die lid zijn van Microsoft Entra ID, kunt u Microsoft Intune gebruiken om de basis- en tussenliggende certificaten naar sessiehosts te distribueren. Zie Trusted root certificate profiles for Microsoft Intune (Vertrouwde basiscertificaatprofielen voor Microsoft Intune) voor meer informatie.

  • Voor sessiehosts die gebruikmaken van hybride deelname aan Microsoft Entra, kunt u een van de voorgaande methoden gebruiken, afhankelijk van uw vereisten.

• Zelfondertekend: installeer de vertrouwde hoofdmap in het archief met vertrouwde basiscertificeringsinstanties op elke sessiehost. Het wordt afgeraden dit certificaat te verspreiden met behulp van groepsbeleid of Intune, omdat het alleen moet worden gebruikt voor testen.

Volgende stappen

Informatie over het toevoegen en beheren van toepassingen via app-koppelingen in Azure Virtual Desktop.