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.
Diese Checkliste gilt in erster Linie für Horizon Cloud-Kundenkonten, über die vor der Dienstversion vom September 2021 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 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 unten aufgeführten Abschnitte erfordern Entscheidungen, bevor der Kern-Pod selbst bereitgestellt wird, während es sich um optionale Elemente handelt oder um diejenigen, die nach der Pod-Bereitstellung entschieden werden können.
| Für die Kern-Pod-Bereitstellung | Kann nach der Kern-Pod-Bereitstellung durchgeführt werden |
|---|---|
|
|
- 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 des Azure-Kontotyps StorageV2 ermöglicht. Stellen Sie sicher, dass Ihre Microsoft Azure-Richtlinien die Erstellung von Inhalten, die den Azure-Kontotyp 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
Wenn sich die folgende Tabelle auf die Microsoft Azure-Kapazität bezieht, ist keine manuelle Installation erforderlich. Solange die angegebenen Kapazitäten im Abonnement verfügbar sind, instanziiert der Pod-Bereitsteller automatisch die beschriebenen VMs.
| ☐ | 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, damit Sie das Microsoft Azure-Portal während der Schritte zur Vorbereitung der Bereitstellung verwenden können. |
| ☐ | Microsoft Azure-Kapazität für die Kern-Horizon Cloud-Pod-Artefakte, die in diesem Abonnement bereitgestellt werden sollen. (Diese Liste schließt die Kapazitäten aus, die für die optionalen Unified Access Gateway-Konfigurationen und für Ihre erwarteten Desktop- und App-Arbeitslasten erforderlich sind.)
|
| ☐ | Optional. Kapazität, die bei der Angabe der Verwendung von Unified Access Gateway für den Pod erforderlich ist.
Hinweis: Das
A4_v2-VM-Modell reicht nur für Proof-of-Concept (PoCs), Pilotversuche oder kleinere Umgebungen aus, in denen Sie wissen, dass Sie 1.000 aktive Sitzungen auf dem Pod nicht überschreiten werden.
Falls die Region Ihres Abonnements die Größen von |
| ☐ | Für jedes Abonnement erstellter Dienstprinzipal und Authentifizierungsschlüssel. Siehe 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. Siehe Ressourcenanbieter, für die Horizon Cloud den Status „Registriert“ im Microsoft Azure-Abonnement haben muss. |
| ☐ | Abonnement-ID, Verzeichnis-ID, Anwendungs-ID und identifizierter Schlüssel für Microsoft Azure. |
| ☐ | Optional. 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. Siehe Konfigurieren des erforderlichen virtuellen Netzwerks in Microsoft Azure. 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 unter
Übersicht über die Verwendung mehrerer Mandantensubnetze.
|
| ☐ | 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 DNS-Anforderungen für einen Horizon Cloud-Pod in Microsoft und zugehörige Dienstfunktionen und Port- und Protokollanforderungen für einen Horizon Cloud-Pod im Manifest der Version vom September 2019 oder höher. |
| ☐ | Optional. 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. |
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. |
Unified Access Gateway-Anforderungen
Der Pod-Bereitstellungsassistent legt bestimmte Elemente unten fest, wenn Sie eine Unified Access Gateway-Konfiguration auf dem Pod auswählen. Definitionsgemäß ermöglicht ein externes Unified Access Gateway Clients in externen Netzwerken den Start der virtuellen Desktops und Apps, während ein internes Unified Access Gateway Clients in internen Netzwerken vertrauenswürdige HTML Access (Blast)-Verbindungen ermöglicht. Um Endbenutzerverbindungen aus dem Internet zu unterstützen und die jeweiligen virtuellen Desktops und Anwendungen zu starten, muss für den Pod ein externes Unified Access Gateway konfiguriert sein.
| ☐ | FQDN für die Unified Access Gateway-Konfiguration. |
| ☐ | Zertifikat oder Zertifikate für das Unified Access Gateway im PEM-Format, das dem FQDN entspricht.
Hinweis: Wenn das Zertifikat oder die Zertifikate, die Sie für diesen Zweck bereitstellen, CRLs (Zertifikatsperrlisten) oder OCSP (Online Certificate Status Protocol)-Einstellungen verwenden, die sich auf bestimmte DNS-Namen beziehen, müssen Sie sicherstellen, dass der ausgehende Internetzugriff aus dem VNet diese DNS-Server auflösen und erreichen kann. Während der Konfiguration Ihres bereitgestellten Zertifikats in der
Unified Access Gateway-Gateway-Konfiguration greift die
Unified Access Gateway-Software auf diese DNS-Namen zu, um den Sperrstatus des Zertifikats zu überprüfen. Wenn diese DNS-Namen nicht erreichbar sind, schlägt die Bereitstellung des Pods während der Phase
Verbindung fehl. Diese Namen sind in hohem Maße von der Zertifizierungsstelle abhängig, die Sie zum Abrufen der Zertifikate verwendet haben. Sie unterliegen daher nicht der Kontrolle von VMware.
|
| ☐ | Optional, außer wenn Sie möchten, dass Ihre Endbenutzer die Zwei-Faktor-Authentifizierung verwenden. In diesem Fall muss das Unified Access Gateway für die Zwei-Faktor-Authentifizierung bei einem RADIUS-Authentifizierungsserver konfiguriert werden, einschließlich:
Hinweis: Wenn Sie nach der Bereitstellung des Pods
Universal Broker verwenden möchten und die Zwei-Faktor-Authentifizierung in
Universal Broker konfiguriert ist, sind einige zusätzliche Konfigurationsschritte erforderlich, wenn Ihre internen Endbenutzer diese Zwei-Faktor-Authentifizierung überspringen möchten. Wenn ein Pod über eine interne
Unified Access Gateway-Konfiguration verfügt, leitet diese Konfiguration die Verbindungsanforderungen an virtuelle Desktops und Apps für solche internen Endbenutzer weiter. Wenn
Universal Broker den Schritt für die Zwei-Faktor-Authentifizierung für Ihre internen Endbenutzer überspringen soll, geben Sie nach der Bereitstellung des Pods und der Konfiguration von
Universal Broker die Bereiche der Egress-NAT-Adressen ein, die Ihrem internen Endbenutzerdatenverkehr entsprechen. Mit diesen Bereichen kann
Universal Broker Datenverkehr des Clients von den internen Endbenutzern identifizieren, die sich von den externen Endbenutzern unterscheiden, um die Zwei-Faktor-Authentifizierung zu überspringen. Weitere Informationen finden Sie im Dokumentationsthema
Definieren von internen Netzwerkbereichen für Universal Broker
|
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 Horizon Cloud-Pod – Onboarding des ersten Pods – Allgemeiner Workflow 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
Der Workflow für die Active Directory-Registrierung der Konsole schreibt die folgenden Elemente vor. Umfassende 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. |
| ☐ |
Referenz: Dienstkonten, die Horizon Cloud für seine Vorgänge benötigt. |
| ☐ |
Referenz: Dienstkonten, die Horizon Cloud für seine Vorgänge benötigt. |
| ☐ |
Weitere Informationen finden Sie unter Dienstkonten, die Horizon Cloud für seine Vorgänge benötigt. Wenn Sie in Microsoft Active Directory eine neue OE erstellen, legt das System möglicherweise automatisch das Attribut |
| ☐ |
Weitere Informationen finden Sie unter Dienstkonten, die Horizon Cloud für seine Vorgänge benötigt. Wenn Sie in Microsoft Active Directory eine neue OE erstellen, legt das System möglicherweise automatisch das Attribut |
| ☐ | Active Directory-Gruppen
Wenn in Ihrer Mandantenumgebung Horizon Cloud-Pods in Microsoft Azure mit Manifesten vor 1600.0 ausgeführt werden, müssen sich das Domänenbeitrittskonto sowie alle zusätzlichen Domänenbeitrittskonten ebenfalls in der Gruppe „Horizon Cloud-Administratoren“ oder in einer Active Directory-Gruppe befinden, der die Rolle Superadministrator in Horizon Cloud erteilt wurde. |
| ☐ | Active Directory-Organisationseinheit (OU) bzw. -einheiten (OUs) für virtuelle Desktops und RDS-sitzungsbasierte Desktops oder veröffentlichte Anwendungen oder beides. Wenn Sie in Microsoft Active Directory eine neue OE erstellen, legt das System möglicherweise automatisch das Attribut |
Universal Broker-Konfiguration
Wenn Sie die Konsole verwenden, um Universal Broker für Ihren Mandanten zu konfigurieren, stellen Sie sicher, dass Sie die Elemente aus der folgenden Tabelle erfüllen, die für Ihre gewünschten Optionen gelten. Ausführliche Informationen finden Sie unter 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 DNS-Anforderungen für einen Horizon Cloud-Pod in Microsoft und zugehörige Dienstfunktionen und Port- und Protokollanforderungen für einen Horizon Cloud-Pod im Manifest der Version vom September 2019 oder höher. |
| ☐ | Abhängig von den Typen der Endbenutzerverbindungen, die Sie bereitstellen möchten, gilt Folgendes:
|
| ☐ | Optional. Wenn Universal Broker die Zwei-Faktor-Authentifizierung erzwingen soll, müssen Pods über ein externes Unified Access Gateway verfügen, das für die Zwei-Faktor-Authentifizierung bei einem RADIUS-Authentifizierungsserver konfiguriert ist. Universal Broker übergibt die Authentifizierungsanforderung an das Unified Access Gateway, das mit dem RADIUS-Server kommuniziert, und leitet dann die Antwort zurück an Universal Broker. Für diese externe Unified Access Gateway-Konfiguration sind die folgenden Elemente erforderlich:
|
| ☐ | Optional: Ein benutzerdefinierter FQDN, den Ihre Endbenutzer für den Zugriff auf den Universal Broker-Dienst und das auf diesem FQDN basierende Zertifikat verwenden. Wenn Sie den von VMware bereitgestellten Brokering-FQDN verwenden möchten, ist kein benutzerdefinierter FQDN erforderlich. |
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. Hintergrundinformationen zur DNS-Datensatzzuordnung finden Sie auf der Microsoft Cloud Services-Dokumentationsseite Konfigurieren eines benutzerdefinierten Domänennamens für einen Azure-Clouddienst
- Wenn Sie Ihren Mandanten mit Universal Broker mit einem benutzerdefinierten FQDN konfigurieren
-
☐ Erstellen Sie einen öffentlichen DNS-Datensatz, der Ihren benutzerdefinierten FQDN dem von VMware bereitgestellten Brokering-FQDN in Ihrer Universal Broker-Konfiguration zuweist. Siehe Konfigurieren von Universal Broker. - Wenn der Pod über ein externes Unified Access Gateway verfügt
-
☐ Erstellen Sie einen öffentlichen DNS-Datensatz für den externen Endbenutzerzugriff, der dem FQDN in der Konfiguration des externen Gateways entspricht. Dieser DNS-Datensatz verweist diesen FQDN auf den externen Microsoft Azure-Lastausgleichsdienst in der externen Unified Access Gateway-Konfiguration des Pods. Hintergrundinformationen zur DNS-Datensatzzuordnung finden Sie auf der Microsoft-Dokumentationsseite Konfigurieren eines benutzerdefinierten Domänennamens für einen Azure-Clouddienst
- Wenn der Pod über ein internes Unified Access Gateway verfügt
-
☐ Erstellen Sie einen internen DNS-Datensatz für den internen Endbenutzerzugriff, der dem FQDN in der internen Gateway-Konfiguration entspricht. Dieser DNS-Datensatz übergibt diesen FQDN an den internen Microsoft Azure-Lastausgleichsdienst in der internen Unified Access Gateway-Konfiguration des Pods. - Wenn Sie den Mandanten für Einzel-Pod-Brokering konfigurieren und Ihren Mandanten in VMware Workspace ONE Access integrieren
-
☐ Erstellen Sie einen internen DNS-Datensatz, um die VMware Workspace ONE Access Connector-Verbindungen zum Pod-Manager zu unterstützen. Der VMware Workspace ONE Access Connector synchronisiert die Informationen zu Benutzerzuweisungen aus dem Pod. 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. ☐ Eine Zertifikatskette (CA-Zertifikat, SSL-Zertifikat, SSL-Schlüsseldatei), die dem obigen internen DNS-Datensatz entspricht, der für VMware Workspace ONE Access Connector-Verbindungen mit dem Pod erstellt wurde. Dieses Zertifikat muss mithilfe der Schritte unter Hochladen von SSL-Zertifikaten auf einen Horizon Cloud-Pod für direkte Verbindungen auf die Pod-Manager hochgeladen werden. Hinweis: Die beiden vorgenannten Punkte werden auch in dem seltenen, untypischen Anwendungsfall eines für Single-Pod-Brokering konfigurierten Mandanten verwendet. Sie würden internen Endbenutzern sagen, dass sie sich direkt mit dem Pod verbinden sollen, anstatt ihnen zu sagen, dass sie sich mit einer internen Unified Access Gateway-Konfiguration auf dem Pod verbinden sollen. Solche direkten Verbindungen innerhalb eines Einzel-Pod-Brokering-Mandanten sind ein ungewöhnlicher Anwendungsfall. In der Regel wird stattdessen ein internes Unified Access Gateway für dieses Szenario 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.
| ☐ | Basis für das Golden Image – mindestens eine der unterstützten Konfigurationen für Microsoft Azure-VMs.
Wenn Sie auf der Image-Seite den Assistenten zum automatisierten Importieren von VMs aus Marketplace 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.
Hinweis: Ab der Version vom Juli 2021 stehen die
Horizon Image-Verwaltungsdienst-Funktionen für Multi-Pod-Images zum Erstellen von Golden Images für Einzelsitzungs-VDI-Desktops zur Verfügung, wenn auf Ihren
Horizon Cloud-Pods das Manifest 2632 oder höher ausgeführt wird und Ihre Mandantenumgebung für die Verwendung von
Universal Broker konfiguriert ist. Durch Ausführen des Workflows „Neues Image“ auf der Seite „Multi-Pod-Images“ wird standardmäßig eine VM mit Standard_D2_v2 erstellt. Wenn die Umschaltoption für GPU aktiviert ist, wird beim Ausführen des Workflows „Neues Image“ auf der Seite „Multi-Pod-Images“ standardmäßig eine VM mit Standard_NV6 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. |
Anforderungen an den Image Management Service (IMS)
Ab der Version vom Juli 2021 sind die Horizon Image-Verwaltungsdienst-Funktionen für die Verwendung mit diesen Pods verfügbar, wenn auf Ihren Horizon Cloud-Pods das Manifest 2632 oder höher ausgeführt wird und Ihre Mandantenumgebung für die Verwendung von Universal Broker konfiguriert ist. Für die Verwendung der vom -Dienst bereitgestellten Multi-Pod-Image-Funktionen gelten zusätzliche Anforderungen. Ausführliche Informationen zu den Systemanforderungen für die Verwendung dieser Funktionen finden Sie im Microsoft Azure-Abschnitt Horizon Image Management Service-Systemanforderungen. Eine Übersicht über die zusätzlichen Anforderungen für das Abonnement und den Dienstprinzipal bei der Verwendung von Multi-Pod-Images finden Sie in der folgenden Tabelle.
| ☐ | Die Abonnements, die von den Pods verwendet werden, die an Multi-Pod-Images teilnehmen, müssen sich innerhalb eines einzelnen AAD-Mandanten (Microsoft Azure Active Directory) befinden. |
| ☐ | Der Dienstprinzipal, der von den Pods verwendet wird, die an Multi-Pod-Images teilnehmen, muss eine der folgenden Anforderungen erfüllen:
Da sich die Pods wahrscheinlich in unterschiedlichen Abonnements befinden, ermöglicht die Anforderung des Lesezugriffs das Abonnement jedes teilnehmenden Pods, die Abonnements der anderen teilnehmenden Pods zu sehen. Diese Sichtlinie ist erforderlich, damit der Dienst die Funktionen der gemeinsam genutzten Azure-Image-Galerie zum Erstellen der Multi-Pod-Images verwenden kann. |
| ☐ | Die benutzerdefinierten Rollen, die von den Dienstprinzipalen der teilnehmenden Pods verwendet werden, müssen die folgenden Berechtigungen im Zusammenhang mit der Verwendung der gemeinsam genutzten Azure-Image-Galerie enthalten.
|
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.
| ☐ | 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 |
Anforderungen für die Horizon-Infrastrukturüberwachung
Wenn Ihr Horizon Cloud-Mandant für die Verwendung von Horizon-Infrastrukturüberwachung aktiviert ist, können Sie die Horizon Universal Console nutzen, um diese Funktion auf Ihren Pods zu aktivieren. Wenn Sie diese Funktion auf einem Pod aktivieren, erstellt das System automatisch eine virtuelle Appliance in demselben Microsoft Azure-Abonnement, in dem dieser Pod vorhanden ist, und konfiguriert diese Appliance für die Erfassung der Infrastrukturdaten. Diese Überwachungsfunktion können Sie erst nach dem Onboarding Ihres Mandanten in VMware Cloud Services aktivieren. Weitere Informationen finden Sie unter Onboarding Ihres Horizon Cloud-Mandanten in VMware Cloud Services und Horizon-Infrastrukturüberwachung und Pods in Ihrer Horizon Cloud-Umgebung.
| ☐ | Führen Sie das Onboarding Ihres Mandanten in VMware Cloud Services durch. |
| ☐ | Das Microsoft Azure-Abonnement aller Pods, auf denen Sie die Horizon-Infrastrukturüberwachung-Funktion aktivieren möchten, muss diese zusätzlichen Anforderungen erfüllen.
|
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)
