Delen via

App koppelen en MSIX-app koppelen in Azure Virtual Desktop

  • Artikel

Er zijn twee functies in Azure Virtual Desktop waarmee u toepassingen dynamisch vanuit een toepassingspakket kunt koppelen aan een gebruikerssessie in Azure Virtual Desktop: app koppelen en MSIX-app koppelen. Met zowel app-bijlage als MSIX-appkoppeling worden toepassingen niet lokaal geïnstalleerd op sessiehosts of installatiekopieën, waardoor het eenvoudiger is om aangepaste installatiekopieën voor uw sessiehosts te maken en operationele overhead en kosten voor uw organisatie te verminderen. Toepassingen worden uitgevoerd in containers, die gebruikersgegevens, het besturingssysteem en andere toepassingen scheiden, waardoor de beveiliging wordt verhoogd en ze gemakkelijker kunnen worden opgelost.

In de volgende tabel wordt msiX-appkoppeling vergeleken met app-bijlage:

MSIX-app-koppeling App-bijlage
Toepassingen worden geleverd met RemoteApp of als onderdeel van een bureaubladsessie. Machtigingen worden beheerd door toewijzing aan toepassingsgroepen, maar alle bureaubladgebruikers zien alle MSIX-apps koppelen toepassingen in de bureaubladtoepassingsgroep. Toepassingen worden geleverd met RemoteApp of als onderdeel van een bureaubladsessie. Machtigingen worden per toepassing per gebruiker toegepast, zodat u meer controle hebt over de toepassingen waartoe uw gebruikers toegang hebben in een externe sessie. Desktopgebruikers zien alleen de apps koppelen die aan hen zijn toegewezen.
Toepassingen kunnen slechts op één hostgroep worden uitgevoerd. Als u wilt dat deze wordt uitgevoerd op een andere hostgroep, moet u een ander pakket maken. Hetzelfde toepassingspakket kan worden gebruikt in meerdere hostgroepen.
Toepassingen kunnen alleen worden uitgevoerd op de hostgroep waarin ze worden toegevoegd. Toepassingen kunnen worden uitgevoerd op elke sessiehost waarop een Windows-clientbesturingssysteem wordt uitgevoerd in dezelfde Azure-regio als het toepassingspakket.
Als u de toepassing wilt bijwerken, moet u de toepassing verwijderen en opnieuw maken met een andere versie van het pakket. U moet de toepassing bijwerken in een onderhoudsvenster. Toepassingen kunnen worden geüpgraded naar een nieuwe toepassingsversie met een nieuwe schijfinstallatiekopieën zonder dat er een onderhoudsvenster nodig is.
Gebruikers kunnen niet twee versies van dezelfde toepassing uitvoeren op dezelfde sessiehost. Gebruikers kunnen twee versies van dezelfde toepassing gelijktijdig uitvoeren op dezelfde sessiehost.
Telemetrie voor gebruik en status is niet beschikbaar via Azure Log Analytics. Telemetrie voor gebruik en status is beschikbaar via Azure Log Analytics.

U kunt de volgende typen en bestandsindelingen van toepassingspakketten gebruiken:

Pakkettype Bestandsindelingen Beschikbaarheid van functies
MSIX- en MSIX-bundel .msix
.msixbundle		 MSIX-app-koppeling
App-bijlage
Appx- en Appx-bundel .appx
.appxbundle		 Alleen app-bijlage
App-V .appv Alleen app-bijlage

MSIX en Appx zijn Windows-toepassingspakketten die een moderne verpakkingservaring bieden voor Windows-toepassingen. Toepassingen worden uitgevoerd in containers, die gebruikersgegevens, het besturingssysteem en andere toepassingen scheiden, waardoor de beveiliging wordt verhoogd en ze 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 toepassingen worden geïnstalleerd op centraal beheerde servers en worden in realtime en op basis van behoefte aan gebruikers geleverd als een service. Gebruikers starten virtuele toepassingen vanaf bekende toegangspunten en communiceren met hen alsof ze lokaal zijn geïnstalleerd.

Tip

Selecteer boven aan dit artikel een knop om te kiezen tussen app-bijlage en MSIX-app-bijlage om de relevante documentatie te bekijken.

U kunt MSIX-pakketten ophalen van softwareleveranciers of u kunt een MSIX-pakket maken vanuit een bestaand installatieprogramma. Zie Wat is MSIX voor meer informatie over MSIX?

Hoe een gebruiker een toepassing krijgt

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, zodat de gebruiker op het juiste moment de juiste toepassing kan krijgen:

  • De toepassing moet worden toegewezen aan de hostgroep. Als u de toepassing toewijst aan de hostgroep, kunt u selectief zijn over de hostgroepen waarop de toepassing beschikbaar is om ervoor te zorgen dat de juiste hardwarebronnen 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 door GPU geoptimaliseerde sessiehosts.

  • De gebruiker moet zich kunnen aanmelden bij sessiehosts in de hostgroep, dus ze moeten zich in een bureaublad- of RemoteApp-toepassingsgroep bevinden. Voor een RemoteApp-toepassingsgroep moet de app-bijlagetoepassing 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 groep of een gebruikersaccount gebruiken.

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

