Führen Sie die folgenden Aufgaben aus, um die Komponenten Ihres Horizon-Pods für das Onboarding des Pods in die Horizon Cloud-Steuerungsebene vorzubereiten. Vergewissern Sie sich, dass die in den folgenden Abschnitten beschriebenen Anforderungen erfüllt sind, um ein erfolgreiches Onboarding durchzuführen.

Diese Checkliste gilt in erster Linie für saubere und neue Horizon Cloud-Kundenkonten, über die vor der Dienstversion vom September 2021 noch nie ein Pod in der Mandantenumgebung bereitgestellt wurde.

Einige der in den folgenden Abschnitten aufgeführten Anforderungen sind für das erfolgreiche Onboarding eines Horizon-Pods für die Verwendung einer Abonnementlizenz mit dem Pod erforderlich. Einige Anforderungen sind für die wichtigsten Aufgaben erforderlich, die nach diesem anfänglichen Onboarding durchgeführt werden, um die Verwendung von Horizon Cloud Steuerungsebenen-Diensten mit dem Pod zu ermöglichen.

Anforderungen an die Horizon Cloud-Steuerungsebene

Aktives My VMware-Konto für die Anmeldung bei der Horizon Cloud-Steuerungsebene.
Gültige Horizon-Universallizenz. Weitere Informationen zu dieser Lizenz finden Sie auf der Seite „Horizon-Universallizenz“.

Horizon-Pod- und Horizon Cloud Connector-Anforderungen

Horizon-Pod mit Version 7.10 oder höher. Um die Nutzung der neuesten Cloud-Dienste und -Funktionen mit dem mit der Cloud verbundenen Pod zu erhalten, muss die aktuell verfügbare Version der Horizon-Pod-Software ausgeführt werden.
Virtuelle Horizon Cloud Connector-Appliance, mindestens Version 1.9 oder höher. Um die Nutzung der neuesten Cloud-Dienste und -Funktionen mit dem cloudverbundenen Pod zu erhalten, muss die aktuelle Version, Horizon Cloud Connector Version 2.0, ausgeführt werden.
  • Statische IP
  • Vorwärts- und Rückwärts-Lookup-Datensätze des DNS
Ressourcenanforderungen für die virtuelle Horizon Cloud Connector-Appliance. Die Ressourcenanforderungen richten sich nach der bereitgestellten Horizon-Pod-Architektur: All-in-SDDC oder Verbundarchitektur. Die nachfolgenden Listen geben an, welche Versionen derzeit für neue Bereitstellungen für jedes Design unterstützt werden.
All-in-SDDC-Architektur
In der All-in-SDDC-Architektur wird das OVA-Format der Appliance innerhalb eines VMware SDDC bereitgestellt.
Version 1.9:
  • Dienste des Profils „Vollständige Funktion“ aktiv: 8 vCPUs, 8 GB Arbeitsspeicher (RAM), 40 GB Datenspeicher
  • Dienste des Profils „Standardfunktion“ aktiv: 4 vCPUs, 6 GB Arbeitsspeicher (RAM), 40 GB Datenspeicher
Version 1.10
8 vCPUs, 8 GB Arbeitsspeicher (RAM), 40 GB Datenspeicher
Version 2.0
  • Primärer Knoten: 8 vCPUs, 8 GB Arbeitsspeicher (RAM), 40 GB Datenspeicher
  • Jeder zusätzliche Worker-Knoten: 8 vCPUs, 8 GB Arbeitsspeicher (RAM), 40 GB Datenspeicher
Verbundarchitektur
In der Verbundarchitektur wird ein cloudnatives Format der Appliance innerhalb der jeweiligen cloudnativen Infrastruktur bereitgestellt. Bei diesen Listen handelt es sich um die aktuell unterstützten cloudnativen Formate und verfügbare Dateidownloads.
Version 1.9
Azure Cloud – 8 vCPUs, 32 GB Arbeitsspeicher (RAM), 40 GB Datenspeicher
Version 1.10
  • Azure Cloud – 8 vCPUs, 32 GB Arbeitsspeicher (RAM), 40 GB Datenspeicher
  • Google Cloud – 8 vCPUs, 32 GB Arbeitsspeicher (RAM), 40 GB Datenspeicher
