Sdílet prostřednictvím


Připojení aplikace ve službě Azure Virtual Desktop

Připojení aplikace umožňuje dynamicky připojovat aplikace z balíčku aplikace k uživatelské relaci ve službě Azure Virtual Desktop. Aplikace nejsou nainstalované místně na hostitelích relací nebo imagích, což usnadňuje vytváření vlastních imagí pro hostitele relací a snižuje provozní režii a náklady pro vaši organizaci. Aplikace běží v kontejnerech, které oddělují uživatelská data, operační systém a další aplikace, což zvyšuje zabezpečení a usnadňuje řešení potíží.

Tady jsou některé z klíčových výhod připojení aplikace:

  • Aplikace se doručují pomocí RemoteAppu nebo jako součást relace plochy. Oprávnění se použijí pro jednotlivé aplikace na uživatele, takže máte větší kontrolu nad aplikacemi, ke kterým mají uživatelé ve vzdálené relaci přístup. Desktopovým uživatelům se zobrazí jenom přiřazené aplikace pro připojení aplikací.
  • Stejný balíček aplikace je možné použít ve více fondech hostitelů.
  • Aplikace můžou běžet na libovolném hostiteli relace s klientským operačním systémem Windows ve stejné oblasti Azure jako balíček aplikace.
  • Aplikace je možné upgradovat na novou verzi aplikace s novou imagí disku bez nutnosti časového období údržby.
  • Uživatelé můžou na stejném hostiteli relace současně spouštět více verzí stejné aplikace.
  • Telemetrie pro využití a stav je k dispozici prostřednictvím Azure Log Analytics.

Můžete použít následující typy balíčků aplikací a formáty souborů:

Typ balíčku Formáty souborů
MSIX a sada MSIX .msix
.msixbundle
Sada Appx a Appx .appx
.appxbundle
App-V .appv

MSIX a Appx jsou formáty balíčků aplikací pro Windows, které poskytují moderní prostředí pro vytváření balíčků aplikací pro Windows. Aplikace běží v kontejnerech, které oddělují uživatelská data, operační systém a další aplikace, což zvyšuje zabezpečení a usnadňuje řešení potíží. MSIX a Appx jsou podobné, kde hlavní rozdíl spočívá v tom, že MSIX je nadmnožinou Appx. MSIX podporuje všechny funkce Appx a další funkce, díky kterým je vhodnější pro podnikové použití.

Microsoft Application Virtualization (App-V) pro Windows poskytuje uživatelům aplikace Win32 jako virtuální aplikace. Virtuální aplikace se instalují na centrálně spravované servery a dodávají se uživatelům jako služba v reálném čase a podle potřeby. Uživatelé spouštějí virtuální aplikace ze známých přístupových bodů a pracují s nimi, jako by byly nainstalované místně.

Balíčky MSIX můžete získat od dodavatelů softwaru nebo můžete vytvořit balíček MSIX z existujícího instalačního programu. Další informace o MSIX najdete v tématu Co je MSIX?.

Jak uživatel získá aplikaci

Různé aplikace můžete přiřadit různým uživatelům ve stejném fondu hostitelů nebo na stejném hostiteli relace. Během přihlašování musí být splněny všechny tři následující požadavky, aby uživatel získal správnou aplikaci ve správný čas:

  • Aplikace musí být přiřazena k fondu hostitelů. Přiřazení aplikace do fondu hostitelů vám umožní vybrat, ve kterých fondech hostitelů je aplikace k dispozici, abyste zajistili, že aplikace bude mít k dispozici správné hardwarové prostředky. Pokud je například aplikace náročná na grafiku, můžete zajistit, aby běžela jenom ve fondu hostitelů s hostiteli relací optimalizovanými pro GPU.

  • Uživatel se musí mít možnost přihlásit k hostitelům relací ve fondu hostitelů, takže musí být ve skupině aplikací Vzdálená plocha nebo Vzdálená aplikace RemoteApp. U skupiny aplikací RemoteApp musí být aplikace Připojení aplikace přidána do skupiny aplikací, ale nemusíte ji přidávat do skupiny desktopových aplikací.

  • Aplikace musí být přiřazena uživateli. Můžete použít skupinu nebo uživatelský účet.