Hoe een gebruiker een toepassing krijgt

U kunt verschillende toepassingen toewijzen aan verschillende gebruikers in dezelfde hostgroep. Met MSIX-app koppelen voegt u MSIX-pakketten toe aan een hostgroep en beheert u de toewijzing van toepassingen met behulp van bureaublad- of RemoteApp-toepassingsgroepen. Tijdens het aanmelden moet aan de volgende vereisten worden voldaan, zodat de gebruiker op het juiste moment de juiste toepassing kan krijgen:

  • De gebruiker moet zich kunnen aanmelden bij sessiehosts in de hostgroep, dus ze moeten zich in een bureaublad- of RemoteApp-toepassingsgroep bevinden.

  • De MSIX-installatiekopie moet worden toegevoegd aan de hostgroep.

Als aan deze vereisten wordt voldaan, krijgt de gebruiker de toepassing. Als u toepassingen toewijst met behulp van een bureaubladtoepassingsgroep, worden ze toegevoegd aan het startmenu van de gebruiker. Gebruikers die niet aan de vereisten voldoen, krijgen de toepassing niet.

Toepassingsinstallatiekopieën

Voordat u uw toepassingspakketten kunt gebruiken met Azure Virtual Desktop, moet u een MSIX-installatiekopieën maken op basis van uw bestaande toepassingspakketten met behulp van het MSIXMGR-hulpprogramma. Vervolgens moet u elke schijfinstallatiekopieën opslaan op een bestandsshare die toegankelijk is voor uw sessiehosts. Zie Bestandsshare voor meer informatie over de vereisten voor een bestandsshare.

::: zone-pivot="app-attach" Als u App-V gebruikt, raadpleegt u Gevirtualiseerde apps voor App-V maken en beheren. ::: zone-end

Schijfinstallatiekopieëntypen

Voor MSIX- en Appx-schijfinstallatiekopieën kunt u Composite Image File System (CimFS), VHDX of VHD gebruiken, maar we raden u niet aan om VHD te gebruiken. Het koppelen en ontkoppelen van CimFS-installatiekopieën is sneller dan VHD- en VHDX-bestanden en verbruikt ook minder CPU en geheugen. U wordt alleen aangeraden CimFS te gebruiken voor uw toepassingsinstallatiekopieën als op uw sessiehosts Windows 11 wordt uitgevoerd.

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

Bestandsnaam Tekengrootte
MyApp.cim 1 kB
objectid_b5742e0b-1b98-40b3-94a6-9cb96f497e56_0 27 KB
objectid_b5742e0b-1b98-40b3-94a6-9cb96f497e56_1 20 KB
objectid_b5742e0b-1b98-40b3-94a6-9cb96f497e56_2 42 KB
region_b5742e0b-1b98-40b3-94a6-9cb96f497e56_0 428 KB
region_b5742e0b-1b98-40b3-94a6-9cb96f497e56_1 217 KB
region_b5742e0b-1b98-40b3-94a6-9cb96f497e56_2 264.132 KB

De volgende tabel is een prestatievergelijking tussen VHDX en CimFS. Deze getallen waren het resultaat van een testuitvoering met elk 500 bestanden van 300 MB per indeling en de tests zijn uitgevoerd op een virtuele DSv4 Azure-machine.

Metrische gegevens VHD CimFS
Gemiddelde koppeltijd 356 ms 255 ms
Gemiddelde ontkoppelingstijd 1615 ms 36 ms
Geheugenverbruik 6% (van 8 GB) 2% (van 8 GB)
CPU (piek tellen) Maximaal meerdere keren Geen effect

Toepassingsregistratie

App koppelt schijfinstallatiekopieën of App-V-pakketten met uw toepassingen van een bestandsshare aan de sessie van een gebruiker tijdens het aanmelden en vervolgens maakt een registratieproces de toepassingen beschikbaar voor de gebruiker. Er zijn twee soorten registratie:

MSIX-app koppelt schijfinstallatiekopieën met uw toepassingen vanuit een bestandsshare aan de sessie van een gebruiker tijdens het aanmelden. Vervolgens maakt een registratieproces de toepassingen beschikbaar voor de gebruiker. Er zijn twee soorten registratie:

  • 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 u kunt gebruiken omdat dit niet van invloed is op de tijd die nodig is om u aan te melden bij Azure Virtual Desktop. On-demand is de standaardregistratiemethode.

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

Belangrijk

