Voraussetzungen für Azure Virtual Desktop

  • Artikel

Es gibt einige Dinge, die Sie für die Verwendung von Azure Virtual Desktop benötigen. Hier finden Sie die Voraussetzungen, die Sie erfüllen müssen, um Ihren Benutzern erfolgreich Desktops und Anwendungen zur Verfügung zu stellen.

Im Allgemeinen gilt:

  • Ein Azure-Konto mit einem aktiven Abonnement
  • Ein unterstützter Identitätsanbieter
  • Ein unterstütztes Betriebssystem für virtuelle Sitzungs-Host-Computer
  • Geeignete Lizenzen
  • Netzwerkkonnektivität
  • Einen Remotedesktopclient

Azure-Konto mit einem aktiven Abonnement

Sie benötigen ein Azure-Konto mit einem aktiven Abonnement, um Azure Virtual Desktop bereitzustellen. Falls Sie noch über keins verfügen, können Sie ein kostenloses Konto erstellen.

Um Azure Virtual Desktop bereitzustellen, müssen Sie die relevanten rollenbasierten Azure-Zugriffssteuerungsrollen (RBAC) zuweisen. Die spezifischen Rollenanforderungen werden in jedem verwandten Artikel für die Bereitstellung von Azure Virtual Desktop behandelt, die im Abschnitt Nächste Schritte aufgeführt sind.

Stellen Sie auch sicher, dass Sie den Ressourcenanbieter Microsoft.DesktopVirtualization für Ihr Abonnement registriert haben. Um den Status des Ressourcenanbieters zu überprüfen und bei Bedarf zu registrieren, wählen Sie die entsprechende Registerkarte für Ihr Szenario aus, und führen Sie die Schritte aus.

Wichtig

Sie müssen über die Berechtigung zum Registrieren eines Ressourcenanbieters verfügen, was den Vorgang */register/action erfordert. Dies ist enthalten, wenn Ihrem Konto die Rolle „Mitwirkender“ oder „Besitzer“ für Ihr Abonnement zugewiesen ist.

  1. Melden Sie sich beim Azure-Portal an.

  2. Wählen Sie Abonnements.

  3. Wählen Sie den Namen Ihres Abonnements aus.

  4. Wählen Sie Ressourcenanbieter aus.

  5. Suchen Sie nach Microsoft.DesktopVirtualization.

  6. Wenn der Status NotRegistered (Nicht registriert) ist, wählen Sie Microsoft.DesktopVirtualization und dann Registrieren aus.

  7. Überprüfen Sie, ob der Status von Microsoft.DesktopVirtualization registriert lautet.

Identität

Um von Ihren Sitzungshosts aus auf Desktops und Anwendungen zugreifen zu können, müssen sich Ihre Benutzer authentifizieren können. Microsoft Entra ID ist der zentralisierte Cloudidentitätsdienst von Microsoft, der diese Funktion ermöglicht. Microsoft Entra ID wird immer verwendet, um Benutzer*innen für Azure Virtual Desktop zu authentifizieren. Sitzungshosts können mit demselben Microsoft Entra-Mandanten oder einer Active Directory-Domäne mithilfe von Active Directory Domain Services (AD DS) oder Microsoft Entra Domain Services verbunden werden, was Ihnen eine Auswahl flexibler Konfigurationsoptionen bietet.

Sitzungshosts

Sie müssen an Sitzungshosts teilnehmen, die Desktops und Anwendungen demselben Microsoft Entra-Mandanten wie Ihre Benutzer oder eine Active Directory-Domäne (AD DS oder Microsoft Entra Domain Services) bereitstellen.

Hinweis

Bei Azure Stack HCI können Sie Sitzungshosts nur in eine Active Directory Domain Services-Domäne einbinden.

Um Sitzungshosts in Microsoft Entra ID oder eine Active Directory-Domäne einzubinden, benötigen Sie die folgenden Berechtigungen:

  • Für die Microsoft Entra ID benötigen Sie ein Konto, mit dem Computer mit Ihrem Mandanten verknüpft werden können. Weitere Informationen finden Sie unter Verwalten von Geräteidentitäten. Weitere Informationen zum Beitreten von Sitzungshosts zu Microsoft Entra ID finden Sie unter Microsoft Entra-eingebundene Sitzungshosts.

  • Für eine Active Directory-Domäne benötigen Sie ein Domänenkonto, das Computer mit Ihrer Domäne verknüpfen kann. Für Microsoft Entra Domain Services müssen Sie Mitglied der Gruppe AAD DC-Administratoren sein.

