Dela via


Appanslutning i Azure Virtual Desktop

Med App Attach kan du dynamiskt koppla program från ett programpaket till en användarsession i Azure Virtual Desktop. Program installeras inte lokalt på sessionsvärdar eller avbildningar, vilket gör det enklare att skapa anpassade avbildningar för dina sessionsvärdar och minska driftkostnaderna för din organisation. Program körs i containrar som separerar användardata, operativsystemet och andra program, vilket ökar säkerheten och gör dem enklare att felsöka.

Här är några av de viktigaste fördelarna med App Attach:

  • Program levereras med RemoteApp eller som en del av en skrivbordssession. Behörigheter tillämpas per program per användare, vilket ger dig större kontroll över vilka program som användarna kan komma åt i en fjärrsession. Skrivbordsanvändare ser bara appkopplingsprogram som tilldelats dem.
  • Samma programpaket kan användas i flera värdpooler.
  • Program kan köras på alla sessionsvärdar som kör ett Windows-klientoperativsystem i samma Azure-region som programpaketet.
  • Program kan uppgraderas till en ny programversion med en ny disk avbildning utan behov av en underhållsperiod.
  • Användare kan köra flera versioner av samma program samtidigt på samma sessionsvärd.
  • Telemetri för användning och hälsa är tillgängligt via Azure Log Analytics.

Du kan använda följande programpakettyper och filformat:

Pakettyp Filformat
MSIX- och MSIX-paket .msix
.msixbundle
Appx- och Appx-paket .appx
.appxbundle
App-V .appv

MSIX och Appx är Windows-programpaketformat som ger en modern paketeringsupplevelse för Windows-program. Program körs i containrar som separerar användardata, operativsystemet och andra program, vilket ökar säkerheten och gör dem enklare att felsöka. MSIX och Appx är liknande, där den största skillnaden är att MSIX är en supermängd av Appx. MSIX stöder alla funktioner i Appx, plus andra funktioner som gör det mer lämpligt för företagsanvändning.

Microsoft Application Virtualization (App-V) för Windows levererar Win32-program till användare som virtuella program. Virtuella program installeras på centralt hanterade servrar och levereras till användare som en tjänst i realtid och efter behov. Användare startar virtuella program från välbekanta åtkomstpunkter och interagerar med dem som om de hade installerats lokalt.

Du kan hämta MSIX-paket från programvaruleverantörer eller skapa ett MSIX-paket från ett befintligt installationsprogram. Mer information om MSIX finns i Vad är MSIX?.

Hur en användare får ett program

Du kan tilldela olika program till olika användare i samma värdpool eller på samma sessionsvärd. Under inloggningen måste alla tre av följande krav uppfyllas för att användaren ska få rätt program vid rätt tidpunkt:

  • Programmet måste tilldelas till värdpoolen. Genom att tilldela programmet till värdpoolen kan du vara selektiv om vilka värdpooler programmet är tillgängligt på för att säkerställa att rätt maskinvaruresurser är tillgängliga för användning av programmet. Om ett program till exempel är grafikintensivt kan du se till att det bara körs på en värdpool med GPU-optimerade sessionsvärdar.

  • Användaren måste kunna logga in på sessionsvärdar i värdpoolen, så de måste vara i en skrivbords- eller RemoteApp-programgrupp. För en RemoteApp-programgrupp måste appkopplingsprogrammet läggas till i programgruppen, men du behöver inte lägga till programmet i en skrivbordsprogramgrupp.

  • Programmet måste tilldelas användaren. Du kan använda en grupp eller ett användarkonto.

Om alla dessa krav uppfylls hämtar användaren programmet. Den här processen ger kontroll över vem som får ett program på vilken värdpool och även hur det är möjligt för användare i en enda värdpool eller till och med loggas in på samma sessionsvärd för flera sessioner att få olika programkombinationer. Användare som inte uppfyller kraven får inte programmet.

Programbilder

Innan du kan använda MSIX-programpaket med Azure Virtual Desktop måste du skapa en MSIX-avbildning från dina befintliga programpaket. Du kan också använda ett App-V-paket i stället. Sedan måste du lagra varje MSIX-avbildning eller App-V-paket på en filresurs som är tillgänglig för sessionsvärdarna. Mer information om kraven för en filresurs finns i Filresurs.

Typer av diskbild

