Diese Checkliste führt Sie durch die Vorbereitung Ihrer Microsoft Azure-Abonnements und -Netzwerke für die Bereitstellung eines Pod über Horizon Cloud in Microsoft Azure. Indem Sie sicherstellen, dass diese Anforderungen wie im folgenden beschrieben erfüllt sind, sorgen Sie sowohl für eine erfolgreiche neue Pod-Bereitstellung als auch für einen erfolgreichen Abschluss der wichtigen Aufgaben, die nach der Bereitstellung eines Pods durchgeführt werden müssen.

Dieses Dokumentationsthema ist in folgende Abschnitte unterteilt:

Diese Checkliste gilt in erster Linie für Horizon Cloud-Kundenkonten, über die vor der Dienstversion vom Oktober 2020 noch nie ein Pod bereitgestellt wurde oder die noch nie cloudverbunden in der Mandantenumgebung bereitgestellt wurden. Solche Umgebungen können als saubere oder neue Umgebungen bezeichnet werden. Neue Pod-Bereitstellungen, die nach der Übertragung der Binärdateien der Cloud-Ebene und den neuen Pod-Manifestversionen auf die Cloud-Ebene der vierteljährlichen Dienstversion vom Oktober 2020 stattfinden, werden mit der neuen Pod-Manifestversion bereitgestellt. Die Anforderungen für eine erfolgreiche Pod-Bereitstellung werden in erster Linie durch die Manifestversion des Pods bestimmt. Auch Binärdateien der Cloud-Ebene, die sich in der Produktions-Cloud-Ebene befinden, bestimmen möglicherweise die Anforderungen für eine erfolgreiche Bereitstellung.

Einige der nachstehend aufgeführten Anforderungen sind für die Pod-Bereitstellung als solche erforderlich. Andere Anforderungen werden für die wichtigsten Aufgaben benötigt, die nach der Pod-Bereitstellung durchgeführt werden, um eine produktive Mandantenumgebung zu erhalten, die von Pods zur Verfügung gestellte Desktops und Anwendungen für Ihre Endbenutzer bereitstellen kann.

Anforderungen für die Pod-Bereitstellung als solche
Anforderungen für eine produktive Umgebung nach der Pod-Bereitstellung
Wichtig: Bevor Sie den Pod-Bereitstellungsassistenten starten und Ihren Pod bereitstellen, müssen Sie zusätzlich zu den unten aufgeführten Anforderungen die folgenden wichtigen Punkte beachten:
  • Ab der Dienstversion vom Juli 2020 müssen in ganz neuen Umgebungen neue Pods mit mindestens einer Gateway-Konfiguration bereitgestellt werden. Wenn Ihr Kundenkonto vor der Version vom Juli 2020 erstellt wurde, Sie Ihren ersten Pod jedoch noch nicht bereitgestellt haben, ist für die Bereitstellung des ersten Pods die Konfiguration von mindestens einem Gateway erforderlich (zum Zeitpunkt der Bereitstellung des Pods).
  • Für eine erfolgreiche Pod-Bereitstellung darf keine der Microsoft Azure-Richtlinien, die Sie oder Ihr IT-Team in Ihrer Microsoft Azure-Umgebung festgelegt haben, die Erstellung der Pod-Komponenten blockieren, ablehnen oder beschränken. Außerdem müssen Sie sicherstellen, dass die integrierten Richtliniendefinitionen Ihrer Microsoft Azure-Richtlinien die Erstellung der Pod-Komponenten nicht blockieren, ablehnen oder einschränken. Als Beispiel müssen Sie und Ihr IT-Team sicherstellen, dass keine Ihrer Microsoft Azure-Richtlinien die Erstellung von Komponenten auf einem Azure-Speicherkonto blockiert, verweigert oder einschränkt. Informationen zu Azure-Richtlinien finden Sie in der Dokumentation zu Azure-Richtlinien.
  • Der Pod-Bereitsteller erfordert, dass Ihr Azure-Speicherkonto dem Bereitsteller die Verwendung der Azure-Kontotypen StorageV1 und StorageV2 erlaubt. Stellen Sie sicher, dass Ihre Microsoft Azure-Richtlinien die Erstellung von Inhalten, die die Azure-Kontotypen StorageV1 und StorageV2 erfordern, nicht einschränken oder ablehnen.
  • Sofern Sie im Bereitstellungsassistenten keine benutzerdefinierten Ressourcen-Tags angeben, erstellt Horizon Cloud im Rahmen der Pod- und Gateway-Bereitstellungsprozesse Ressourcengruppen (RGs) in Ihrem Microsoft Azure-Abonnement, für die keine Tags vorhanden sind. Dies beinhaltet die anfängliche Ressourcengruppe, die für die temporäre Jump Box erstellt wird, mit deren Hilfe diese Bereitstellungsvorgänge orchestriert werden. Seit der Aktualisierung der Cloud-Ebene vom 8. Oktober 2020 verfügt der Bereitstellungsassistent über eine Funktion, in der Sie benutzerdefinierte Ressourcen-Tags angeben können, die Sie auf die vom Bereitsteller erstellten Ressourcengruppen anwenden möchten. Wenn Sie keine benutzerdefinierten Ressourcen-Tags angeben und Ihr Microsoft Azure-Abonnement bestimmte Ressourcen-Tag-Anforderungen aufweist, schlägt die Pod-Bereitstellung fehl, wenn Sie versuchen, einen Pod in diesem Abonnement bereitzustellen. Die Pod-Bereitstellung kann bei Pod-Aktualisierungen oder beim Hinzufügen einer Gateway-Konfiguration zu einem Pod fehlschlagen. Wenn Sie nicht planen, die Funktion für benutzerdefinierte Ressourcen-Tags des Bereitstellungsassistenten zu verwenden, müssen Sie sicherstellen, dass Ihre Microsoft Azure-Richtlinien das Erstellen der nicht markierten Ressourcengruppen des Pods im Zielabonnement ermöglichen. Eine Liste der vom Bereitsteller erstellten RGs finden Sie im Administratorhandbuch unter dem Thema Für einen in Microsoft Azure bereitgestellten Pod erstellte Ressourcengruppen.
  • Alle mit der Cloud verbundenen Pods müssen zum Zeitpunkt der Bereitstellung dieser Pods für denselben Satz von Active Directory-Domänen sichtbar sein.

