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
  • Mandantenkonto der Steuerungsebene
  • Microsoft Azure-Abonnementelemente
  • Netzwerk
  • Ports und Protokolle
  • Optionales Unified Access Gateway (in Pod-Bereitstellung)
  • Active Directory
  • Optionales Unified Access Gateway (nach der Bereitstellung hinzugefügt)
  • Universal Broker
  • DNS-Datensätze
  • Golden Images, Desktop, Farmkapazitäten
  • Microsoft Windows-Betriebssystemlizenzen
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:
  • 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.)
Pod
  • Temporäre Pod-Bereitstellungsengine, auch als (temporäre) Jumpbox bezeichnet – 1 x Standard_F2
  • Pod/Pod-Manager mit aktivierter Hochverfügbarkeit – 2 x Standard_D4_v3 (ohne Standard_D4_v3 in der Region: 2 x Standard_D3_v2)
  • Pod/Pod-Manager ohne aktivierte Hochverfügbarkeit – 1 x Standard_D4_v3 (ohne Standard_D4_v3 in der Region: 1 x Standard_D3_v2)
  • Microsoft Azure-Datenbank für PostgreSQL-Dienst – Generation 5, Arbeitsspeicher optimiert, 2 vCores, 10 GB Speicher
  • Wenn Ihr Pod einsatzbereit ist, muss Ihre Kapazität in der Microsoft Azure-Cloud auch die importierten VMs, Golden Images, virtuellen Desktops, RDSH-Farmen und App Volumes-VMs mit App-Erfassung aufnehmen können, die Sie in diesem Pod erstellen. Weitere Informationen finden Sie unten im Abschnitt Horizon Cloud-Basisimages, Desktops und Farmen.
  • Wenn in Ihrem Mandantenkonto die Verwendung der Horizon-Infrastrukturüberwachung-Funktion aktiviert ist und Sie diese Funktion auf dem Pod aktivieren möchten, nachdem dieser bereitgestellt ist, muss Ihre Kapazität zu diesem Zeitpunkt auch die Bereitstellung der Virtuelle Horizon Edge-Appliance abdecken. Sehen Sie hierzu den folgenden Abschnitt Anforderungen für die Horizon-Infrastrukturüberwachung.
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.
Externes Unified Access Gateway im selben VNet des Pods
2 x Standard_A4_v2 oder 2 x Standard_F8s_v2
Externes Unified Access Gateway in einem eigenen VNet
  • Externe Unified Access Gateway-Bereitstellungsengine, auch als (temporäre) Gateway-Jumpbox bezeichnet – 1 x Standard_F2
  • Externer Gateway-Connector – 1 x Standard_A1_v2
  • Externes Unified Access Gateway – 2 x Standard_A4_v2 oder 2 x Standard_F8s_v2.
Internes Unified Access Gateway
2 x Standard_A4_v2 oder 2 x Standard_F8s_v2

Falls die Region Ihres Abonnements die Größen von Standard_F8s_v2 VM nicht anbietet, zeigt der Assistent für die Pod-Bereitstellung im Schritt „Gateways festlegen“ diese Auswahlmöglichkeit nicht an.

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.
  • Verwaltungssubnetz – mindestens /27
  • VM-Subnetz – Primär (Mandant) – mindestens /27 mit /24 – vorzugsweise /22, basierend auf der Anzahl der Desktops und RDS-Server
  • DMZ-Subnetz – mindestens /28, wenn Unified Access Gateway im VNet des Pods bereitgestellt wird (optional)
Subnetze können entweder manuell auf dem VNet oder durch Horizon Cloud während der Bereitstellung erstellt werden. Wenn Sie manuell erstellte Subnetze verwenden, können keine anderen Ressourcen angehängt werden.
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.
  • Verwaltungssubnetz – mindestens /27
  • Back-End-Subnetz – mindestens /27, vorzugsweise mit /24 – /22, basierend auf der Anzahl der Desktops und RDS-Server
  • DMZ-Subnetz (Front-End-Subnetz) – mindestens /28