Benutzer

Ihre Benutzer benötigen Konten, die sich in der Microsoft Entra ID befinden. Wenn Sie in Ihrer Bereitstellung von Azure Virtual Desktop auch AD DS oder Microsoft Entra Domain Services verwenden, müssen diese Konten Hybrididentitäten sein, was bedeutet, dass die Benutzerkonten synchronisiert werden. Je nachdem, welchen Identitätsanbieter Sie verwenden, müssen Sie die folgenden Punkte beachten:

  • Wenn Sie Microsoft Entra ID mit AD DS verwenden, müssen Sie Microsoft Entra Connect konfigurieren, um Benutzeridentitätsdaten zwischen AD DS und Microsoft Entra ID zu synchronisieren.
  • Wenn Sie Microsoft Entra ID mit Microsoft Entra Domain Services verwenden, werden Benutzerkonten von Microsoft Entra-ID mit Microsoft Entra Domain Services synchronisiert. Dieser Synchronisierungsvorgang erfolgt automatisch.

Wichtig

Das Benutzerkonto muss in dem Microsoft Entra-Mandanten vorhanden sein, den Sie für Azure Virtual Desktop verwenden. Azure Virtual Desktop unterstützt keine B2B-, B2C- oder privaten Microsoft-Konten.

Bei Verwendung von Hybrididentitäten muss entweder der UPN (UserPrincipalName) oder die SID (Sicherheits-ID) in Active Directory Domain Services und Microsoft Entra ID übereinstimmen. Weitere Informationen finden Sie unter Unterstützte Identitäten und Authentifizierungsmethoden.

Unterstützte Identitätsszenarien

In der folgenden Tabelle werden die derzeit von Azure Virtual Desktop unterstützten Identitätsszenarien zusammengefasst:

Identitätsszenario Sitzungshosts Benutzerkonten
Microsoft Entra ID + AD DS Verknüpft mit AD DS Synchronisiert in Microsoft Entra ID und AD DS
Microsoft Entra ID + AD DS Mitglied der Microsoft Entra ID Synchronisiert in Microsoft Entra ID und AD DS
Microsoft Entra ID + Microsoft Entra Domain Services Verbunden mit Microsoft Entra Domain Services Synchronisierte Microsoft Entra ID und Microsoft Entra Domain Services
Microsoft Entra ID + Microsoft Entra Domain Services + AD DS Verbunden mit Microsoft Entra Domain Services Synchronisiert in Microsoft Entra ID und AD DS
Microsoft Entra ID + Microsoft Entra Domain Services Mitglied der Microsoft Entra ID Synchronisierte Microsoft Entra ID und Microsoft Entra Domain Services
Nur Microsoft Entra Mitglied der Microsoft Entra ID In Microsoft Entra ID

Detailliertere Informationen zu unterstützten Identitätsszenarien, einschließlich einmaliges Anmelden und Multi-Faktor-Authentifizierung, finden Sie unter Unterstützte Identitäten und Authentifizierungsmethoden.

FSLogix-Profilcontainer

Um FSLogix-Profilcontainer beim Hinzufügen Ihrer Sitzungshosts zu Microsoft Entra ID verwenden zu können, müssen Sie Profile auf Azure Files oder Azure NetApp Files speichern und Ihre Benutzerkonten müssen Hybrididentitäten sein. Sie müssen diese Konten in AD DS erstellen und in Microsoft Entra ID synchronisieren. Weitere Informationen zum Bereitstellen des FSLogix-Profilcontainers mit verschiedenen Identitätsszenarien finden Sie in den folgenden Artikeln:

Bereitstellungsparameter

Beim Bereitstellen von Sitzungshosts müssen Sie die folgenden Identitätsparameter eingeben:

  • Domänenname, wenn AD DS oder Microsoft Entra Domain Services verwendet werden.
  • Anmeldeinformationen zum Hinzufügen von Sitzungshosts zur Domäne.
  • Organisationseinheit (OE), ein optionaler Parameter, mit dem Sie Sitzungshosts zur Bereitstellungszeit in der gewünschten Organisationseinheit platzieren können.

Wichtig

