Wymagania wstępne dotyczące usługi Azure Virtual Desktop
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.
Zaloguj się w witrynie Azure Portal.
Wybierz pozycję Subskrypcje.
Wybierz nazwę subskrypcji.
Wybierz pozycję Dostawcy zasobów.
Wyszukaj ciąg Microsoft.DesktopVirtualization.
Jeśli stan to NotRegistered, wybierz pozycję Microsoft.DesktopVirtualization, a następnie wybierz pozycję Zarejestruj.
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 Local można dołączać hosty sesji tylko do domeny usług domena usługi Active Directory. Hosty sesji można dołączać tylko do domeny usług domena usługi Active Directory Services (AD DS). Obejmuje to korzystanie z dołączania hybrydowego firmy Microsoft Entra, w którym można korzystać z niektórych funkcji udostępnianych przez microsoft Entra ID.
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 Administratorzy kontrolera domeny usługi AAD.
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ć program Microsoft Entra Connect, aby synchronizować dane tożsamości użytkownika między usługami AD DS i Identyfikatorem entra firmy Microsoft.
- 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:
- Skonfiguruj kontener profilów FSLogix za pomocą usług Azure Files i usług domena usługi Active Directory lub Microsoft Entra Domain Services.
- Konfigurowanie kontenera profilów FSLogix przy użyciu usług Azure Files i Microsoft Entra ID.
- Konfigurowanie kontenera profilów FSLogix za pomocą usługi Azure NetApp Files
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) |
---|---|---|
|
|
|
|
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 dla hostów sesji:
- 32-bitowe systemy operacyjne.
- N, KN, LTSC i inne wersje systemów operacyjnych Windows, które nie zostały wymienione w poprzedniej tabeli.
- Dyski w warstwie Ultra dla typu dysku systemu operacyjnego.
- Efemeryczne dyski systemu operacyjnego dla maszyn wirtualnych platformy Azure.
- Zestawy skalowania maszyn wirtualnych.
- Maszyny wirtualne platformy Azure oparte na architekturze Arm64.
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:
- Szablony obrazów niestandardowych w usłudze Azure Virtual Desktop
- Przechowywanie i udostępnianie obrazów w galerii obliczeń platformy Azure.
- Utwórz zarządzany obraz uogólnionej maszyny wirtualnej na platformie Azure.
Alternatywnie w przypadku usługi Azure Local można użyć obrazów systemu operacyjnego z następujących lokalizacji:
- W witrynie Azure Marketplace. Aby uzyskać więcej informacji, zobacz Tworzenie lokalnego obrazu maszyny wirtualnej platformy Azure przy użyciu obrazów witryny Azure Marketplace.
- Konto usługi Azure Storage. Aby uzyskać więcej informacji, zobacz Tworzenie lokalnego obrazu maszyny wirtualnej platformy Azure przy użyciu obrazu na koncie usługi Azure Storage.
- Udział lokalny. Aby uzyskać więcej informacji, zobacz Tworzenie lokalnego obrazu maszyny wirtualnej platformy Azure przy użyciu obrazów w udziale lokalnym.
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:
- Automatycznie w ramach procesu konfiguracji puli hostów w witrynie Azure Portal.
- Ręcznie dodając hosty sesji do istniejącej puli hostów w witrynie Azure Portal.
- Programowo za pomocą interfejsu wiersza polecenia platformy Azure lub programu Azure PowerShell.
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 na platformie Azure Local 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 na platformie Azure Local.
Uwaga
Aby zapewnić ciągłość działania przy użyciu najnowszej aktualizacji zabezpieczeń, zaktualizuj maszyny wirtualne na platformie Azure Local 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. Aby sprawdzić, które lokalizacje mają najlepsze opóźnienie, wyszukaj żądaną lokalizację w statystykach opóźnienia rundy sieci platformy 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ć program Microsoft Entra Connect w celu włączenia dołączania hybrydowego 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 . Hosty sesji dla sesji użytkownika mogą jednak znajdować się w dowolnym regionie świadczenia usługi Azure i lokalnie w przypadku korzystania z usługi Azure Virtual Desktop w usłudze Azure Local, 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:
- Klient klasyczny systemu Windows
- Aplikacja ze sklepu Azure Virtual Desktop dla systemu Windows
- Klient internetowy
- Klient systemu macOS
- Klient systemów iOS i iPadOS
- Klient systemu operacyjnego Android i Chrome
- Aplikacja pulpitu zdalnego dla systemu Windows
Ważne
Usługa Azure Virtual Desktop nie obsługuje połączeń z klienta połączeń usług RemoteApp i pulpitu (RADC) ani klienta połączenia 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
Aby uzyskać prosty sposób na rozpoczęcie pracy z usługą Azure Virtual Desktop przez utworzenie przykładowej infrastruktury, zobacz Samouczek: wdrażanie przykładowej infrastruktury usługi Azure Virtual Desktop przy użyciu pulpitu z systemem Windows 11.
Aby uzyskać bardziej szczegółowe i elastyczne podejście do wdrażania usługi Azure Virtual Desktop, zobacz Wdrażanie usługi Azure Virtual Desktop.