Dołączanie aplikacji w usłudze Azure Virtual Desktop

Dołączanie aplikacji umożliwia dynamiczne dołączanie aplikacji z pakietu aplikacji do sesji użytkownika w usłudze Azure Virtual Desktop. Aplikacje nie są instalowane lokalnie na hostach ani obrazach sesji, co ułatwia tworzenie obrazów niestandardowych dla hostów sesji oraz zmniejsza obciążenie operacyjne i koszty ponoszone przez organizację. Aplikacje są uruchamiane w kontenerach, które oddzielają dane użytkownika, system operacyjny i inne aplikacje, zwiększając bezpieczeństwo i ułatwiając rozwiązywanie problemów.

Oto niektóre z kluczowych zalet dołączania aplikacji:

  • Aplikacje są dostarczane za pomocą programu RemoteApp lub w ramach sesji pulpitu. Uprawnienia są stosowane dla poszczególnych aplikacji i poszczególnych użytkowników, co zapewnia większą kontrolę nad aplikacjami, do których użytkownicy mogą uzyskiwać dostęp podczas sesji zdalnej. Użytkownicy komputerów stacjonarnych widzą tylko przypisane do nich aplikacje dołączania aplikacji.

  • Ten sam pakiet aplikacji może być używany w wielu pulach hostów.

  • Aplikacje mogą być uruchamiane na dowolnym hoście sesji z uruchomionym klientem Windows lub obsługiwanym systemem operacyjnym Windows Server w tym samym regionie platformy Azure co pakiet aplikacji.

  • Aplikacje można uaktualnić do nowej wersji aplikacji przy użyciu nowego obrazu dysku bez konieczności tworzenia okna obsługi.

  • Użytkownicy mogą uruchamiać wiele wersji tej samej aplikacji jednocześnie na tym samym hoście sesji.

  • Dane telemetryczne dotyczące użycia i kondycji są dostępne za pośrednictwem usługi Azure Log Analytics.

Można korzystać z następujących typów pakietów aplikacji i formatów plików:

Rodzaj opakowania Formaty plików
Pakiet MSIX i MSIX .msix
.msixbundle
Appx i pakiet Appx .appx
.appxbundle
App-V .appv

MSIX i Appx to formaty pakietów aplikacji systemu Windows, które zapewniają nowoczesne środowisko tworzenia pakietów dla aplikacji systemu Windows. Aplikacje są uruchamiane w kontenerach, które oddzielają dane użytkownika, system operacyjny i inne aplikacje, zwiększając bezpieczeństwo i ułatwiając rozwiązywanie problemów. MSIX i Appx są podobne, gdzie główna różnica polega na tym, że MSIX jest nadzbiorem Appx. MSIX obsługuje wszystkie funkcje Appx oraz inne funkcje, które sprawiają, że jest bardziej odpowiedni do użytku w przedsiębiorstwach.

Microsoft Application Virtualization (App-V) dla systemu Windows dostarcza użytkownikom aplikacje Win32 jako aplikacje wirtualne. Aplikacje wirtualne są instalowane na centralnie zarządzanych serwerach i dostarczane użytkownikom jako usługa w czasie rzeczywistym i w zależności od potrzeb. Użytkownicy uruchamiają aplikacje wirtualne ze znanych punktów dostępu i wchodzą z nimi w interakcję tak, jakby były zainstalowane lokalnie.

Pakiety MSIX można uzyskać od dostawców oprogramowania lub utworzyć pakiet MSIX z istniejącego instalatora. Aby dowiedzieć się więcej o MSIX, zobacz Co to jest MSIX?.

W jaki sposób użytkownik otrzymuje aplikację