Anforderungen an die Horizon Cloud-Steuerungsebene

Aktives My VMware-Konto für die Anmeldung bei der Horizon Cloud-Steuerungsebene.

Anforderungen für Microsoft Azure-Abonnements

Gültiges Microsoft Azure-Abonnement in einer unterstützten Microsoft Azure-Umgebung (Azure Commercial, Azure China und Azure Government). Wenn Sie das externe Unified Access Gateway in einem eigenen VNet mit einem eigenen Abonnement bereitstellen, benötigen Sie ein zusätzliches gültiges Microsoft Azure-Abonnement in derselben Microsoft Azure-Umgebung.
Hinweis: Horizon Cloud unterstützt die Mehrheit der Microsoft Azure-Regionen. Eine Auflistung der derzeit nicht unterstützten Microsoft Azure-Regionen finden Sie im VMware Knowledgebase-Artikel „Microsoft Azure-Regionen mit Horizon Cloud Service für Microsoft Azure (77121)“.
Gültige Microsoft Azure-Administratorrechte in diesem Microsoft Azure-Abonnement. Weitere Informationen finden Sie in der Microsoft-Dokumentation unter dem Thema Erste Schritte mit rollenbasierter Zugriffssteuerung im Azure-Portal.
Verfügbare Microsoft Azure-Mindestkapazität für Horizon Cloud-Infrastruktur zusätzlich zur erwarteten Desktop- und App-Arbeitslast. Solange diese Kapazität zur Verfügung gestellt wird, stellt Horizon Cloud diese VMs automatisch bereit. Eine manuelle Installation ist damit nicht erforderlich.
  • 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
  • Externes Unified Access Gateway (optional, sofern kein internes Gateway angegeben ist) – 2 x Standard_A4_v2 oder 2 x Standard_F8s_v2
  • Internes Unified Access Gateway (optional, sofern kein externes Gateway angegeben ist) – 2 x Standard_A4_v2 oder 2 x Standard_F8s_v2
