Voraussetzungen für AVD und VDS v5.4
Beitragende
AVD- und VDS-Anforderungen und Hinweise
In diesem Dokument werden die erforderlichen Elemente zur Implementierung von Azure Virtual Desktop (AVD) mithilfe von NetApp Virtual Desktop Service (VDS) beschrieben. Die „Quick Checklist“ enthält eine kurze Liste der erforderlichen Komponenten und Schritte zur Vorabbereitstellung, um eine effiziente Bereitstellung zu gewährleisten. Der restliche Leitfaden bietet je nach getroffenen Konfigurationsauswahl detailliertere Informationen für jedes Element.
Schnelle Checkliste
Azure-Anforderungen
-
Azure AD-Mandant
-
Microsoft 365-Lizenzierung zur Unterstützung von AVD
-
Azure Abonnement
-
Verfügbare Azure Quote für virtuelle Azure-Maschinen
-
Azure-Administratorkonto mit globalen Administratorrollen und Abonnementberechtigungen
-
Domänenadministratorkonto mit der Rolle „Enterprise Admin“ für AD Connect Setup
Informationen vor der Implementierung
-
Bestimmen Sie die Gesamtzahl der Benutzer
-
Azure Region Bestimmen
-
Bestimmen Sie Den Active Directory-Typ
-
Storage-Typ Ermitteln
-
Host-VM-Image oder -Anforderungen ermitteln
-
Bewerten vorhandener Azure und On-Premises-Netzwerkkonfiguration
VDS-Bereitstellung – Detaillierte Anforderungen
Verbindungsanforderungen für Endbenutzer
-
Windows Desktop
-
Web
-
MacOS
-
IOS
-
IGEL Think Client (Linux)
-
Android (Vorschau)
|
Azure Virtual Desktop unterstützt den Remote App und Desktop Connections-Client (RADC) oder den MSTSC-Client (Remote Desktop Connection) nicht. |
|
Azure Virtual Desktop unterstützt derzeit den Remote Desktop-Client aus dem Windows Store nicht. Unterstützung für diesen Client wird in einem zukünftigen Release hinzugefügt. |
Die Remote Desktop Clients müssen Zugriff auf die folgenden URLs haben:
Adresse | Ausgehender TCP-Port | Zweck | Client(e) |
---|---|---|---|
*.AVD.microsoft.com |
443 |
Dienstverkehr |
Alle |
*.servicebus.windows.net 443 Fehlerbehebungsdaten |
Alle |
go.microsoft.com |
443 |
Microsoft FWLinks |
Alle |
Aka.ms |
443 |
Microsoft URL-Shortener |
Alle |
docs.microsoft.com |
443 |
Dokumentation |
Alle |
privacy.microsoft.com |
443 |
Datenschutzerklärung |
Alle |
query.prod.cms.rt.microsoft.com |
443 |
|
Das Öffnen dieser URLs ist für ein zuverlässiges Client-Erlebnis unerlässlich. Das Blockieren des Zugriffs auf diese URLs wird nicht unterstützt und wirkt sich auf die Servicefunktionalität aus. Diese URLs entsprechen nur den Client-Sites und -Ressourcen und enthalten keine URLs für andere Dienste wie Azure Active Directory. |
Startpunkt DES VDS-Setup-Assistenten
Der VDS-Setup-Assistent kann einen Großteil der erforderlichen Voraussetzungen für eine erfolgreiche AVD-Bereitstellung verarbeiten. Der Setup-Assistent ("") Erzeugt oder verwendet die folgenden Komponenten.
Azure-Mandant
Erforderlich: ein Azure-Mandant und Azure Active Directory
Die AVD-Aktivierung in Azure ist eine mandantenfähige Einstellung. VDS unterstützt die Ausführung einer AVD-Instanz pro Mandant.
Azure-Abonnement
Erforderlich: ein Azure Abonnement (beachten Sie die Abonnement-ID, die Sie verwenden möchten)
Alle bereitgestellten Azure Ressourcen sollten in einem dedizierten Abonnement eingerichtet werden. Das erleichtert die Kostenverfolgung für AVD und vereinfacht den Bereitstellungsprozess. HINWEIS: Kostenlose Azure-Testversionen werden nicht unterstützt, da sie nicht über ausreichende Gutschriften für die Bereitstellung einer funktionsfähigen AVD-Implementierung verfügen.
Azure Kernkontingent
Genügend Quote für die VM-Familien, die Sie verwenden werden - insbesondere mindestens 10 Kerne der D v3-Familie für die anfängliche Plattform-Bereitstellung (so wenige wie 2 Kerne verwendet werden können, aber 10 deckt jede erste Möglichkeit der Bereitstellung).
Azure-Administratorkonto
Erforderlich: ein globales Azure-Administratorkonto.
Der VDS-Einrichtungsassistent fordert den Azure Admin an, dem VDS-Dienstprincipal delegierte Berechtigungen zu erteilen und die VDS Azure Enterprise-Applikation zu installieren. Der Administrator muss die folgenden Azure-Rollen zugewiesen haben:
-
Globaler Administrator auf dem Mandanten
-
Besitzerrolle im Abonnement
VM Image
Erforderlich: ein Azure-Image, das Multi-Session Windows 10 unterstützt.
Im Azure Marketplace finden Sie die aktuellsten Versionen ihres Basis-Images unter Windows 10. Alle Azure-Abonnements können automatisch auf diese zugreifen. Wenn Sie ein anderes Bild oder ein benutzerdefiniertes Image verwenden möchten, soll das VDS-Team Ratschläge zum Erstellen oder Ändern anderer Bilder geben oder allgemeine Fragen zu Azure-Bildern mit uns teilen und wir können ein Gespräch vereinbaren.
Active Directory
Für AVD muss die Benutzeridentität ein Bestandteil von Azure AD sein und die VMs zu einer Active Directory-Domäne gehören, die mit derselben Azure AD-Instanz synchronisiert wird. VMs können nicht direkt mit der Azure AD-Instanz verbunden werden, daher muss ein Domänen-Controller mit Azure AD konfiguriert und synchronisiert werden.
-
Der automatisierte Aufbau einer Active Directory-Instanz innerhalb des Abonnements. Die AD-Instanz wird typischerweise durch VDS auf der VDS Control VM (CWMGR1) für Azure Virtual Desktop-Implementierungen erstellt, die diese Option verwenden. AD Connect muss im Rahmen der Einrichtung für die Synchronisierung mit Azure AD konfiguriert sein.
-
Integration in eine vorhandene Active Directory-Domäne, auf die über das Azure-Abonnement (normalerweise über Azure VPN oder Express Route) zugegriffen werden kann, und hat ihre Benutzerliste mit Azure AD über AD Connect oder ein Produkt eines Drittanbieters synchronisiert.
Storage-Ebene
Bei AVD ist die Storage-Strategie so ausgelegt, dass sich keine persistenten Benutzer-/Unternehmensdaten auf den AVD-Session-VMs befinden. Persistente Daten für Benutzerprofile, Benutzerdateien und Ordner sowie Unternehmens-/Applikationsdaten werden auf einem oder mehreren Daten-Volumes gehostet, die auf einer unabhängigen Datenebene gehostet werden.
FSLogix ist eine Technologie für Containerbildung und löst zahlreiche Probleme bei der Benutzerprofil (wie Datenwildwuchs und langsame Anmeldungen), indem ein User Profile Container (VHD oder VHDX Format) beim Initialisieren der Session-Hosts eingebunden wird.
Aufgrund dieser Architektur ist eine Datenspeicherfunktion erforderlich. Diese Funktion muss in der Lage sein, den Datentransfer jeden Morgen/Nachmittag zu verarbeiten, wenn ein großer Teil der Benutzer sich gleichzeitig anmeldet/abmeldet. Selbst Umgebungen mittlerer Größe können erhebliche Anforderungen an den Datentransfer stellen. Die Festplatten-Performance der Daten-Storage-Ebene ist eine der primären Performance-Variablen für den Endbenutzer. Dabei muss besonders darauf Wert legen, die Performance dieses Storage angemessen zu dimensionieren, nicht nur die Storage-Menge. Im Allgemeinen sollte die Storage-Ebene so dimensioniert sein, dass sie 5-15 IOPS pro Benutzer unterstützt.
-
Einrichtung und Konfiguration von Azure NetApp Files (ANF) (empfohlen). ANF Standard Service Level unterstützt bis zu 150 Benutzer, Umgebungen mit 150-500 Benutzern ANF Premium wird empfohlen. Für 500+ Benutzer wird ANF Ultra empfohlen.
-
Einrichtung und Konfiguration einer File Server VM
Netzwerkbetrieb
Erforderlich: Inventarisierung aller vorhandenen Netzwerknetze einschließlich der Subnetze, die über eine Azure Express Route oder VPN zum Azure Abonnement sichtbar sind. Die Implementierung muss sich überschneidende Subnetze vermeiden.
Mit dem VDS-Setup-Assistenten können Sie den Netzwerkbereich definieren, falls im Rahmen der geplanten Integration in vorhandene Netzwerke ein Bereich erforderlich oder vermieden werden muss.
Bestimmen Sie während der Bereitstellung einen IP-Bereich für den Benutzer. Gemäß Azure Best Practices werden nur IP-Adressen in einem privaten Bereich unterstützt.
-
192.168.0.0 bis 192.168.255.255
-
172.16.0.0 bis 172.31.255.255
-
10.0.0.0 bis 10.255.255.255
CKWMGR1
Einige der einzigartigen Funktionen von VDS, wie zum Beispiel die kostensparende Funktion für Workload Scheduling und Live Scaling, erfordern einen administrativen Präsenz im Mandanten und im Abonnement. Daher wird eine administrative VM namens CWMGR1 im Rahmen der Automatisierung des VDS-Einrichtungsassistenten bereitgestellt. Neben VDS-Automatisierungsaufgaben enthält diese VM auch VDS-Konfigurationen in einer SQL Express-Datenbank, lokale Protokolldateien und ein erweitertes Konfigurationsprogramm mit dem Namen DCConfig.
-
Ein RDS-Gateway (wird nur in RDS-Implementierungen verwendet)
-
Ein HTML 5-Gateway (nur in RDS-Implementierungen verwendet)
-
Ein RDS-Lizenzserver (wird nur in RDS-Implementierungen verwendet)
-
Ein Domain-Controller (falls ausgewählt)
Entscheidungsbaum im Bereitstellungsassistenten
Im Rahmen der ersten Implementierung werden eine Reihe von Fragen beantwortet, um die Einstellungen für die neue Umgebung anzupassen. Im Folgenden finden Sie einen Überblick über die wichtigsten Entscheidungen, die getroffen werden sollen.
Azure Region
Legen Sie fest, welche Region oder Regionen Azure Ihre AVD Virtual Machines hosten wird. Beachten Sie, dass für Azure NetApp Files und bestimmte VM-Familien (z. B. VMs mit GPU-Unterstützung) eine definierte Support-Liste für Azure-Regionen vorhanden ist, während AVD in den meisten Regionen verfügbar ist.
-
Dieser Link kann zur Identifizierung verwendet werden "Produktverfügbarkeit von Azure nach Region"
Typ Active Directory
Legen Sie fest, welchen Active Directory-Typ Sie verwenden möchten:
-
Active Directory vor Ort vorhanden
-
Siehe "AVD VDS-Komponenten und -Berechtigungen" Dokument, um die erforderlichen Berechtigungen und Komponenten in Azure und der lokalen Active Directory-Umgebung zu erläutern
-
Neue auf Azure Abonnementbasis basierende Active Directory Instanz
-
Azure Active Directory Domain Services
Datenspeicher
Legen Sie fest, wo die Daten für Benutzerprofile, einzelne Dateien und Unternehmensfreigaben platziert werden. Zur Auswahl stehen:
-
Azure NetApp Dateien
-
Azure Files
-
Herkömmlicher Dateiserver (Azure VM mit Managed Disk)
NetApp VDS Implementierungsanforderungen für vorhandene Komponenten
NetApp VDS-Implementierung mit vorhandenen Active Directory Domain Controllern
Dieser Konfigurationstyp erweitert eine vorhandene Active Directory-Domäne, um die AVD-Instanz zu unterstützen. In diesem Fall implementiert VDS eine begrenzte Anzahl von Komponenten in der Domäne, um automatisierte Bereitstellungs- und Verwaltungsaufgaben für die AVD-Komponenten zu unterstützen.
-
Ein vorhandener Active Directory-Domänencontroller, auf den VMs auf dem Azure vnet zugreifen können, normalerweise über Azure VPN oder Express Route ODER über einen in Azure erstellten Domänen-Controller.
-
Erweiterung der VDS-Komponenten und -Berechtigungen, die für das VDS-Management von AVD-Hostpools und Daten-Volumes erforderlich sind, wenn sie der Domäne hinzugefügt werden. Im AVD VDS-Handbuch für Komponenten und Berechtigungen werden die erforderlichen Komponenten und Berechtigungen definiert, und für den Bereitstellungsvorgang ist ein Domänenbenutzer mit Domänenberechtigungen erforderlich, um das Skript auszuführen, mit dem die erforderlichen Elemente erstellt werden.
-
Beachten Sie, dass durch die VDS-Implementierung standardmäßig bei von VDS erstellten VMs ein vnet erstellt wird. Die vnet kann entweder mit vorhandenen Azure-Netzwerk-VNets Peered werden oder die CWMGR1-VM kann mit den erforderlichen vordefinierten Subnetzen in ein vorhandenes vnet verschoben werden.
Identifikationsdaten und Werkzeug zur Vorbereitung der Domäne
Administratoren müssen an einem bestimmten Punkt des Bereitstellungsprozesses eine Domänenadministratorberechtigung bereitstellen. Eine temporäre Domänenadministratorberechtigung kann später erstellt, verwendet und gelöscht werden (sobald der Bereitstellungsprozess abgeschlossen ist). Alternativ können Kunden, die Unterstützung beim Aufbau der Voraussetzungen benötigen, das Domain Preparation Tool nutzen.
NetApp VDS-Implementierung mit vorhandenem Filesystem
VDS erstellt Windows-Freigaben, mit denen über AVD-Session-VMs auf Benutzerprofile, persönliche Ordner und Unternehmensdaten zugegriffen werden kann. VDS implementiert standardmäßig entweder die File-Server- oder Azure NetApp File-Optionen, aber wenn Sie eine vorhandene Dateispeicherkomponente besitzen, kann VDS die Freigaben auf diese Komponente verweisen, sobald die VDS-Bereitstellung abgeschlossen ist.
-
Die Komponente muss SMB v3 unterstützen
-
Die Komponente muss mit derselben Active Directory-Domäne wie die AVD-Sitzungshosts verbunden sein
-
Die Komponente muss in der Lage sein, einen UNC-Pfad zur Verwendung in der VDS-Konfiguration zur Verfügung zu stellen – ein Pfad kann für alle drei Freigaben verwendet werden, oder es können separate Pfade für jedes dieser Freigaben festgelegt werden. Beachten Sie, dass VDS Berechtigungen auf Benutzerebene für diese Freigaben festlegen wird. Beachten Sie daher das VDS AVD Components and Permissions Dokument, um sicherzustellen, dass die entsprechenden Berechtigungen für die VDS Automation Services erteilt wurden.
NetApp VDS-Implementierung mit vorhandenen Azure AD Domain Services
Für diese Konfiguration ist ein Prozess erforderlich, um die Attribute der vorhandenen Azure Active Directory Domain Services-Instanz zu identifizieren. Wenden Sie sich an Ihren Account Manager, um eine Bereitstellung dieses Typs anzufordern. NetApp VDS-Implementierung mit vorhandener AVD-Implementierung bei diesem Konfigurationstyp wird vorausgesetzt, dass die erforderlichen Azure vnet-, Active Directory- und AVD-Komponenten bereits vorhanden sind. Die VDS-Implementierung erfolgt auf dieselbe Weise wie die Konfiguration „NetApp VDS Deployment with Existing AD“, fügt jedoch die folgenden Anforderungen hinzu:
-
Rd-Eigentümerrolle für den AVD-Mandanten muss den VDS Enterprise Applications in Azure gewährt werden
-
AVD Host Pool und AVD Host Pool VMs müssen über die VDS Import Funktion in der VDS Web App in VDS importiert werden Dieser Prozess sammelt die Metadaten der AVD-Host-Pools und der VM-Session und speichert sie in VDS, sodass diese Elemente vom VDS gemanagt werden können
-
AVD-Benutzerdaten müssen mithilfe des CRA-Tools in den VDS-Benutzerabschnitt importiert werden. Dieser Prozess fügt Metadaten zu jedem Benutzer in die VDS-Steuerebene ein, sodass die AVD App Group-Mitgliedschaft und die Sitzungsinformationen über VDS verwaltet werden können
ANHANG A: VDS-Steuerebenen-URLs und IP-Adressen
VDS-Komponenten im Azure-Abonnement kommunizieren mit den globalen VDS-Komponenten der Kontrollebene, wie der VDS-Webanwendung und den VDS-API-Endpunkten. Für den Zugriff müssen die folgenden Basis-URI-Adressen für den bidirektionalen Zugriff auf Port 443 sicher gestellt werden:
Wenn Ihr Zutrittskontrollgerät nur eine sichere Liste nach IP-Adresse erstellen kann, sollte die folgende Liste der IP-Adressen geschützt werden. Beachten Sie, dass VDS den Azure Traffic Manager Service verwendet. Diese Liste kann sich daher im Laufe der Zeit ändern:
13.67.190.243 13.67.215.62 13.89.50.122 13.67.227.115 13.67.227.230 13.67.227.227 23.99.136.91 40.122.119.157 40.78.132.166 40.78.129.17 40.122.52.167 40.70.147.2 40.86.99.202 13.68.19.178 13.68.114.184 137.116.69.208 13.68.18.80 13.68.114.115 13.68.114.136 40.70.63.81 52.171.218.239 52.171.223.92 52.171.217.31 52.171.216.93 52.171.220.134 92.242.140.21
ANHANG B: Microsoft AVD-Anforderungen
Dieser Abschnitt zu den Microsoft AVD-Anforderungen enthält eine Zusammenfassung der AVD-Anforderungen von Microsoft. Vollständige und aktuelle AVD-Anforderungen finden Sie hier:
Host-Lizenzierung für Azure Virtual Desktop-Session
Azure Virtual Desktop unterstützt die folgenden Betriebssysteme. Stellen Sie also sicher, dass Sie über die entsprechenden Lizenzen für Ihre Benutzer verfügen, die auf dem Desktop und den Apps basieren, die Sie implementieren möchten:
BETRIEBSSYSTEM | Erforderliche Lizenz |
---|---|
Windows 10 Enterprise Multi-Session oder Windows 10 Enterprise |
MICROSOFT 365 E3, E5, A3, A5, F3, Business Premium Windows E3, E5, A3, A5 |
Windows 7 Enterprise |
MICROSOFT 365 E3, E5, A3, A5, F3, Business Premium Windows E3, E5, A3, A5 |
Windows Server 2012 R2, 2016, 2019 |
RDS Client Access License (CAL) mit Software Assurance |
URL-Zugriff für AVD-Maschinen
Die virtuellen Azure-Maschinen, die Sie für Azure Virtual Desktop erstellen, müssen Zugriff auf die folgenden URLs haben:
Adresse | Ausgehender TCP-Port | Zweck | Service-Tag |
---|---|---|---|
*.AVD.microsoft.com |
443 |
Dienstverkehr |
Windows VirtualDesktop |
mrsglobalsteus2prod.blob.core.windows.net |
443 |
Agent- und SXS-Stack-Updates |
AzureCloud |
*.core.windows.net |
443 |
Agent-Traffic |
AzureCloud |
*.servicebus.windows.net |
443 |
Agent-Traffic |
AzureCloud |
prod.warmpath.msftcloudes.com |
443 |
Agent-Traffic |
AzureCloud |
catalogartifact.azureedge.net |
443 |
Azure Marketplace |
AzureCloud |
kms.core.windows.net |
1688 |
Windows-Aktivierung |
Internet |
AVDportalstorageblob.blob.core.windows.net |
443 |
Support im Azure-Portal |
AzureCloud |
In der folgenden Tabelle sind optionale URLs aufgeführt, auf die Ihre virtuellen Azure-Maschinen Zugriff haben:
Adresse | Ausgehender TCP-Port | Zweck | Service-Tag |
---|---|---|---|
*.microsoftonline.com |
443 |
Authentifizierung bei MS Online Services |
Keine |
*.events.data.microsoft.com |
443 |
Telemetrie-Service |
Keine |
www.msftconnecttest.com |
443 |
Erkennt, ob das Betriebssystem mit dem Internet verbunden ist |
Keine |
*.prod.do.dsp.mp.microsoft.com |
443 |
Windows Update |
Keine |
login.windows.net |
443 |
Melden Sie sich bei MS Online Services, Office 365 an |
Keine |
*.sfx.ms |
443 |
Updates für die OneDrive Client-Software |
Keine |
*.digicert.com |
443 |
Überprüfung des Zertifikatsannulfs |
Keine |
Optimale Performance-Faktoren
Stellen Sie sicher, dass Ihr Netzwerk die folgenden Anforderungen erfüllt, um eine optimale Leistung zu erzielen:
-
Die RTT-Latenz (Round Trip) vom Netzwerk des Clients in die Azure-Region, in der Host-Pools eingesetzt wurden, sollte weniger als 150 ms betragen.
-
Der Netzwerkverkehr kann außerhalb der Grenzen von Ländern/Regionen fließen, wenn VMs, auf denen Desktops und Applikationen gehostet werden, eine Verbindung zum Management-Service herstellen.
-
Um die Netzwerk-Performance zu optimieren, empfehlen wir, dass die VMs des Session-Hosts in derselben Azure-Region wie der Management-Service zusammenliegen.
Unterstützte BS-Images für Virtual Machines
Azure Virtual Desktop unterstützt die folgenden x64-Betriebssystem-Images:
-
Windows 10 Enterprise Multi-Session, Version 1809 oder höher
-
Windows 10 Enterprise, Version 1809 oder höher
-
Windows 7 Enterprise
-
Windows Server 2019
-
Windows Server 2016
-
Windows Server 2012 R2
Azure Virtual Desktop unterstützt keine Images des Betriebssystems x86 (32 Bit), Windows 10 Enterprise N oder Windows 10 Enterprise KN. Aufgrund der Sektorgröße unterstützt Windows 7 zudem keine VHD- oder VHDX-basierten Profillösungen, die auf Managed Azure Storage gehostet werden.
Die verfügbaren Automatisierungs- und Implementierungsoptionen hängen davon ab, welches Betriebssystem und welche Version Sie wählen. Die in der folgenden Tabelle aufgeführten Angaben werden gezeigt:
Betriebssystem | Azure Image-Galerie | Manuelle VM-Implementierung | INTEGRATION VON ARM-Vorlagen | Bereitstellen von Host-Pools auf Azure Marketplace |
---|---|---|---|---|
Windows 10 Multisession, Version 1903 |
Ja. |
Ja. |
Ja. |
Ja. |
Windows 10 Multisession, Version 1809 |
Ja. |
Ja. |
Nein |
Nein |
Windows 10 Enterprise, Version 1903 |
Ja. |
Ja. |
Ja. |
Ja. |
Windows 10 Enterprise, Version 1809 |
Ja. |
Ja. |
Nein |
Nein |
Windows 7 Enterprise |
Ja. |
Ja. |
Nein |
Nein |
Windows Server 2019 |
Ja. |
Ja. |
Nein |
Nein |
Windows Server 2016 |
Ja. |
Ja. |
Ja. |
Ja. |
Windows Server 2012 R2 |
Ja. |
Ja. |
Nein |
Nein |