Możesz przypisać różne aplikacje do różnych użytkowników w tej samej puli hostów lub na tym samym hoście sesji. Podczas logowania muszą być spełnione wszystkie trzy z następujących wymagań, aby użytkownik mógł pobrać właściwą aplikację we właściwym czasie:

  • Aplikacja musi być przypisana do puli hostów. Przypisanie aplikacji do puli hostów umożliwia wybór pul hostów, w których aplikacja jest dostępna, aby upewnić się, że odpowiednie zasoby sprzętowe są dostępne dla aplikacji. Jeśli na przykład aplikacja intensywnie korzysta z grafiki, możesz upewnić się, że będzie ona działać tylko w puli hostów z hostami sesji zoptymalizowanymi pod kątem procesora GPU.

  • Użytkownik musi mieć możliwość zalogowania się do hostów sesji w puli hostów, więc musi znajdować się w grupie aplikacji klasycznych lub aplikacji RemoteApp. W przypadku grupy aplikacji RemoteApp aplikacja dołączania aplikacji musi zostać dodana do grupy aplikacji, ale nie trzeba dodawać aplikacji do grupy aplikacji klasycznych.

  • Aplikacja musi być przypisana do użytkownika. Możesz użyć grupy lub konta użytkownika.

Jeśli wszystkie te wymagania są spełnione, użytkownik otrzymuje aplikację. Ten proces zapewnia kontrolę nad tym, kto otrzymuje aplikację w której puli hostów, a także jak użytkownicy w pojedynczej puli hostów lub nawet zalogowani do tego samego hosta sesji wielosesyjnej mogą uzyskać różne kombinacje aplikacji. Użytkownicy, którzy nie spełniają wymagań, nie otrzymają aplikacji.

Obrazy aplikacji

Zanim będzie można używać pakietów aplikacji MSIX z usługą Azure Virtual Desktop, należy utworzyć obraz MSIX z istniejących pakietów aplikacji. Zamiast tego możesz użyć pakietu App-V. Następnie musisz przechowywać każdy obraz MSIX lub pakiet App-V w udziale plików, który jest dostępny dla hostów sesji. Aby uzyskać więcej informacji na temat wymagań dotyczących udziału plików, zobacz Udział plików.

Typy obrazów dysków

W przypadku obrazów dysków MSIX i Appx można użyć systemu plików obrazu kompozytowego (CimFS),VHDX lub VHD, ale nie zalecamy używania dysku VHD. Montowanie i odinstalowywanie obrazów systemu plików CimFS jest szybsze niż w przypadku obrazów VHD i VHDX, a także zużywa mniej procesora CPU i pamięci. Zalecamy używanie CimFS dla obrazów aplikacji tylko wtedy, gdy hosty sesji działają pod kontrolą systemu Windows 11.

Obraz systemu plików CimFS jest kombinacją kilku plików: jeden plik ma .cim rozszerzenie pliku i zawiera metadane wraz z co najmniej dwoma innymi plikami, jednym zaczynającym się objectid_ , a drugim region_ zawierającym rzeczywiste dane aplikacji. Pliki towarzyszące plikowi .cim nie mają rozszerzenia. Poniższa tabela zawiera listę przykładowych plików, które można znaleźć dla obrazu systemu CimFS:

Nazwa pliku Rozmiar
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

Poniższa tabela zawiera porównanie wydajności między dyskami VHDX i CimFS. Liczby te były wynikiem testu z 500 plikami po 300 MB każdy na format, a testy przeprowadzono na maszynie wirtualnej DSv4 Azure.

Metryka Wirtualny dysk twardy (VHD) CimFS
Średni czas montowania 356 ms 255 ms
Średni czas odmontowywania 1615 ms 36 ms
Zużycie pamięci 6% (z 8 GB) 2% (z 8 GB)
Procesor CPU (skok liczby) Wielokrotne osiąganie maksimum Brak efektu

Rejestracja aplikacji

Dołączanie aplikacji instaluje obrazy dysków lub pakiety App-V zawierające aplikacje z udziału plików do sesji użytkownika podczas logowania, a następnie proces rejestracji udostępnia aplikacje użytkownikowi. Istnieją dwa rodzaje rejestracji:

  • Na żądanie: aplikacje są rejestrowane tylko częściowo podczas logowania, a pełna rejestracja aplikacji jest odraczana do momentu uruchomienia aplikacji przez użytkownika. Zalecamy używanie typu rejestracji na żądanie, ponieważ nie wpływa on na czas potrzebny do zalogowania się do usługi Azure Virtual Desktop. Domyślną metodą rejestracji jest Na żądanie.

  • Blokowanie logowania: każda aplikacja przypisana do użytkownika jest w pełni zarejestrowana. Rejestracja odbywa się, gdy użytkownik loguje się do swojej sesji, co może mieć wpływ na czas logowania do usługi Azure Virtual Desktop.

