Wymagania wstępne dotyczące usługi Azure Virtual Desktop

  • Artykuł

Istnieje kilka rzeczy, które należy rozpocząć korzystanie z usługi Azure Virtual Desktop. W tym miejscu możesz znaleźć wymagania wstępne, które należy spełnić, aby zapewnić użytkownikom komputery stacjonarne i aplikacje.

Na wysokim poziomie potrzebne są następujące elementy:

  • Konto platformy Azure z aktywną subskrypcją
  • Obsługiwany dostawca tożsamości
  • Obsługiwany system operacyjny dla maszyn wirtualnych hosta sesji
  • Odpowiednie licencje
  • Łączność sieciowa
  • Klient pulpitu zdalnego

Konto platformy Azure z aktywną subskrypcją

Do wdrożenia usługi Azure Virtual Desktop potrzebujesz konta platformy Azure z aktywną subskrypcją. Jeśli jeszcze go nie masz, możesz bezpłatnie utworzyć konto.

Aby wdrożyć usługę Azure Virtual Desktop, należy przypisać odpowiednie role kontroli dostępu na podstawie ról (RBAC) platformy Azure. Konkretne wymagania dotyczące roli zostały omówione w każdym z powiązanych artykułów dotyczących wdrażania usługi Azure Virtual Desktop, które są wymienione w sekcji Następne kroki .

Upewnij się również, że zarejestrowano dostawcę zasobów Microsoft.DesktopVirtualization dla subskrypcji. Aby sprawdzić stan dostawcy zasobów i zarejestrować się w razie potrzeby, wybierz odpowiednią kartę dla danego scenariusza i wykonaj kroki.

Ważne

Musisz mieć uprawnienia do rejestrowania dostawcy zasobów, który wymaga */register/action operacji. Jest to uwzględniane, jeśli Twoje konto ma przypisaną rolę współautora lub właściciela subskrypcji.

  1. Zaloguj się w witrynie Azure Portal.

  2. Wybierz pozycję Subskrypcje.

  3. Wybierz nazwę subskrypcji.

  4. Wybierz pozycję Dostawcy zasobów.

  5. Wyszukaj ciąg Microsoft.DesktopVirtualization.

  6. Jeśli stan to NotRegistered, wybierz pozycję Microsoft.DesktopVirtualization, a następnie wybierz pozycję Zarejestruj.

  7. Sprawdź, czy stan Microsoft.DesktopVirtualization ma wartość Zarejestrowano.

Tożsamość

Aby uzyskać dostęp do komputerów stacjonarnych i aplikacji z hostów sesji, użytkownicy muszą mieć możliwość uwierzytelniania. Microsoft Entra ID to scentralizowana usługa tożsamości w chmurze firmy Microsoft, która umożliwia korzystanie z tej funkcji. Identyfikator Entra firmy Microsoft jest zawsze używany do uwierzytelniania użytkowników w usłudze Azure Virtual Desktop. Hosty sesji można dołączyć do tej samej dzierżawy firmy Microsoft Entra lub do domeny usługi Active Directory przy użyciu usług domena usługi Active Directory Services (AD DS) lub Microsoft Entra Domain Services, zapewniając wybór elastycznych opcji konfiguracji.

Hosty sesji

Należy dołączyć hosty sesji, które udostępniają komputery stacjonarne i aplikacje do tej samej dzierżawy firmy Microsoft Entra co użytkownicy lub domeny usługi Active Directory (usługi AD DS lub Microsoft Entra Domain Services).

Uwaga

W przypadku usługi Azure Stack HCI można dołączać hosty sesji tylko do domeny usług domena usługi Active Directory Services.

Aby dołączyć hosty sesji do identyfikatora Entra firmy Microsoft lub domeny usługi Active Directory, potrzebne są następujące uprawnienia:

  • W przypadku identyfikatora Entra firmy Microsoft potrzebne jest konto, które może dołączać komputery do dzierżawy. Aby uzyskać więcej informacji, zobacz Zarządzanie tożsamościami urządzeń. Aby dowiedzieć się więcej na temat dołączania hostów sesji do identyfikatora Entra firmy Microsoft, zobacz Hosty sesji przyłączone do firmy Microsoft.

  • W przypadku domeny usługi Active Directory potrzebne jest konto domeny, które może dołączać komputery do domeny. W przypadku usług Microsoft Entra Domain Services należy być członkiem grupy kontrolerów domeny usługi AAD Administracja istrators.