För MSIX- och Appx-diskbilder kan du använda CimFS (Composite Image File System),VHDX eller VHD, men vi rekommenderar inte att du använder VHD. Montering och avmontering av CimFS-avbildningar är snabbare än VHD- och VHDX-avbildningar och förbrukar också mindre PROCESSOR och minne. Vi rekommenderar bara att du använder CimFS för dina programbilder om sessionsvärdarna kör Windows 11.

En CimFS-avbildning är en kombination av flera filer: en fil har filnamnstillägget .cim och innehåller metadata, tillsammans med minst två andra filer, en som börjar med objectid_ och den andra börjar med region_ som innehåller faktiska programdata. Filerna som .cim medföljer filen har inget filnamnstillägg. Följande tabell är en lista med exempelfiler som du hittar för en CimFS-avbildning:

Filnamn Storlek
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

Följande tabell är en prestandajämförelse mellan VHDX och CimFS. Dessa siffror var resultatet av en testkörning med 500 filer på 300 MB vardera per format och testerna utfördes på en virtuell DSv4 Azure-dator.

Metrisk VHD CimFS
Genomsnittlig monteringstid 356 ms 255 ms
Genomsnittlig avmonteringstid 1615 ms 36 ms
Minnesförbrukning 6 % (av 8 GB) 2 % (av 8 GB)
CPU (antalstoppar) Maxat flera gånger Ingen effekt

Försiktighet

Ett problem påverkar för närvarande CimFS-avbildningar med Windows 11 version 24H2, vilket förhindrar att avbildningarna monteras. Vi arbetar aktivt med en korrigering som beräknas vara tillgänglig i juni 2025. Lösningar är att använda VHDX-avbildningar i stället eller använda en version av Windows 11 före 24H2.

Programregistrering

App Attach monterar diskbilder eller App-V-paket som innehåller dina program från en filresurs till en användares session under inloggningen. En registreringsprocess gör sedan programmen tillgängliga för användaren. Det finns två typer av registrering:

  • På begäran: program registreras endast delvis vid inloggning och den fullständiga registreringen av ett program skjuts upp tills användaren startar programmet. På begäran är den registreringstyp som vi rekommenderar att du använder eftersom det inte påverkar den tid det tar att logga in på Azure Virtual Desktop. På begäran är standardregistreringsmetoden.

  • Blockering av loggar: varje program som du tilldelar till en användare är helt registrerat. Registreringen sker när användaren loggar in på sin session, vilket kan påverka inloggningstiden till Azure Virtual Desktop.

Viktigt

Alla MSIX- och Appx-programpaket innehåller ett certifikat. Du ansvarar för att se till att certifikaten är betrodda i din miljö. Självsignerade certifikat stöds med lämplig förtroendekedja.

Appkoppling begränsar inte antalet program som användare kan använda. Du bör överväga ditt tillgängliga nätverksdataflöde och antalet öppna referenser per fil (varje bild) som filresursen stöder, eftersom det kan begränsa antalet användare eller program som du kan stödja. Mer information finns i Filresurs.

Programtillstånd

Programpaket anges som aktiva eller inaktiva. Paket som har angetts som aktiva gör programmet tillgängligt för användare. Azure Virtual Desktop ignorerar paket som angetts som inaktiva och läggs inte till när en användare loggar in.

Nya programversioner

Du kan lägga till en ny version av ett program genom att ange en ny avbildning som innehåller det uppdaterade programmet. Du kan använda den här nya avbildningen på två sätt:

  • Sida vid sida: Skapa ett nytt program med hjälp av den nya diskbilden och tilldela det till samma värdpooler och användare som det befintliga programmet.

  • På plats: Skapa en ny avbildning där programmets versionsnummer ändras och uppdatera sedan det befintliga programmet så att den nya avbildningen används. Versionsnumret kan vara högre eller lägre, men du kan inte uppdatera ett program med samma versionsnummer. Ta inte bort den befintliga avbildningen förrän alla användare har använt den.

När de har uppdaterats får användarna den uppdaterade programversionen nästa gång de loggar in. Användarna behöver inte sluta använda den tidigare versionen för att lägga till en ny version.

Identitetsprovidrar

Här är de identitetsprovidrar som du kan använda med App Attach:

Identitetsprovider Status
Microsoft Entra ID Stöds
Active Directory Domain Services (AD DS) Stöds
Microsoft Entra Domain Services Stöds inte

Filresurs

