Bevor Sie den 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: 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.

Voraussetzungen für alle Bereitstellungen

  • Wenn Sie einen weiteren Pod hinzufügen, können Sie dasselbe Abonnement verwenden, das Sie für die vorherigen Pods verwendet haben. Alternativ können Sie ein anderes Abonnement verwenden, wenn dies in Ihrer Organisation erforderlich ist. Bei Verwendung eines anderen Abonnements müssen Sie die im Bereitstellungshandbuch beschriebenen Schritte durchführen, um die Abonnement-ID, Verzeichnis-ID und Anwendungs-ID sowie den Anwendungsschlüssel abzurufen. Sie müssen sicherstellen, dass das von Ihnen verwendete Abonnement die in diesem Handbuch beschriebenen Anforderungen erfüllt, insbesondere, dass der Dienstprinzipal über die entsprechenden Rollenberechtigungen verfügt, die auf den relevanten Ebenen in Ihrem Abonnement gewährt werden. Sie können zum Dokument für die ersten Schritte navigieren, das online auf der Horizon Cloud-Dokumentationsseite verfügbar ist.
  • Wenn Ihr Mandant so konfiguriert ist, dass er Universal Broker für Ihre Pods in Microsoft Azure verwendet, müssen Sie bei der Ausführung des Bereitstellungsassistenten für einen neuen Pod eine Site angeben. Sie können entweder eine vorhandene Site auswählen oder eine neue Site angeben.
  • Stellen Sie sicher, dass in der Region, in der Sie den Pod bereitstellen möchten, ein VNet vorhanden ist, das die unter Konfigurieren des erforderlichen virtuellen Netzwerks in Microsoft Azure beschriebenen Anforderungen erfüllt.
    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, 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 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 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.
  • Stellen Sie sicher, dass Sie die Informationen für mindestens einen NTP-Server besitzen, den der Pod für die Uhrzeitsynchronisierung verwenden soll. Bei diesem NTP-Server kann es sich um einen öffentlichen NTP-Server oder Ihren eigenen NTP-Server handeln. Der von Ihnen angegebene NTP-Server muss aus dem konfigurierten virtuellen Netzwerk erreichbar sein. 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.
  • 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 Erstellen Sie im Vorfeld der Pod-Bereitstellung die erforderlichen Subnetze des Horizon Cloud-Pods auf Ihrem VNet in Microsoft Azure. und Bei der 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.
    Wichtig: Wenn Sie nach Ihrem ersten Pod weitere Pods bereitstellen, können Sie ein vorhandenes Subnetz, das bereits von einem vorhandenen Pod verwendet wird, nicht erneut verwenden.
  • 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. Ab dem mit der vierteljährlichen Dienstversion vom Juli 2020 verfügbaren neuen Pod-Manifest, müssen Sie bei der Bereitstellung der beiden Gateway-Konfigurationen auf einem Pod für beide Gateway-Konfigurationen denselben FQDN angeben. Nachdem der Pod sowohl mit der Konfiguration des internen und des externen Gateways bereitgestellt wurde, müssen Sie den eingehenden Datenverkehr der Endbenutzer-Clients dahingehend konfigurieren, dass er zum entsprechenden Lastenausgleichsdienst 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. Da 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 Erstellen Sie im Vorfeld der Pod-Bereitstellung die erforderlichen Subnetze des Horizon Cloud-Pods auf 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 eine Konfiguration mit externem Unified Access Gateway bereitstellen und die Verwendung einer öffentlichen IP-Adresse für den Lastausgleichsdienst der Konfiguration verhindern möchten, müssen Sie eine IP-Adresse angeben, die Sie in Ihren DNS-Einstellungen dem FQDN zugeordnet haben, den die 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 Konvertieren einer Zertifikatdatei in das für die Pod-Bereitstellung erforderliche PEM-Format.

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

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, stellen Sie sicher, dass Sie über die folgenden bei der Konfiguration Ihres Authentifizierungsservers verwendeten Informationen verfügen, damit Sie diese in den entsprechenden Feldern im Assistenten zur Pod-Bereitstellung angeben können. Wenn Sie über einen primären und einen sekundären Server verfügen, ermitteln Sie die Informationen für beide Server.

  • 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
  • Nummer des Authentifizierungsports, in der Regel der UDP-Port 1812.
  • 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.