Użytkownicy

Użytkownicy potrzebują kont, które znajdują się w identyfikatorze Microsoft Entra ID. Jeśli używasz również usług AD DS lub Microsoft Entra Domain Services we wdrożeniu usługi Azure Virtual Desktop, te konta muszą być tożsamościami hybrydowymi, co oznacza, że konta użytkowników są synchronizowane. Należy pamiętać o następujących kwestiach na podstawie używanego dostawcy tożsamości:

  • Jeśli używasz identyfikatora Entra firmy Microsoft z usługami AD DS, musisz skonfigurować usługę Microsoft Entra Połączenie, aby synchronizować dane tożsamości użytkownika między usługami AD DS i microsoft Entra ID.
  • Jeśli używasz identyfikatora Entra firmy Microsoft z usługami Microsoft Entra Domain Services, konta użytkowników są synchronizowane w jeden sposób z usługi Microsoft Entra ID do usług Microsoft Entra Domain Services. Ten proces synchronizacji jest automatyczny.

Ważne

Konto użytkownika musi istnieć w dzierżawie usługi Microsoft Entra używanej w usłudze Azure Virtual Desktop. Usługa Azure Virtual Desktop nie obsługuje kont B2B, B2C ani osobistych kont Microsoft.

W przypadku korzystania z tożsamości hybrydowych identyfikator UserPrincipalName (UPN) lub identyfikator zabezpieczeń (SID) musi być zgodny z domena usługi Active Directory Services i Microsoft Entra ID. Aby uzyskać więcej informacji, zobacz Obsługiwane tożsamości i metody uwierzytelniania.

Obsługiwane scenariusze tożsamości

W poniższej tabeli przedstawiono podsumowanie scenariuszy tożsamości obsługiwanych obecnie przez usługę Azure Virtual Desktop:

Scenariusz dotyczący tożsamości Hosty sesji Konta użytkowników
Microsoft Entra ID + AD DS Przyłączone do usług AD DS W usłudze Microsoft Entra ID i AD DS zsynchronizowano
Microsoft Entra ID + AD DS Dołączono do identyfikatora Entra firmy Microsoft W usłudze Microsoft Entra ID i AD DS zsynchronizowano
Microsoft Entra ID + Microsoft Entra Domain Services Przyłączone do usług Microsoft Entra Domain Services W usłudze Microsoft Entra ID i Microsoft Entra Domain Services zsynchronizowano
Microsoft Entra ID + Microsoft Entra Domain Services + AD DS Przyłączone do usług Microsoft Entra Domain Services W usłudze Microsoft Entra ID i AD DS zsynchronizowano
Microsoft Entra ID + Microsoft Entra Domain Services Dołączono do identyfikatora Entra firmy Microsoft W usłudze Microsoft Entra ID i Microsoft Entra Domain Services zsynchronizowano
Microsoft Entra-only Dołączono do identyfikatora Entra firmy Microsoft W identyfikatorze Entra firmy Microsoft

Aby uzyskać bardziej szczegółowe informacje na temat obsługiwanych scenariuszy tożsamości, w tym logowania jednokrotnego i uwierzytelniania wieloskładnikowego, zobacz Obsługiwane tożsamości i metody uwierzytelniania.

Kontener profilu FSLogix

Aby używać kontenera profilów FSLogix podczas dołączania hostów sesji do identyfikatora Entra firmy Microsoft, musisz przechowywać profile w usłudze Azure Files lub Azure NetApp Files , a konta użytkowników muszą być tożsamościami hybrydowymi. Należy utworzyć te konta w usługach AD DS i zsynchronizować je z identyfikatorem Entra firmy Microsoft. Aby dowiedzieć się więcej na temat wdrażania kontenera profilów FSLogix z różnymi scenariuszami tożsamości, zobacz następujące artykuły:

Parametry wdrożenia

Podczas wdrażania hostów sesji należy wprowadzić następujące parametry tożsamości:

  • Nazwa domeny, jeśli używasz usług AD DS lub Microsoft Entra Domain Services.
  • Poświadczenia dołączania hostów sesji do domeny.
  • Jednostka organizacyjna (OU), który jest opcjonalnym parametrem, który umożliwia umieszczanie hostów sesji w żądanym czasie jednostki organizacyjnej.

Ważne

Konto używane do dołączania do domeny nie może mieć włączonego uwierzytelniania wieloskładnikowego (MFA).

Systemy operacyjne i licencje