Subnetze können entweder manuell auf dem VNet oder durch Horizon Cloud während der Bereitstellung erstellt werden. Wenn Sie manuell erstellte Subnetze verwenden, können keine anderen Ressourcen angehängt werden. Für diesen Anwendungsfall werden die Subnetze in der Regel manuell erstellt. In diesem Anwendungsfall ähnelt der Zweck des Subnetzes des Back-End dem Zweck des VM-Subnetzes (Primär), der in der vorherigen Tabellenzeile beschrieben ist.
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:
  • DNS-Adressen, mit denen Unified Access Gateway den Namen dieses Authentifizierungsservers auflöst
  • Routen, über die Unified Access Gateway das Netzwerkrouting zu diesem Authentifizierungsserver auflöst
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:
  • Lokaler Active Directory-Server, der über VPN/Express-Route verbunden ist
  • Active Directory-Server in Microsoft Azure
  • Microsoft Azure Active Directory Domain Services
Unterstützte Domänenfunktionsebenen von Active Directory Domain Services (AD DS):
  • Microsoft Windows Server 2008 R2
  • Microsoft Windows Server 2012 R2
  • Microsoft Windows Server 2016
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.
Domänendienstkonto
Active Directory-Domänendienstkonto (ein Standardbenutzer mit Lesezugriff), das das Attribut sAMAccountName hat. Das Attribut „sAMAccountName“ darf höchstens 20 Zeichen lang sein und darf keines der folgenden Zeichen enthalten: "/ \ [ ] : ; | = , + * ? < >

Das Konto muss über die folgenden Berechtigungen verfügen:

  • Inhalt auflisten
  • Alle Eigenschaften lesen
  • Berechtigungen lesen
  • Read tokenGroupsGlobalAndUniversal (implizit enthalten in Alle Eigenschaften lesen)

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.

  • Wenn Sie mit dem lokalen VMware Horizon-Angebot vertraut sind, sind die oben genannten Berechtigungen derselbe Satz, der für die sekundären Anmeldekonten des lokalen Horizon-Angebots erforderlich sind.
  • In der Regel sollten den Domänendienstkonten die Standardberechtigungen für den Lesezugriff gewährt werden, die üblicherweise Authentifizierte Benutzer in einer Microsoft Active Directory-Bereitstellung erhalten. Wenn sich die AD-Administratoren Ihrer Organisation jedoch dafür entschieden haben, schreibgeschützte Berechtigungen für reguläre Benutzer zu sperren, müssen Sie diese AD-Administrator bitten, die Standardeinstellungen für Authentifizierte Benutzer für die Domänendienstkonten beizubehalten, die Sie für Horizon Cloud verwenden.

Referenz: Dienstkonten, die Horizon Cloud für seine Vorgänge benötigt.

Zusätzliches Domänendienstkonto
Muss vom Hauptdomänendienstkonto getrennt sein. Die Benutzeroberfläche verhindert die erneute Verwendung desselben Kontos in beiden Feldern.

Active Directory-Domänendienstkonto (ein Standardbenutzer mit Lesezugriff), das das Attribut sAMAccountName hat. Das Attribut „sAMAccountName“ darf höchstens 20 Zeichen lang sein und darf keines der folgenden Zeichen enthalten: "/ \ [ ] : ; | = , + * ? < >

Das Konto muss über die folgenden Berechtigungen verfügen:

  • Inhalt auflisten
  • Alle Eigenschaften lesen
  • Berechtigungen lesen
  • Read tokenGroupsGlobalAndUniversal (implizit enthalten in Alle Eigenschaften lesen)

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.

  • Wenn Sie mit dem lokalen VMware Horizon-Angebot vertraut sind, sind die oben genannten Berechtigungen derselbe Satz, der für die sekundären Anmeldekonten des lokalen Horizon-Angebots erforderlich sind.
  • In der Regel sollten den Domänendienstkonten die Standardberechtigungen für den Lesezugriff gewährt werden, die üblicherweise Authentifizierte Benutzer in einer Microsoft Active Directory-Bereitstellung erhalten. Wenn sich die AD-Administratoren Ihrer Organisation jedoch dafür entschieden haben, schreibgeschützte Berechtigungen für reguläre Benutzer zu sperren, müssen Sie diese AD-Administrator bitten, die Standardeinstellungen für Authentifizierte Benutzer für die Domänendienstkonten beizubehalten, die Sie für Horizon Cloud verwenden.

Referenz: Dienstkonten, die Horizon Cloud für seine Vorgänge benötigt.