Ważna

Wszystkie pakiety aplikacji MSIX i Appx zawierają certyfikat. To Ty odpowiadasz za to, aby certyfikaty były zaufane w Twoim środowisku. Certyfikaty z podpisem własnym są obsługiwane przez odpowiedni łańcuch zaufania.

Dołączanie aplikacji nie ogranicza liczby aplikacji, z których mogą korzystać użytkownicy. Należy wziąć pod uwagę dostępną przepływność sieci i liczbę otwartych dojść na plik (każdy obraz) obsługiwany przez udział plików, ponieważ może to ograniczyć liczbę użytkowników lub aplikacji, które można obsługiwać. Aby uzyskać więcej informacji, zobacz Udział plików.

Stan aplikacji

Pakiety aplikacji są ustawiane jako aktywne lub nieaktywne. Pakiety ustawione jako aktywne udostępniają aplikację użytkownikom. Usługa Azure Virtual Desktop ignoruje pakiety ustawione jako nieaktywne i nie są dodawane, gdy użytkownik się zaloguje.

Nowe wersje aplikacji

Nową wersję aplikacji można dodać, podając nowy obraz zawierający zaktualizowaną aplikację. Tego nowego obrazu możesz używać na dwa sposoby:

  • Obok siebie: utwórz nową aplikację przy użyciu nowego obrazu dysku i przypisz ją do tych samych pul hostów i użytkowników, co istniejąca aplikacja.

  • W miejscu: utwórz nowy obraz, gdzie numer wersji aplikacji ulega zmianie, a następnie zaktualizuj istniejącą aplikację, aby używała nowego obrazu. Numer wersji może być wyższy lub niższy, ale nie można zaktualizować aplikacji przy użyciu tego samego numeru wersji. Nie usuwaj istniejącego obrazu, dopóki wszyscy użytkownicy nie skończą z niego korzystać.

Po zaktualizowaniu użytkownicy otrzymają zaktualizowaną wersję aplikacji przy następnym logowaniu. Użytkownicy nie muszą zaprzestać używania poprzedniej wersji, aby dodać nową wersję.

Dostawcy tożsamości

Oto dostawcy tożsamości, których można używać z dołączaniem aplikacji:

Dostawca tożsamości Stan
Microsoft Entra ID Obsługiwane
Active Directory Domain Services (AD DS) Obsługiwane
Microsoft Entra Domain Services Nieobsługiwane

Udział plików

Dołączanie aplikacji wymaga, aby obrazy aplikacji były przechowywane w udziale plików SMB, który jest następnie instalowany na każdym hoście sesji podczas logowania. Dołączanie aplikacji nie ma zależności od typu sieci szkieletowej magazynu używanej przez udział plików. Zalecamy korzystanie z Azure Files, ponieważ jest on zgodny z Microsoft Entra ID lub Active Directory Domain Services i oferuje doskonałą relację kosztów z kosztami ogólnymi na zarządzanie.

Możesz także użyć plików Azure NetApp Files, ale wymaga to dołączenia hostów sesji do usług Active Directory Domain Services.

Poniższe sekcje zawierają pewne wskazówki dotyczące uprawnień, wydajności i dostępności wymaganych dla udziału plików.

Uprawnienia