Hinweis:
  • Ab der Dienstversion vom Juli 2020 sind in sauberen Umgebungen neue Pods erforderlich, um eine Bereitstellung mit mindestens einer Gateway-Konfiguration durchführen zu können. Wenn Ihr Kundenkonto vor der Version vom Juli 2020 erstellt wurde, Sie Ihren ersten Pod jedoch noch nicht bereitgestellt haben, ist für die Bereitstellung des ersten Pods die Konfiguration von mindestens einem Gateway erforderlich (zum Zeitpunkt der Bereitstellung des Pods). Folglich muss Ihre minimale Microsoft Azure-Kapazität die VMs für eine der Gateway-Konfigurationen aufnehmen können, wie in der obigen Liste beschrieben.
  • Falls die Region Ihres Abonnements die Größen von Standard_F8s_v2 nicht anbietet, zeigt der Assistent für die Pod-Bereitstellung im Schritt „Gateways festlegen“ diese Auswahlmöglichkeit nicht an.
  • Nach Abschluss der Pod-Bereitstellung muss Ihre Kapazität in Microsoft Azure Cloud auch für die importierten VMs, die Golden Images, die virtuellen Desktops und die RDSH-Farmen ausreichen, die Sie in diesem Pod erstellen. Wenn für Ihr Konto die Verwendung der App Volumes-Funktionen aktiviert ist und Sie den Workflow für die Erfassung von Anwendungen der Konsole verwenden, muss Ihre Kapazität auch für die VMs in der vom System generierten Desktop-Zuweisung ausreichen, die für diesen Erfassungsvorgang verwendet werden. Weitere Informationen finden Sie unten im Abschnitt Horizon Cloud-Basisimages, Desktops und Farmen.

Das externe Unified Access Gateway kann optional in einem eigenen virtuellen Microsoft Azure-Netzwerk (VNet) bereitgestellt werden, entweder mit demselben Abonnement wie der Pod oder mit einem anderen Abonnement. Bei der Bereitstellung des externen Unified Access Gateway in einem eigenen VNet ist die folgende Kapazität für das Abonnement erforderlich, unter dem das externe Unified Access Gateway bereitgestellt wird:

  • 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.
Für jedes Abonnement erstellter Dienstprinzipal und Authentifizierungsschlüssel. Zusätzliche Informationen finden Sie unter Erstellen einer Azure Active Directory-Anwendung und eines Dienstprinzipals mit Ressourcenzugriff mithilfe eines Portals. Siehe auch Erstellen des vom Horizon Cloud-Podbereitsteller benötigten Dienstprinzipals durch Erstellen einer Anwendungsregistrierung.
Jedem Dienstprinzipal muss die entsprechende Rolle zugewiesen werden, die die Aktionen zulässt, die Horizon Cloud im Abonnement durchführen muss. Bei dieser Rolle kann es sich um die Rolle Teilnehmer oder eine benutzerdefinierte Rolle mit den erforderlichen zulässigen Aktionen auf Abonnementebene handeln. Wenn Sie die Konfiguration des externen Gateways in einer vorhandenen Ressourcengruppe in einem separaten Abonnement bereitstellen, können detailliertere Berechtigungen für den Dienstprinzipal dieses Abonnements festgelegt werden. Weitere Informationen zu den erforderlichen Rollenaktionen finden Sie unter Für Horizon Cloud in Ihren Microsoft Azure-Abonnements erforderliche Vorgänge.
Wichtig: Die Rolle muss direkt dem Dienstprinzipal zugewiesen werden, der für Horizon Cloud verwendet wird. Die Verwendung einer gruppenbasierten Zuweisung einer Rolle für den Dienstprinzipal – in dem die Rolle einer Gruppe zugewiesen und der Dienstprinzipal Mitglied dieser Gruppe ist – wird nicht unterstützt.
Erforderliche Ressourcenanbieter sind in jedem Microsoft Azure-Abonnement registriert. Weitere Informationen finden Sie in Schritt 8.b unter Erstellen des erforderlichen Dienstprinzipals durch Erstellen einer Anwendungsregistrierung durch den Horizon Cloud-Pod-Bereitsteller.
Abonnement-ID, Verzeichnis-ID, Anwendungs-ID und identifizierter Schlüssel für Microsoft Azure.
Wenn Sie das externe Unified Access Gateway mit einem eigenen Abonnement in einem separaten VNet bereitstellen und Ihre Organisation die Verwendung einer von Ihnen kontrollierten Ressourcengruppe erfordert, die nicht vom Pod-Bereitsteller erstellt wurde, nutzen Sie die Funktion zur Bereitstellung des externen Unified Access Gateway in Ihrer eigenen benannten Ressourcengruppe. Um diese Funktion zu verwenden, müssen Sie diese Ressourcengruppe in dem Abonnement erstellen, bevor Sie den Pod-Bereitsteller ausführen. Sie müssen auch sicherstellen, dass die erforderlichen Berechtigungen für den Pod-Bereitsteller vorhanden sind, damit er die Unified Access Gateway-Konfiguration in dieser Ressourcengruppe bereitstellen, die Konfiguration verwalten und die Unified Access Gateway-Software im standardmäßigen Pod-Aktualisierungsvorgang aktualisieren kann. Weitere Informationen zu den erforderlichen Berechtigungen finden Sie unter Für Horizon Cloud in Ihren Microsoft Azure-Abonnements erforderliche Vorgänge.