Istnieje możliwość wyboru systemów operacyjnych, których można używać do hostów sesji w celu udostępniania komputerów stacjonarnych i aplikacji. Możesz użyć różnych systemów operacyjnych z różnymi pulami hostów, aby zapewnić elastyczność użytkownikom. Obsługujemy 64-bitowe systemy operacyjne i jednostki SKU w poniższej tabeli (gdzie obsługiwane wersje i daty są wbudowane w zasady cyklu życia firmy Microsoft) oraz metody licencjonowania stosowane dla każdego celu komercyjnego:

System operacyjny
(tylko 64-bitowa)		 Metoda licencjonowania
(Wewnętrzne cele handlowe)		 Metoda licencjonowania
(Zewnętrzne cele handlowe)
  • Microsoft 365 E3, E5, A3, A5, F3, Business Premium, Korzyści dla Studentów
  • Windows Enterprise E3, E5
  • Windows Education A3, A5
  • Windows VDA na użytkownika
  • Cennik dostępu poszczególnych użytkowników przez zarejestrowanie subskrypcji platformy Azure.
  • Licencja dostępu klienta usług pulpitu zdalnego (CAL) z pakietem Software Assurance (na użytkownika lub na urządzenie)
  • Licencje subskrypcji użytkowników usług pulpitu zdalnego.
  • Licencja dostępu subskrybenta usług pulpitu zdalnego systemu Windows Server 2022 (SAL).

Ceny dostępu poszczególnych użytkowników nie są dostępne dla systemów operacyjnych Windows Server.

Aby dowiedzieć się więcej na temat licencji, których można używać, w tym cennika dostępu dla poszczególnych użytkowników, zobacz Licencjonowanie usługi Azure Virtual Desktop.

Ważne

  • Następujące elementy nie są obsługiwane:

  • Wsparcie dla systemu Windows 7 zakończyło się 10 stycznia 2023 r.

  • Wsparcie dla systemu Windows Server 2012 R2 zakończyło się 10 października 2023 r.

W przypadku platformy Azure możesz użyć obrazów systemu operacyjnego udostępnianych przez firmę Microsoft w witrynie Azure Marketplace lub utworzyć własne niestandardowe obrazy przechowywane w galerii obliczeniowej platformy Azure lub jako obraz zarządzany. Użycie niestandardowych szablonów obrazów dla usługi Azure Virtual Desktop umożliwia łatwe tworzenie niestandardowego obrazu, którego można użyć podczas wdrażania maszyn wirtualnych hosta sesji. Aby dowiedzieć się więcej na temat tworzenia obrazów niestandardowych, zobacz:

Alternatywnie w przypadku rozwiązania Azure Stack HCI można używać obrazów systemu operacyjnego z następujących lokalizacji:

Maszyny wirtualne można wdrożyć do użycia jako hosty sesji z tych obrazów przy użyciu dowolnej z następujących metod:

Jeśli licencja uprawnia Do korzystania z usługi Azure Virtual Desktop, nie musisz instalować ani stosować oddzielnej licencji, jednak jeśli korzystasz z cen dostępu dla poszczególnych użytkowników dla użytkowników zewnętrznych, musisz zarejestrować subskrypcję platformy Azure. Upewnij się, że licencja systemu Windows używana na hostach sesji jest poprawnie przypisana na platformie Azure, a system operacyjny jest aktywowany. Aby uzyskać więcej informacji, zobacz Stosowanie licencji systemu Windows do maszyn wirtualnych hosta sesji.

W przypadku hostów sesji w usłudze Azure Stack HCI należy licencjonować i aktywować używane maszyny wirtualne przed ich użyciem z usługą Azure Virtual Desktop. Aby aktywować wielosesyjne systemy Windows 10 i Windows 11 Enterprise oraz Windows Server 2022 Datacenter: Azure Edition, użyj weryfikacji platformy Azure dla maszyn wirtualnych. W przypadku wszystkich innych obrazów systemu operacyjnego (takich jak Windows 10 i Windows 11 Enterprise i inne wersje systemu Windows Server) należy nadal używać istniejących metod aktywacji. Aby uzyskać więcej informacji, zobacz Aktywowanie maszyn wirtualnych z systemem Windows Server w usłudze Azure Stack HCI.

Uwaga

