Der Zweck dieser Checkliste besteht darin, Sie über die erforderlichen Elemente für eine First-Gen-Horizon Cloud on Microsoft Azure-Bereitstellung zu informieren. Wenn Sie diese Checkliste befolgen, können Sie den Pod-Bereitsteller erfolgreich ausführen und die Tag-1-Aufgaben abschließen.

Achtung: Verwenden Sie diese Seite nur, wenn Sie auf eine First-Gen-Mandantenumgebung in der First-Gen-Steuerungsebene zugreifen können. Wie im KB-Artikel 92424 beschrieben, hat die First-Gen-Steuerungsebene das Ende der Verfügbarkeit (End of Availability, EOA) erreicht. Weitere Informationen finden Sie in diesem Artikel.

Ab August 2022 ist Horizon Cloud Service – next-gen allgemein verfügbar und verfügt über eine eigene Dokumentation zur Verwendung von Next-Gen, die hier verfügbar ist.

Ein Hinweis darauf, ob es sich um eine Next-Gen- oder First-Gen-Umgebung handelt, ist das Muster, das im URL-Feld des Browsers angezeigt wird, nachdem Sie sich bei Ihrer Umgebung angemeldet haben und die Bezeichnung Horizon Universal Console sehen. Bei einer Next-Gen-Umgebung enthält die URL-Adresse der Konsole eine Komponente wie /hcsadmin/. Die URL der First-Gen-Konsole enthält einen anderen Abschnitt (/horizonadmin/).

Checklisten-Zielgruppe

Diese Checkliste gilt in erster Linie für Horizon Cloud-Kundenkonten, für die vor der Dienstaktualisierung am 2. November 2023 noch nie eine Horizon Cloud on Microsoft Azure-Bereitstellung in der Mandantenumgebung stattgefunden hat. Solche Mandanten werden oft als saubere (clean-slate) Umgebungen oder Umgebungen auf der grünen Wiese (greenfield) bezeichnet.

Der hier beschriebene Satz gilt in erster Linie für Produktionsbereitstellungen. Test- und die meisten Proof-of-Concept-Bereitstellungen können in der Regel mit einer Teilmenge durchgeführt werden, wie in einer vereinfachten Proof-of-Concept-Bereitstellung dargestellt.

Einige der unten aufgeführten Abschnitte müssen vor der Ausführung des Assistenten für die Bereitstellung eines neuen Pods eingerichtet werden.

Einige Elemente können verschoben werden, bis die Bereitstellung abgeschlossen ist und ausgeführt wird.

Einige Elemente sind als optional aufgeführt, da sie sich auf die Optionen beziehen, die Sie für Ihre Horizon Cloud on Microsoft Azure-Bereitstellung treffen.

Beispielsweise können Sie den Assistenten für neue Pods ausführen, ohne eine Unified Access Gateway-Konfiguration auszuwählen, und die Gateway-Konfiguration später hinzufügen. In diesem Fall brauchen Sie die Unified Access Gateway-Anforderungen erst zu einem späteren Zeitpunkt erfüllen.

Erfüllen Sie diese, bevor Sie den Assistenten für neue Pods ausführen. Kann nach der Bereitstellung des Pods erledigt werden
  • Mandantenkonto der Steuerungsebene
  • Microsoft Azure-Abonnementelemente
  • Netzwerk
  • Ports und Protokolle
  • Optionale Unified Access Gateway-Elemente
  • Active Directory
  • Optionales Unified Access Gateway (nach der Bereitstellung hinzugefügt)
  • Universal Broker
  • DNS-Datensätze
  • Golden Images, Desktop, Farmkapazitäten
  • Microsoft Windows-Betriebssystemlizenzen

Einige wichtige Überlegungen

Wenn Sie eine Test- oder Proof-of-Concept-Bereitstellung von Horizon Cloud on Microsoft Azure durchführen, sind Sie möglicherweise der Besitzer des Microsoft Azure-Abonnements, das Sie für die Bereitstellung verwenden werden – oder Sie führen das Proof-of-Concept im Auftrag einer Organisation durch, der das Abonnement gehört.