Netzwerkanforderungen

Virtuelles Microsoft Azure-Netzwerk (VNet), das in der gewünschten Microsoft Azure-Region mit dem anwendbaren Adressbereich zur Abdeckung der erforderlichen Subnetze erstellt wurde. Weitere Informationen finden Sie unter Virtuelles Azure-Netzwerk.

Wenn Sie das externe Unified Access Gateway in einem eigenen, vom VNet des Pods getrennten VNet bereitstellen, müssen Sie dieses VNet des Unified Access Gateway in derselben Microsoft Azure-Region erstellen wie das VNet des Pods mit anwendbarem Adressbereich, um erforderliche Subnetze abzudecken, und die beiden VNets als Peers verbinden.

3 sich nicht überschneidende Adressbereiche im CIDR-Format im VNet des Pods, reserviert für Subnetze.
  • 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 im Administratorhandbuch.
Bei der Bereitstellung des externen Unified Access Gateway in einem eigenen, vom VNet des Pods getrennten VNet 3 sich nicht überschneidende Adressbereiche im CIDR-Format im VNet des Unified Access Gateway, reserviert für Subnetze.
  • 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 Anforderungen an DNS für einen Horizon Cloud-Pod in Microsoft Azure und Port- und Protokollanforderungen für einen Horizon Cloud-Pod im Manifest der Version vom September 2019 oder höher.
Proxy-Serverinformationen bei Bedarf für ausgehenden Internetzugriff auf dem VNet, das während der Bereitstellung und des laufenden Betriebs der Horizon Cloud-Umgebung verwendet wird (optional)
Microsoft Azure VPN/Express-Route konfiguriert (optional)
FQDN für externen Benutzerzugriff, internen Benutzerzugriff oder beide (erforderlich, wenn ein Pod mit Unified Access Gateway bereitgestellt wird).
Hinweis: Für Pods, die mit der Manifestversion 2298.0 oder höher neu bereitgestellt wurden, gilt: Wenn ein Pod über beide Gateway-Typen verfügt, muss in den Konfigurationen für das externe Gateway und das interne Gateway im Pod derselbe FQDN angegeben werden. Da beide Gateways den gleichen FQDN verwenden, konfigurieren Sie nach der Pod-Bereitstellung ein aufgeteiltes DNS (Split Domain Name System), um die Gateway-Adresse entweder zum externen Gateway oder zum internen Gateway aufzulösen, je nach dem Ursprungsnetzwerk der DNS-Abfrage des Endbenutzer-Clients.
Zertifikat oder Zertifikate für Unified Access Gateway im PEM-Format, das dem FQDN entspricht (erforderlich, wenn ein Pod mit Unified Access Gateway bereitgestellt wird).
Hinweis:
  • Für Pods, die mit der Manifestversion 2298.0 oder höher neu bereitgestellt werden, muss in den Konfigurationen für das externe Gateway und das interne Gateway im Pod derselbe FQDN angegeben werden. Da das Zertifikat mit dem FQDN übereinstimmen muss, wenn ein Pod beide Gateway-Typen besitzt, wird in beiden Gateway-Konfigurationen dasselbe Zertifikat verwendet.
  • 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.
Zwei-Faktor-Authentifizierung für einen lokalen RADIUS-Authentifizierungsserver (optional)
  • 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

Port- und Protokollanforderungen

Für das Onboarding von Pods und den laufenden Betrieb Ihrer Horizon Cloud-Umgebung sind bestimmte Ports und Protokolle erforderlich. Siehe Port- und Protokollanforderungen für einen Horizon Cloud-Pod im Manifest der Version vom September 2019 oder höher.

Pod-Bereitstellungsworkflow

Die vorstehenden Elemente sind diejenigen, die vor dem Start des Pod-Bereitstellungsassistenten benötigt werden. Nachdem Sie sichergestellt haben, dass Sie über die vorstehenden Elemente verfügen, führen Sie die unter Allgemeiner Workflow, wenn Sie Ihren ersten mit der Cloud verbundenen Horizon Cloud-Pod mit dem Pod-Bereitsteller in Microsoft Azure bereitstellen beschriebenen Pod-Bereitstellungsschritte bis Schritt 4 aus, um Ihren Pod bereitzustellen.