Aby zapewnić ciągłą funkcjonalność przy użyciu najnowszej aktualizacji zabezpieczeń, zaktualizuj maszyny wirtualne w usłudze Azure Stack HCI do najnowszej aktualizacji zbiorczej do 17 czerwca 2024 r. Ta aktualizacja jest niezbędna, aby maszyny wirtualne nadal korzystały z korzyści platformy Azure. Aby uzyskać więcej informacji, zobacz Weryfikacja platformy Azure dla maszyn wirtualnych.

Napiwek

Aby uprościć prawa dostępu użytkowników podczas początkowego programowania i testowania, usługa Azure Virtual Desktop obsługuje cennik tworzenia i testowania platformy Azure. Jeśli wdrożysz usługę Azure Virtual Desktop w subskrypcji usługi Azure Dev/Test, użytkownicy końcowi mogą łączyć się z tym wdrożeniem bez oddzielnych uprawnień licencji w celu przeprowadzenia testów akceptacyjnych lub przekazania opinii.

Sieć

Istnieje kilka wymagań sieciowych, które należy spełnić, aby pomyślnie wdrożyć usługę Azure Virtual Desktop. Dzięki temu użytkownicy mogą łączyć się ze swoimi komputerami stacjonarnymi i aplikacjami, jednocześnie zapewniając im najlepsze możliwe środowisko użytkownika.

Użytkownicy łączący się z usługą Azure Virtual Desktop bezpiecznie ustanawiają odwrotne połączenie z usługą, co oznacza, że nie trzeba otwierać żadnych portów przychodzących. Protokół TCP (Transmission Control Protocol) na porcie 443 jest używany domyślnie, jednak protokół RDP Shortpath może służyć do sieci zarządzanych i sieci publicznych, które ustanawiają bezpośredni transport oparty na protokole UDP (User Datagram Protocol).

Aby pomyślnie wdrożyć usługę Azure Virtual Desktop, należy spełnić następujące wymagania sieciowe:

  • Potrzebujesz sieci wirtualnej i podsieci dla hostów sesji. Jeśli tworzysz hosty sesji w tym samym czasie co pula hostów, musisz utworzyć tę sieć wirtualną z wyprzedzeniem, aby była wyświetlana na liście rozwijanej. Sieć wirtualna musi znajdować się w tym samym regionie świadczenia usługi Azure co host sesji.

  • Upewnij się, że ta sieć wirtualna może łączyć się z kontrolerami domeny i odpowiednimi serwerami DNS, jeśli używasz usług AD DS lub Microsoft Entra Domain Services, ponieważ musisz dołączyć hosty sesji do domeny.

  • Hosty sesji i użytkownicy muszą mieć możliwość nawiązania połączenia z usługą Azure Virtual Desktop. Te połączenia używają również protokołu TCP na porcie 443 do określonej listy adresów URL. Aby uzyskać więcej informacji, zobacz Wymagana lista adresów URL. Upewnij się, że te adresy URL nie są blokowane przez filtrowanie sieci lub zaporę, aby wdrożenie działało prawidłowo i było obsługiwane. Jeśli użytkownicy muszą uzyskać dostęp do platformy Microsoft 365, upewnij się, że hosty sesji mogą łączyć się z punktami końcowymi platformy Microsoft 365.

Rozważ również następujące elementy:

  • Użytkownicy mogą potrzebować dostępu do aplikacji i danych hostowanych w różnych sieciach, dlatego upewnij się, że hosty sesji mogą się z nimi łączyć.

  • Opóźnienie czasu rundy (RTT) z sieci klienta do regionu platformy Azure zawierającego pule hostów powinno być mniejsze niż 150 ms. Użyj narzędzia do szacowania środowiska, aby wyświetlić kondycję połączenia i zalecany region świadczenia usługi Azure. Aby zoptymalizować wydajność sieci, zalecamy utworzenie hostów sesji w regionie świadczenia usługi Azure znajdującym się najbliżej użytkowników.

  • Użyj usługi Azure Firewall dla wdrożeń usługi Azure Virtual Desktop, aby ułatwić blokowanie środowiska i filtrowanie ruchu wychodzącego.

  • Aby ułatwić zabezpieczenie środowiska usługi Azure Virtual Desktop na platformie Azure, zalecamy, aby nie otwierać portu przychodzącego 3389 na hostach sesji. Usługa Azure Virtual Desktop nie wymaga otwarcia otwartego portu przychodzącego. Jeśli musisz otworzyć port 3389 na potrzeby rozwiązywania problemów, zalecamy użycie dostępu just in time do maszyny wirtualnej. Zalecamy również, aby nie przypisywać publicznego adresu IP do hostów sesji.