Der Besitzer des Abonnements muss sicherstellen, dass keine der Microsoft Azure-Richtlinien, die im Abonnement des Pods in Kraft sind, die Erstellung der Pod-Komponenten blockieren, verweigern oder einschränken.

Der Grund dafür ist, dass der Pod-Bereitsteller während des Pod-Bereitstellungsvorgangs API-Aufrufe verwendet, um Ressourcen innerhalb des Abonnements zu erstellen, das im Assistenten für neue Pods angegeben ist. Wenn in diesem Abonnement Microsoft Azure-Richtlinien in Kraft sind, die die Erstellung der Pod-Komponenten blockieren, verweigern oder einschränken würden, ist die Bereitstellung nicht erfolgreich und erfordert eine Support-Anfrage an den VMware-Support.

Ein Beispiel: Der Pod-Bereitsteller verlangt, dass keine der Microsoft Azure-Richtlinien, die im Abonnement des Pods in Kraft sind, die Erstellung von Komponenten auf dem Azure-Speicherkonto blockieren, verweigern oder einschränken.

Bevor Sie den Assistenten für neue Pods ausführen, vergewissern Sie sich beim Besitzer des Abonnements, dass die Definitionen der integrierten Microsoft Azure-Richtlinien die Erstellung der Pod-Komponenten nicht blockieren, verweigern oder einschränken.

Anforderungen an die Horizon Cloud-Steuerungsebene

VMware Customer Connect-Konto, das von VMware für die Anmeldung bei der Horizon Cloud-Steuerungsebene konfiguriert wurde.

Eine Übersicht über die Beziehung dieses Kontos zu Ihrem Horizon Cloud-Mandantenkonto finden Sie auf der Seite Horizon Service-Bereitstellungen und Onboarding von Pods.

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, müssen Sie ein zusätzliches gültiges Microsoft Azure-Abonnement in derselben Microsoft Azure-Umgebung erwerben.
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-Administrationsrechte in diesem Microsoft Azure-Abonnement, damit Sie das Microsoft Azure-Portal verwenden und die Schritte zur Vorbereitung der Pod-Bereitstellung durchführen können.
Horizon Cloud-App-Registrierung und geheimer Clientschlüssel, der im Abonnement des Pods erstellt wurde. Siehe First-Gen-Mandanten – Erstellen einer Horizon Cloud-App-Registrierung im Abonnement des Pods.

Wenn Sie oder Ihre Organisation die Funktion zur Bereitstellung der externen Gateway-Konfiguration in einem vom Pod-Abonnement getrennten Abonnement verwenden, benötigt dieses Gateway-Abonnement ebenfalls eine Horizon Cloud-App-Registrierung und einen geheimen Clientschlüssel.

Durch das Erstellen der Horizon Cloud-App-Registrierung in einem Abonnement wird automatisch ein Dienstprinzipal gemäß dem standardmäßigen Microsoft Azure-Verhalten erstellt.

Weisen Sie diesem Dienstprinzipal eine Rolle zu, die es Horizon Cloud ermöglicht, API-Aufrufe im Abonnement des Pods durchzuführen.

Normalerweise wird die Rolle Contributor auf der Abonnementebene des Pods zugewiesen.

Alternativ kann die Rolle eine benutzerdefinierte Rolle sein, die auf der Abonnementebene des Pods zugewiesen wird.

Wenn Sie die Konfiguration des externen Gateways in einer vorhandenen Ressourcengruppe in einem separaten Abonnement bereitstellen, können Sie entweder eine benutzerdefinierte Rolle oder die Rolle Contributor für den Dienstprinzipal dieses Gateway-Abonnements zuweisen.

Wenn Sie oder Ihre Organisation für die Horizon Cloud-App-Registrierung eine benutzerdefinierte Rolle verwenden möchten, lesen Sie die folgende Seite, auf der die Aktionen beschrieben werden, die diese benutzerdefinierte Rolle aufweisen muss – Wenn Ihre Organisation die Verwendung einer benutzerdefinierten Rolle bevorzugt.