Nachdem der Pod erfolgreich bereitgestellt wurde, stellen Sie sicher, dass die im folgenden Abschnitt beschriebenen Elemente vorhanden sind, damit Sie die übrigen wichtigen Schritte dieses allgemeinen Workflows abschließen können.

Active Directory-Anforderungen

Die folgenden Elemente werden für den Workflow zur Registrierung von Active Directory benötigt. Informationen zu diesem Workflow finden Sie unter Durchführen der ersten Active Directory-Domänenregistrierung in der Horizon Cloud-Umgebung.

Eine der folgenden unterstützten Active Directory-Konfigurationen:
  • 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. Die Checkliste für diese Horizon-Pods finden Sie unter VMware Horizon-Pods mit Horizon Cloud – Checkliste der Voraussetzungen – Aktualisiert für die Verbindung von Pods ab der Dienstversion vom Oktober 2020.
Domänendienstkonto
  • Active Directory-Domänendienstkonto (ein Standardbenutzer mit Lesezugriff) mit folgenden Berechtigungen:
    • Inhalt auflisten
    • Alle Eigenschaften lesen
    • Berechtigungen lesen
    • Read tokenGroupsGlobalAndUniversal (implizit enthalten in Alle Eigenschaften lesen)
    Hinweis:
    • 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) mit folgenden Berechtigungen:
    • Inhalt auflisten
    • Alle Eigenschaften lesen
    • Berechtigungen lesen
    • Read tokenGroupsGlobalAndUniversal (implizit enthalten in Alle Eigenschaften lesen)
    Hinweis:
    • 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)
  • Ist ein Mitglied der Horizon Cloud-Administratorengruppe
  • 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 alle nachfolgenden Objekte der Zielorganisationseinheit (OU), die Sie für Farmen und VDI-Desktop-Zuweisungen verwenden möchten.
  • Weitere Informationen und Anforderungen finden Sie unter Dienstkonten, die Horizon Cloud für seine Vorgänge benötigt.
Hinweis: Wenn Sie in Microsoft Active Directory eine neue OE erstellen, legt das System möglicherweise automatisch das Attribut Prevent Accidental Deletion fest, das für die neu erstellte OE und alle abgeleiteten Objekte für die Berechtigung „Alle untergeordneten Objekte löschen“ Deny anwendet. Wenn Sie daher dem Domänenbeitrittskonto explizit die Berechtigung „Computerobjekte löschen“ zugewiesen haben, hat Active Directory im Fall einer neu erstellten OE möglicherweise eine Außerkraftsetzung auf die explizit zugewiesene Berechtigung „Computerobjekte löschen“ angewendet. Da durch das Löschen des Flags Versehentliches Löschen verhindern das von Active Directory auf die Berechtigung „Alle untergeordneten Objekte löschen“ angewendete Deny möglicherweise nicht automatisch gelöscht wird, müssen Sie im Fall einer neu hinzugefügten OE das für die Berechtigung zum Löschen aller untergeordneten Objekte in der OE und allen untergeordneten OEs festgelegte Deny möglicherweise prüfen und manuell löschen, bevor Sie das Domänenbeitrittskonto in der Horizon Cloud-Konsole verwenden.
Zusätzliches Domänenbeitrittskonto (optional, kann nicht dasselbe Konto verwenden wie oben)
  • 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)
  • Ist ein Mitglied der Horizon Cloud-Administratorengruppe
  • 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 alle nachfolgenden Objekte der Zielorganisationseinheit (OU), die Sie für Farmen und virtuelle VDI-Desktops verwenden möchten.
  • Weitere Informationen und Anforderungen finden Sie unter Dienstkonten, die Horizon Cloud für seine Vorgänge benötigt.
Hinweis: Wenn Sie in Microsoft Active Directory eine neue OE erstellen, legt das System möglicherweise automatisch das Attribut Prevent Accidental Deletion fest, das für die neu erstellte OE und alle abgeleiteten Objekte für die Berechtigung „Alle untergeordneten Objekte löschen“ Deny anwendet. Wenn Sie daher dem Domänenbeitrittskonto explizit die Berechtigung „Computerobjekte löschen“ zugewiesen haben, hat Active Directory im Fall einer neu erstellten OE möglicherweise eine Außerkraftsetzung auf die explizit zugewiesene Berechtigung „Computerobjekte löschen“ angewendet. Da durch das Löschen des Flags Versehentliches Löschen verhindern das von Active Directory auf die Berechtigung „Alle untergeordneten Objekte löschen“ angewendete Deny möglicherweise nicht automatisch gelöscht wird, müssen Sie im Fall einer neu hinzugefügten OE das für die Berechtigung zum Löschen aller untergeordneten Objekte in der OE und allen untergeordneten OEs festgelegte Deny möglicherweise prüfen und manuell löschen, bevor Sie das Domänenbeitrittskonto in der Horizon Cloud-Konsole verwenden.
Active Directory-Gruppen
  • Horizon Cloud-Administratoren – Active Directory-Sicherheitsgruppe für Horizon Cloud-Administratoren. Enthält die Horizon Cloud-Administratorbenutzer und das Domänenbeitrittskonto. Diese Gruppe wird der Rolle Superadministrator in Horizon Cloud hinzugefügt.
  • 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.