Domänenbeitrittskonto
Active Directory-Domänenbeitrittskonto, das vom System zum Durchführen von Sysprep-Vorgängen und zum Hinzufügen der virtuellen Computer zur Domäne verwendet werden kann. In der Regel ein neues Konto, das Sie für diesen ausdrücklichen Zweck erstellen. (Ein Benutzerkonto für den Domänenbeitritt)

Das Konto muss das Attribut sAMAccountName haben. Das Attribut „sAMAccountName“ darf höchstens 20 Zeichen lang sein und darf keines der folgenden Zeichen enthalten: "/ \ [ ] : ; | = , + * ? < >

Die Verwendung von Leerzeichen im Benutzernamen des Kontos wird derzeit nicht unterstützt.

Sie sollten das Kontokennwort auch auf Läuft nie ab einstellen, um sicherzustellen, dass Horizon Cloud die Sysprep-Vorgänge weiterhin ausführen und die virtuellen Computer der Domäne hinzufügen kann.

Für dieses Konto sind die folgenden Active Directory-Berechtigungen erforderlich: „Alle Eigenschaften lesen“, „Kennwort zurücksetzen“, „Computerobjekte erstellen“, „Computerobjekte löschen“ und „Alle Eigenschaften schreiben“. Dieses Konto benötigt außerdem die Active Directory-Berechtigung „Alle Eigenschaften schreiben“ für alle nachfolgenden Objekte der Zielorganisationseinheit (OU), die Sie für Farmen und VDI-Desktop-Zuweisungen verwenden möchten.

Hinweis: Ab Pod-Manifest 2474.0 sind die erforderlichen Berechtigungen für das Domänenbeitrittskonto im Vergleich zum vorherigen Satz, der für Manifeste vor 2474 verwendet wurde, reduziert und umfassen nun das Schreiben aller Eigenschaften auf untergeordnete Computerobjekte. Pods, die frühere Manifeste ausführen, benötigen weiterhin den vorherigen Satz an Berechtigungen. Weitere Informationen hierzu finden Sie unter Dienstkonten, die Horizon Cloud für seine Vorgänge benötigt.

In Bezug auf die Zielorganisationseinheit (OU), die Sie für Farmen und VDI-Desktop-Zuweisungen verwenden möchten, benötigt dieses Konto auch die Active Directory-Berechtigung „Alle Eigenschaften schreiben“ für alle nachfolgenden Objekte dieser Zielorganisationseinheit (OU).

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 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.

Optionales Hilfsdomänenbeitrittskonto
Active Directory-Domänenbeitrittskonto, das vom System zum Durchführen von Sysprep-Vorgängen und zum Hinzufügen der virtuellen Computer zur Domäne verwendet werden kann. In der Regel ein neues Konto, das Sie für diesen ausdrücklichen Zweck erstellen. (Ein Benutzerkonto für den Domänenbeitritt)

Das Konto muss das Attribut sAMAccountName haben. Das Attribut „sAMAccountName“ darf höchstens 20 Zeichen lang sein und darf keines der folgenden Zeichen enthalten: "/ \ [ ] : ; | = , + * ? < >

Die Verwendung von Leerzeichen im Benutzernamen des Kontos wird derzeit nicht unterstützt.

Sie sollten das Kontokennwort auch auf Läuft nie ab einstellen, um sicherzustellen, dass Horizon Cloud die Sysprep-Vorgänge weiterhin ausführen und die virtuellen Computer der Domäne hinzufügen kann.

Für dieses Konto sind die folgenden Active Directory-Berechtigungen erforderlich: „Alle Eigenschaften lesen“, „Kennwort zurücksetzen“, „Computerobjekte erstellen“, „Computerobjekte löschen“ und „Alle Eigenschaften schreiben“. Dieses Konto benötigt außerdem die Active Directory-Berechtigung „Alle Eigenschaften schreiben“ für alle nachfolgenden Objekte der Zielorganisationseinheit (OU), die Sie für Farmen und VDI-Desktop-Zuweisungen verwenden möchten.

Hinweis: Ab Pod-Manifest 2474.0 sind die erforderlichen Berechtigungen für das Domänenbeitrittskonto im Vergleich zum vorherigen Satz, der für Manifeste vor 2474 verwendet wurde, reduziert und umfassen nun das Schreiben aller Eigenschaften auf untergeordnete Computerobjekte. Pods, die frühere Manifeste ausführen, benötigen weiterhin den vorherigen Satz an Berechtigungen. Weitere Informationen hierzu finden Sie unter Dienstkonten, die Horizon Cloud für seine Vorgänge benötigt.