Hinweis: Die Rolle muss dem Dienstprinzipal der Horizon Cloud-App-Registrierung direkt zugewiesen werden. Die Verwendung einer gruppenbasierten Zuweisung einer Rolle zu diesem Dienstprinzipal wird nicht unterstützt.
Erforderliche Ressourcenanbieter sind in jedem Microsoft Azure-Abonnement registriert. Weitere Informationen finden Sie unter Registrieren von Ressourcenanbietern.
Abonnement-ID, Verzeichnis-ID, Anwendungs-ID und Schlüssel für das Abonnement, das Sie im Bereitstellungsassistenten angeben.
Das Abonnement muss die Verwendung des Azure StorageV2-Kontotyps zulassen. Stellen Sie sicher, dass die Microsoft Azure-Richtlinien des Abonnements die Erstellung von Inhalten, die den Kontotyp Azure StorageV2 erfordern, nicht einschränken oder ablehnen.
Das Abonnement muss die Erstellung von Ressourcengruppen ohne Tags zulassen, es sei denn, Sie geben benutzerdefinierte Ressourcen-Tags im Pod-Bereitstellungsassistenten an. Bei der Pod-Bereitstellung werden Ressourcengruppen im Abonnement des Pods ohne Tags erstellt, es sei denn, Sie geben benutzerdefinierte Ressourcen-Tags im Assistenten an.

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. Wenn Sie im Assistenten 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. Die Namen der vom Bereitsteller erstellten Ressourcengruppen finden Sie unter Ressourcengruppen, die vom Pod-Bereitsteller erstellt werden.

Optional. Wenn Ihre Organisation vorschreibt, dass Sie eine bestimmte, vorab erstellte und von der Organisation benannte Ressourcengruppe für das externe Unified Access Gateway in einem vom Pod-Abonnement getrennten VNet und Abonnement verwenden müssen, würden Sie die Funktion verwenden, um das externe Unified Access Gateway in Ihrer eigenen benannten Ressourcengruppe bereitzustellen. Wenn Sie diese Funktion nicht verwenden, erstellt der Pod-Bereitsteller automatisch eine Ressourcengruppe mit seiner eigenen Namenskonvention.

Um diese Funktion zu verwenden, müssen Sie diese Ressourcengruppe in dem Abonnement erstellen, bevor Sie den Pod-Bereitsteller ausführen. Sie müssen außerdem 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 für die benutzerdefinierte Rolle finden Sie unter Wenn Ihre Organisation die Verwendung einer benutzerdefinierten Rolle bevorzugt.

Anforderungen an Microsoft Azure-Kapazität

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.