Active Directory-Organisationseinheit (OU) bzw. -einheiten (OUs) für virtuelle Desktops und RDS-sitzungsbasierte Desktops oder veröffentlichte Anwendungen oder beides.
Hinweis: Wenn Sie in Microsoft Active Directory eine neue OE erstellen, legt das System möglicherweise automatisch das Attribut Prevent Accidental Deletion fest, das für die neu erstellte OE und alle abgeleiteten Objekte für die Berechtigung „Alle untergeordneten Objekte löschen“ Deny anwendet. Wenn Sie daher dem Domänenbeitrittskonto explizit die Berechtigung „Computerobjekte löschen“ zugewiesen haben, hat Active Directory im Fall einer neu erstellten OE möglicherweise eine Außerkraftsetzung auf die explizit zugewiesene Berechtigung „Computerobjekte löschen“ angewendet. Da durch das Löschen des Flags Versehentliches Löschen verhindern das von Active Directory auf die Berechtigung „Alle untergeordneten Objekte löschen“ angewendete Deny möglicherweise nicht automatisch gelöscht wird, müssen Sie im Fall einer neu hinzugefügten OE das für die Berechtigung zum Löschen aller untergeordneten Objekte in der OE und allen untergeordneten OEs festgelegte Deny möglicherweise prüfen und manuell löschen, bevor Sie das Domänenbeitrittskonto in der Horizon Cloud-Konsole verwenden.

Universal Broker-Anforderungen

Ab der Version vom Juli 2020 gilt: Wenn Ihre Horizon Cloud-Mandantenumgebung ein ab diesem Datum gültiges völlig neues Konto ist und Sie soeben die Bereitstellung Ihres ersten Pods in Microsoft Azure abgeschlossen haben, dann können Sie Universal Broker als Brokering-Methode für Ihre Umgebung auswählen. Wenn Sie Universal Broker für Ihre Umgebung konfigurieren möchten, werden folgende Elemente benötigt. Siehe Konfigurieren von Universal Broker.

Ausgehender Internetzugriff der VNets, die Sie für den Pod verwenden, muss bestimmte DNS-Namen auflösen und über bestimmte Ports und Protokolle erreichen können. Dies ist für die Universal Broker-Konfiguration und den laufenden Betrieb erforderlich. Eine Liste der DNS-Namen und Ports finden Sie unter Anforderungen an DNS für einen Horizon Cloud-Pod in Microsoft Azure und Port- und Protokollanforderungen für einen Horizon Cloud-Pod im Manifest der Version vom September 2019 oder höher.
Optional: Konfigurieren Sie die Gateways Ihres Pods für die 2-Faktor-Authentifizierung bei einem RADIUS-Authentifizierungsserver, wenn Universal Broker für den Pod eine 2-Faktor-Authentifizierung verwenden soll.
  • 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 (optional)

Anforderungen an den DNS-Datensatz

Nachdem der Pod in der Microsoft Azure-Cloud bereitgestellt wurde und abhängig von Ihrer Geschäftssituation und den Funktionen, die Sie nutzen möchten, ist es wichtig, Datensätze in Ihrem DNS-Server einzurichten, die vollqualifizierte Domänennamen (FQDNs) den IP-Adressen des Pods zuordnen.