Appanslutning kräver att dina programbilder lagras på en SMB-filresurs, som sedan monteras på varje sessionsvärd under inloggningen. Appkopplingen har inte beroenden för vilken typ av lagringsinfrastruktur som filresursen använder. Vi rekommenderar att du använder Azure Files eftersom det är kompatibelt med Microsoft Entra ID eller Active Directory Domain Services och erbjuder ett bra värde mellan kostnader och hanteringskostnader.

Du kan också använda Azure NetApp Files, men det kräver att dina sessionsvärdar är anslutna till Active Directory Domain Services.

Följande avsnitt innehåller vägledning om de behörigheter, prestanda och tillgänglighet som krävs för filresursen.

Behörigheter

Varje sessionsvärd monterar programbilder från filresursen. Du måste konfigurera NTFS och dela behörigheter så att varje sessionsvärddatorobjekt kan läsa åtkomst till filerna och filresursen. Hur du konfigurerar rätt behörighet beror på vilken lagringsprovider och identitetsprovider du använder för filresursen och sessionsvärdarna.

  • Om du vill använda Azure Files när sessionsvärdarna är anslutna till Microsoft Entra ID måste du tilldela rollbaserad åtkomstkontrollrollen läsare och dataåtkomst i Azure till både Azure Virtual Desktop och AZURE Virtual Desktop ARM Provider-tjänstens huvudnamn. Med den här RBAC-rolltilldelningen kan sessionsvärdarna komma åt lagringskontot med hjälp av åtkomstnycklar eller Microsoft Entra.

  • Information om hur du tilldelar en Azure RBAC-roll till tjänstens huvudnamn för Azure Virtual Desktop finns i Tilldela RBAC-roller till Azure Virtual Desktop-tjänstens huvudnamn. I en framtida uppdatering behöver du inte tilldela tjänstens huvudnamn för Azure Virtual Desktop ARM-providern .

    Mer information om hur du använder Azure Files med sessionsvärdar som är anslutna till Microsoft Entra ID, Active Directory Domain Services eller Microsoft Entra Domain Services finns i Översikt över Azure Files identitetsbaserade autentiseringsalternativ för SMB-åtkomst.

    Varning

    Genom att tilldela tjänstens huvudnamn för Azure Virtual Desktop ARM-providern till lagringskontot tilldelas Azure Virtual Desktop-tjänsten till alla data i lagringskontot. Vi rekommenderar att du bara lagrar appar som ska användas med App Attach i det här lagringskontot och roterar åtkomstnycklarna regelbundet.

  • För Azure Files med Active Directory Domain Services måste du tilldela rollbaserad åtkomstkontrollroll (RBAC) för Storage File Data SMB Share Reader som standardbehörighet på resursnivå och konfigurera NTFS-behörigheter för att ge läsbehörighet till varje sessionsvärds datorobjekt.

    Mer information om hur du använder Azure Files med sessionsvärdar som är anslutna till Microsoft Entra ID, Active Directory Domain Services eller Microsoft Entra Domain Services finns i Översikt över Azure Files identitetsbaserade autentiseringsalternativ för SMB-åtkomst.

  • För Azure NetApp Files kan du skapa en SMB-volym och konfigurera NTFS-behörigheter för att ge läsbehörighet till varje sessionsvärds datorobjekt. Sessionsvärdarna måste vara anslutna till Active Directory Domain Services eller Microsoft Entra Domain Services.

Du kan kontrollera att behörigheterna är korrekta med hjälp av PsExec. Mer information finns i Kontrollera filresursåtkomst.

Prestanda

Kraven kan variera mycket beroende på hur många paketerade program som lagras i en avbildning och du måste testa dina program för att förstå dina krav. För större avbildningar måste du allokera mer bandbredd. I följande tabell visas ett exempel på kraven för en enskild avbildning på 1 GB eller Ett App-V-paket som innehåller ett program som kräver varje sessionsvärd:

Resurs Krav
IOPS för stabilt tillstånd En IOP
Inloggning för datorstart 10 IOPS
Latens 400 ms

För att optimera prestanda för dina program rekommenderar vi:

  • Filresursen bör finnas i samma Azure-region som sessionsvärdarna. Om du använder Azure Files måste ditt lagringskonto finnas i samma Azure-region som dina sessionsvärdar.

  • Undanta diskbilderna som innehåller dina program från antivirusgenomsökningar eftersom de är skrivskyddade.

  • Se till att din lagrings- och nätverksinfrastruktur kan ge tillräcklig prestanda. Du bör undvika att använda samma filresurs med FSLogix-profilcontainrar.

Tillgänglighet