Pokud jsou všechny tyto požadavky splněny, uživatel získá aplikaci. Tento proces poskytuje kontrolu nad tím, kdo získá aplikaci ve kterém fondu hostitelů a jak je možné, aby uživatelé v rámci jednoho fondu hostitelů nebo se dokonce přihlásili ke stejnému hostiteli relace s více relacemi, získali různé kombinace aplikací. Uživatelé, kteří nesplňují požadavky, aplikaci nezískají.

Image aplikací

Než budete moct používat balíčky aplikací MSIX se službou Azure Virtual Desktop, musíte z existujících balíčků aplikací vytvořit image MSIX . Alternativně můžete místo toho použít balíček App-V. Každou image MSIX nebo balíček App-V pak musíte uložit do sdílené složky, ke které mají přístup hostitelé relací. Další informace o požadavcích na sdílenou složku najdete v tématu Sdílená složka.

Typy imagí disků

U imagí disků MSIX a Appx můžete použít Systém souborů složených obrázků (CimFS),VHDX nebo VHD, ale nedoporučujeme používat VHD. Připojení a odpojování imagí CimFS je rychlejší než image VHD a VHDX a také spotřebovává méně procesoru a paměti. Pro image aplikací doporučujeme používat CimFS jenom v případě, že hostitelé relací používají Windows 11.

Obrázek CimFS je kombinací několika souborů: jeden soubor má příponu .cim souboru a obsahuje metadata spolu s nejméně dvěma dalšími soubory, jeden počínaje objectid_ a druhý počínaje region_ , které obsahují skutečná data aplikace. Doprovodné .cim soubory nemají příponu souboru. Následující tabulka obsahuje seznam ukázkových souborů, které byste našli pro image CimFS:

Název souboru Velikost
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

Následující tabulka uvádí porovnání výkonu mezi VHDX a CimFS. Tato čísla byla výsledkem testovacího běhu s 500 soubory o velikosti 300 MB pro každý formát a testy se provedly na virtuálním počítači Azure DSv4.

Metrický VHD CimFS
Průměrná doba připojení 356 ms 255 ms
Average unmount time 1615 ms 36 ms
Využití paměti 6 % (z 8 GB) 2 % (z 8 GB)
Procesor (špička počtu) Maxed out multiple times Bez efektu

Registrace aplikace

Připojení aplikace připojí image disku nebo balíčky App-V obsahující vaše aplikace ze sdílené složky do relace uživatele během přihlašování a pak proces registrace zpřístupní aplikace uživateli. Existují dva typy registrace:

  • Na vyžádání: Aplikace se při přihlášení zaregistrují jenom částečně a úplná registrace aplikace se odloží, dokud uživatel aplikaci nesstartuje. Doporučujeme použít typ registrace na vyžádání, protože nemá vliv na dobu potřebnou k přihlášení ke službě Azure Virtual Desktop. Výchozí metoda registrace je na vyžádání.

  • Blokování přihlášení: Každá aplikace, kterou přiřadíte uživateli, je plně zaregistrovaná. Registrace probíhá, když se uživatel přihlašuje ke své relaci, což může mít vliv na čas přihlášení ke službě Azure Virtual Desktop.

Důležité

Všechny balíčky aplikací MSIX a Appx obsahují certifikát. Zodpovídáte za to, že certifikáty jsou ve vašem prostředí důvěryhodné. Certifikáty podepsané svým držitelem se podporují s odpovídajícím řetězem důvěryhodnosti.