Hinweis: Für Pods, die mit der Manifestversion 2298.0 oder höher bereitgestellt wurden, gilt: Wenn ein Pod über beide Gateway-Typen verfügt, muss in den Konfigurationen für das externe Gateway und das interne Gateway im Pod derselbe FQDN angegeben werden. Da beide Gateways den gleichen FQDN verwenden, konfigurieren Sie nach der Pod-Bereitstellung ein aufgeteiltes DNS (Split Domain Name System), um die Gateway-Adresse entweder zum externen Gateway oder zum internen Gateway aufzulösen, je nach dem Ursprungsnetzwerk der DNS-Abfrage des Endbenutzer-Clients.
Wenn Sie Universal Broker mit einem benutzerdefinierten FQDN konfiguriert haben, erstellen Sie einen öffentlichen DNS-Datensatz, der Ihren benutzerdefinierten FQDN dem von VMware bereitgestellten Brokering-FQDN in Ihrer Universal Broker-Konfiguration zuordnet. Siehe Konfigurieren von Universal Broker.
Für den externen Endbenutzerzugriff erstellter öffentlicher DNS-Datensatz, der dem FQDN entspricht und auf den externen Lastausgleichsdienst von Microsoft Azure in der externen Unified Access Gateway-Konfiguration des Pods verweist (erforderlich, wenn der bereitgestellte Pod diese Konfiguration besitzt). Weitere Informationen finden Sie unter Konfigurieren eines benutzerdefinierten Domänennamens für einen Azure-Clouddienst.
Für den internen Endbenutzerzugriff erstellter interner DNS-Datensatz, der dem FQDN entspricht und auf den internen Lastausgleichsdienst von Microsoft Azure in der internen Unified Access Gateway-Konfiguration des Pods verweist (erforderlich, wenn der bereitgestellte Pod diese Konfiguration besitzt).
Interner DNS-Datensatz, der erstellt wird, wenn Sie Einzel-Pod-Brokering für Ihre Bereitstellung auswählen und die Bereitstellung mit VMware Workspace ONE Access integrieren möchten. In diesem Szenario unterstützt dieser interne DNS-Datensatz die VMware Workspace ONE Access-Verbindungen mit dem Pod, in dem der VMware Workspace ONE Access Connector die Informationen über Benutzerzuweisungen vom Pod synchronisiert. Dieser interne DNS-Datensatz stimmt mit dem FQDN im Zertifikat überein, das Sie direkt auf den Pod hochladen werden, und verweist auf den internen Microsoft Azure-Load Balancer des Pods. Erforderlich, wenn Sie VMware Workspace ONE Access mit einem Pod in einer für Einzel-Pod-Brokering konfigurierten Umgebung verwenden möchten.
Hinweis: Dieser interne DNS-Datensatz und ein Zertifikat, das zum Pod passt und in den Pod selbst hochgeladen wird, werden auch im seltenen, untypischen Anwendungsfall verwendet, wenn Sie interne Endbenutzer zum Herstellen einer direkten Verbindung mit dem Pod auffordern würden, anstatt sie eine Verbindung mit einer internen Unified Access Gateway-Konfiguration auf dem Pod herstellen zu lassen. Derartige direkte Verbindungen sind ein ungewöhnliches Anwendungsbeispiel. In der Regel wird stattdessen ein internes Unified Access Gateway verwendet.
Zertifikatskette (CA-Zertifikat, SSL-Zertifikat, SSL-Schlüsseldatei), die dem obigen internen DNS-Datensatz entspricht, der für VMware Workspace ONE Access-Verbindungen mit dem Pod erstellt wurde. Weitere Informationen finden Sie unter Hochladen von SSL-Zertifikaten auf einen Horizon Cloud-Pod für direkte Verbindungen. (Dies ist auch erforderlich, wenn Sie den untypischen Anwendungsfall haben, dass interne Endbenutzer eine direkte Verbindung mit dem Pod herstellen. Direkte Verbindungen stellen eine seltene, ungewöhnliche Nutzung dar. In der Regel wird stattdessen ein internes Unified Access Gateway verwendet.)

Golden Images, Desktops und Farmen für Horizon Cloud

Ihr Microsoft Azure-Abonnement muss die folgenden Anforderungen erfüllen, die von den Typen der Golden Images, VDI-Desktops und RDS-Farmen abhängig sind, die Sie über den bereitgestellten Pod bereitstellen möchten.

Hinweis: Wenn in Ihrem Konto die Verwendung der App Volumes-Funktionen aktiviert ist und Sie die Aktion Erfassen der Konsole verwenden, um App Volumes-Anwendungen zu Ihrem Bestand hinzuzufügen, dann generiert das System eine Desktop-Zuweisung von zwei Desktop-VMs, um den Erfassungsworkflow zu unterstützen. Ihre Kapazität muss auch das Erstellen dieser Desktops abdecken, während Sie den Erfassungsworkflow durchführen. Sie können diese Desktop-Zuweisung löschen, nachdem das Erfassen von Anwendungen für Ihre Umgebung abgeschlossen ist.
Basis für das Golden Image – eine der unterstützten Konfigurationen für Microsoft Azure-VMs.
  • Standard_D3_v2, Standard_D4_v3
  • Standard_D2_v2, Standard_D2_v3
  • Standard_NV6