Active Directory-Benutzer, der im Pod-Onboarding-Prozess bei der Kopplung des Horizon Cloud Connector mit dem Connection Server des Pods angegeben wird. Dieser Active Directory-Benutzer muss über die vordefinierte Rolle Administratoren für die root-Zugriffsgruppe verfügen, wie in der Horizon Console des Pods unter Ansicht für globale Administratoren > Rollenberechtigungen > Administratoren angezeigt. Anders ausgedrückt: Der für den Pod-Onboarding-Prozess angegebene Active Directory-Benutzer ist Superbenutzer für diesen Pod, wie in der Horizon -Dokumentation im Handbuch Verwaltung von Horizon oder Verwaltung von Horizon Console beschrieben. Diese Dokumentation ist für die Softwareversion Ihres Pods verfügbar.

Active Directory-Anforderungen

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-Mandanten müssen zum Zeitpunkt der Bereitstellung dieser Pods auf der Cloud-Steuerungsebene für denselben Satz von Active Directory-Domänen sichtbar sein. Diese sichtbare Anforderung gilt nicht nur für zusätzliche Horizon-Pods, die Sie nach dem ersten Pod in Ihre Pod-Flotte einbinden, sondern auch für Horizon Cloud-Pods, die über denselben Cloud-Mandanten in Microsoft Azure bereitgestellt werden.

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)
  • 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, die in diesem Dokumentationsthema zum lokalen angegeben 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.

Sie sollten auch das Kennwort für das Konto auf Läuft nie ab festlegen, um den Dauerzugriff auf die Anmeldung bei Ihrer Horizon Cloud-Umgebung zu gewährleisten.

Weitere Informationen und Anforderungen finden Sie unter Dienstkonten, die Horizon Cloud für seine Vorgänge benötigt.

Zusätzliches Domänendienstkonto – kann nicht dasselbe Konto verwenden wie oben.

  • 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)
  • 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, die in diesem Dokumentationsthema zum lokalen angegeben 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.

Sie sollten auch das Kennwort für das Konto auf Läuft nie ab festlegen, um den Dauerzugriff auf die Anmeldung bei Ihrer Horizon Cloud-Umgebung zu gewährleisten.

Weitere Informationen und Anforderungen finden Sie unter Dienstkonten, die Horizon Cloud für seine Vorgänge benötigt.

Domänenbeitrittskonto
  • Active Directory-Domänenbeitrittskonto, das vom System zum Ausführen von Sysprep-Vorgängen und zum Hinzufügen von Computern zur Domäne verwendet werden kann, in der Regel ein neues Konto (Benutzerkonto für Domänenbeitritt)
  • Kontokennwort auf Unbegrenzt gültig festlegen
  • Für dieses Konto sind die folgenden Active Directory-Berechtigungen erforderlich: Inhalt auflisten, Alle Eigenschaften lesen, Berechtigungen lesen, Kennwort zurücksetzen, Computerobjekte erstellen, Computerobjekte löschen.
  • Dieses Konto benötigt außerdem die Active Directory-Berechtigung „Alle Eigenschaften schreiben“ für die nachfolgenden Objekte der Zielorganisationseinheit (OE), die Sie für Farmen und VDI-Desktop-Zuweisungen verwenden möchten, die Sie mit der Horizon Universal Console erstellen.
  • Weitere Informationen und Anforderungen finden Sie unter Dienstkonten, die Horizon Cloud für seine Vorgänge benötigt.
Hinweis:
  • Die Verwendung von Leerzeichen im Benutzernamen des Domänenbeitrittskontos wird nicht unterstützt. Wenn der Benutzername des Domänenbeitrittskontos ein Leerzeichen enthält, kommt es zu unerwarteten Ergebnissen in den Systemvorgängen, die auf dieses Konto angewiesen sind.
  • 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.
  • Vor Manifest 1600.0 benötigte dieses Konto die Berechtigungen der Systemrolle Superadministrator. Wenn Ihre Mandantenumgebung über Horizon Cloud-Pods in Microsoft Azure verfügt, auf denen Manifeste vor Manifest 1600.0 ausgeführt werden, muss sich das Domänenbeitrittskonto in der beschriebenen Horizon Cloud-Administratorgruppe befinden. Das System verwendet dieses Domänenbeitrittskonto mit allen Horizon Cloud-Pods Ihres Mandanten in Microsoft Azure. Wenn Ihr Mandant über Pods mit Manifesten vor 1600.0 verfügt, muss das Domänenbeitrittskonto diese Anforderung erfüllen. Weitere Informationen finden Sie unter Dienstkonten, die Horizon Cloud für seine Vorgänge benötigt.