Für das Konto, das Sie für den Beitritt zu einer Domäne verwenden, darf die mehrstufige Authentifizierung (Multi-Factor Authentication, MFA) nicht aktiviert sein.

Betriebssysteme und Lizenzen

Ihnen bietet sich eine Auswahl an Betriebssystemen, die Sie für Sitzungshosts verwenden können, um Desktops und Anwendungen zur Verfügung zu stellen. Sie können verschiedene Betriebssysteme mit unterschiedlichen Hostpools verwenden, um Ihren Benutzern Flexibilität zu bieten. Wir unterstützen die in der folgenden Tabelle aufgeführten 64-Bit-Betriebssysteme und SKUs (in denen unterstützte Versionen und Datumsangaben mit der Microsoft-Lebenszyklusrichtlinie übereinstimmen), zusammen mit den Lizenzierungsmethoden, die für jeden kommerziellen Zweck gelten:

Betriebssystem
(nur 64-Bit)		 Lizenzierungsmethode
(Interne kommerzielle Zwecke)		 Lizenzierungsmethode
(Externe kommerzielle Zwecke)
  • Microsoft 365 E3, E5, A3, A5, F3, Business Premium, Student Use Benefit
  • Windows Enterprise E3, E5
  • Windows Education A3, A5
  • Windows VDA pro Benutzer
  • Remotedesktopdienste (Remote Desktop Services, RDS)-Clientzugriffslizenz (Client Access License, CAL) mit Software Assurance (pro Benutzer oder pro Gerät)
  • RDS-Benutzerabonnementlizenzen.
  • Windows Server 2022 RDS-Abonnementzugriffslizenz (Subscriber Access License, SAL).

Für Windows Server-Betriebssysteme sind Zugriffspreise pro Benutzer nicht verfügbar.

Weitere Informationen zu Lizenzen, die Sie verwenden können, einschließlich der Zugriffspreise pro Benutzer, finden Sie unter Lizenzierung von Azure Virtual Desktop.

Wichtig

Für Azure können Sie Betriebssystem-Images verwenden, die von Microsoft im Azure Marketplace zur Verfügung gestellt werden, oder Sie können Ihre eigenen benutzerdefinierten Images erstellen, die in einer Azure Compute Gallery oder als verwaltetes Image gespeichert werden. Mit benutzerdefinierten Imagevorlagen für Azure Virtual Desktop können Sie ganz einfach ein benutzerdefiniertes Image erstellen, das Sie beim Bereitstellen von Sitzungshost-VMs verwenden können. Weitere Informationen zum Erstellen benutzerdefinierter Images finden Sie unter:

Alternativ können Sie für Azure Stack HCI auch Betriebssystem-Images von folgenden Orten verwenden:

Sie können VMs für die Verwendung als Sitzungshosts aus diesen Images mit einer der folgenden Methoden bereitstellen:

Wenn Sie mit Ihrer Lizenz zur Verwendung von Azure Virtual Desktop berechtigt sind, müssen Sie keine separate Lizenz installieren oder anwenden. Wenn Sie jedoch Preise für den benutzerspezifischen Zugriff für externe Benutzer verwenden, müssen Sie sich für ein Azure-Abonnement registrieren. Sie müssen sicherstellen, dass die auf Ihren Sitzungs-Hosts verwendete Windows-Lizenz in Azure ordnungsgemäß zugewiesen und das Betriebssystem aktiviert ist. Weitere Informationen finden Sie unter Anwenden einer Windows-Lizenz auf virtuelle Sitzungs-Host-Computer.

Für Sitzungshosts auf Azure Stack HCI müssen Sie die von Ihnen verwendeten VMs lizenzieren und aktivieren, bevor Sie sie mit Azure Virtual Desktop verwenden. Zum Aktivieren von Windows 10 und Windows 11 Enterprise Multisession und Windows Server 2022 Datacenter: Azure Edition verwenden Sie die Azure-Überprüfung für VMs. Für alle anderen Betriebssystem-Images (z. B. Windows 10 und Windows 11 Enterprise und andere Editionen von Windows Server) sollten Sie weiterhin vorhandene Aktivierungsmethoden verwenden. Weitere Informationen finden Sie unter Lizenzieren von Windows Server-VMs in Azure Stack HCI.

Tipp