Hinweis: Wenn Sie den Assistenten zum automatisierten Importieren von VMs aus dem Download-Center verwenden, um eine Basis-VM zu erstellen, verwendet das System automatisch eine der oben genannten VM-Größen. Die Standardauswahl des Systems basiert auf den interne Algorithmen, einschließlich der Überprüfung, welche Größen in der Microsoft Azure-Region des Pods verfügbar sind. Wenn Sie den Assistenten zum Erstellen einer GPU-fähigen VM verwenden, wird standardmäßig die VM-Größe „Standard_NV6“ erstellt. Wenn Sie den Assistenten verwenden, um eine auf dem Serverbetriebssystem basierte VM zu erstellen, wird eine VM mit „Standard_D2_v2“ oder „Standard_D2_v3“ erstellt. Beim Erstellen einer Clientbetriebssystem-basierten VM oder einer Windows 10-VM für mehrere Sitzungen wird eine VM mit „Standard_D3_v2“ oder „Standard_D4_v3“ erstellt.
Modellauswahl für die Desktop-VMs in VDI-Desktop-Zuweisungen – eine beliebige der Konfigurationen für Microsoft Azure-VMs, die in der Microsoft Azure-Region verfügbar sind (mit Ausnahme derjenigen, die nicht mit Horizon Cloud-Desktopvorgängen kompatibel sind).

Für Produktionsumgebungen empfehlen VMware-Skalierungstests die Verwendung von Modellen mit mindestens 2 CPUs.

Modellauswahl für die RDSH-VMs in Farmen – eine der Konfigurationen für Microsoft Azure-VMs, die in der Microsoft Azure-Region verfügbar sind (mit Ausnahme derjenigen, die nicht mit Horizon Cloud-RDS-Farmvorgängen kompatibel sind).

Diese Anforderung gilt auch für eine VM, auf der Microsoft Windows 10 Enterprise für Mehrfachsitzungen ausgeführt wird, wenn diese VM mit Horizon Cloud verwendet wird. Gemäß Beschreibung in den Häufig gestellten Fragen zu Microsoft Windows 10 Enterprise für Mehrfachsitzungen in der Microsoft Azure Windows Virtual Desktop-Dokumentation ist Microsoft Windows 10 Enterprise für Mehrfachsitzungen ein Remotedesktop-Sitzungshost(RDSH)-Typ, der mehrere gleichzeitige interaktive Sitzungen zulässt, die zuvor nur von Microsoft Windows Server Betriebssystemen bereitgestellt werden konnten. Die für RDS-Server geltenden Horizon Cloud-Workflows gelten auch für Microsoft Windows 10 Enterprise für Mehrfachsitzungen.

Für Produktionsumgebungen empfehlen VMware-Skalierungstests die Verwendung von Modellen mit mindestens 2 CPUs.

Lizenzierung für die Microsoft Windows-Betriebssysteme

Diese Elemente beziehen sich auf die Microsoft Windows-Betriebssysteme in Ihren importierten VMs, auf Golden Images, auf RDSH-fähige Farm-VMs und auf virtuelle Desktop-VMs. Eine Liste der von Horizon Cloud unterstützten Microsoft Windows-Betriebssysteme finden Sie im VMware Knowledgebase-Artikel 78170 und VMware Knowledgebase-Artikel 70965.

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

Tipp: Informationen zur Lizenzierung für Microsoft Windows Virtual Desktop für Windows 10 Enterprise für Mehrfachsitzungen und Windows 7 Enterprise finden Sie in der Microsoft Azure-Dokumentation unter dem Thema Preisgestaltung für Windows Virtual Desktop.
Lizenzierung für einen oder mehrere der folgenden Typen: Microsoft Windows 7 Enterprise, Microsoft Windows 10 (Clienttypen)
Lizenzierung für Microsoft Windows 10 Enterprise für Mehrfachsitzungen
Lizenzierung für einen oder mehrere der folgenden Typen: Microsoft Windows Server 2012 R2, Microsoft Server 2016, Microsoft Server 2019
Lizenzierungsserver für Microsoft Windows RDS – für Hochverfügbarkeit werden redundante Lizenzierungsserver empfohlen
Microsoft RDS-Benutzer oder -Geräte-CALs oder beides

Referenzarchitektur

Verwenden Sie die nachfolgenden Architekturdiagramme als Referenz.

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.