Eventuella haveriberedskapsplaner för Azure Virtual Desktop måste inkludera replikering av filresursen till den sekundära redundansplatsen. Du måste också se till att sökvägen till filresursen är tillgänglig på den sekundära platsen. Du kan till exempel använda DFS-namnområden (Distributed File System) med Azure Files för att ange ett enda resursnamn för olika filresurser. Mer information om haveriberedskap för Azure Virtual Desktop finns i Konfigurera en plan för affärskontinuitet och haveriberedskap.

Azure Files

Azure Files har gränser för antalet öppna referenser per rotkatalog, katalog och fil. VHDX- eller CimFS-diskavbildningar monteras med sessionsvärdens datorkonto, vilket innebär att en handtag öppnas per sessionsvärd per diskavbildning i stället för per användare. Mer information om begränsningar och storleksvägledning finns i Azure Files skalbarhets- och prestandamål och Azure Files storleksvägledning för Azure Virtual Desktop.

MSIX- och Appx-paketcertifikat

Alla MSIX- och Appx-paket kräver ett giltigt kodsigneringscertifikat. Om du vill använda dessa paket med App Attach måste du se till att hela certifikatkedjan är betrodd på sessionsvärdarna. Ett kodsigneringscertifikat har objektidentifieraren 1.3.6.1.5.5.7.3.3. Du kan hämta ett kodsigneringscertifikat för dina paket från:

  • En offentlig certifikatutfärdare (CA).

  • Ett internt företag eller fristående certifikatutfärdare, till exempel Active Directory Certificate Services. Du måste exportera kodsigneringscertifikatet, inklusive dess privata nyckel.

  • Ett verktyg som PowerShell-cmdleten New-SelfSignedCertificate som genererar ett självsignerat certifikat. Du bör bara använda självsignerade certifikat i en testmiljö. Mer information om hur du skapar ett självsignerat certifikat för MSIX- och Appx-paket finns i Skapa ett certifikat för paketsignering.

När du har skaffat ett certifikat måste du signera DINA MSIX- eller Appx-paket digitalt med certifikatet. Du kan använda MSIX-paketeringsverktyget för att signera dina paket när du skapar ett MSIX-paket. Mer information finns i Skapa ett MSIX-paket från alla skrivbordsinstallationsprogram.

För att säkerställa att certifikatet är betrott på sessionsvärdarna behöver du dina sessionsvärdar för att lita på hela certifikatkedjan. Hur sessionsvärdarna litar på certifikatkedjan beror på varifrån du fick certifikatet och hur du hanterar sessionsvärdarna och identitetsprovidern som du använder. Följande tabell innehåller vägledning om hur du ser till att certifikatet är betrott på dina sessionsvärdar:

  • Offentlig certifikatutfärdare: Certifikat från en offentlig certifikatutfärdare är betrodda som standard i Windows och Windows Server.

  • Intern företags-CA:

    • För sessionsvärdar som är anslutna till Active Directory, med AD CS konfigurerat som intern företagscertifikatutfärdarorganisation, är betrodda som standard och lagras i konfigurationsnamngivningskontexten för Active Directory Domain Services. När AD CS är en konfigurerad som en fristående certifikatutfärdare måste du konfigurera grupprincip för att distribuera rotcertifikat och mellanliggande certifikat till sessionsvärdar. Mer information finns i Distribuera certifikat till Windows-enheter med hjälp av grupprincip.

    • För sessionsvärdar som är anslutna till Microsoft Entra ID kan du använda Microsoft Intune för att distribuera rotcertifikat och mellanliggande certifikat till sessionsvärdar. Mer information finns i Betrodda rotcertifikatprofiler för Microsoft Intune.

    • För sessionsvärdar som använder Microsoft Entra hybridanslutning kan du använda någon av de tidigare metoderna, beroende på dina krav.

  • Självsignerad: Installera den betrodda roten i arkivet Betrodda rotcertifikatutfärdare på varje sessionsvärd. Vi rekommenderar inte att du distribuerar det här certifikatet med hjälp av grupprincip eller Intune eftersom det endast ska användas för testning.

Viktigt

Du bör tidsstämpla paketet så att dess giltighet kan vara längre än certifikatets förfallodatum. När certifikatet upphör att gälla måste du annars uppdatera paketet med ett nytt giltigt certifikat och återigen se till att sessionsvärdarna litar på certifikatkedjan.

Nästa steg

Lär dig hur du lägger till och hanterar program för appkoppling i Azure Virtual Desktop.