Każdy host sesji instaluje obrazy aplikacji z udziału plików. Aby umożliwić każdemu obiektowi hosta sesji dostęp do odczytu do plików i udziału plików, należy skonfigurować system plików NTFS i uprawnienia udziału. Sposób konfigurowania poprawnych uprawnień zależy od tego, jakiego dostawcy magazynu i tożsamości używasz dla hostów sesji i udziału plików.

  • Aby używać usługi Azure Files, gdy hosty sesji są dołączone do usługi Tożsamość Microsoft Entra ID, należy przypisać rolę kontroli dostępu opartej na rolach (RBAC) czytnika i dostępu do danych platformy Azure zarówno do usługi Azure Virtual Desktop, jak i dostawcy ARM usługi Azure Virtual Desktop. To przypisanie roli RBAC umożliwia hostom sesji uzyskiwanie dostępu do konta magazynu przy użyciu kluczy dostępu lub usługi Microsoft Entra.

  • Aby dowiedzieć się, jak przypisać rolę kontroli dostępu opartej na rolach platformy Azure do jednostek usługi Azure Virtual Desktop, zobacz Przypisywanie ról RBAC do jednostek usługi Azure Virtual Desktop. W przyszłej aktualizacji nie trzeba przypisywać podmiotu zabezpieczeń dostawcy ARM usługi Azure Virtual Desktop.

    Aby uzyskać więcej informacji na temat korzystania z usługi Azure Files z hostami sesji przyłączonymi do usługi Microsoft Entra ID, usług Active Directory Domain Services lub usług Microsoft Entra Domain Services, zobacz Omówienie usługi Azure Files opcje uwierzytelniania opartego na tożsamościach dla dostępu do protokołu SMB.

    Ostrzeżenie

    Przypisanie podmiotu zabezpieczeń usługi dostawcy ARM usługi Azure Virtual Desktop do konta magazynu przyznaje usługę Azure Virtual Desktop do wszystkich danych na koncie magazynu. Zalecamy, aby na tym koncie magazynu przechowywać tylko aplikacje do użycia z dołączaniem aplikacji i regularnie zmieniać klawisze dostępu.

  • W przypadku Azure Files z programem Active Directory Domain Services należy przypisać rolę kontroli dostępu opartej na rolach (RBAC) Azure dane pliku magazynu jako domyślne uprawnienie na poziomie udziału, a także skonfigurować uprawnienia systemu plików NTFS w celu udzielenia dostępu do odczytu do obiektu komputera każdego hosta sesji.

    Aby uzyskać więcej informacji na temat korzystania z usługi Azure Files z hostami sesji przyłączonymi do usługi Microsoft Entra ID, usług Active Directory Domain Services lub usług Microsoft Entra Domain Services, zobacz Omówienie usługi Azure Files opcje uwierzytelniania opartego na tożsamościach dla dostępu do protokołu SMB.

  • W przypadku usługi Azure NetApp Files można utworzyć wolumin SMB i skonfigurować uprawnienia systemu plików NTFS w celu udzielenia dostępu do odczytu do obiektu komputera każdego hosta sesji. Hosty sesji muszą być przyłączone do usług domenowych Active Directory Domain Services lub usług domenowych Microsoft Entra Domain Services.

Poprawność uprawnień można sprawdzić za pomocą programu PsExec. Aby uzyskać więcej informacji, zobacz Sprawdzanie dostępu do udziału plików.

User and Deployment Configuration Files

W przypadku pakietów App-V dostarczanych za pośrednictwem dołączania aplikacji można użyć plików dynamicznej konfiguracji App-V w celu dostosowania zachowania aplikacji. Dołączanie aplikacji automatycznie wykrywa standardowe pliki konfiguracyjne, które są zgodne z oczekiwaną konwencją nazewnictwa. Jeśli znajdują się one w tym samym folderze co pakiet dołączania aplikacji, a plik xml ma prefiks z nazwą pliku App-V, pliki te są automatycznie kojarzone z pakietem aplikacji podczas przetwarzania. Jeśli ścieżka pliku to \share\folder\nazwa_pliku.appv, poniższe przykłady zostaną automatycznie wykryte i użyte z pakietem.

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

Pliki konfiguracyjne użytkownika są oceniane na poziomie użytkownika, co pozwala różnym użytkownikom na otrzymywanie różnych ustawień aplikacji. Z kolei pliki konfiguracji wdrożenia są stosowane na poziomie komputera i są współużytkowane przez wszystkich użytkowników hosta sesji. Obecnie konfiguracja użytkownika jest obsługiwana tylko w przypadku połączeń z pulpitem, a nie w przypadku zdalnych połączeń aplikacji.

