Diese Checkliste führt Sie durch die Vorbereitung Ihrer Microsoft Azure-Abonnements und -Netzwerke für die Bereitstellung eines Pod über Horizon Cloud in Microsoft Azure. Indem Sie sicherstellen, dass diese Anforderungen wie im folgenden beschrieben erfüllt sind, sorgen Sie sowohl für eine erfolgreiche neue Pod-Bereitstellung als auch für einen erfolgreichen Abschluss der wichtigen Aufgaben, die nach der Bereitstellung eines Pods durchgeführt werden müssen.
Dieses Dokumentationsthema ist in folgende Abschnitte unterteilt:
- Anforderungen an die Horizon Cloud-Steuerungsebene
- Anforderungen für Microsoft Azure-Abonnements
- Netzwerkanforderungen
- Port- und Protokollanforderungen
- Pod-Bereitstellungsworkflow
- Active Directory-Anforderungen
- Universal Broker-Anforderungen
- Anforderungen an den DNS-Datensatz
- Golden Images, Desktops und Farmen für Horizon Cloud
- Lizenzierung für die Microsoft Windows-Betriebssysteme
- Referenzarchitektur
- Ressourcen
Diese Checkliste gilt in erster Linie für Horizon Cloud-Kundenkonten, über die vor der Dienstversion vom Oktober 2020 noch nie ein Pod bereitgestellt wurde oder die noch nie cloudverbunden in der Mandantenumgebung bereitgestellt wurden. Solche Umgebungen können als saubere oder neue Umgebungen bezeichnet werden. Neue Pod-Bereitstellungen, die nach der Übertragung der Binärdateien der Cloud-Ebene und den neuen Pod-Manifestversionen auf die Cloud-Ebene der vierteljährlichen Dienstversion vom Oktober 2020 stattfinden, werden mit der neuen Pod-Manifestversion bereitgestellt. Die Anforderungen für eine erfolgreiche Pod-Bereitstellung werden in erster Linie durch die Manifestversion des Pods bestimmt. Auch Binärdateien der Cloud-Ebene, die sich in der Produktions-Cloud-Ebene befinden, bestimmen möglicherweise die Anforderungen für eine erfolgreiche Bereitstellung.
Einige der nachstehend aufgeführten Anforderungen sind für die Pod-Bereitstellung als solche erforderlich. Andere Anforderungen werden für die wichtigsten Aufgaben benötigt, die nach der Pod-Bereitstellung durchgeführt werden, um eine produktive Mandantenumgebung zu erhalten, die von Pods zur Verfügung gestellte Desktops und Anwendungen für Ihre Endbenutzer bereitstellen kann.
- Anforderungen für die Pod-Bereitstellung als solche
- Anforderungen für eine produktive Umgebung nach der Pod-Bereitstellung
Wichtig: Bevor Sie den Pod-Bereitstellungsassistenten starten und Ihren Pod bereitstellen, müssen Sie zusätzlich zu den unten aufgeführten Anforderungen die folgenden wichtigen Punkte beachten:
- Ab der Dienstversion vom Juli 2020 müssen in ganz neuen Umgebungen neue Pods mit mindestens einer Gateway-Konfiguration bereitgestellt werden. Wenn Ihr Kundenkonto vor der Version vom Juli 2020 erstellt wurde, Sie Ihren ersten Pod jedoch noch nicht bereitgestellt haben, ist für die Bereitstellung des ersten Pods die Konfiguration von mindestens einem Gateway erforderlich (zum Zeitpunkt der Bereitstellung des Pods).
- Für eine erfolgreiche Pod-Bereitstellung darf keine der Microsoft Azure-Richtlinien, die Sie oder Ihr IT-Team in Ihrer Microsoft Azure-Umgebung festgelegt haben, die Erstellung der Pod-Komponenten blockieren, ablehnen oder beschränken. Außerdem müssen Sie sicherstellen, dass die integrierten Richtliniendefinitionen Ihrer Microsoft Azure-Richtlinien die Erstellung der Pod-Komponenten nicht blockieren, ablehnen oder einschränken. Als Beispiel müssen Sie und Ihr IT-Team sicherstellen, dass keine Ihrer Microsoft Azure-Richtlinien die Erstellung von Komponenten auf einem Azure-Speicherkonto blockiert, verweigert oder einschränkt. Informationen zu Azure-Richtlinien finden Sie in der Dokumentation zu Azure-Richtlinien.
- Der Pod-Bereitsteller erfordert, dass Ihr Azure-Speicherkonto dem Bereitsteller die Verwendung der Azure-Kontotypen StorageV1 und StorageV2 erlaubt. Stellen Sie sicher, dass Ihre Microsoft Azure-Richtlinien die Erstellung von Inhalten, die die Azure-Kontotypen StorageV1 und StorageV2 erfordern, nicht einschränken oder ablehnen.
- Sofern Sie im Bereitstellungsassistenten keine benutzerdefinierten Ressourcen-Tags angeben, erstellt Horizon Cloud im Rahmen der Pod- und Gateway-Bereitstellungsprozesse Ressourcengruppen (RGs) in Ihrem Microsoft Azure-Abonnement, für die keine Tags vorhanden sind. Dies beinhaltet die anfängliche Ressourcengruppe, die für die temporäre Jump Box erstellt wird, mit deren Hilfe diese Bereitstellungsvorgänge orchestriert werden. Seit der Aktualisierung der Cloud-Ebene vom 8. Oktober 2020 verfügt der Bereitstellungsassistent über eine Funktion, in der Sie benutzerdefinierte Ressourcen-Tags angeben können, die Sie auf die vom Bereitsteller erstellten Ressourcengruppen anwenden möchten. Wenn Sie keine benutzerdefinierten Ressourcen-Tags angeben und Ihr Microsoft Azure-Abonnement bestimmte Ressourcen-Tag-Anforderungen aufweist, schlägt die Pod-Bereitstellung fehl, wenn Sie versuchen, einen Pod in diesem Abonnement bereitzustellen. Die Pod-Bereitstellung kann bei Pod-Aktualisierungen oder beim Hinzufügen einer Gateway-Konfiguration zu einem Pod fehlschlagen. Wenn Sie nicht planen, die Funktion für benutzerdefinierte Ressourcen-Tags des Bereitstellungsassistenten zu verwenden, müssen Sie sicherstellen, dass Ihre Microsoft Azure-Richtlinien das Erstellen der nicht markierten Ressourcengruppen des Pods im Zielabonnement ermöglichen. Eine Liste der vom Bereitsteller erstellten RGs finden Sie im Administratorhandbuch unter dem Thema Für einen in Microsoft Azure bereitgestellten Pod erstellte Ressourcengruppen.
- Alle mit der Cloud verbundenen Pods müssen zum Zeitpunkt der Bereitstellung dieser Pods für denselben Satz von Active Directory-Domänen sichtbar sein.
Anforderungen an die Horizon Cloud-Steuerungsebene
| ☐ | Aktives My VMware-Konto für die Anmeldung bei der Horizon Cloud-Steuerungsebene. |
Anforderungen für Microsoft Azure-Abonnements
| ☐ | Gültiges Microsoft Azure-Abonnement in einer unterstützten Microsoft Azure-Umgebung (Azure Commercial, Azure China und Azure Government). Wenn Sie das externe Unified Access Gateway in einem eigenen VNet mit einem eigenen Abonnement bereitstellen, benötigen Sie ein zusätzliches gültiges Microsoft Azure-Abonnement in derselben Microsoft Azure-Umgebung.
Hinweis:
Horizon Cloud unterstützt die Mehrheit der Microsoft Azure-Regionen. Eine Auflistung der derzeit nicht unterstützten Microsoft Azure-Regionen finden Sie im
VMware Knowledgebase-Artikel „Microsoft Azure-Regionen mit Horizon Cloud Service für Microsoft Azure (77121)“.
|
| ☐ | Gültige Microsoft Azure-Administratorrechte in diesem Microsoft Azure-Abonnement. Weitere Informationen finden Sie in der Microsoft-Dokumentation unter dem Thema Erste Schritte mit rollenbasierter Zugriffssteuerung im Azure-Portal. |
| ☐ | Verfügbare Microsoft Azure-Mindestkapazität für Horizon Cloud-Infrastruktur zusätzlich zur erwarteten Desktop- und App-Arbeitslast. Solange diese Kapazität zur Verfügung gestellt wird, stellt Horizon Cloud diese VMs automatisch bereit. Eine manuelle Installation ist damit nicht erforderlich.
Hinweis:
Das externe Unified Access Gateway kann optional in einem eigenen virtuellen Microsoft Azure-Netzwerk (VNet) bereitgestellt werden, entweder mit demselben Abonnement wie der Pod oder mit einem anderen Abonnement. Bei der Bereitstellung des externen Unified Access Gateway in einem eigenen VNet ist die folgende Kapazität für das Abonnement erforderlich, unter dem das externe Unified Access Gateway bereitgestellt wird:
|
| ☐ | Für jedes Abonnement erstellter Dienstprinzipal und Authentifizierungsschlüssel. Zusätzliche Informationen finden Sie unter Erstellen einer Azure Active Directory-Anwendung und eines Dienstprinzipals mit Ressourcenzugriff mithilfe eines Portals. Siehe auch Erstellen des vom Horizon Cloud-Podbereitsteller benötigten Dienstprinzipals durch Erstellen einer Anwendungsregistrierung. |
| ☐ | Jedem Dienstprinzipal muss die entsprechende Rolle zugewiesen werden, die die Aktionen zulässt, die Horizon Cloud im Abonnement durchführen muss. Bei dieser Rolle kann es sich um die Rolle Teilnehmer oder eine benutzerdefinierte Rolle mit den erforderlichen zulässigen Aktionen auf Abonnementebene handeln. Wenn Sie die Konfiguration des externen Gateways in einer vorhandenen Ressourcengruppe in einem separaten Abonnement bereitstellen, können detailliertere Berechtigungen für den Dienstprinzipal dieses Abonnements festgelegt werden. Weitere Informationen zu den erforderlichen Rollenaktionen finden Sie unter Für Horizon Cloud in Ihren Microsoft Azure-Abonnements erforderliche Vorgänge.
Wichtig: Die Rolle muss direkt dem Dienstprinzipal zugewiesen werden, der für
Horizon Cloud verwendet wird. Die Verwendung einer gruppenbasierten Zuweisung einer Rolle für den Dienstprinzipal – in dem die Rolle einer Gruppe zugewiesen und der Dienstprinzipal Mitglied dieser Gruppe ist – wird nicht unterstützt.
|
| ☐ | Erforderliche Ressourcenanbieter sind in jedem Microsoft Azure-Abonnement registriert. Weitere Informationen finden Sie in Schritt 8.b unter Erstellen des erforderlichen Dienstprinzipals durch Erstellen einer Anwendungsregistrierung durch den Horizon Cloud-Pod-Bereitsteller. |
| ☐ | Abonnement-ID, Verzeichnis-ID, Anwendungs-ID und identifizierter Schlüssel für Microsoft Azure. |
| ☐ | Wenn Sie das externe Unified Access Gateway mit einem eigenen Abonnement in einem separaten VNet bereitstellen und Ihre Organisation die Verwendung einer von Ihnen kontrollierten Ressourcengruppe erfordert, die nicht vom Pod-Bereitsteller erstellt wurde, nutzen Sie die Funktion zur Bereitstellung des externen Unified Access Gateway in Ihrer eigenen benannten Ressourcengruppe. Um diese Funktion zu verwenden, müssen Sie diese Ressourcengruppe in dem Abonnement erstellen, bevor Sie den Pod-Bereitsteller ausführen. Sie müssen auch sicherstellen, dass die erforderlichen Berechtigungen für den Pod-Bereitsteller vorhanden sind, damit er die Unified Access Gateway-Konfiguration in dieser Ressourcengruppe bereitstellen, die Konfiguration verwalten und die Unified Access Gateway-Software im standardmäßigen Pod-Aktualisierungsvorgang aktualisieren kann. Weitere Informationen zu den erforderlichen Berechtigungen finden Sie unter Für Horizon Cloud in Ihren Microsoft Azure-Abonnements erforderliche Vorgänge. |
Netzwerkanforderungen
| ☐ | Virtuelles Microsoft Azure-Netzwerk (VNet), das in der gewünschten Microsoft Azure-Region mit dem anwendbaren Adressbereich zur Abdeckung der erforderlichen Subnetze erstellt wurde. Weitere Informationen finden Sie unter Virtuelles Azure-Netzwerk. Wenn Sie das externe Unified Access Gateway in einem eigenen, vom VNet des Pods getrennten VNet bereitstellen, müssen Sie dieses VNet des Unified Access Gateway in derselben Microsoft Azure-Region erstellen wie das VNet des Pods mit anwendbarem Adressbereich, um erforderliche Subnetze abzudecken, und die beiden VNets als Peers verbinden. |
| ☐ | 3 sich nicht überschneidende Adressbereiche im CIDR-Format im VNet des Pods, reserviert für Subnetze.
Hinweis: Für Pods, die mit der Manifestversion 2298.0 oder höher neu bereitgestellt werden, können Sie den Pod bearbeiten, um zusätzliche Mandantensubnetze für die Verwendung mit den VMs in Ihren Farmen und Desktop-Zuweisungen hinzuzufügen. Die zusätzlichen Mandanten-Subnetze können sich in demselben VNet befinden, in dem der Pod bereitgestellt ist, oder in einem Peer-VNet. Weitere Informationen finden Sie im
Administratorhandbuch.
|
| ☐ | Bei der Bereitstellung des externen Unified Access Gateway in einem eigenen, vom VNet des Pods getrennten VNet 3 sich nicht überschneidende Adressbereiche im CIDR-Format im VNet des Unified Access Gateway, reserviert für Subnetze.
|
| ☐ | NTP-Server verfügbar und über den Horizon Cloud-Pod und Unified Access Gateway-Instanzen zugänglich. |
| ☐ | Konfigurieren Sie den DNS-Server des VNet (virtuellen Netzwerks) und verweisen Sie auf einen gültigen DNS-Server, der sowohl interne Computernamen als auch externe Namen auflösen kann. |
| ☐ | Ausgehender Internetzugriff aus den VNets, die Sie für die Pod- und Gateway-Bereitstellung verwenden, muss bestimmte DNS-Namen unter Verwendung bestimmter Ports und Protokolle auflösen und erreichen können. Dies ist für die Bereitstellung und den laufenden Betrieb erforderlich. Eine Liste der DNS-Namen und Ports finden Sie unter Anforderungen an DNS für einen Horizon Cloud-Pod in Microsoft Azure und Port- und Protokollanforderungen für einen Horizon Cloud-Pod im Manifest der Version vom September 2019 oder höher. |
| ☐ | Proxy-Serverinformationen bei Bedarf für ausgehenden Internetzugriff auf dem VNet, das während der Bereitstellung und des laufenden Betriebs der Horizon Cloud-Umgebung verwendet wird (optional) |
| ☐ | Microsoft Azure VPN/Express-Route konfiguriert (optional) |
| ☐ | FQDN für externen Benutzerzugriff, internen Benutzerzugriff oder beide (erforderlich, wenn ein Pod mit Unified Access Gateway bereitgestellt wird).
Hinweis: Für Pods, die mit der Manifestversion 2298.0 oder höher neu bereitgestellt wurden, gilt: Wenn ein Pod über beide Gateway-Typen verfügt, muss in den Konfigurationen für das externe Gateway und das interne Gateway im Pod derselbe FQDN angegeben werden. Da beide Gateways den gleichen FQDN verwenden, konfigurieren Sie nach der Pod-Bereitstellung ein aufgeteiltes DNS (Split Domain Name System), um die Gateway-Adresse entweder zum externen Gateway oder zum internen Gateway aufzulösen, je nach dem Ursprungsnetzwerk der DNS-Abfrage des Endbenutzer-Clients.
|
| ☐ | Zertifikat oder Zertifikate für Unified Access Gateway im PEM-Format, das dem FQDN entspricht (erforderlich, wenn ein Pod mit Unified Access Gateway bereitgestellt wird).
Hinweis:
|
| ☐ | Zwei-Faktor-Authentifizierung für einen lokalen RADIUS-Authentifizierungsserver (optional)
|
Port- und Protokollanforderungen
| ☐ | Für das Onboarding von Pods und den laufenden Betrieb Ihrer Horizon Cloud-Umgebung sind bestimmte Ports und Protokolle erforderlich. Siehe Port- und Protokollanforderungen für einen Horizon Cloud-Pod im Manifest der Version vom September 2019 oder höher. |
Pod-Bereitstellungsworkflow
Die vorstehenden Elemente sind diejenigen, die vor dem Start des Pod-Bereitstellungsassistenten benötigt werden. Nachdem Sie sichergestellt haben, dass Sie über die vorstehenden Elemente verfügen, führen Sie die unter Allgemeiner Workflow, wenn Sie Ihren ersten mit der Cloud verbundenen Horizon Cloud-Pod mit dem Pod-Bereitsteller in Microsoft Azure bereitstellen beschriebenen Pod-Bereitstellungsschritte bis Schritt 4 aus, um Ihren Pod bereitzustellen.
Nachdem der Pod erfolgreich bereitgestellt wurde, stellen Sie sicher, dass die im folgenden Abschnitt beschriebenen Elemente vorhanden sind, damit Sie die übrigen wichtigen Schritte dieses allgemeinen Workflows abschließen können.
Active Directory-Anforderungen
Die folgenden Elemente werden für den Workflow zur Registrierung von Active Directory benötigt. Informationen zu diesem Workflow finden Sie unter Durchführen der ersten Active Directory-Domänenregistrierung in der Horizon Cloud-Umgebung.
| ☐ | Eine der folgenden unterstützten Active Directory-Konfigurationen:
|
| ☐ | Unterstützte Domänenfunktionsebenen von Active Directory Domain Services (AD DS):
|
| ☐ | Alle mit der Cloud verbundenen Pods im selben Horizon Cloud-Kundenkonto müssen zum Zeitpunkt der Bereitstellung dieser Pods für denselben Satz von Active Directory-Domänen sichtbar sein. Diese Anforderung gilt nicht nur für zusätzliche Pods, die Sie nach dem ersten Pod in Microsoft Azure bereitstellen, sondern auch für die Horizon-Pods, die über Horizon Cloud Connector und per Cloud mit dem gleichen Kundenkonto verbunden sind. Die Checkliste für diese Horizon-Pods finden Sie unter VMware Horizon-Pods mit Horizon Cloud – Checkliste der Voraussetzungen – Aktualisiert für die Verbindung von Pods ab der Dienstversion vom Oktober 2020. |
| ☐ | Domänendienstkonto
Sie sollten auch das Kennwort für das Konto auf Läuft nie ab festlegen, um den Dauerzugriff auf die Anmeldung bei Ihrer Horizon Cloud-Umgebung zu gewährleisten. Weitere Informationen und Anforderungen finden Sie unter Dienstkonten, die Horizon Cloud für seine Vorgänge benötigt. |
| ☐ | Zusätzliches Domänendienstkonto – kann nicht dasselbe Konto verwenden wie oben
Sie sollten auch das Kennwort für das Konto auf Läuft nie ab festlegen, um den Dauerzugriff auf die Anmeldung bei Ihrer Horizon Cloud-Umgebung zu gewährleisten. Weitere Informationen und Anforderungen finden Sie unter Dienstkonten, die Horizon Cloud für seine Vorgänge benötigt. |
| ☐ | Domänenbeitrittskonto
Hinweis: Wenn Sie in Microsoft Active Directory eine neue OE erstellen, legt das System möglicherweise automatisch das Attribut
Prevent Accidental Deletion fest, das für die neu erstellte OE und alle abgeleiteten Objekte für die Berechtigung „Alle untergeordneten Objekte löschen“
Deny anwendet. Wenn Sie daher dem Domänenbeitrittskonto explizit die Berechtigung „Computerobjekte löschen“ zugewiesen haben, hat Active Directory im Fall einer neu erstellten OE möglicherweise eine Außerkraftsetzung auf die explizit zugewiesene Berechtigung „Computerobjekte löschen“ angewendet. Da durch das Löschen des Flags
Versehentliches Löschen verhindern das von Active Directory auf die Berechtigung „Alle untergeordneten Objekte löschen“ angewendete
Deny möglicherweise nicht automatisch gelöscht wird, müssen Sie im Fall einer neu hinzugefügten OE das für die Berechtigung zum Löschen aller untergeordneten Objekte in der OE und allen untergeordneten OEs festgelegte
Deny möglicherweise prüfen und manuell löschen, bevor Sie das Domänenbeitrittskonto in der
Horizon Cloud-Konsole verwenden.
|
| ☐ | Zusätzliches Domänenbeitrittskonto (optional, kann nicht dasselbe Konto verwenden wie oben)
Hinweis: Wenn Sie in Microsoft Active Directory eine neue OE erstellen, legt das System möglicherweise automatisch das Attribut
Prevent Accidental Deletion fest, das für die neu erstellte OE und alle abgeleiteten Objekte für die Berechtigung „Alle untergeordneten Objekte löschen“
Deny anwendet. Wenn Sie daher dem Domänenbeitrittskonto explizit die Berechtigung „Computerobjekte löschen“ zugewiesen haben, hat Active Directory im Fall einer neu erstellten OE möglicherweise eine Außerkraftsetzung auf die explizit zugewiesene Berechtigung „Computerobjekte löschen“ angewendet. Da durch das Löschen des Flags
Versehentliches Löschen verhindern das von Active Directory auf die Berechtigung „Alle untergeordneten Objekte löschen“ angewendete
Deny möglicherweise nicht automatisch gelöscht wird, müssen Sie im Fall einer neu hinzugefügten OE das für die Berechtigung zum Löschen aller untergeordneten Objekte in der OE und allen untergeordneten OEs festgelegte
Deny möglicherweise prüfen und manuell löschen, bevor Sie das Domänenbeitrittskonto in der
Horizon Cloud-Konsole verwenden.
|
| ☐ | Active Directory-Gruppen
|
| ☐ | Active Directory-Organisationseinheit (OU) bzw. -einheiten (OUs) für virtuelle Desktops und RDS-sitzungsbasierte Desktops oder veröffentlichte Anwendungen oder beides.
Hinweis: Wenn Sie in Microsoft Active Directory eine neue OE erstellen, legt das System möglicherweise automatisch das Attribut
Prevent Accidental Deletion fest, das für die neu erstellte OE und alle abgeleiteten Objekte für die Berechtigung „Alle untergeordneten Objekte löschen“
Deny anwendet. Wenn Sie daher dem Domänenbeitrittskonto explizit die Berechtigung „Computerobjekte löschen“ zugewiesen haben, hat Active Directory im Fall einer neu erstellten OE möglicherweise eine Außerkraftsetzung auf die explizit zugewiesene Berechtigung „Computerobjekte löschen“ angewendet. Da durch das Löschen des Flags
Versehentliches Löschen verhindern das von Active Directory auf die Berechtigung „Alle untergeordneten Objekte löschen“ angewendete
Deny möglicherweise nicht automatisch gelöscht wird, müssen Sie im Fall einer neu hinzugefügten OE das für die Berechtigung zum Löschen aller untergeordneten Objekte in der OE und allen untergeordneten OEs festgelegte
Deny möglicherweise prüfen und manuell löschen, bevor Sie das Domänenbeitrittskonto in der
Horizon Cloud-Konsole verwenden.
|
Universal Broker-Anforderungen
Ab der Version vom Juli 2020 gilt: Wenn Ihre Horizon Cloud-Mandantenumgebung ein ab diesem Datum gültiges völlig neues Konto ist und Sie soeben die Bereitstellung Ihres ersten Pods in Microsoft Azure abgeschlossen haben, dann können Sie Universal Broker als Brokering-Methode für Ihre Umgebung auswählen. Wenn Sie Universal Broker für Ihre Umgebung konfigurieren möchten, werden folgende Elemente benötigt. Siehe Konfigurieren von Universal Broker.
| ☐ | Ausgehender Internetzugriff der VNets, die Sie für den Pod verwenden, muss bestimmte DNS-Namen auflösen und über bestimmte Ports und Protokolle erreichen können. Dies ist für die Universal Broker-Konfiguration und den laufenden Betrieb erforderlich. Eine Liste der DNS-Namen und Ports finden Sie unter Anforderungen an DNS für einen Horizon Cloud-Pod in Microsoft Azure und Port- und Protokollanforderungen für einen Horizon Cloud-Pod im Manifest der Version vom September 2019 oder höher. |
| ☐ | Optional: Konfigurieren Sie die Gateways Ihres Pods für die 2-Faktor-Authentifizierung bei einem RADIUS-Authentifizierungsserver, wenn Universal Broker für den Pod eine 2-Faktor-Authentifizierung verwenden soll.
|
| ☐ | Optional: Ein benutzerdefinierter FQDN, den Ihre Endbenutzer für den Zugriff auf den Universal Broker-Dienst und das auf diesem FQDN basierende Zertifikat verwenden (optional) |
Anforderungen an den DNS-Datensatz
Nachdem der Pod in der Microsoft Azure-Cloud bereitgestellt wurde und abhängig von Ihrer Geschäftssituation und den Funktionen, die Sie nutzen möchten, ist es wichtig, Datensätze in Ihrem DNS-Server einzurichten, die vollqualifizierte Domänennamen (FQDNs) den IP-Adressen des Pods zuordnen.
Hinweis: Für Pods, die mit der Manifestversion 2298.0 oder höher bereitgestellt wurden, gilt: Wenn ein Pod über beide Gateway-Typen verfügt, muss in den Konfigurationen für das externe Gateway und das interne Gateway im Pod derselbe FQDN angegeben werden. Da beide Gateways den gleichen FQDN verwenden, konfigurieren Sie nach der Pod-Bereitstellung ein aufgeteiltes DNS (Split Domain Name System), um die Gateway-Adresse entweder zum externen Gateway oder zum internen Gateway aufzulösen, je nach dem Ursprungsnetzwerk der DNS-Abfrage des Endbenutzer-Clients.
| ☐ | Wenn Sie Universal Broker mit einem benutzerdefinierten FQDN konfiguriert haben, erstellen Sie einen öffentlichen DNS-Datensatz, der Ihren benutzerdefinierten FQDN dem von VMware bereitgestellten Brokering-FQDN in Ihrer Universal Broker-Konfiguration zuordnet. Siehe Konfigurieren von Universal Broker. |
| ☐ | Für den externen Endbenutzerzugriff erstellter öffentlicher DNS-Datensatz, der dem FQDN entspricht und auf den externen Lastausgleichsdienst von Microsoft Azure in der externen Unified Access Gateway-Konfiguration des Pods verweist (erforderlich, wenn der bereitgestellte Pod diese Konfiguration besitzt). Weitere Informationen finden Sie unter Konfigurieren eines benutzerdefinierten Domänennamens für einen Azure-Clouddienst. |
| ☐ | Für den internen Endbenutzerzugriff erstellter interner DNS-Datensatz, der dem FQDN entspricht und auf den internen Lastausgleichsdienst von Microsoft Azure in der internen Unified Access Gateway-Konfiguration des Pods verweist (erforderlich, wenn der bereitgestellte Pod diese Konfiguration besitzt). |
| ☐ | Interner DNS-Datensatz, der erstellt wird, wenn Sie Einzel-Pod-Brokering für Ihre Bereitstellung auswählen und die Bereitstellung mit VMware Workspace ONE Access integrieren möchten. In diesem Szenario unterstützt dieser interne DNS-Datensatz die VMware Workspace ONE Access-Verbindungen mit dem Pod, in dem der VMware Workspace ONE Access Connector die Informationen über Benutzerzuweisungen vom Pod synchronisiert. Dieser interne DNS-Datensatz stimmt mit dem FQDN im Zertifikat überein, das Sie direkt auf den Pod hochladen werden, und verweist auf den internen Microsoft Azure-Load Balancer des Pods. Erforderlich, wenn Sie VMware Workspace ONE Access mit einem Pod in einer für Einzel-Pod-Brokering konfigurierten Umgebung verwenden möchten.
Hinweis: Dieser interne DNS-Datensatz und ein Zertifikat, das zum Pod passt und in den Pod selbst hochgeladen wird, werden auch im seltenen, untypischen Anwendungsfall verwendet, wenn Sie interne Endbenutzer zum Herstellen einer direkten Verbindung mit dem Pod auffordern würden, anstatt sie eine Verbindung mit einer internen
Unified Access Gateway-Konfiguration auf dem Pod herstellen zu lassen. Derartige direkte Verbindungen sind ein ungewöhnliches Anwendungsbeispiel. In der Regel wird stattdessen ein internes
Unified Access Gateway verwendet.
|
| ☐ | Zertifikatskette (CA-Zertifikat, SSL-Zertifikat, SSL-Schlüsseldatei), die dem obigen internen DNS-Datensatz entspricht, der für VMware Workspace ONE Access-Verbindungen mit dem Pod erstellt wurde. Weitere Informationen finden Sie unter Hochladen von SSL-Zertifikaten auf einen Horizon Cloud-Pod für direkte Verbindungen. (Dies ist auch erforderlich, wenn Sie den untypischen Anwendungsfall haben, dass interne Endbenutzer eine direkte Verbindung mit dem Pod herstellen. Direkte Verbindungen stellen eine seltene, ungewöhnliche Nutzung dar. In der Regel wird stattdessen ein internes Unified Access Gateway verwendet.) |
Golden Images, Desktops und Farmen für Horizon Cloud
Ihr Microsoft Azure-Abonnement muss die folgenden Anforderungen erfüllen, die von den Typen der Golden Images, VDI-Desktops und RDS-Farmen abhängig sind, die Sie über den bereitgestellten Pod bereitstellen möchten.
Hinweis: Wenn in Ihrem Konto die Verwendung der
App Volumes-Funktionen aktiviert ist und Sie die Aktion
Erfassen der Konsole verwenden, um
App Volumes-Anwendungen zu Ihrem Bestand hinzuzufügen, dann generiert das System eine Desktop-Zuweisung von zwei Desktop-VMs, um den Erfassungsworkflow zu unterstützen. Ihre Kapazität muss auch das Erstellen dieser Desktops abdecken, während Sie den Erfassungsworkflow durchführen. Sie können diese Desktop-Zuweisung löschen, nachdem das Erfassen von Anwendungen für Ihre Umgebung abgeschlossen ist.
| ☐ | Basis für das Golden Image – eine der unterstützten Konfigurationen für Microsoft Azure-VMs.
Hinweis: Wenn Sie den Assistenten zum automatisierten Importieren von VMs aus dem Download-Center verwenden, um eine Basis-VM zu erstellen, verwendet das System automatisch eine der oben genannten VM-Größen. Die Standardauswahl des Systems basiert auf den interne Algorithmen, einschließlich der Überprüfung, welche Größen in der Microsoft Azure-Region des Pods verfügbar sind. Wenn Sie den Assistenten zum Erstellen einer GPU-fähigen VM verwenden, wird standardmäßig die VM-Größe „Standard_NV6“ erstellt. Wenn Sie den Assistenten verwenden, um eine auf dem Serverbetriebssystem basierte VM zu erstellen, wird eine VM mit „Standard_D2_v2“ oder „Standard_D2_v3“ erstellt. Beim Erstellen einer Clientbetriebssystem-basierten VM oder einer Windows 10-VM für mehrere Sitzungen wird eine VM mit „Standard_D3_v2“ oder „Standard_D4_v3“ erstellt.
|
| ☐ | Modellauswahl für die Desktop-VMs in VDI-Desktop-Zuweisungen – eine beliebige der Konfigurationen für Microsoft Azure-VMs, die in der Microsoft Azure-Region verfügbar sind (mit Ausnahme derjenigen, die nicht mit Horizon Cloud-Desktopvorgängen kompatibel sind). Für Produktionsumgebungen empfehlen VMware-Skalierungstests die Verwendung von Modellen mit mindestens 2 CPUs. |
| ☐ | Modellauswahl für die RDSH-VMs in Farmen – eine der Konfigurationen für Microsoft Azure-VMs, die in der Microsoft Azure-Region verfügbar sind (mit Ausnahme derjenigen, die nicht mit Horizon Cloud-RDS-Farmvorgängen kompatibel sind). Diese Anforderung gilt auch für eine VM, auf der Microsoft Windows 10 Enterprise für Mehrfachsitzungen ausgeführt wird, wenn diese VM mit Horizon Cloud verwendet wird. Gemäß Beschreibung in den Häufig gestellten Fragen zu Microsoft Windows 10 Enterprise für Mehrfachsitzungen in der Microsoft Azure Windows Virtual Desktop-Dokumentation ist Microsoft Windows 10 Enterprise für Mehrfachsitzungen ein Remotedesktop-Sitzungshost(RDSH)-Typ, der mehrere gleichzeitige interaktive Sitzungen zulässt, die zuvor nur von Microsoft Windows Server Betriebssystemen bereitgestellt werden konnten. Die für RDS-Server geltenden Horizon Cloud-Workflows gelten auch für Microsoft Windows 10 Enterprise für Mehrfachsitzungen. Für Produktionsumgebungen empfehlen VMware-Skalierungstests die Verwendung von Modellen mit mindestens 2 CPUs. |
Lizenzierung für die Microsoft Windows-Betriebssysteme
Diese Elemente beziehen sich auf die Microsoft Windows-Betriebssysteme in Ihren importierten VMs, auf Golden Images, auf RDSH-fähige Farm-VMs und auf virtuelle Desktop-VMs. Eine Liste der von Horizon Cloud unterstützten Microsoft Windows-Betriebssysteme finden Sie im VMware Knowledgebase-Artikel 78170 und VMware Knowledgebase-Artikel 70965.
Horizon Cloud stellt keine Lizenz für das Gastbetriebssystem bereit, die für die Verwendung von Microsoft Windows-Betriebssystemen erforderlich ist, die Sie im Zuge der Verwendung der Horizon Cloud-Workflows nutzen. Sie, der Kunde, sind dafür verantwortlich, über gültige und geeignete Microsoft-Lizenzen zu verfügen, die Sie zu Folgendem berechtigen: Erstellen von, Ausführen von Workflows für und Betreiben von Windows-basierten Desktop-VMs und RDSH-VMs, die Sie für Ihre Horizon Cloud-Mandantenumgebung auswählen. Die erforderliche Lizenzierung hängt von der beabsichtigten Verwendung ab.
Tipp: Informationen zur Lizenzierung für Microsoft Windows Virtual Desktop für Windows 10 Enterprise für Mehrfachsitzungen und Windows 7 Enterprise finden Sie in der Microsoft Azure-Dokumentation unter dem Thema
Preisgestaltung für Windows Virtual Desktop.
| ☐ | Lizenzierung für einen oder mehrere der folgenden Typen: Microsoft Windows 7 Enterprise, Microsoft Windows 10 (Clienttypen) |
| ☐ | Lizenzierung für Microsoft Windows 10 Enterprise für Mehrfachsitzungen |
| ☐ | Lizenzierung für einen oder mehrere der folgenden Typen: Microsoft Windows Server 2012 R2, Microsoft Server 2016, Microsoft Server 2019 |
| ☐ | Lizenzierungsserver für Microsoft Windows RDS – für Hochverfügbarkeit werden redundante Lizenzierungsserver empfohlen |
| ☐ | Microsoft RDS-Benutzer oder -Geräte-CALs oder beides |
Referenzarchitektur
Verwenden Sie die nachfolgenden Architekturdiagramme als Referenz.
Ressourcen
Weitere Informationen finden Sie in den folgenden Ressourcen.
- Dokumentationsseite für VMware Horizon Cloud Service: Links zu den Produkthandbüchern und Versionshinweisen
- Dokumentationsseite für VMware Unified Access Gateway
- Schnellstart-Lernprogramm für VMware Horizon Cloud on Microsoft Azure
- Übersicht über Microsoft Azure Resource Manager (5 Minuten)
- Erstellen eines Microsoft Azure-Dienstprinzipals mithilfe des Portals (6 Minuten)
- Virtuelles Microsoft Azure-Netzwerk (VNet) (5 Minuten)
- Peering für virtuelle Microsoft Azure-Netzwerke (6 Minuten)