Připojení aplikace neomezuje počet aplikací, které můžou uživatelé používat. Měli byste zvážit dostupnou propustnost sítě a počet otevřených popisovačů na soubor (každý obrázek), který vaše sdílená složka podporuje, protože to může omezit počet uživatelů nebo aplikací, které můžete podporovat. Další informace najdete v tématu Sdílená složka.

Stav aplikace

Balíčky aplikací jsou nastavené jako aktivní nebo neaktivní. Balíčky nastavené na aktivní zpřístupňuje aplikaci uživatelům. Azure Virtual Desktop ignoruje balíčky nastavené na neaktivní a nepřidají se, když se uživatel přihlásí.

Nové verze aplikací

Novou verzi aplikace můžete přidat tak, že zadáte novou image obsahující aktualizovanou aplikaci. Tento nový obrázek můžete použít dvěma způsoby:

  • Vedle sebe: Vytvořte novou aplikaci pomocí nové image disku a přiřaďte ji stejným fondům hostitelů a uživatelům jako stávající aplikace.

  • Místně: Vytvořte novou image, kde se změní číslo verze aplikace, a pak aktualizujte existující aplikaci tak, aby používala novou image. Číslo verze může být vyšší nebo nižší, ale nemůžete aktualizovat aplikaci se stejným číslem verze. Neodstraňovat existující image, dokud ji všichni uživatelé nedokončí.

Po aktualizaci získají uživatelé aktualizovanou verzi aplikace při příštím přihlášení. Uživatelé nemusí přestat používat předchozí verzi, aby mohli přidat novou verzi.

Zprostředkovatelé identit

Tady jsou zprostředkovatelé identity, které můžete použít s připojením aplikace:

Zprostředkovatel identity Stav
Microsoft Entra ID Podporováno
Active Directory Domain Services (AD DS) Podporováno
Microsoft Entra Doménové služby Není podporováno

Sdílená složka

Připojení aplikace vyžaduje, aby image aplikace byly uložené ve sdílené složce SMB, která se pak při přihlašování připojí k hostiteli každé relace. Připojení aplikace nemá závislosti na typu prostředků infrastruktury úložiště, které sdílená složka používá. Doporučujeme používat Azure Files, protože je kompatibilní s Microsoft Entra ID nebo Active Directory Domain Services a nabízí velkou hodnotu mezi náklady a režií na správu.

Můžete také použít Azure NetApp Files, ale to vyžaduje připojení hostitelů relací k Active Directory Domain Services.

Následující části obsahují pokyny k oprávněním, výkonu a dostupnosti požadovaných pro sdílenou složku.

Oprávnění

Každý hostitel relace připojí image aplikací ze sdílené složky. Musíte nakonfigurovat oprávnění NTFS a sdílení, aby každý objekt počítače hostitele relace povolil přístup ke čtení souborů a sdílené složky. Způsob konfigurace správného oprávnění závisí na tom, kterého zprostředkovatele úložiště a zprostředkovatele identity používáte pro sdílenou složku a hostitele relací.

  • Pokud chcete použít Azure Files, když se hostitelé relace připojí k Microsoft Entra ID, musíte přiřadit roli Řízení přístupu na základě role (RBAC) v Azure čtenář a přístup k datům k instančním objektům azure Virtual Desktopu i poskytovateli služeb ARM služby Azure Virtual Desktop. Toto přiřazení role RBAC umožňuje hostitelům relací přístup k účtu úložiště pomocí přístupových klíčů nebo Microsoft Entra.

  • Informace o přiřazení role Azure RBAC k instančním objektům služby Azure Virtual Desktop najdete v tématu Přiřazení rolí RBAC k instančním objektům služby Azure Virtual Desktop. V budoucí aktualizaci nebudete muset přiřazovat instanční objekt poskytovatele ARM služby Azure Virtual Desktop .

    Další informace o používání Azure Files s hostiteli relací připojenými k Microsoft Entra ID, Active Directory Domain Services nebo Microsoft Entra Doménové služby najdete v tématu Přehled Azure Files Možnosti ověřování na základě identit pro přístup k protokolu SMB.

    Upozornění

    Přiřazení instančního objektu poskytovatele AZURE Virtual Desktop ARM k účtu úložiště udělí službu Azure Virtual Desktop pro všechna data v účtu úložiště. V tomto účtu úložiště doporučujeme ukládat jenom aplikace pro použití s připojením aplikace a pravidelně obměňovat přístupové klíče.

  • Pro Azure Files s Active Directory Domain Services musíte jako výchozí oprávnění na úrovni sdílené složky přiřadit roli RBAC (RBAC) v Azure pro řízení přístupu na základě role a nakonfigurovat oprávnění NTFS tak, aby poskytovala přístup ke čtení k objektu počítače každého hostitele relace.

    Další informace o používání Azure Files s hostiteli relací připojenými k Microsoft Entra ID, Active Directory Domain Services nebo Microsoft Entra Doménové služby najdete v tématu Přehled Azure Files Možnosti ověřování na základě identit pro přístup k protokolu SMB.

  • Pro Azure NetApp Files můžete vytvořit svazek SMB a nakonfigurovat oprávnění NTFS tak, aby poskytovala přístup ke čtení k objektu počítače každého hostitele relace. Hostitelé relací musí být připojení k Active Directory Domain Services nebo Microsoft Entra Doménové služby.