Zur Vereinfachung der Benutzerzugriffsrechte während der ersten Entwicklung und Tests unterstützt Azure Virtual Desktop Preise für Azure Dev/Test. Wenn Sie Azure Virtual Desktop in einem Azure Dev/Test-Abonnement bereitstellen, können Endbenutzer eine Verbindung mit dieser Bereitstellung in Azure ohne separaten Anspruch auf eine Lizenz herstellen, um Akzeptanztests durchzuführen oder Feedback zu geben.

Network

Es gibt mehrere Netzwerkanforderungen, die Sie erfüllen müssen, um Azure Virtual Desktop erfolgreich bereitzustellen. Dadurch können Benutzer eine Verbindung mit ihren Desktops und Anwendungen herstellen und profitieren gleichzeitig von der bestmöglichen Benutzererfahrung.

Benutzer, die eine Verbindung zu Azure Virtual Desktop herstellen, stellen sicher eine umgekehrte Verbindung mit dem Dienst her, sodass Sie keine eingehenden Ports öffnen müssen. Das Übertragungssteuerungsprotokoll (TCP) auf Port 443 wird standardmäßig verwendet. RDP Shortpath kann jedoch für verwaltete Netzwerke und öffentliche Netzwerke verwendet werden, die einen direkten UDP-(User Datagram Protocol-)basierten Transport einrichten.

Es gibt mehrere Netzwerkanforderungen, die Sie erfüllen müssen, um Azure Virtual Desktop erfolgreich bereitzustellen:

  • Sie benötigen ein virtuelles Netzwerk und ein Subnetz für Ihre Sitzungshosts. Wenn Sie Ihre Sitzungshosts gleichzeitig mit einem Hostpool erstellen, müssen Sie dieses virtuelle Netzwerk im Voraus erstellen, damit es in der Dropdownliste angezeigt wird. Ihr virtuelles Netzwerk muss in derselben Azure-Region wie Ihr flexibler Server bereitgestellt werden.

  • Stellen Sie sicher, dass dieses virtuelle Netzwerk eine Verbindung zu Ihren Domänencontrollern und den entsprechenden DNS-Servern herstellen kann, wenn Sie AD DS oder Microsoft Entra Domain Services verwenden, da Sie die Sitzungshosts mit der Domäne verbinden müssen.

  • Ihre Sitzungshosts und -benutzer müssen eine Verbindung mit dem Azure Virtual Desktop-Dienst herstellen können. Diese Verbindungen verwenden für eine Liste bestimmter URLs ebenfalls TCP an Port 443. Weitere Informationen finden Sie unter Liste der erforderlichen URLs. Sie müssen sicherstellen, dass diese URLs nicht durch die Netzwerkfilterung oder eine Firewall blockiert werden, damit Ihre Bereitstellung ordnungsgemäß funktioniert und unterstützt wird. Wenn Ihre Benutzer auf Microsoft 365 zugreifen müssen, stellen Sie sicher, dass Ihre Sitzungshosts eine Verbindung mit Microsoft 365-Endpunkten herstellen können.

Berücksichtigen Sie außerdem folgende Punkte:

  • Ihre Benutzer benötigen möglicherweise Zugriff auf Anwendungen und Daten, die in verschiedenen Netzwerken bereitgestellt werden. Stellen Sie daher sicher, dass Ihre Sitzungshosts eine Verbindung mit ihnen herstellen können.

  • Die Roundtripzeit zwischen dem Netzwerk des Clients und der Azure-Region, in der die Hostpools bereitgestellt wurden, muss unter 150 ms liegen. Zeigen Sie mithilfe des Qualitätsschätzers die Verbindungsintegrität und die empfohlene Azure-Region an. Zur Optimierung der Netzwerkleistung wird empfohlen, Sitzungshosts in der Azure-Region zu erstellen, die Ihren Benutzern am nächsten ist.

  • Verwenden Azure Firewall für Azure Virtual Desktop-Bereitstellungen, um Ihre Umgebung zu schützen und ausgehenden Datenverkehr zu filtern.

  • Zum Schutz Ihrer Azure Virtual Desktop-Umgebung in Azure empfiehlt es sich, den eingehenden Port 3389 auf Ihren Sitzungshost nicht zu öffnen. Azure Virtual Desktop erfordert keinen geöffneten eingehenden Port. Wenn Sie den Port 3389 zur Problembehandlung öffnen müssen, verwenden Sie am besten den Just-In-Time-Zugriff auf virtuelle Computer. Es wird auch empfohlen, Ihren Sitzungshosts keine öffentliche IP-Adresse zuzuweisen.