In Bezug auf die Zielorganisationseinheit (OU), die Sie für Farmen und VDI-Desktop-Zuweisungen verwenden möchten, benötigt dieses Konto auch die Active Directory-Berechtigung „Alle Eigenschaften schreiben“ für alle nachfolgenden Objekte dieser Zielorganisationseinheit (OU).

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 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
  • Horizon Cloud-Administratoren – Active Directory-Sicherheitsgruppe für Horizon Cloud-Administratoren. Enthält die Horizon Cloud-Administratorbenutzer. Dieser Gruppe wird die Rolle Superadministrator in Horizon Cloud gewährt.
  • Horizon Cloud-Benutzer – Active Directory-Sicherheitsgruppe für die Benutzer, die auf virtuelle Desktops und RDS-sitzungsbasierte Desktops sowie veröffentlichte Anwendungen in Horizon Cloud zugreifen können.

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 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-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:
  • Für Endbenutzerverbindungen aus dem Internet und den Start ihrer virtuellen Desktops und Anwendungen muss für einen Pod ein externes Unified Access Gateway konfiguriert sein.
  • Wenn alle Ihre Endbenutzerverbindungen immer von Ihrem internen Netzwerk stammen, ist auf dem Pod kein Unified Access Gateway erforderlich – außer wenn Universal Broker die Zwei-Faktor-Authentifizierung mit diesen internen Endbenutzerverbindungen erzwingen soll.
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:
  • DNS-Adressen, mit denen Unified Access Gateway den Namen des Authentifizierungsservers auflöst
  • Routen, über die Unified Access Gateway das Netzwerkrouting zum Authentifizierungsserver auflöst
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

Hinweis: Wenn Sie einen Pod bereitgestellt haben, bei dem die internen und externen Gateway-Konfigurationen den gleichen FQDN besitzen, 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 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.

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 – mindestens eine der unterstützten Konfigurationen für Microsoft Azure-VMs.
  • Standard_D3_v2, Standard_D4_v3
  • Standard_D2_v2, Standard_D2_v3
  • Standard_NV6

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:
  • Derselbe Dienstprinzipal, der für alle teilnehmenden Pods und Abonnements verwendet wird.
  • Jeder Dienstprinzipal muss über Lesezugriff auf jedes Microsoft Azure-Abonnement verfügen, das von diesen teilnehmenden Pods verwendet wird.

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.
  • Microsoft.Compute/galleries/read
  • Microsoft.Compute/galleries/write
  • Microsoft.Compute/galleries/delete
  • Microsoft.Compute/galleries/images/*
  • Microsoft.Compute/galleries/images/versions/*

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

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.
  • Virtuelle Horizon Edge-Appliance – 1 x Standard_D4_v3

Referenzarchitektur

Verwenden Sie die nachfolgenden Architekturdiagramme als Referenz.

Abbildung 1. Abbildung der Horizon Cloud-Pod-Architektur für einen Pod mit aktivierter und konfigurierter Hochverfügbarkeit mit der Konfiguration eines externen und eines internen Gateways, wobei das externe Gateways in demselben VNet bereitgestellt wird wie der Pod, drei Netzwerkkarten auf den externen Gateway-VMs, zwei Netzwerkkarten auf den internen Gateway-VMs und eine öffentliche IP-Adresse, die für den Lastausgleich des externen Gateways aktiviert ist

Darstellung der Architektur der Ressourcengruppen, VMs und Subnetze für einen Pod, bei dem Hochverfügbarkeit und beide Arten von Unified Access Gateway-Konfigurationen aktiviert sind und bei dem sich das externe Gateway in demselben VNet befindet wie der Pod.

Abbildung 2. Darstellung der Architekturelemente des externen Gateways, wenn das externe Gateway in seinem eigenen VNet bereitgestellt wird, getrennt vom VNet des Pods, mit drei Netzwerkkarten und in einer vom Pod-Bereitsteller erstellten Ressourcengruppe

Darstellung der Architekturelemente des externen Gateways, wenn das externe Gateway in seinem eigenen VNet bereitgestellt wird, getrennt vom VNet des Pods und in einer vom Pod-Bereitstellungsanbieter erstellten Ressourcengruppe

Ressourcen

Weitere Informationen finden Sie in den folgenden Ressourcen.