Zusätzliches Domänenbeitrittskonto (optional, kann nicht dasselbe Konto verwenden wie oben)
  • Active Directory-Domänenbeitrittskonto, das vom System zum Ausführen von Sysprep-Vorgängen und zum Hinzufügen von Computern zur Domäne verwendet werden kann, in der Regel ein neues Konto (Benutzerkonto für Domänenbeitritt)
  • Kontokennwort auf Unbegrenzt gültig festlegen
  • Für dieses Konto sind die folgenden Active Directory-Berechtigungen erforderlich: Inhalt auflisten, Alle Eigenschaften lesen, Berechtigungen lesen, Kennwort zurücksetzen, Computerobjekte erstellen, Computerobjekte löschen.
  • Dieses Konto benötigt außerdem die Active Directory-Berechtigung „Alle Eigenschaften schreiben“ für die nachfolgenden Objekte der Zielorganisationseinheit (OE), die Sie für Farmen und VDI-Desktop-Zuweisungen verwenden möchten, die Sie mit der Horizon Universal Console erstellen.
  • Weitere Informationen und Anforderungen finden Sie unter Dienstkonten, die Horizon Cloud für seine Vorgänge benötigt.
Hinweis:
  • Die Verwendung von Leerzeichen im Benutzernamen des Domänenbeitrittskontos wird nicht unterstützt. Wenn der Benutzername des Domänenbeitrittskontos ein Leerzeichen enthält, kommt es zu unerwarteten Ergebnissen in den Systemvorgängen, die auf dieses Konto angewiesen sind.
  • 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.
  • Vor Manifest 1600.0 benötigte dieses Konto die Berechtigungen der Systemrolle Superadministrator. Wenn Ihre Mandantenumgebung über Horizon Cloud-Pods in Microsoft Azure verfügt, auf denen Manifeste vor Manifest 1600.0 ausgeführt werden, muss sich das Domänenbeitrittskonto in der beschriebenen Horizon Cloud-Administratorgruppe befinden. Das System verwendet dieses Domänenbeitrittskonto mit allen Horizon Cloud-Pods Ihres Mandanten in Microsoft Azure. Wenn Ihr Mandant über Pods mit Manifesten vor 1600.0 verfügt, muss das Domänenbeitrittskonto diese Anforderung erfüllen. Weitere Informationen finden Sie unter Dienstkonten, die Horizon Cloud für seine Vorgänge benötigt.
Active Directory-Gruppen
  • Horizon Cloud-Administratoren – Active Directory-Sicherheitsgruppe für Horizon Cloud-Administratoren. Enthält die Horizon Cloud-Administratorbenutzer und das Domänenbeitrittskonto. 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.
Hinweis: 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.

DNS, Ports und Protokollanforderungen

Bestimmte Ports und Protokolle sind sowohl für das Onboarding eines Horizon-Pods in Horizon Cloud als auch für den laufenden Betrieb des Pods, den mit diesem Pod gekoppelten Horizon Cloud Connector und Horizon Cloud Connector mit der Horizon Cloud-Steuerungsebene erforderlich. Siehe DNS-, Port- und Protokollanforderungen bei Verwendung von Horizon Cloud Connector und einem Horizon-Pod.

Universal Broker

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.

Ausgehende Kommunikationen von dem gekoppelten Horizon Cloud Connector des Pods müssen bestimmte DNS-Namen mithilfe bestimmter Ports und Protokolle auflösen und erreichen. Dies ist für die Universal Broker-Konfiguration und den laufenden Betrieb erforderlich. Weitere Informationen finden Sie unter Horizon-Pods – Port- und Protokollanforderungen für Universal Broker.
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: 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.
Optional. Wenn Universal Broker die Zwei-Faktor-Authentifizierung erzwingen soll, muss für Pods ein externer Unified Access Gateway für die Zwei-Faktor-Authentifizierung bei einem Authentifizierungsserver konfiguriert sein. 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

Lizenzierung für die Microsoft Windows-Betriebssysteme

Horizon Cloud stellt keine Lizenz für das Gastbetriebssystem bereit, die für die Verwendung von Microsoft Windows-Betriebssystemen erforderlich ist, die Sie im Zuge der Verwendung der Horizon Cloud-Workflows nutzen. Sie, der Kunde, sind dafür verantwortlich, über gültige und geeignete Microsoft-Lizenzen zu verfügen, die Sie zu Folgendem berechtigen: Erstellen von, Ausführen von Workflows für und Betreiben von Windows-basierten Desktop-VMs und RDSH-VMs, die Sie für Ihre Horizon Cloud-Mandantenumgebung auswählen. Die erforderliche Lizenzierung hängt von der beabsichtigten Verwendung ab.

Lizenzierung für einen oder mehrere der folgenden Typen: Microsoft Windows 7 Enterprise, Microsoft Windows 10
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