Weitere Informationen finden Sie unter Grundlegendes zur Netzwerkkonnektivität für Azure Virtual Desktop.

Hinweis

Um Azure Virtual Desktop zuverlässig und skalierbar zu halten, werden Datenverkehrsmuster und -nutzung aggregiert, um die Integrität und Leistung der Infrastruktursteuerungsebene zu überwachen. Diese Informationen werden von allen Standorten aggregiert, an denen sich die Dienstinfrastruktur befindet, und dann an die Region „USA“ übermittelt. Für die an die US-Region gesendeten Daten wird ein Scrubbing ausgeführt, es werden keine Kundendaten übertragen. Weitere Informationen finden Sie unter Datenstandorte für Azure Virtual Desktop.

Sitzungshostverwaltung

Beachten Sie beim Verwalten von Sitzungshosts die folgenden Punkte:

  • Aktivieren Sie keine Richtlinien oder Konfigurationen, die eine Deaktivierung des Windows Installers bewirken. Wenn Sie den Windows Installer deaktivieren, kann der Dienst keine Agent-Updates auf Ihren Sitzungshosts installieren, und Ihre Sitzungshosts funktionieren nicht einwandfrei.

  • Wenn Sie Sitzungshosts einer AD DS-Domäne hinzufügen und diese mit Intune verwalten möchten, müssen Sie Microsoft Entra Connect konfigurieren, um die Microsoft Entra-Hybridverbindung zu aktivieren.

  • Wenn Sie an Sitzungshosts an einer Domäne der Microsoft Entra Domain Services teilnehmen, können Sie diese nicht mit Intuneverwalten.

  • Wenn Sie die Microsoft Entra-Verbindung mit Windows Server für Ihre Sitzungshosts verwenden, können Sie diese nicht in Intune registrieren, da Windows Server nicht von Intune unterstützt wird. Sie müssen Microsoft Entra-Hybridverbindung und Gruppenrichtlinien von einer Active Directory-Domäne oder lokale Gruppenrichtlinien auf jedem Sitzungshost verwenden.

Azure-Regionen

Sie können Hostpools, Arbeitsbereiche und Anwendungsgruppen in den folgenden Azure-Regionen bereitstellen. Diese Liste der Regionen gibt an, wo die Metadaten für den Hostpool gespeichert werden können. Sitzungshosts für die Benutzersitzungen können sich jedoch in einer beliebigen Azure-Region befinden, und lokal, wenn Sie Azure Virtual Desktop in Azure Stack HCI verwenden, sodass Sie Computeressourcen in der Nähe Ihrer Benutzer bereitstellen können. Weitere Informationen zu den Datentypen und Standorten finden Sie unter Datenstandorte für Azure Virtual Desktop.

  • Australien (Osten)
  • Kanada, Mitte
  • Kanada, Osten
  • Indien, Mitte
  • USA (Mitte)
  • East US
  • USA (Ost) 2
  • Japan, Osten
  • USA Nord Mitte
  • Nordeuropa
  • USA Süd Mitte
  • UK, Süden
  • UK, Westen
  • USA, Westen-Mitte
  • Europa, Westen
  • USA (Westen)
  • USA, Westen 2
  • USA, Westen 3

Azure Virtual Desktop ist auch in Sovereign Clouds verfügbar, z. B. Azure für US Government und Azure, betrieben von 21Vianet in China.

Weitere Informationen zur Architektur und Resilienz des Azure Virtual Desktop-Diensts finden Sie unter Architektur und Resilienz des Azure Virtual Desktop-Dienstes.

Remotedesktopclients

Ihre Benutzer benötigen einen Remotedesktopclient, um eine Verbindung mit Desktops und Anwendungen herzustellen. Die folgenden Remotedesktopclients unterstützen Azure Virtual Desktop:

Wichtig

Azure Virtual Desktop bietet keine Unterstützung für den RADC- (RemoteApp and Desktop Connections) oder den Remotedesktopverbindungsclient (MSTSC).

Informationen dazu, welche URLs die Clients zum Herstellen einer Verbindung verwenden und die Sie in Firewalls und Internetfilter zulassen müssen, finden Sie in der Liste der erforderlichen URLs.

Nächste Schritte