Zaawansowane scenariusze mogą wymagać wielu plików konfiguracji użytkownika dla tej samej aplikacji. W takich przypadkach dodatkowe pliki konfiguracji użytkownika muszą zostać jawnie skojarzone z pakietem aplikacji za pomocą programu PowerShell.

Dołączanie aplikacji sprawdza obiekt zależności

  • Ścieżka pliku jest określona w polu DependencyName, która kończy się ciągiem UserConfig.xml

  • Zawiera pole wydawcy identyfikujące grupę zabezpieczeń usługi Microsoft Entra, która powinna otrzymać tę konfigurację. Wartość pola Publisher pakietu aplikacji musi być ustawiona na Identyfikator obiektu docelowej grupy zabezpieczeń.

Podczas logowania narzędzie dołączania aplikacji ocenia członkostwo użytkownika w grupach i stosuje odpowiednią konfigurację użytkownika na podstawie skojarzonej grupy.

Administratorzy powinni używać wielu plików konfiguracyjnych użytkowników tylko wtedy, gdy różne populacje użytkowników wymagają odrębnych ustawień aplikacji. Wdrożenia standardowe mogą nadal korzystać z automatycznie wykrytego pliku konfiguracji pojedynczego użytkownika.

Wydajność

Wymagania mogą się znacznie różnić w zależności od liczby spakowanych aplikacji przechowywanych w obrazie. Aby zrozumieć swoje wymagania, należy przetestować aplikacje. W przypadku większych obrazów trzeba przydzielić większą przepustowość. W poniższej tabeli przedstawiono przykłady wymagań, jakie pojedynczy obraz o rozmiarze 1 GB lub pakiet App-V zawierający jedną aplikację wymaga na hosta sesji:

Zasób Wymagania
Liczby operacji we/wy w stanie ustalonym Jedno we/wy
Logowanie do rozruchu komputera 10 operacji we/wy na sekundę
Opóźnienie 400 ms

Aby zoptymalizować wydajność aplikacji, zalecamy wykonanie następujących czynności:

  • Udział plików powinien znajdować się w tym samym regionie platformy Azure co hosty sesji. Jeśli używasz usługi Azure Files, konto magazynu musi znajdować się w tym samym regionie platformy Azure co hosty sesji.

  • Wyklucz obrazy dysków zawierające Twoje aplikacje ze skanowania antywirusowego, ponieważ są one tylko do odczytu.

  • Upewnij się, że magazyn i sieć szkieletowa mogą zapewnić odpowiednią wydajność. Należy unikać używania tego samego udziału plików z kontenerami profilów FSLogix.

Dostępność

Wszystkie plany odzyskiwania po awarii dla usługi Azure Virtual Desktop muszą obejmować replikowanie udziału plików do dodatkowej lokalizacji trybu failover. Musisz także upewnić się, że ścieżka udziału plików jest dostępna w lokalizacji dodatkowej. Możesz na przykład użyć przestrzeni nazw rozproszonego systemu plików (DFS) z usługą Azure Files, aby zapewnić jedną nazwę udziału w różnych udziałach plików. Aby dowiedzieć się więcej o odzyskiwaniu po awarii dla usługi Azure Virtual Desktop, zobacz Konfigurowanie planu ciągłości działania i odzyskiwania po awarii.

Azure Files

W usłudze Azure Files obowiązują ograniczenia liczby otwartych dojść na katalog główny, katalog i plik. Obrazy dysków VHDX lub CimFS są instalowane przy użyciu konta komputera hosta sesji, co oznacza, że jedno dojście jest otwierane dla każdego hosta sesji dla obrazu dysku, a nie dla użytkownika. Aby uzyskać więcej informacji na temat limitów i wskazówek dotyczących ustalania rozmiaru, zobacz cele docelowe skalowalności i wydajności usługi Azure Files oraz wskazówki dotyczące ustalania rozmiaru usługi Azure Files dla usługi Azure Virtual Desktop.

Certyfikaty pakietów MSIX i Appx