Aby dowiedzieć się więcej, zobacz Omówienie łączności sieciowej usługi Azure Virtual Desktop.

Uwaga

Aby zapewnić niezawodność i skalowalność usługi Azure Virtual Desktop, agregujemy wzorce ruchu i użycie w celu sprawdzenia kondycji i wydajności płaszczyzny kontroli infrastruktury. Zagregujemy te informacje ze wszystkich lokalizacji, w których znajduje się infrastruktura usługi, a następnie wysyłamy je do regionu USA. Dane wysyłane do regionu USA obejmują dane szorowane, ale nie dane klientów. Aby uzyskać więcej informacji, zobacz Lokalizacje danych dla usługi Azure Virtual Desktop.

Zarządzanie hostem sesji

Podczas zarządzania hostami sesji należy wziąć pod uwagę następujące kwestie:

  • Nie włączaj żadnych zasad ani konfiguracji, które wyłączają Instalatora Windows. Jeśli wyłączysz Instalatora Windows, usługa nie będzie mogła instalować aktualizacji agenta na hostach sesji, a hosty sesji nie będą działać prawidłowo.

  • Jeśli dołączasz hosty sesji do domeny usług AD DS i chcesz zarządzać nimi przy użyciu usługi Intune, musisz skonfigurować usługę Microsoft Entra Połączenie, aby włączyć dołączanie hybrydowe firmy Microsoft Entra.

  • Jeśli dołączasz hosty sesji do domeny usług Microsoft Entra Domain Services, nie możesz zarządzać nimi przy użyciu usługi Intune.

  • Jeśli używasz programu Microsoft Entra join z systemem Windows Server dla hostów sesji, nie możesz zarejestrować ich w usłudze Intune, ponieważ system Windows Server nie jest obsługiwany w usłudze Intune. Należy użyć przyłączania hybrydowego firmy Microsoft Entra i zasad grupy z domeny usługi Active Directory lub lokalnych zasad grupy na każdym hoście sesji.

Regiony platformy Azure

Pule hostów, obszary robocze i grupy aplikacji można wdrażać w następujących regionach świadczenia usługi Azure. Ta lista regionów to miejsce, w którym można przechowywać metadane puli hostów . Jednak hosty sesji dla sesji użytkowników mogą znajdować się w dowolnym regionie świadczenia usługi Azure i lokalnie podczas korzystania z usługi Azure Virtual Desktop w usłudze Azure Stack HCI, co umożliwia wdrażanie zasobów obliczeniowych blisko użytkowników. Aby uzyskać więcej informacji na temat typów danych i lokalizacji, zobacz Lokalizacje danych dla usługi Azure Virtual Desktop.

  • Australia Wschodnia
  • Kanada Środkowa
  • Kanada Wschodnia
  • Indie Środkowe
  • Central US
  • East US
  • Wschodnie stany USA 2
  • Japonia Wschodnia
  • Północno-środkowe stany USA
  • Europa Północna
  • South Central US
  • Południowe Zjednoczone Królestwo
  • Zachodnie Zjednoczone Królestwo
  • Zachodnio-środkowe stany USA
  • West Europe
  • Zachodnie stany USA
  • Zachodnie stany USA 2
  • Zachodnie stany USA 3

Usługa Azure Virtual Desktop jest również dostępna w suwerennych chmurach, takich jak platforma Azure dla instytucji rządowych USA i platforma Azure obsługiwana przez firmę 21Vianet w Chinach.

Aby dowiedzieć się więcej na temat architektury i odporności usługi Azure Virtual Desktop, zobacz Architektura i odporność usługi Azure Virtual Desktop.

Klienci usług pulpitu zdalnego

Użytkownicy potrzebują klienta pulpitu zdalnego, aby nawiązać połączenie z komputerami stacjonarnymi i aplikacjami. Następujący klienci obsługują usługę Azure Virtual Desktop:

Ważne

Usługa Azure Virtual Desktop nie obsługuje połączeń z klienta usług RemoteApp i pulpitu Połączenie ions (RADC) ani klienta Połączenie ion pulpitu zdalnego (MSTSC).

Aby dowiedzieć się, które adresy URL są używane przez klientów do nawiązywania połączenia i które należy zezwolić za pośrednictwem zapór i filtrów internetowych, zobacz listę Wymaganych adresów URL.

Następne kroki