Uwaga
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Istnieje kilka rzeczy, które należy rozpocząć przy użyciu usługi Azure Virtual Desktop. Tutaj możesz znaleźć wymagania wstępne, które należy wykonać, aby pomyślnie udostępnić 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 potrzebne jest konto platformy Azure z aktywną subskrypcją. Jeśli jeszcze go nie masz, możesz utworzyć konto bezpłatnie.
Aby wdrożyć usługę Azure Virtual Desktop, musisz przypisać odpowiednie role kontroli dostępu opartej na rolach (RBAC) platformy Azure. Określone wymagania dotyczące ról są omówione w każdym z powiązanych artykułów dotyczących wdrażania usługi Azure Virtual Desktop, które zostały 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żna
Musisz mieć uprawnienia do rejestrowania dostawcy zasobów, co wymaga */register/action
operacji. Jest ono uwzględniane, jeśli twoje konto ma przypisaną rolę współautora lub właściciela subskrypcji.
Zaloguj się do witryny Azure Portal.
Wybierz pozycję Subskrypcje.
Wybierz nazwę subskrypcji.
Wybierz pozycję Dostawcy zasobów.
Wyszukaj pozycję Microsoft.DesktopVirtualization.
Jeśli stan to NotRegistered, wybierz pozycję Microsoft.DesktopVirtualization, a następnie wybierz pozycję Zarejestruj.
Sprawdź, czy stan microsoft.desktopVirtualization jest zarejestrowany.
Tożsamości
Aby uzyskać dostęp do pulpitów i aplikacji z hostów sesji, użytkownicy muszą mieć możliwość uwierzytelniania. Tożsamość Microsoft Entra jest scentralizowaną usługą tożsamości w chmurze firmy Microsoft, która umożliwia korzystanie z tej funkcji. Tożsamość Microsoft Entra jest zawsze używana do uwierzytelniania użytkowników w usłudze Azure Virtual Desktop. Hosty sesji mogą być przyłączone do tej samej dzierżawy Microsoft Entra lub do domeny usługi Active Directory przy użyciu Active Directory Domain Services (AD DS) lub Microsoft Entra Domain Services, zapewniając możliwość wyboru elastycznych opcji konfiguracji.
Hosty sesji
Należy dołączyć do hostów sesji, które udostępniają komputery stacjonarne i aplikacje w tej samej dzierżawie Microsoft Entra co użytkownicy, lub do domeny usługi Active Directory (usług AD DS lub Microsoft Entra Domain Services).
Uwaga
W przypadku Azure lokalnie można dołączyć hosty sesji tylko do domeny Active Directory Domain Services. Hosty sesji można dołączać tylko w Azure lokalnie do domeny Active Directory Domain Services (AD DS). Obejmuje to używanie Microsoft Entra sprzężenia hybrydowego, w którym można korzystać z niektórych funkcji udostępnianych przez Tożsamość Microsoft Entra.
Aby dołączyć hosty sesji do Tożsamość Microsoft Entra lub domeny usługi Active Directory, potrzebne są następujące uprawnienia:
Do Tożsamość Microsoft Entra 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 Tożsamość Microsoft Entra, zobacz Microsoft Entra przyłączonych hostów sesji.
W przypadku domeny usługi Active Directory potrzebne jest konto domeny, które może dołączać komputery do domeny. Aby Microsoft Entra Domain Services, musisz być członkiem grupy Administratorzy kontrolera domeny usługi AAD.
Użytkownicy
Użytkownicy potrzebują kont znajdujących się w Tożsamość Microsoft Entra. 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 Tożsamość Microsoft Entra z usługami AD DS, musisz skonfigurować Microsoft Entra Connect, aby synchronizować dane tożsamości użytkownika między usługami AD DS i Tożsamość Microsoft Entra.
- Jeśli używasz Tożsamość Microsoft Entra z Microsoft Entra Domain Services, konta użytkowników są synchronizowane w jedną stronę od Tożsamość Microsoft Entra do Microsoft Entra Domain Services. Ten proces synchronizacji jest automatyczny.
Ważna
Konto użytkownika musi istnieć w dzierżawie Microsoft Entra używanej dla usługi 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 nazwa UserPrincipalName (UPN) lub identyfikator zabezpieczeń (SID) muszą być zgodne z Active Directory Domain Services i Tożsamość Microsoft Entra. Aby uzyskać więcej informacji, zobacz Obsługiwane tożsamości i metody uwierzytelniania.
Obsługiwane scenariusze tożsamości
Poniższa tabela zawiera podsumowanie scenariuszy tożsamości obsługiwanych obecnie przez usługę Azure Virtual Desktop:
Scenariusz tożsamości | Hosty sesji | Konta użytkowników |
---|---|---|
Tożsamość Microsoft Entra + AD DS | Przyłączone do usług AD DS | W usługach Tożsamość Microsoft Entra i AD DS zsynchronizowane |
Tożsamość Microsoft Entra + AD DS | Przyłączone do Tożsamość Microsoft Entra | W usługach Tożsamość Microsoft Entra i AD DS zsynchronizowane |
Tożsamość Microsoft Entra + Microsoft Entra Domain Services | Przyłączone do Microsoft Entra Domain Services | W Tożsamość Microsoft Entra i Microsoft Entra Domain Services zsynchronizowane |
Tożsamość Microsoft Entra + Microsoft Entra Domain Services + AD DS | Przyłączone do Microsoft Entra Domain Services | W usługach Tożsamość Microsoft Entra i AD DS zsynchronizowane |
Tożsamość Microsoft Entra + Microsoft Entra Domain Services | Przyłączone do Tożsamość Microsoft Entra | W Tożsamość Microsoft Entra i Microsoft Entra Domain Services zsynchronizowane |
tylko Microsoft Entra | Przyłączone do Tożsamość Microsoft Entra | W Tożsamość Microsoft Entra |
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 profilu FSLogix podczas dołączania hostów sesji do Tożsamość Microsoft Entra, należy przechowywać profile na 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 Tożsamość Microsoft Entra. Aby dowiedzieć się więcej na temat wdrażania kontenera profilu FSLogix z różnymi scenariuszami tożsamości, zobacz następujące artykuły:
- Skonfiguruj kontener profilu FSLogix przy użyciu Azure Files i Active Directory Domain Services lub Microsoft Entra Domain Services.
- Skonfiguruj kontener profilu FSLogix przy użyciu Azure Files i Tożsamość Microsoft Entra.
- Konfigurowanie kontenera profilu FSLogix przy użyciu 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 przyłączenia hostów sesji do domeny.
- Jednostka organizacyjna (OU), która jest opcjonalnym parametrem, który umożliwia umieszczenie hostów sesji w żądanej jednostce organizacyjnej w czasie wdrażania.
Ważna
Konto używane do dołączania do domeny nie może mieć włączonego uwierzytelniania wieloskładnikowego (MFA).
Systemy operacyjne i licencje
Masz do wyboru systemy operacyjne, których można użyć do hostów sesji w celu udostępniania pulpitów i aplikacji. Możesz użyć różnych systemów operacyjnych z różnymi pulami hostów, aby zapewnić użytkownikom elastyczność. Obsługujemy 64-bitowe systemy operacyjne i jednostki SKU na poniższych listach 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-bitowe) |
Metoda licencjonowania (Wewnętrzne cele handlowe) |
Metoda licencjonowania (Zewnętrzne cele handlowe) |
---|---|---|
|
|
|
|
Cennik dostępu dla poszczególnych użytkowników nie jest dostępny dla Windows Server systemów operacyjnych. |
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żna
- 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.
- Virtual Machine Scale Sets.
- Maszyny wirtualne platformy Azure oparte na usłudze Arm64.
W przypadku platformy Azure można używać obrazów systemu operacyjnego udostępnianych przez firmę Microsoft w Azure Marketplace lub tworzyć własne obrazy niestandardowe przechowywane w galerii usługi Azure Compute Gallery 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:
- Niestandardowe szablony obrazów 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 Azure lokalnie można użyć obrazów systemu operacyjnego z:
- Azure Marketplace. Aby uzyskać więcej informacji, zobacz Tworzenie obrazu maszyny wirtualnej Azure lokalnie przy użyciu obrazów Azure Marketplace.
- Konto usługi Azure Storage. Aby uzyskać więcej informacji, zobacz Tworzenie obrazu maszyny wirtualnej Azure lokalnie przy użyciu obrazu na koncie usługi Azure Storage.
- Udział lokalny. Aby uzyskać więcej informacji, zobacz Tworzenie obrazu maszyny wirtualnej Azure lokalnie 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 Azure Portal.
- Ręcznie przez dodanie hostów sesji do istniejącej puli hostów w Azure Portal.
- Programowo za pomocą interfejsu wiersza polecenia platformy Azure lub Azure PowerShell.
Jeśli licencja uprawnia do korzystania z usługi Azure Virtual Desktop, nie musisz instalować ani stosować oddzielnej licencji, jednak jeśli używasz cen dostępu dla poszczególnych użytkowników dla użytkowników zewnętrznych, musisz zarejestrować subskrypcję platformy Azure. Musisz upewnić się, że licencja systemu Windows używana na hostach sesji jest poprawnie przypisana na platformie Azure i że 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 Azure lokalnie należy uzyskać licencję i aktywować maszyny wirtualne używane przed ich użyciem w usłudze Azure Virtual Desktop. Do aktywowania Windows 10 i Windows 11 Enterprise wielu sesji 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 oraz innych wersji Windows Server) należy nadal używać istniejących metod aktywacji. Aby uzyskać więcej informacji, zobacz Aktywowanie maszyn wirtualnych Windows Server na Azure lokalnie.
Uwaga
Aby zapewnić ciągłą funkcjonalność najnowszej aktualizacji zabezpieczeń, zaktualizuj maszyny wirtualne na Azure lokalnie do najnowszej aktualizacji zbiorczej do 17 czerwca 2024 r. Ta aktualizacja jest niezbędna dla maszyn wirtualnych, aby nadal korzystać z korzyści platformy Azure. Aby uzyskać więcej informacji, zobacz Weryfikacja platformy Azure dla maszyn wirtualnych.
Porada
Aby uprościć prawa dostępu użytkowników podczas początkowego opracowywania i testowania, usługa Azure Virtual Desktop obsługuje cennik usługi Azure Dev/Test. Jeśli wdrożysz usługę Azure Virtual Desktop w ramach subskrypcji usługi Azure Dev/Test, użytkownicy końcowi mogą nawiązać połączenie z tym wdrożeniem bez oddzielnych uprawnień licencyjnych 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 pulpitami 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 można użyć protokołu RDP Shortpath dla 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, musisz spełnić następujące wymagania sieciowe:
Potrzebujesz sieci wirtualnej i podsieci dla hostów sesji. Jeśli hosty sesji zostaną utworzone 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ązywania 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 Lista wymaganych adresów URL. Musisz upewnić 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.
Należy również wziąć pod uwagę następujące kwestie:
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, który zawiera pule hostów, powinno być mniejsze niż 150 ms. Aby sprawdzić, które lokalizacje mają największe opóźnienie, wyszukaj żądaną lokalizację w statystykach opóźnienia w sieci platformy Azure. Aby zoptymalizować wydajność sieci, zalecamy utworzenie hostów sesji w regionie platformy Azure znajdującym się najbliżej użytkowników.
Użyj Azure Firewall dla wdrożeń usługi Azure Virtual Desktop, aby zablokować środowisko i odfiltrować ruch wychodzący.
Aby zabezpieczyć środowisko 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 na potrzeby rozwiązywania problemów musisz otworzyć port 3389, 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 Understanding Azure Virtual Desktop network connectivity (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. Te informacje agregujemy 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ą szorowane dane, 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 może zainstalować aktualizacji agenta na hostach sesji, a hosty sesji nie będą działać poprawnie.
Jeśli dołączasz hosty sesji do domeny usług AD DS i chcesz nimi zarządzać przy użyciu Intune, musisz skonfigurować Microsoft Entra Connect, aby włączyć Microsoft Entra przyłączanie hybrydowe.
Jeśli dołączasz hosty sesji do domeny Microsoft Entra Domain Services, nie możesz zarządzać nimi przy użyciu Intune.
Jeśli używasz Microsoft Entra dołączania do Windows Server dla hostów sesji, nie możesz zarejestrować ich w Intune, ponieważ Windows Server nie jest obsługiwany w przypadku Intune. Należy użyć Microsoft Entra przyłączania hybrydowego i zasady grupy z domeny usługi Active Directory lub zasady grupy lokalnych 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 platformy Azure i lokalnie podczas korzystania z usługi Azure Virtual Desktop w Azure lokalnie, co umożliwia wdrażanie zasobów obliczeniowych w pobliżu 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
- Środkowe stany USA
- Wschodnie stany USA
- Wschodnie stany USA 2
- Japonia Wschodnia
- Japonia Zachodnia
- Północno-środkowe stany USA
- Europa Północna
- Republika Południowej Afryki Północnej
- Południowo-środkowe stany USA
- Południowe Zjednoczone Królestwo
- Zachodnie Zjednoczone Królestwo
- Zachodnio-środkowe stany USA
- Europa Zachodnia
- 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.
Nawiązywanie połączenia z sesją zdalną
Użytkownicy muszą używać Windows App lub klienta pulpitu zdalnego, aby łączyć się z pulpitami i aplikacjami. Możesz nawiązać połączenie z:
- System Windows
- macOS
- iOS/iPadOS
- System operacyjny Android/Chrome
- Przeglądarka internetowa
Aby uzyskać więcej informacji, zobacz Wprowadzenie do Windows App w celu nawiązywania połączenia z urządzeniami i aplikacjami.
Ważna
Usługa Azure Virtual Desktop nie obsługuje połączeń z klienta usługi RemoteApp and Desktop Connections (RADC) ani klienta połączenia pulpitu zdalnego (MSTSC).
Aby dowiedzieć się, których adresów URL klienci używają do nawiązywania połączenia i których należy zezwolić za pośrednictwem zapór i filtrów internetowych, zobacz listę Wymagany adres URL.
Następne kroki
Gdy wszystko będzie gotowe do wypróbowania usługi Azure Virtual Desktop, użyj przewodnika Szybki start, aby wdrożyć przykładowe środowisko usługi Azure Virtual Desktop z Windows 11 Enterprise wielu sesjach.
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.