Für Kapazitäten, die VM-Familien betreffen, verwendet das Microsoft Azure-Portal auch den Begriff Kontingent.

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
  • Pod-Manager – 2 x Standard_D4_v3 (ohne Standard_D4_v3 in der Region: 2 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.
  • In einem besonderen Fall, in dem Sie eine Support-Anfrage stellen und der VMware Support feststellt, dass diese Anfrage nur durch die vorübergehende Bereitstellung einer supportbezogenen Jumpbox-VM bearbeitet werden kann, muss Ihre Kapazität die Bereitstellung einer Standard_F2-Modell-VM zu diesem Zeitpunkt zulassen.
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
  • 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.

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 First-Gen-Horizon Cloud – 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.
Tipp: Nach der Bereitstellung des Pods können Sie den Pod bearbeiten, um Mandantensubnetze zur 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 und Anforderungen für Ports und Protokolle.
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, wenn Sie ein Netzwerk zwischen dem VNet und Ihrem lokalen Unternehmensnetzwerk herstellen möchten.

Port- und Protokollanforderungen

Für das Onboarding von Pods und den laufenden Betrieb Ihrer Horizon Cloud-Umgebung sind bestimmte Ports und Protokolle erforderlich. Weitere Informationen finden Sie unter Ports und Protokolle.

Unified Access Gateway-Anforderungen

Sie können den Assistenten für neue Pods ausführen, ohne eine Unified Access Gateway-Konfiguration auszuwählen, und die Gateway-Konfiguration später hinzufügen. In diesem Fall brauchen Sie die Unified Access Gateway-Anforderungen erst zu einem späteren Zeitpunkt erfüllen. 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.

Wenn Sie die Unified Access Gateway-Optionen im Assistenten für neue Pods auswählen, verlangt der Assistent die folgenden Elemente.

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 der Unified Access Gateway für die Zwei-Faktor-Authentifizierung mit einem der Authentifizierungssystemtypen konfiguriert werden, die für die Verwendung mit Horizon Cloud on Microsoft Azure-Bereitstellungen unterstützt werden.

Die Konfiguration sollte Folgendes umfassen:

  • 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: Nachdem der Pod bereitgestellt wurde und Sie die Zwei-Faktor-Authentifizierung in den Universal Broker-Einstellungen konfiguriert haben, sind einige zusätzliche Konfigurationsschritte erforderlich, wenn Sie möchten, dass auch Ihre internen Endbenutzer die Zwei-Faktor-Authentifizierung überspringen. 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 First-Gen-Mandanten – Horizon Cloud on Microsoft Azure-Bereitstellungen – Allgemeine Reihenfolge 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, die auf die Computer-OE oder auf die OE angewendet werden, die Sie in die Benutzeroberfläche für den Domänenbeitritt der Konsole eingeben.

  • Alle Eigenschaften lesen – nur dieses Objekt
  • Computerobjekte erstellen – dieses Objekt und alle abgeleiteten Objekte
  • Computerobjekte löschen – dieses Objekt und alle abgeleiteten Objekte
  • Alle Eigenschaften schreiben – Abgeleitete Computerobjekte
  • Kennwort zurücksetzen – abgeleitete Computerobjekte

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, die auf die Computer-OE oder auf die OE angewendet werden, die Sie in die Benutzeroberfläche für den Domänenbeitritt der Konsole eingeben.

  • Alle Eigenschaften lesen – nur dieses Objekt
  • Computerobjekte erstellen – dieses Objekt und alle abgeleiteten Objekte
  • Computerobjekte löschen – dieses Objekt und alle abgeleiteten Objekte
  • Alle Eigenschaften schreiben – Abgeleitete Computerobjekte
  • Kennwort zurücksetzen – abgeleitete Computerobjekte

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.

Horizon Cloud unterstützt die Verwendung von Active Directory-Sicherheitsgruppen sowohl für Administratoranmeldungen als auch für Endbenutzerberechtigungen. Verschachtelte Gruppen werden unterstützt. Die Gruppenmitgliedschaft wird durch die Abfrage des berechneten Attributs tokenGroups bewertet, d. h. Horizon Cloud hat keine Einschränkungen hinsichtlich der Verschachtelungstiefe, sondern unterstützt die in Ihrem Active Directory festgelegten Einstellungen.

Auf die Frage, ob es zusätzliche Überlegungen oder Einschränkungen im Zusammenhang mit Active Directory-Gruppen und der Kombination von Horizon Cloud plus Universal Broker plus Workspace ONE Access Cloud gibt, lautet die Antwort: Nein, keine.

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.

Wenn Sie eine für LDAPS konfigurierte Active Directory verwenden möchten, müssen Sie die Aktivierung der von LDAPS unterstützten Funktionen mit Ihrem Horizon Cloud-Mandanten anfordern. Weitere Informationen finden Sie unter Verwenden von für LDAPS konfigurierten Active Directory-Umgebungen.

Universal Broker-Konfiguration

Stellen Sie bei der Konfiguration des Universal Brokers sicher, dass Sie die Punkte aus der folgenden Tabelle erfüllen, die auf die von Ihnen gewünschten Optionen zutreffen. 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 First-Gen-Mandanten – Horizon Cloud on Microsoft Azure-Bereitstellungen – Anforderungen an die Auflösung von Hostnamen, DNS-Namen und First-Gen-Mandanten – Horizon Cloud-Pod – Anforderungen an Ports und Protokolle.
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, die für die Zwei-Faktor-Authentifizierung mit einem der Authentifizierungssystemtypen konfiguriert ist, die für die Verwendung mit Horizon Cloud on Microsoft Azure-Bereitstellungen unterstützt werden.

Universal Broker übergibt die Authentifizierungsanforderung an das Unified Access Gateway, das mit dem Authentifizierungsserver kommuniziert, und leitet die Antwort dann 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 den Universal Broker des Mandanten 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.

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.

Beachten Sie auch die folgende Supportmatrix für die Verwendung der Microsoft Azure VM-Modelle Generation 1 VM, Generation 2 VM, in Bezug auf die Gastbetriebssysteme Windows 10 und Windows 11.

Azure-VM-Modell Windows 10 Windows 11
Generation 1 VM Unterstützt Nicht unterstützt
Generation 2 VM Nicht unterstützt Unterstützt
Basis für das Golden Image – mindestens eine der unterstützten Konfigurationen für Microsoft Azure-VMs.
  • Standard_DS2_v2
  • Standard_NV12s_v3 (für den automatisierten Assistenten zum Importieren von VMs vom Marketplace oder für den manuellen Import und den NVIDIA GRID-Grafiktreiber), Standard_NV8as_v4 (für die manuelle Importmethode und den AMD-Grafiktreiber)
  • Standard_D4s_v3

Wenn Sie den Assistenten zum automatisierten Importieren von VMs der Konsole 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 seinen internen Einstellungen und dem jeweiligen Betriebssystem (OS).

Das System verwendet die angegebenen Modelle sowohl für Einzel- als auch für Multi-Pod-Images.

Der Assistent zum Importieren von VMs aus dem Marketplace erstellt:
  • Non-GPU, non-Windows 11, a Standard_DS2_v2 VM
  • Non-GPU using Windows 11, a Standard_D4s_v3 VM
  • GPU-fähig, ein Standard_NV12s_v3 VM-Modell
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 der Konfigurationen, 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 der Konfigurationen, 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 oder Windows 11 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 Enterprise für Mehrfachsitzungen in der Microsoft Azure Virtual Desktop-Dokumentation ist Microsoft Windows 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 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 stehen die Horizon Image-Verwaltungsdienst-Funktionen für diese Pods zur Verfügung, wenn auf allen Ihren Horizon Cloud-Pods Manifest 2632 oder höher ausgeführt wird und Universal Broker für Ihren Mandanten aktiviert 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 an das Pod-Abonnement, die Horizon Cloud-App-Registrierung dieses Abonnements und seinen 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 Horizon Cloud-App-Registrierung, der von den Pods verwendet wird, die an Multi-Pod-Images beteiligt sind, 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.

Alle benutzerdefinierten Rollen, die von den Dienstprinzipalen der teilnehmenden Pods verwendet werden, müssen die folgenden Berechtigungen in Bezug auf die Verwendung der Azure-freigegebene 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 Azure Virtual Desktop für Windows 11 Enterprise für Mehrfachsitzungen, Windows 10 Enterprise für Mehrfachsitzungen und Windows 7 Enterprise finden Sie in der Microsoft Azure-Dokumentation unter dem Thema Preisgestaltung für Azure Virtual Desktop.
Lizenzierung für einen oder mehrere der folgenden Typen: Microsoft Windows 7 Enterprise, Microsoft Windows 10, Microsoft Windows 11 (Einzelsitzung, VDI-Client-Typen)
Lizenzierung für Microsoft Windows 10 Enterprise für Mehrfachsitzungen oder Microsoft Windows 11 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.

Abbildung 1. Abbildung der Horizon-Cloud-Pod-Architektur, bei der der Pod sowohl über externe als auch über interne Gateway-Konfigurationen verfügt, 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 Lastausgleichsdienst des externen Gateways aktiviert ist

Darstellung der Architektur der Ressourcengruppen, VMs und Subnetze für einen Pod, bei dem 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