Wszystkie pakiety MSIX i Appx wymagają prawidłowego certyfikatu podpisywania kodu. Aby korzystać z tych pakietów z dołączaniem aplikacji, musisz upewnić się, że cały łańcuch certyfikatów jest zaufany na hostach sesji. Certyfikat podpisywania kodu ma identyfikator 1.3.6.1.5.5.7.3.3obiektu . Certyfikat podpisywania kodu dla pakietów można uzyskać z:

  • Publiczny urząd certyfikacji.

  • Wewnętrzny urząd certyfikacji przedsiębiorstwa lub autonomiczny urząd certyfikacji, na przykład usługi certyfikatów Active Directory. Musisz wyeksportować certyfikat podpisywania kodu, w tym jego klucz prywatny.

  • Narzędziem, takim jak polecenie cmdlet New-SelfSignedCertificate programu PowerShell, które generuje certyfikat z podpisem własnym. W środowisku testowym należy używać tylko certyfikatów z podpisem własnym. Aby uzyskać więcej informacji na temat tworzenia certyfikatu z podpisem własnym dla pakietów MSIX i Appx, zobacz Tworzenie certyfikatu do podpisywania pakietów.

Po uzyskaniu certyfikatu musisz cyfrowo podpisać pakiety MSIX lub Appx za pomocą tego certyfikatu. Do podpisywania pakietów można użyć narzędzia do tworzenia pakietów MSIX Packaging Tool podczas tworzenia pakietu MSIX. Aby uzyskać więcej informacji, zobacz Tworzenie pakietu MSIX z poziomu dowolnego instalatora klasycznego.

Aby mieć pewność, że certyfikat jest zaufany na hostach sesji, hosty sesji muszą ufać całemu łańcuchowi certyfikatów. To, w jakim stopniu hosty sesji ufają łańcuchowi certyfikatów, zależy od tego, skąd uzyskano certyfikat i jak zarządzasz hostami sesji oraz używanym dostawcą tożsamości. Poniższa tabela zawiera wskazówki dotyczące zapewniania zaufania certyfikatu na hostach sesji:

  • Publiczny urząd certyfikacji: certyfikaty z publicznego urzędu certyfikacji są domyślnie zaufane w systemach Windows i systemie Windows Server.

  • Wewnętrzny urząd certyfikacji przedsiębiorstwa:

    • W przypadku hostów sesji połączonych z usługą Active Directory, w których usługi AD CS są skonfigurowane jako wewnętrzny urząd certyfikacji przedsiębiorstwa, są one domyślnie zaufane i przechowywane w kontekście nazewnictwa konfiguracji usług Active Directory Domain Services. Gdy usługi AD CS są skonfigurowane jako autonomiczne urzędy certyfikacji, należy skonfigurować zasady grupy w celu dystrybucji certyfikatów głównych i pośrednich do hostów sesji. Aby uzyskać więcej informacji, zobacz Dystrybucja certyfikatów do urządzeń z systemem Windows przy użyciu zasady grupy.

    • W przypadku hostów sesji połączonych z usługą Microsoft Entra ID można użyć usługi Microsoft Intune do dystrybucji certyfikatów głównych i pośrednich do hostów sesji. Aby uzyskać więcej informacji, zobacz Profile zaufanych certyfikatów głównych dla usługi Microsoft Intune.

    • W przypadku hostów sesji korzystających ze sprzężenia hybrydowego usługi Microsoft Entra możesz użyć jednej z poprzednich metod, w zależności od wymagań.

  • Z podpisem własnym: zainstaluj zaufany element główny w magazynie zaufanych głównych urzędów certyfikacji na każdym hoście sesji. Nie zalecamy rozpowszechniania tego certyfikatu przy użyciu zasady grupy ani usługi Intune, ponieważ powinien on być używany tylko do testowania.

Ważna

Powinieneś oznaczyć paczkę sygnaturą czasową, aby jej ważność mogła przetrwać dłużej niż data ważności certyfikatu. W przeciwnym razie, po wygaśnięciu certyfikatu, należy zaktualizować pakiet przy użyciu nowego ważnego certyfikatu i ponownie upewnić się, że hosty sesji ufają łańcuchowi certyfikatów.

Następne kroki

Dowiedz się, jak dodawać aplikacje i zarządzać nimi w usłudze Azure Virtual Desktop.

  • Last updated on