Správnost oprávnění můžete ověřit pomocí nástroje PsExec. Další informace najdete v tématu Kontrola přístupu ke sdílené složce.

Představení

Požadavky se můžou výrazně lišit v závislosti na tom, kolik zabalených aplikací je uložených v imagi, a abyste porozuměli vašim požadavkům, potřebujete aplikace otestovat. U větších imagí je potřeba přidělit větší šířku pásma. Následující tabulka uvádí příklad požadavků na jednu 1GB image nebo balíček App-V obsahující jednu aplikaci, která vyžaduje každého hostitele relace:

Zdroj Požadavky
Vstupně-výstupní operace za stabilní stav Jeden IOP
Přihlášení ke spuštění počítače 10 vstupně-výstupních operací za sekundu
Latence 400 ms

Pokud chcete optimalizovat výkon vašich aplikací, doporučujeme:

  • Sdílená složka by měla být ve stejné oblasti Azure jako hostitelé relací. Pokud používáte Azure Files, musí být váš účet úložiště ve stejné oblasti Azure jako hostitelé relací.

  • Vylučte diskové bitové kopie obsahující vaše aplikace z antivirových kontrol, protože jsou jen pro čtení.

  • Ujistěte se, že úložiště a síťové prostředky infrastruktury poskytují odpovídající výkon. Neměli byste používat stejnou sdílenou složku s kontejnery profilů FSLogix.

Dostupnost

Všechny plány zotavení po havárii pro Azure Virtual Desktop musí zahrnovat replikaci sdílené složky do sekundárního umístění převzetí služeb při selhání. Musíte také zajistit, aby cesta ke sdílené složce byla přístupná v sekundárním umístění. Můžete například použít obory názvů systému souborů DFS (Distributed File System) s Azure Files a zadat jeden název sdílené složky napříč různými sdílenými složkami. Další informace o zotavení po havárii pro Službu Azure Virtual Desktop najdete v tématu Nastavení plánu provozní kontinuity a zotavení po havárii.

Azure Files

Azure Files má omezení počtu otevřených popisovačů na kořenový adresář, adresář a soubor. Image disků VHDX nebo CimFS se připojují pomocí účtu počítače hostitele relace, což znamená, že je otevřen jeden popisovač pro každého hostitele relace na diskovou image, nikoli na uživatele. Další informace o omezeních a pokynech k určení velikosti najdete v tématu Azure Files cíle škálovatelnosti a výkonu a pokyny k Azure Files určení velikosti pro Službu Azure Virtual Desktop.

