Bevor Sie den First-Gen-Pod-Bereitstellungsassistenten ausführen, stellen Sie sicher, dass Ihre Umgebung diese Voraussetzungen erfüllt. Die folgenden Elemente sind erforderlich, damit Sie die angeforderten Werte im Pod-Bereitstellungsassistenten angeben und mit der nächsten Assistentenseite fortfahren können.

Wichtig: Diese Informationen gelten 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.
Wichtig: Bevor Sie den Pod-Bereitstellungsassistenten starten und Ihren Pod bereitstellen, müssen Sie zusätzlich zu den unten aufgeführten Anforderungen die folgenden wichtigen Punkte beachten:
  • Für eine erfolgreiche Pod-Bereitstellung darf keine der Microsoft Azure-Richtlinien, die Sie oder Ihr IT-Team in Ihrer Microsoft Azure-Umgebung festgelegt haben, die Erstellung der Pod-Komponenten blockieren, ablehnen oder beschränken. Außerdem müssen Sie sicherstellen, dass die integrierten Richtliniendefinitionen Ihrer Microsoft Azure-Richtlinien die Erstellung der Pod-Komponenten nicht blockieren, ablehnen oder einschränken. Zwei Beispiele für zulässige Elemente sind: Sie und Ihr IT-Team müssen sicherstellen, dass keine Ihrer Microsoft Azure-Richtlinien die Erstellung von Komponenten für das Azure-Speicherkonto blockiert, verweigert oder beschränkt. Außerdem müssen Sie sicherstellen, dass Ihre Microsoft Azure-Richtlinien resourceType von Microsoft.MarketplaceOrdering/* zulassen. Der Pod-Bereitstellungsprozess basiert auf der Annahme von Azure Marketplace-Angeboten von vmware-inc publisherID von VMware. Informationen zu Azure-Richtlinien finden Sie in der Dokumentation zu Azure-Richtlinien. Informationen dazu, wie der Dienst den Ressourcentyp Microsoft.MarketplaceOrdering/* verwendet, finden Sie unter Wenn Ihre IT-Organisation Einschränkungen bei der Nutzung von Azure Marketplace-Angeboten oder bei Marketplace-Käufen hat.
  • Der Pod-Bereitsteller setzt voraus, dass Ihr Azure-Speicherkonto dem Bereitsteller ermöglicht, den Kontotyp Azure StorageV2 in der Ressourcengruppe des Pods im Abonnement zu erstellen. Dieses Speicherkonto wird für die App Volumes-Funktionen des Pods verwendet. Stellen Sie während der Pod-Bereitstellung sicher, dass Ihre Microsoft Azure-Richtlinien die Erstellung von Inhalten, die den Azure-Kontotyp StorageV2 erfordern, nicht einschränken oder ablehnen.
  • 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.

Voraussetzungen für alle Bereitstellungen

  • Stellen Sie sicher, dass alle vorbereitenden Aufgaben abgeschlossen sind, wie in First-Gen-Mandanten – Vorbereiten der Bereitstellung eines First-Gen- Horizon Cloud-Pods in Microsoft Azure beschrieben.
  • Vergewissern Sie sich, dass Sie über die unter First-Gen-Mandanten – Mandantenbezogene Informationen für den Assistenten für die Horizon Cloud-Pod-Bereitstellung beschriebenen Abonnementinformationen verfügen.
  • Stellen Sie sicher, dass ein virtuelles Netzwerk in Ihrem Microsoft Azure-Abonnement und in der Region, in der Sie den Pod bereitstellen, vorhanden ist, wie in First-Gen-Horizon Cloud – Konfigurieren des erforderlichen virtuellen Netzwerks in Microsoft Azure beschrieben.
    Wichtig: Nicht alle Microsoft Azure-Regionen unterstützen GPU-fähige virtuelle Maschinen. Wenn Sie den Pod für GPU-fähige Desktops oder Remoteanwendungen verwenden möchten, stellen Sie sicher, dass die Microsoft Azure-Region, die Sie für den Pod auswählen, die VM-Typen der NV-Serie, NVv4-Serie und NCv2-Serie, die Sie verwenden möchten, bereitstellt und dass diese in dieser Version von Horizon Cloud unterstützt werden. Weitere Details finden Sie in der Microsoft-Dokumentation unter https://azure.microsoft.com/de-de/regions/services/.
  • Stellen Sie sicher, dass die Konfiguration Ihres VNets auf einen DNS zeigt, der externe Adressen auflösen kann. Der Pod-Bereitsteller muss in der Lage sein, externe Adressen in der Horizon Cloud-Steuerungsebene zu erreichen, um die Pod-Software sicher in Ihre Microsoft Azure-Umgebung herunterzuladen.
  • Stellen Sie sicher, dass die DNS-, Port- und Protokollanforderungen des Pods-Bereitstellers erfüllt sind, wie in 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 beschrieben.
  • Wenn Sie für den ausgehenden Internetzugriff einen Proxy verwenden müssen, stellen Sie sicher, dass Sie die Netzwerkinformationen für Ihre Proxy-Konfiguration und die gegebenenfalls benötigten Anmeldedaten für die Authentifizierung besitzen. Für die Bereitstellung des Pods ist ein ausgehender Internetzugriff erforderlich.
    Wichtig: Die Bearbeitung oder Aktualisierung der Proxy-Einstellungen auf einem Pod nach der Bereitstellung des Pods in Microsoft Azure wird derzeit nicht unterstützt. Auch das Hinzufügen einer Proxy-Konfiguration zu einem bereitgestellten Pod, der ohne Proxy-Einstellungen bereitgestellt wurde, wird derzeit nicht unterstützt.
  • Stellen Sie sicher, dass Sie die Informationen für mindestens einen NTP-Server besitzen, den die Pod-Manager-Instanzen und Unified Access Gateway-Instanzen für die Uhrzeitsynchronisierung verwenden sollen. Bei diesem NTP-Server kann es sich um einen öffentlichen NTP-Server oder Ihren eigenen NTP-Server handeln. Der angegebene NTP-Server muss über die virtuellen Netzwerke erreichbar sein, in denen Sie die Pod-Manager-Instanzen und Unified Access Gateway-Instanzen bereitstellen möchten. Wenn Sie einen NTP-Server unter Verwendung seines Domänennamens anstelle seiner numerischen IP-Adresse verwenden möchten, müssen Sie außerdem sicherstellen, dass das für das virtuelle Netzwerk konfigurierte DNS den Namen des NTP-Servers auflösen kann.
    Hinweis: Es wird empfohlen, denselben NTP-Server für die Pod-Manager-Instanzen, Unified Access Gateway-Instanzen und Ihre Active Directory-Server zu verwenden. Wenn diese Instanzen verschiedene NTP-Server verwenden, kann es zu Zeitverzögerungen kommen. Solche Zeitverzögerungen können später zu Fehlern führen, wenn das Gateway versucht, Endbenutzersitzungen für ihre Desktops und Anwendungen zu authentifizieren.
  • Wenn der Bereitsteller die erforderlichen Subnetze nicht automatisch erstellen soll, stellen Sie sicher, dass die erforderlichen Subnetze im Voraus erstellt wurden und im VNet vorhanden sind. Die Schritte zum Erstellen der erforderlichen Subnetze im Voraus finden Sie unter First-Gen-Mandanten – Erstellen Sie im Vorfeld der Pod-Bereitstellung die erforderlichen Subnetze des Horizon Cloud-Pods in Ihrem VNet in Microsoft Azure. und First-Gen-Mandanten – Verwendung vorhandener Subnetze für einen Horizon Cloud-Pod in Microsoft Azure.
    Vorsicht: Die Subnetze, die Sie in Ihrem VNet für die Pod-Bereitstellung manuell erstellen, müssen leer bleiben. Verwenden Sie keine vorhandenen Subnetze, die bereits Elemente enthalten, die IP-Adressen in diesen Subnetzen verwenden. Wenn eine IP-Adresse bereits in den Subnetzen verwendet wird, treten sehr wahrscheinlich Probleme auf, z. B. Fehler bei der Pod-Bereitstellung und andere IP-Konfliktprobleme im Nachhinein. Sie dürfen weder Ressourcen in diese Subnetze einbinden noch eine der IP-Adressen an anderer Stelle verwenden. Diese Warnung umfasst Pods, die von Horizon Cloud bereitgestellt werden – verwenden Sie keine Subnetze erneut, auf denen Sie bereits einen Pod bereitgestellt haben.
  • Wenn der Bereitsteller die erforderlichen Subnetze erstellt, stellen Sie sicher, dass Sie die Adressbereiche kennen, die Sie in den Assistenten für das Management-Subnetz, das Desktop-Subnetz und das DMZ-Subnetz eingeben. Das DMZ-Subnetz ist erforderlich, wenn Sie eine externe Unified Access Gateway-Konfiguration möchten. Stellen Sie auch sicher, dass sich diese Bereiche nicht überschneiden. Die Eingabe der Adressbereiche erfolgt in CIDR-Notation (Classless Inter-Domain Routing Notation). Der Assistent zeigt einen Fehler an, wenn die eingegebenen Subnetzbereiche einander überlappen. Für den Management-Subnetz-Bereich ist mindestens CIDR /27 erforderlich. Für den DMZ-Subnetzbereich ist ein CIDR von mindestens /28 erforderlich. Wenn Sie die Verwaltungs- und DMZ-Subnetz-Bereiche gemeinsam nutzen möchten, können Sie den Bereich des DMZ-Subnetzes ähnlich wie das Management-Subnetz mit einer spezifizierten IP angeben. Wenn das Management-Subnetz beispielsweise 192.168.8.0/27 ist, wäre ein entsprechendes DMZ-Subnetz 192.168.8.32/27.
    Wichtig: Die CIDRs, die Sie in die Felder des Assistenten eingeben, müssen so definiert sein, dass jede Kombination aus Präfix und Bitmaske zu einem IP-Adressbereich mit dem Präfix als Ausgangs-IP-Adresse führt. Microsoft Azure erfordert, dass das CIDR-Präfix den Anfang des Bereichs darstellt. Das korrekte CIDR 192.168.182.48/28 würde beispielsweise den IP-Bereich 192.168.182.48 bis 192.168.182.63 ergeben. Dabei ist das Präfix mit der IP-Startadresse (192.168.182.48) identisch. Das falsche CIDR 192.168.182.60/28 würde jedoch den IP-Bereich 192.168.182.48 bis 192.168.182.63 ergeben, in dem die IP-Startadresse nicht das Präfix 192.168.182.60 ist. Stellen Sie sicher, dass Ihre CIDRs IP-Adressbereiche ergeben, bei denen die IP-Startadresse mit dem CIDR-Präfix übereinstimmt.
  • Wenn der Bereitsteller die erforderlichen Subnetze erstellt, stellen Sie sicher, dass Subnetze mit diesen Adressbereichen nicht bereits im VNet vorhanden sind. In diesem Szenario erstellt der Bereitsteller selbst die Subnetze automatisch anhand der Adressbereiche, die Sie im Assistenten angeben. Wenn der Assistent Subnetze mit bereits vorhandenen Bereichen erkennt, zeigt der Assistent einen Fehler über überlappende Adressen an und geht nicht weiter. Wenn Ihr VNet ein Peer ist, stellen Sie außerdem sicher, dass die CIDR-Adressbereiche, die Sie im Assistenten eingeben möchten, bereits im Adressbereich des VNets enthalten sind.

Voraussetzungen für die Unified Access Gateway-Konfigurationen

Wenn Sie möchten, dass der Pod eine Unified Access Gateway-Konfiguration verwendet, müssen Sie Folgendes angeben:

  • Den vollqualifizierten Domänennamen (FQDN), den Ihre Endbenutzer für den Zugriff auf den Dienst verwenden werden. Wenn Sie planen, den gleichen FQDN für die externen und internen Gateway-Konfigurationen zu verwenden, müssen Sie nach der Bereitstellung des Pods den eingehenden Datenverkehr des Endbenutzer-Clients so konfigurieren, dass er zum entsprechenden Lastausgleichsdienst des Gateways weitergeleitet wird. Das Ziel besteht darin, das Routing so einzurichten, dass der Client-Datenverkehr aus dem Internet an den öffentlichen Microsoft Azure Load Balancer des externen Gateways und der Client-Datenverkehr aus Ihrem Intranet an den internen Microsoft Azure Load Balancer des internen Gateways weitergeleitet wird. In diesem Szenario, in dem beide Gateways den gleichen FQDN haben, konfigurieren Sie 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. Dann kann der FQDN im Endbenutzer-Client zur Weiterleitung an das externe Gateway verwendet werden, wenn sich der Client im Internet befindet, und zur Weiterleitung an das interne Gateway, wenn sich der Client in Ihrem internen Netzwerk befindet.
    Wichtig: Dieser FQDN darf keine Unterstriche enthalten. In diesem Release werden Verbindungen zu den Unified Access Gateway-Instanzen fehlschlagen, wenn der FQDN Unterstriche enthält.
  • Ein signiertes SSL-Server-Zertifikat (im PEM-Format) basierend auf diesem FQDN. Die Unified Access Gateway-Funktionen erfordern für Clientverbindungen SSL, wie in der Produktdokumentation zu Unified Access Gateway beschrieben. Das Zertifikat muss von einer vertrauenswürdigen Zertifizierungsstelle (CA) signiert sein. Die PEM-Datei muss die gesamte Zertifikatskette mit dem privaten Schlüssel enthalten. Die PEM-Datei muss z. B. das SSL-Serverzertifikat, alle erforderlichen Zwischenzertifizierungsstellen-Zertifikate, das Stamm-Zertifizierungsstellenzertifikat und den privaten Schlüssel enthalten. OpenSSL ist ein Tool mit dem Sie die PEM-Datei erstellen können.
    Wichtig: Alle Zertifikate in der Zertifikatskette müssen gültige Zeiträume aufweisen. Die Unified Access Gateway-VMs erfordern, dass alle Zertifikate in der Zertifikatskette und alle gegebenenfalls vorhandenen Zwischenzertifikate gültige Zeiträume besitzen. Wenn ein Zertifikat in der Zertifikatskette abgelaufen ist, können später beim Hochladen des Zertifikats in die Unified Access Gateway-Konfiguration unerwartete Fehler auftreten.
  • Wenn Sie mit einer externen Unified Access Gateway-Konfiguration bereitstellen, müssen Sie ein DMZ-Subnetz (Demilitarized Zone) angeben. Sie können dieses DMZ-Subnetz auf zwei Arten angeben:
    • Erstellen des DMZ-Subnetzes im Voraus im VNet. Bei dieser Methode müssen Sie auch die Verwaltungs- und Desktop-Mandantensubnetze im Voraus erstellen. Die jeweiligen Schritten finden Sie unter First-Gen-Mandanten – Erstellen Sie im Vorfeld der Pod-Bereitstellung die erforderlichen Subnetze des Horizon Cloud-Pods in Ihrem VNet in Microsoft Azure..
    • Automatische Erstellung des DMZ-Subnetzes durch den Bereitsteller während der Bereitstellung. Bei dieser Methode müssen Sie einen Adressbereich in den Assistenten für das DMZ-Subnetz eingeben und sicherstellen, dass sich der Bereich nicht mit den Bereichen für das Verwaltungs- und Desktop-Mandantensubnetz überschneidet. Die Eingabe der Adressbereiche erfolgt in CIDR-Notation (Classless Inter-Domain Routing Notation). Der Assistent zeigt einen Fehler an, wenn die eingegebenen Subnetzbereiche einander überlappen. Für den DMZ-Subnetzbereich ist ein CIDR von mindestens /28 erforderlich. Wenn Sie die Bereiche Verwaltung und DMZ-Subnetz gemeinsam nutzen möchten, können Sie den Bereich des DMZ-Subnetzes genauso angeben wie das Management-Subnetz mit einer angegebenen IP. Wenn das Management-Subnetz beispielsweise 192.168.8.0/27 ist, wäre ein entsprechendes DMZ-Subnetz 192.168.8.32/27. Weitere Informationen finden Sie im wichtigen Hinweis unter Voraussetzungen für alle Bereitstellungen zur Gewährleistung, dass der IP-Adressbereich über eine Kombination aus Präfix und Bit-Maske verfügt, die einen Bereich mit dem Präfix als IP-Startadresse ergibt.
  • Wenn Sie mit einer externen Unified Access Gateway-Konfiguration bereitstellen und verhindern möchten, dass eine öffentliche IP-Adresse für den Lastausgleichsdienst der Konfiguration verwendet wird, müssen Sie eine IP-Adresse angeben, die Sie in Ihren DNS-Einstellungen dem FQDN zugewiesen haben, den Ihre Endbenutzer für PCoIP-Verbindungen in ihren Horizon-Clients verwenden sollen.

Weitere Informationen zu der für Unified Access Gateway benötigten PEM-Datei finden Sie unter First-Gen-Mandanten – Konvertieren einer Zertifikatsdatei in das PEM-Format, das für Horizon Cloud First-Gen-Pod-Bereitstellungen erforderlich ist.

Voraussetzungen bei der Bereitstellung mit der Konfiguration eines externen Unified Access Gateway unter Verwendung von dessen eigenem VNet oder Abonnement anstelle des VNets oder Abonnements des Pods

Hinweis: Beim Bereitstellen eines externen Gateways über ein eigenes VNet wird eine Gateway-Connector-VM bereitgestellt. In Anforderungen an Ports und Protokolle für einen Horizon Cloud Pod enthält der Abschnitt, der die Ports und Protokolle der Gateway-Connector-VM beschreibt, auch eine Beschreibung dieser Gateway-Connector-VM, die besagt, dass diese Gateway-Connector-VM einen Namen hat, der einen Teil wie vmw-hcs-ID enthält, wobei ID die Bereitsteller-ID des Gateways ist, und einen Teil node.

Zusammen mit den obigen Voraussetzungen bei der Bereitstellung mit einer Konfiguration mit Unified Access Gateway müssen diese speziellen Voraussetzungen erfüllt sein, wenn das externe Gateway in seinem eigenen VNet oder Abonnement bereitgestellt wird. Die Verwendung eines eigenen Abonnements ist ein Sonderfall der Verwendung seines eigenen VNet, da das eigene Abonnement auch ein eigenes VNet erfordert, denn VNets gehören jeweils dem Bereich eines Abonnements an.

Voraussetzungen bei der Bereitstellung mit einer Konfiguration zur Zwei-Faktor-Authentifizierung

Wenn Sie vorhaben, die Zwei-Faktor-Authentifizierung zu verwenden oder diese auf einem lokalen Zwei-Faktor-Authentifizierungsserver zu nutzen, vergewissern Sie sich, dass Sie über die folgenden Informationen aus der Konfiguration Ihres Authentifizierungsservers verfügen, damit Sie sie in die erforderlichen Felder des Assistenten zum Hinzufügen von Pods eingeben können.

Rufen Sie die folgenden aufgelisteten Informationen je nach ihrem Typ ab.

RADIUS

Wenn Sie Einstellungen sowohl für einen primären als auch für einen zusätzlichen RADIUS-Server konfigurieren, müssen Sie die Informationen für jeden dieser Server abrufen.

  • IP-Adresse oder DNS-Name des Authentifizierungsservers
  • Der gemeinsame geheime Schlüssel, der für die Ver- und Entschlüsselung der Protokollmeldungen des Authentifizierungsservers verwendet wird
  • Authentifizierungsportnummern, in der Regel 1812/UDP für RADIUS.
  • Art des Authentifizierungs-Protokolls. Zu den Authentifizierungstypen zählen PAP (Password Authentication Protocol), CHAP (Challenge Handshake Authentication Protocol), MSCHAP1, MSCHAP2 (Microsoft Challenge Handshake Authentication Protocol, Version 1 und 2).
    Hinweis: Prüfen Sie in der Dokumentation Ihres RADIUS-Anbieters, welches Authentifizierungsprotokoll der RADIUS-Anbieter empfiehlt, und verwenden Sie den angegebenen Protokolltyp. Die Pod-Funktionalität zur Unterstützung der Zwei-Faktor-Authentifizierung mit RADIUS wird von den Unified Access Gateway-Instanzen bereitgestellt. Unified Access Gateway unterstützt PAP, CHAP, MSCHAP1 und MSCHAP2. PAP ist in der Regel weniger sicher als MSCHAP2. PAP ist auch ein einfacheres Protokoll als MSCHAP2. Obwohl die meisten RADIUS-Anbieter mit dem einfacheren PAP-Protokoll kompatibel sind, bieten einige RADIUS-Anbieter daher weniger Kompatibilität mit dem sichereren MSCHAP2.
RSA SecurID
Hinweis: Der RSA SecurID-Typ wird von Horizon Cloud on Microsoft Azure-Bereitstellungen unterstützt, auf denen Manifest 3139.x oder höher ausgeführt wird. Die Benutzeroberflächenoption zur Angabe des RSA SecurID-Typs in den Assistenten „Pod hinzufügen“ und „Pod bearbeiten“ wird ab Mitte März 2022 in den Assistenten zur Auswahl angezeigt.
  • Zugriffsschlüssel vom RSA SecurID Authentication Manager-Server.
  • RSA SecurID-Kommunikationsportnummer. In der Regel 5555 wie in den RSA Authentication Manager-Systemeinstellungen für RSA SecurID-Authentifizierungs-API festgelegt.
  • Hostname des RSA SecurID-Authentifizierungsmanager-Servers.
  • IP-Adresse dieses RSA SecurID Authentication Manager-Servers.
  • Wenn der RSA SecurID Authentication Manager-Server oder dessen Lastausgleichsserver über ein selbstsigniertes Zertifikat verfügt, benötigen Sie das CA-Zertifikat, das im Assistenten „Pod hinzufügen“ bereitgestellt werden muss. Das Zertifikat muss im PEM-Format vorliegen (Dateitypen .cer oder .cert oder .pem)