Alle MSIX- en Appx-toepassingspakketten bevatten een certificaat. U bent verantwoordelijk voor het controleren of de certificaten worden vertrouwd in uw omgeving. Zelfondertekende certificaten worden ondersteund met de juiste vertrouwensketen.

App-bijlage beperkt niet het aantal toepassingen dat gebruikers kunnen gebruiken. U moet rekening houden met de beschikbare netwerkdoorvoer en het aantal geopende ingangen per bestand (elke afbeelding) dat door uw bestandsshare wordt ondersteund, omdat het aantal gebruikers of toepassingen dat u kunt ondersteunen, kan worden beperkt. Zie Bestandsshare voor meer informatie.

Belangrijk

Alle MSIX-toepassingspakketten bevatten een certificaat. U bent verantwoordelijk voor het controleren of de certificaten worden vertrouwd in uw omgeving. Zelfondertekende certificaten worden ondersteund.

MsiX-appkoppeling beperkt niet het aantal toepassingen dat gebruikers kunnen gebruiken. U moet rekening houden met de beschikbare netwerkdoorvoer en het aantal geopende ingangen per bestand (elke afbeelding) dat door uw bestandsshare wordt ondersteund, omdat het aantal gebruikers of toepassingen dat u kunt ondersteunen, kan worden beperkt. Zie Bestandsshare voor meer informatie.

Toepassingsstatus

Toepassingspakketten worden ingesteld als actief of inactief. Pakketten die zijn ingesteld op actief, maken de toepassing beschikbaar voor gebruikers. Pakketten die zijn ingesteld op inactief, worden genegeerd door Azure Virtual Desktop en worden niet toegevoegd wanneer een gebruiker zich aanmeldt.

Een MSIX-pakket wordt ingesteld als actief of inactief. MSIX-pakketten die zijn ingesteld op actief, maken de toepassing beschikbaar voor gebruikers. MSIX-pakketten die zijn ingesteld op inactief, worden genegeerd door Azure Virtual Desktop 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 op te leveren die de bijgewerkte toepassing bevat. U kunt deze nieuwe installatiekopieën op twee manieren gebruiken:

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

  • In-place: maak een nieuwe installatiekopieën waarin het versienummer van de toepassing wordt gewijzigd en werk vervolgens de bestaande toepassing bij om de nieuwe installatiekopieën te gebruiken. Het versienummer kan hoger of lager zijn, maar u kunt een toepassing niet bijwerken met hetzelfde versienummer. Verwijder de bestaande installatiekopieën pas als alle gebruikers klaar zijn met het gebruik ervan.

Zodra ze zijn bijgewerkt, krijgen gebruikers de bijgewerkte toepassingsversie de volgende keer dat ze zich aanmelden. Gebruikers hoeven de vorige versie niet meer te gebruiken om een nieuwe versie toe te voegen.

Nieuwe versies van toepassingen

Als msix-app is gekoppeld, moet u het toepassingspakket verwijderen en vervolgens een nieuwe toepassing maken met behulp van de nieuwe schijfinstallatiekopie en deze toewijzen aan dezelfde hostgroepen. U kunt niet in-place bijwerken zoals u kunt met app-bijlage. Gebruikers krijgen de nieuwe installatiekopieën met de bijgewerkte toepassing wanneer ze zich de volgende keer aanmelden. U moet deze taken uitvoeren tijdens een onderhoudsvenster.

Id-providers

Dit zijn de id-providers die u kunt gebruiken met app-bijlage:

Identiteitsprovider Status
Microsoft Entra ID Ondersteund
Active Directory-domein Services (AD DS) Ondersteund
Microsoft Entra Domain Services. Niet ondersteund

Dit zijn de id-providers die u kunt gebruiken met MSIX-app koppelen:

Identiteitsprovider Status
Microsoft Entra ID Niet ondersteund
Active Directory-domein Services (AD DS) Ondersteund
Microsoft Entra Domain Services (Azure AD DS) Niet ondersteund

Bestandsshare

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

U kunt ook Azure NetApp Files gebruiken, maar hiervoor moeten uw sessiehosts worden toegevoegd aan Active Directory-domein Services.

MsiX-app-koppeling vereist dat uw toepassingsinstallatiekopieën worden opgeslagen op een SMB versie 3-bestandsshare, die vervolgens tijdens het aanmelden op elke sessiehost wordt gekoppeld. MSIX-app-koppeling heeft geen afhankelijkheden van het type opslaginfrastructuur dat door de bestandsshare wordt gebruikt. We raden u aan Om Azure Files te gebruiken omdat deze compatibel is met de ondersteunde id-providers die u kunt gebruiken voor het koppelen van MSIX-apps en biedt veel waarde tussen kosten- en beheeroverhead. U kunt ook Azure NetApp Files gebruiken, maar hiervoor moeten uw sessiehosts worden toegevoegd aan Active Directory-domein Services.

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