Certifikáty balíčků MSIX a Appx

Všechny balíčky MSIX a Appx vyžadují platný certifikát pro podepisování kódu. Pokud chcete tyto balíčky používat s připojením aplikace, musíte zajistit, aby byl celý řetěz certifikátů na hostitelích relací důvěryhodný. Podpisový certifikát kódu má identifikátor 1.3.6.1.5.5.7.3.3objektu . Certifikát pro podepisování kódu pro balíčky můžete získat z:

  • Veřejná certifikační autorita (CA).

  • Interní podniková nebo samostatná certifikační autorita, jako je služba Active Directory Certificate Services. Musíte exportovat certifikát pro podepisování kódu, včetně jeho privátního klíče.

  • Nástroj, jako je rutina Prostředí PowerShell New-SelfSignedCertificate , která generuje certifikát podepsaný svým držitelem. V testovacím prostředí byste měli používat pouze certifikáty podepsané svým držitelem. Další informace o vytvoření certifikátu podepsaného svým držitelem pro balíčky MSIX a Appx najdete v tématu Vytvoření certifikátu pro podepisování balíčků.

Jakmile získáte certifikát, musíte s certifikátem digitálně podepsat balíčky MSIX nebo Appx. Při vytváření balíčku MSIX můžete balíčky podepsat pomocí nástroje MSIX Packaging Tool . Další informace najdete v tématu Vytvoření balíčku MSIX z libovolného desktopového instalačního programu.

Pokud chcete zajistit, aby byl certifikát na hostitelích relací důvěryhodný, potřebujete, aby hostitelé relací důvěřovali celému řetězu certifikátů. To, jak hostitelé relací důvěřují řetězu certifikátů, závisí na tom, odkud jste certifikát získali a jak spravujete hostitele relací a zprostředkovatele identity, kterého používáte. Následující tabulka obsahuje pokyny, jak zajistit, aby byl certifikát na hostitelích relací důvěryhodný:

  • Veřejná certifikační autorita: Certifikáty z veřejné certifikační autority jsou ve windows a Windows Server ve výchozím nastavení důvěryhodné.

  • Interní certifikační autorita organizace:

    • Hostitelé relací připojení ke službě Active Directory s nakonfigurovanou službou AD CS jako interní certifikační autoritou organizace jsou ve výchozím nastavení důvěryhodní a ukládají se v kontextu názvů konfigurace Active Directory Domain Services. Pokud je služba AD CS nakonfigurovaná jako samostatná certifikační autorita, musíte nakonfigurovat Zásady skupiny pro distribuci kořenových a zprostředkujících certifikátů hostitelům relací. Další informace najdete v tématu Distribuce certifikátů do zařízení s Windows pomocí Zásady skupiny.

    • U hostitelů relací připojených k Microsoft Entra ID můžete použít Microsoft Intune k distribuci kořenových a zprostředkujících certifikátů hostitelům relací. Další informace najdete v tématu Profily důvěryhodných kořenových certifikátů pro Microsoft Intune.

    • V případě hostitelů relací, kteří používají Microsoft Entra hybridní připojení, můžete v závislosti na vašich požadavcích použít některou z předchozích metod.

  • Podepsaný svým držitelem: Nainstalujte důvěryhodný kořenový adresář do úložiště důvěryhodných kořenových certifikačních autorit na každém hostiteli relace. Nedoporučujeme distribuovat tento certifikát pomocí Zásady skupiny nebo Intune, protože by se měl používat jenom pro testování.

Důležité

Měli byste balíček časového razítka, aby jeho platnost přečkala datum vypršení platnosti vašeho certifikátu. Jinak po vypršení platnosti certifikátu budete muset balíček aktualizovat novým platným certifikátem a znovu zajistit, aby hostitelé relací důvěřovali řetězu certifikátů.

Další kroky

Naučte se přidávat a spravovat aplikace pro připojení aplikací ve službě Azure Virtual Desktop.