Machtigingen

Elke sessiehost koppelt toepassingsinstallatiekopieën van de bestandsshare. U moet NTFS- en sharemachtigingen configureren om elke sessiehostcomputerobject leestoegang te geven tot de bestanden en bestandsshare. Hoe u de juiste machtiging configureert, is afhankelijk van de opslagprovider en id-provider die u gebruikt voor uw bestandsshare en sessiehosts.

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

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

Prestaties

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

Bron Vereisten
IOPS met een stabiele status Eén IOP
Aanmelding bij opstarten van machine 10 IOPS
Latentie 400 ms

We raden u aan om de prestaties van uw toepassingen te optimaliseren:

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

  • Sluit de schijfinstallatiekopieën met uw toepassingen uit van antivirusscans omdat ze alleen-lezen zijn.

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

Beschikbaarheid

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

Azure Files

Azure Files heeft limieten voor het aantal geopende ingangen per hoofdmap, map en bestand. Wanneer u app-bijlage of MSIX-appkoppeling gebruikt, worden VHDX- of CimFS-schijfinstallatiekopieën gekoppeld met behulp van het computeraccount van de sessiehost, wat betekent dat er per sessiehost per schijfinstallatiekopie één ingang wordt geopend in plaats van per gebruiker. Zie De schaalbaarheids- en prestatiedoelen van Azure Files en richtlijnen voor het aanpassen van de grootte van Azure Virtual Desktop voor meer informatie over de limieten en richtlijnen voor het aanpassen van de grootte.

MSIX- en Appx-pakketcertificaten

Voor alle MSIX- en Appx-pakketten is een geldig certificaat voor ondertekening van code vereist. Als u deze pakketten wilt gebruiken met app-koppeling, moet u ervoor zorgen dat de hele certificaatketen wordt vertrouwd op uw sessiehosts. Een certificaat voor ondertekening van programmacode heeft de object-id 1.3.6.1.5.5.7.3.3. U kunt een certificaat voor ondertekening van programmacode voor uw pakketten ophalen uit:

  • Een openbare certificeringsinstantie (CA).

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

  • Een hulpprogramma zoals de PowerShell-cmdlet New-SelfSignedCertificate waarmee een zelfondertekend certificaat wordt gegenereerd. Gebruik alleen zelfondertekende certificaten in een testomgeving. Zie Een certificaat maken voor pakketondertekening voor MSIX- en Appx-pakketten 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. U kunt het MSIX Packaging Tool gebruiken om uw pakketten te ondertekenen wanneer u een MSIX-pakket maakt. Zie Een MSIX-pakket maken vanuit een desktopinstallatieprogramma voor meer informatie.

Om ervoor te zorgen dat het certificaat wordt vertrouwd op uw sessiehosts, hebt u uw sessiehosts nodig om de hele certificaatketen te vertrouwen. Hoe u dit doet, is afhankelijk van waar u het certificaat vandaan hebt gekregen en hoe u uw sessiehosts en de id-provider beheert die u gebruikt. De volgende tabel bevat enkele richtlijnen voor het controleren of het certificaat wordt vertrouwd op uw sessiehosts:

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

  • Ca voor interne ondernemingen:

    • Voor sessiehosts die zijn toegevoegd aan Active Directory, waarbij AD CS is geconfigureerd als de interne ca voor ondernemingen, worden standaard vertrouwd en opgeslagen in de configuratienaamgevingscontext van Active Directory-domein Services. Wanneer AD CS een zelfstandige CERTIFICERINGsinstantie is, moet u Groepsbeleid configureren om de basis- en tussencertificaten te distribueren naar sessiehosts. Zie Certificaten distribueren naar Windows-apparaten met behulp van groepsbeleid voor meer informatie.

    • Voor sessiehosts die zijn toegevoegd aan Microsoft Entra-id, kunt u Microsoft Intune gebruiken om de hoofdcertificaten en tussenliggende certificaten te distribueren naar sessiehosts. Zie Vertrouwde basiscertificaatprofielen voor Microsoft Intune voor meer informatie.

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

  • Zelfondertekend: installeer de vertrouwde basismap in het archief vertrouwde basiscertificeringsinstanties op elke sessiehost. U wordt afgeraden dit certificaat te distribueren met behulp van Groepsbeleid of Intune, omdat dit alleen mag worden gebruikt voor testen.

Belangrijk

U moet de tijdstempel van uw pakket instellen, zodat de geldigheid ervan de vervaldatum van uw certificaat kan uitvallen. Als het certificaat is verlopen, moet u het pakket bijwerken met een nieuw geldig certificaat en opnieuw controleren of het wordt vertrouwd op uw sessiehosts.

Volgende stappen

Meer informatie over het toevoegen en beheren van app-attach-toepassingen in Azure Virtual Desktop.