Hinzufügen einer Gateway-Konfiguration zu einem bereitgestellten Horizon Cloud-Pod

Wenn Sie anfänglich einen Horizon Cloud-Pod in Microsoft Azure ohne Gateway oder mit nur einem Gateway-Typ bereitgestellt haben, können Sie dem Pod später mithilfe des Workflows „Pod bearbeiten“ eine Gateway-Konfiguration hinzufügen. Sie starten diesen Workflow über die Detailseite des Pods.

Tipp: Die Konsole ist dynamisch. In der Benutzerschnittstelle werden nur solche Workflows, Schalter und Felder angezeigt, die sinnvoll und entsprechend der aktuellen Konfiguration des Pods und der Konfiguration Ihrer Gesamtumgebung geeignet sind.

Wie unter Ihre Horizon Cloud on Microsoft Azure-Bereitstellungen beschrieben, kann ein Pod eine externe Gateway-Konfiguration, eine interne oder beide Typen besitzen. Mit diesem Workflow können Sie den Typ hinzufügen, den der Pod noch nicht besitzt. Zur gleichen Zeit, in der Sie den Pod zum Hinzufügen einer Gateway-Konfiguration bearbeiten, können Sie auch die Einstellungen für die 2-Faktor-Authentifizierung für dieses Gateway angeben.

Wichtig: Beim Ändern des Pods mithilfe dieser Schritte sollten Sie die folgenden Punkte beachten:

Beachten Sie, dass die IP-Einstellung für den Lastausgleich eines externen Gateways nicht geändert werden kann, nachdem die Konfiguration des externen Gateways einmal festgelegt wurde. Wenn Sie eine externe Gateway-Konfiguration hinzufügen, haben Sie die Möglichkeit, eine private IP-Adresse für den Lastausgleich des Gateways anstelle einer öffentlichen zu verwenden. Standardmäßig wird eine öffentliche IP-Adresse verwendet.
Wenn der Mandant für die Verwendung von Universal Broker konfiguriert ist und für die Broker-Einstellungen die Zwei-Faktor-Authentifizierung aktiviert ist, muss derselbe Zwei-Faktor-Authentifizierungstyp auf den externen Gateways aller Pods in der Flotte festgelegt werden.
Während der Zeit, in der das System die Pod-Konfiguration ändert, gelten die folgenden Einschränkungen, bis dieser Vorgang abgeschlossen ist:
- Sie können auf dem Pod keine Verwaltungsaufgaben durchführen.
- Endbenutzer, die keine Verbindung zu ihren Desktops oder Remoteanwendungen haben, die vom Pod bereitgestellt werden, und versuchen, eine Verbindung herzustellen, können dies nicht tun.
- Endbenutzer mit über den Pod verbundenen Sitzungen werden von ihren aktiven Sitzungen getrennt. Es tritt kein Datenverlust auf. Nachdem Sie die Änderungen an der Konfiguration ausgeführt haben, können sich diese Benutzer neu verbinden.

Voraussetzungen

Hinweis: Wenn für den Pod Hochverfügbarkeit aktiviert ist und eine der Pod-Manager-VMs offline ist, verhindert das System das Hinzufügen eines Gateways zum Pod. Die Meldung wird angezeigt, nachdem Sie auf Speichern und Beenden klicken. Sie müssen die inaktive Pod-Manager-VM mithilfe des Microsoft Azure-Portals wieder online bringen, bevor Sie das Gateway hinzufügen können.

Wenn Sie eine Gateway-Konfiguration zu einem vorhandenen Pod in Microsoft Azure hinzufügen, müssen Sie die in Voraussetzungen für die Unified Access Gateway-Konfigurationen beschriebenen Informationen eingeben, um die Felder im Assistenten „Pod bearbeiten“ zu vervollständigen. Wenn Sie das Gateway hinzufügen und gleichzeitig die Einstellungen für die Zwei-Faktor-Authentifizierung festlegen, müssen Sie die unter Voraussetzungen bei der Bereitstellung mit einer Konfiguration zur Zwei-Faktor-Authentifizierung beschriebenen Informationen angeben. Wenn Sie eine Konfiguration für ein externes Gateway hinzufügen und dieses ein eigenes Abonnement verwenden soll, benötigen Sie auch die Informationen dieses Abonnements. Außerdem müssen Sie sicherstellen, dass das VNet, das Sie für dieses Gateway verwenden wollen, das VNet-Anforderungen erfüllt. Informationen zu diesen VNet-Anforderungen finden Sie unter Konfigurieren des erforderlichen virtuellen Netzwerks in Microsoft Azure.

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.

Prozedur

Navigieren Sie in der Konsole zu Einstellungen > Kapazität und klicken Sie auf den Namen des Pods, um die zugehörige Detailseite zu öffnen.
Klicken Sie auf der Detailseite des Pods auf Bearbeiten.
Wenn Sie im Schritt „Abonnement“ eine Konfiguration für ein externes Gateway hinzufügen und dieses ein anderes Abonnement verwenden soll als der Pod, müssen Sie Anderes Abonnement für das externe Gateway verwenden aktivieren und die Abonnementinformationen eingeben.
Klicken Sie so oft auf Weiter, bis Sie zum Schritt Gateway-Einstellungen gelangen.
Dieser Schritt enthält einen Abschnitt für die Konfiguration des externen Gateways und einen Abschnitt für die Konfiguration des internen Gateways. Die Benutzeroberfläche gibt die aktuelle Konfiguration des Pods und die Gateway-Einstellungen wieder, über die er bereits verfügt.

Um ein externes Gateway hinzuzufügen, aktivieren Sie den Schalter Externes UAG aktivieren? und füllen Sie die Felder im Abschnitt Externes UAG aus.

Option	Beschreibung
Externes Gateway aktivieren?	Legt fest, ob der Pod über eine externe Gateway-Konfiguration verfügt. Die externe Konfiguration ermöglicht den Zugriff auf Desktops und Anwendungen für Benutzer, die sich außerhalb Ihres Unternehmensnetzwerks befinden. Der Pod enthält eine Microsoft Azure-Load Balancer-Ressource und Unified Access Gateway-Instanzen, um diesen Zugriff bereitzustellen. Hinweis: Es wird empfohlen, die standardmäßig aktivierte Einstellung nicht zu deaktivieren. Wenn diese Umschaltfläche deaktiviert ist, müssen sich die Clients entweder über Workspace ONE Access mit seiner Connector-Appliance direkt mit den Pod-Managern verbinden, oder die Clients verbinden sich direkt mit dem Lastausgleichsdienst der Pod-Manager, oder sie verbinden sich über eine interne Gateway-Konfiguration. In den ersten beiden genannten Szenarien, d. h. bei der Verbindung von Clients über Workspace ONE Access, das in den Pod integriert ist, oder bei der direkten Verbindung mit dem Lastausgleichsdienst, sind einige Schritte nach der Bereitstellung erforderlich. Laden Sie in diesen Szenarien nach der Bereitstellung des Pods SSL-Zertifikate auf die Pod Manager-VMs hoch, indem Sie die Schritte unter Konfigurieren von SSL-Zertifikaten direkt auf den Pod Manager-VMs ausführen.
FQDN	Geben Sie den erforderlichen vollqualifizierten Domänennamen (FQDN) ein, z. B. `ourOrg.example.com`, den der Pod-Bereitsteller in der Konfiguration für die Unified Access Gateway-Instanzen des Gateways angibt. Sie müssen der Eigentümer dieses Domänennamens sein und ein Zertifikat im PEM-Format besitzen, das diesen FQDN validieren kann. Horizon Cloud erwartet, dass dieser für die externe Gateway-Konfiguration angegebene FQDN öffentlich aufgelöst werden kann. Wenn Sie die Umschaltoption Öffentliche IP aktivieren? deaktivieren, um eine IP-Adresse aus Ihrer Firewall oder Ihrem NAT-Setup anzugeben, sind Sie dafür verantwortlich, dass dieser FQDN dieser IP-Adresse in Ihrer Firewall oder ihrem NAT-Setup zugewiesen ist. Dieser FQDN wird für PCoIP-Verbindungen zum Gateway verwendet. 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.
DNS-Adressen	Geben Sie optional durch Kommas getrennte Adressen für zusätzliche DNS-Server ein, die Unified Access Gateway für die Namensauflösung verwenden kann. Wenn Sie diese externe Unified Access Gateway-Konfiguration für die Verwendung der Zwei-Faktor-Authentifizierung mit einem Zwei-Faktor-Authentifizierungsserver konfigurieren, der sich außerhalb der VNet-Topologie befindet, in der die Unified Access Gateway-Instanzen bereitgestellt werden, geben Sie die Adresse eines DNS-Servers an, der den Hostnamen dieses Authentifizierungsservers auflösen kann. Beispiel: Wenn sich Ihre Zwei-Faktor-Authentifizierung lokal befindet, geben Sie einen DNS-Server ein, der den Namen dieses Authentifizierungsservers auflösen kann. Wie in den Bereitstellungsvoraussetzungen beschrieben, muss die VNet-Topologie, die für die Horizon Cloud on Microsoft Azure-Bereitstellung verwendet wird, in der Lage sein, mit Ihrem DNS-Server zu kommunizieren, der die externe Namensauflösung während der Bereitstellung der Unified Access Gateway-Instanzen und für deren laufenden Betrieb bereitstellen soll. Standardmäßig wird der DNS-Server verwendet, der in dem VNet konfiguriert ist, in dem die Instanzen bereitgestellt werden. Wenn Sie Adressen in DNS-Adressen angeben, verwenden die bereitgestellten Unified Access Gateway-Instanzen diese Adressen zusätzlich zu den DNS-Serverinformationen in der VNet-Konfiguration.
Routen	Geben Sie optional benutzerdefinierte Routen zu zusätzlichen Gateways an, die die bereitgestellten Unified Access Gateway-Instanzen für die Auflösung von Netzwerk-Routen für den Endbenutzerzugriff verwenden sollen. Die angegebenen Routen werden verwendet, damit Unified Access Gateway das Netzwerk-Routing auflösen kann, z. B. für die Kommunikation mit Servern für die Zwei-Faktor-Authentifizierung. Wenn Sie den Pod so konfigurieren, dass er eine Zwei-Faktor-Authentifizierung mit lokalem Authentifizierungsserver verwendet, müssen Sie die korrekte Route eingeben, über die die Unified Access Gateway-Instanzen diesen Server erreichen können. Beispiel: Wenn Ihr Authentifizierungsserver lokal 10.10.60.20 als IP-Adresse verwendet, würden Sie 10.10.60.0/24 und Ihre standardmäßige Route-Gateway-Adresse als benutzerdefinierte Route eingeben. Sie können Ihre standardmäßige Route-Gateway-Adresse über die Express-Route oder VPN-Konfiguration für diese Horizon Cloud on Microsoft Azure-Bereitstellung ermitteln. Geben Sie die benutzerdefinierten Routen als eine durch Kommas getrennte Liste in der Form `ipv4-network-address/bits ipv4-gateway-address` an, z. B.: `192.168.1.0/24 192.168.0.1, 192.168.2.0/24 192.168.0.2`.
NTP-Server des Pods erben	Diese Umschaltoption ist standardmäßig aktiviert, damit die Unified Access Gateway-Instanzen denselben NTP-Server verwenden, der für die Pod-Manager-Instanzen angegeben ist. Es wird dringend empfohlen, diese Umschaltoption aktiviert zu lassen. 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 diese Umschaltoption aktiviert ist und Sie das externe Gateway in einem eigenen, vom VNet des Pods getrennten VNet bereitstellen, stellen Sie sicher, dass die NTP-Server, die für die Pod-Manager-Instanzen angegeben sind, von dem virtuellen Netzwerk, das Sie für die Bereitstellung des externen Gateways auswählen, erreichbar sind.
VM-Modell	Wählen Sie das Modell aus, das für die Unified Access Gateway-Instanzen verwendet werden soll. Sie müssen sicherstellen, dass das von Ihnen für diesen Pod angegebene Microsoft Azure-Abonnement die Kapazität für zwei VMs des ausgewählten Modells bereitstellen kann. Wichtig: In der aktuellen Dienstversion kann das von diesen Instanzen verwendete VM-Modell nicht einfach geändert werden, nachdem die Gateway-Konfiguration in Ihrem Abonnement bereitgestellt wurde. Zum Ändern des VM-Modells nach der Bereitstellung muss die Gateway-Konfiguration gelöscht und erneut bereitgestellt werden. Wenn Sie erwarten, dass Ihre Umgebung auf 2.000 Sitzungen pro Pod skaliert werden soll, wählen Sie `F8s_v2` aus. Wie in Grenzwerte des VMware Horizon Cloud Service on Microsoft Azure-Diensts angegeben, reicht das `A4_v2`-VM-Modell nur für Proof-of-Concept (PoCs), Pilotumgebungen oder kleinere Umgebungen aus, in denen Sie wissen, dass Sie 1.000 aktive Sitzungen auf dem Pod nicht überschreiten werden.
Zertifikat	Laden Sie das Zertifikat im PEM-Format hoch, mit dem Unified Access Gateway den Clients die Herstellung vertrauenswürdiger Verbindungen mit Unified Access Gateway-Instanzen ermöglicht, die in Microsoft Azure ausgeführt werden. Das Zertifikat muss auf dem eingegebenen FQDN basieren und von einer vertrauenswürdigen Zertifizierungsstelle signiert sein. Die PEM-Datei muss die gesamte Zertifikatskette und den privaten Schlüssel enthalten: SSL-Zertifikat, Zwischenstellen-Zertifikate, Stamm-Zertifizierungsstellenzertifikat, privater Schlüssel.
Blast Extreme-TCP-Port	Wählen Sie den TCP-Port aus, der in der Blast Extreme TCP-Einstellung innerhalb der Unified Access Gateway-Konfiguration verwendet werden soll. Diese Einstellung bezieht sich auf Blast Extreme über Blast Secure Gateway auf Unified Access Gateway für den vom Client gesendeten Datenverkehr. Port 8443 wird bevorzugt, da er effizienter ist, eine bessere Leistung bietet und weniger Ressourcen auf den Unified Access Gateway-Instanzen verwendet. Aus diesen Gründen hat der Assistent 8443 als Standardwert festgelegt. Die Alternative, 443, ist weniger effizient, weniger leistungsfähig und verursacht eine CPU-Belastung in den Instanzen, was bei den Endbenutzer-Clients zu spürbaren Verzögerungen beim Datenverkehr führen kann. Der Wert 443 sollte nur verwendet werden, wenn Ihre Organisation clientseitige Einschränkungen festgelegt hat, z. B. wenn Ihre Organisation nur 443 für ausgehende Verbindungen zulässt. Hinweis: Der für Blast Extreme verwendete UDP-Port ist von dieser Einstellung nicht betroffen und ist immer UDP 8443.
Verschlüsselungs-Suites	Obwohl die Standardeinstellungen in fast allen Fällen nicht geändert werden müssen, bietet Unified Access Gateway diese Funktion zur optionalen Angabe der kryptografischen Algorithmen, die zum Verschlüsseln der Kommunikation zwischen Clients und den Unified Access Gateway-Appliances verwendet werden. Mindestens eine Verschlüsselungs-Suite muss aus der Liste auf dem Bildschirm ausgewählt werden. Die Liste auf dem Bildschirm zeigt die Verschlüsselungs-Suites an, die für die Horizon Cloud on Microsoft Azure-Bereitstellung zulässig sind.

Geben Sie die Einstellungen für den Microsoft-Lastausgleichsdienst dieses Gateways an.

Option	Beschreibung
Öffentliche IP aktivieren?	Legt fest, ob der Load Balancing-Typ dieses Gateways als „Privat“ oder „öffentlich“ konfiguriert ist. Wenn diese Option aktiviert ist, wird die bereitgestellte Microsoft Azure-Lastausgleichsressource mit einer öffentlichen IP-Adresse konfiguriert. Wenn sie deaktiviert ist, wird die Microsoft Azure-Lastausgleichsressource mit einer privaten IP-Adresse konfiguriert. Wichtig: In dieser Version können Sie den Load Balancing-Typ des externen Gateways später nicht von „Öffentlich“ zu „Privat“ oder von „Privat“ zu „Öffentlich“ ändern. Die einzige Möglichkeit, diese Änderung vorzunehmen, besteht darin, die Gateway-Konfiguration vollständig aus dem bereitgestellten Pod zu löschen und dann den Pod zu bearbeiten, um ihn mit der entgegengesetzten Einstellung wieder hinzuzufügen. Wenn Sie diese Umschaltoption deaktivieren, wird das Feld Öffentliche IP für Horizon-FQDN angezeigt.
Öffentliche IP für Horizon-FQDN	Wenn Sie den bereitgestellten Microsoft Azure-Lastausgleichsdienst nicht mit einer öffentlichen IP konfigurieren möchten, müssen Sie die IP-Adresse angeben, der Sie dem FQDN zuweisen, den Sie im Feld FQDN angegeben haben. Die Horizon-Clients Ihrer Endbenutzer verwenden diesen FQDN für PCoIP-Verbindungen zum Gateway. Der Bereitsteller konfiguriert diese IP-Adresse in den Unified Access Gateway-Konfigurationseinstellungen.

Option

Beschreibung

Öffentliche IP aktivieren?

Legt fest, ob der Load Balancing-Typ dieses Gateways als „Privat“ oder „öffentlich“ konfiguriert ist. Wenn diese Option aktiviert ist, wird die bereitgestellte Microsoft Azure-Lastausgleichsressource mit einer öffentlichen IP-Adresse konfiguriert. Wenn sie deaktiviert ist, wird die Microsoft Azure-Lastausgleichsressource mit einer privaten IP-Adresse konfiguriert.

Wichtig: In dieser Version können Sie den Load Balancing-Typ des externen Gateways später nicht von „Öffentlich“ zu „Privat“ oder von „Privat“ zu „Öffentlich“ ändern. Die einzige Möglichkeit, diese Änderung vorzunehmen, besteht darin, die Gateway-Konfiguration vollständig aus dem bereitgestellten Pod zu löschen und dann den Pod zu bearbeiten, um ihn mit der entgegengesetzten Einstellung wieder hinzuzufügen.

Wenn Sie diese Umschaltoption deaktivieren, wird das Feld Öffentliche IP für Horizon-FQDN angezeigt.

Öffentliche IP für Horizon-FQDN

Wenn Sie den bereitgestellten Microsoft Azure-Lastausgleichsdienst nicht mit einer öffentlichen IP konfigurieren möchten, müssen Sie die IP-Adresse angeben, der Sie dem FQDN zuweisen, den Sie im Feld FQDN angegeben haben. Die Horizon-Clients Ihrer Endbenutzer verwenden diesen FQDN für PCoIP-Verbindungen zum Gateway. Der Bereitsteller konfiguriert diese IP-Adresse in den Unified Access Gateway-Konfigurationseinstellungen.

Geben Sie die Netzwerkeinstellungen des externen Gateways an.

Option	Beschreibung
Anderes virtuelles Netzwerk verwenden	Dieser Schalter steuert, ob das externe Gateway in seinem eigenen, vom VNet des Pods getrennten VNet bereitgestellt wird. In den folgenden Zeilen werden die unterschiedlichen Szenarien beschrieben. Hinweis: Wenn Sie im ersten Schritt des Assistenten angegeben haben, dass ein anderes Abonnement für das externe Gateway verwendet werden soll, ist dieser Schalter standardmäßig aktiviert. Sie müssen in diesem Fall ein VNet für das Gateway auswählen. Wenn diese Umschaltoption aktiviert ist und die Umschaltoption NTP-Server des Pods erben aktiviert ist, stellen Sie sicher, dass die NTP-Server, die für die Pod-Manager-Instanzen angegeben sind, von dem virtuellen Netzwerk aus erreichbar sind, das Sie für die Bereitstellung des externen Gateways auswählen.
Anderes virtuelles Netzwerk verwenden – deaktiviert	Wenn die Umschaltoption deaktiviert ist, wird das externe Gateway im VNet des Pods bereitgestellt. In diesem Fall müssen Sie das DMZ-Subnetz angeben. DMZ-Subnetz – Wenn im Schritt des Assistenten für die Pod-Einrichtung Vorhandenes Subnetz verwenden aktiviert wird, werden unter DMZ-Subnetz die Subnetze aufgeführt, die auf dem für das Virtuelle Netzwerk ausgewählten VNet verfügbar sind. Wählen Sie das vorhandene Subnetz aus, das Sie als DMZ-Subnetz des Pods verwenden möchten. Wichtig: Wählen Sie ein leeres Subnetz aus, mit dem keine anderen Ressourcen verknüpft sind. Wenn das Subnetz nicht leer ist, können unerwartete Ergebnisse während des Bereitstellungsvorgangs oder während Pod-Vorgängen auftreten. DMZ-Subnetz (CIDR) – Wenn Vorhandenes Subnetz verwenden im vorherigen Schritt des Assistenten deaktiviert wurde, geben Sie das Subnetz (in CIDR-Notation) für das DMZ-Netzwerk (entmilitarisierte Zone) ein, das konfiguriert wird, um die Unified Access Gateway-Instanzen mit dem öffentlichen Microsoft Azure-Lastausgleichsdienst des Gateways zu verbinden.
Anderes virtuelles Netzwerk verwenden – aktiviert	Wenn der Schalter aktiviert ist, wird das externe Gateway in seinem eigenen VNet bereitgestellt. In diesem Fall müssen Sie das zu verwendende VNet auswählen und dann die drei erforderlichen Subnetze angeben. Aktivieren Sie den Schalter Vorhandenes Subnetz verwenden, um aus Subnetzen auszuwählen, die Sie im Voraus auf dem angegebenen VNet erstellt haben. Geben Sie andernfalls die Subnetze in CIDR-Notation an. Wichtig: Wählen Sie leere Subnetze aus, mit denen keine anderen Ressourcen verknüpft sind. Wenn die Subnetze nicht leer sind, können unerwartete Ergebnisse während des Bereitstellungsvorgangs oder während Pod-Vorgängen auftreten. In diesem Fall werden das VNet des Gateways und das VNet des Pods als Peers miteinander verbunden. Es wird empfohlen, die Subnetze im Voraus zu erstellen und die CIDR-Einträge hier nicht zu verwenden. Siehe 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. Verwaltungssubnetz – Geben Sie das Subnetz an, das für das Verwaltungssubnetz des Gateways verwendet werden soll. Ein CIDR von mindestens /27 ist erforderlich. Dieses Subnetz muss über den Microsoft.SQL-Dienst verfügen, der als Dienst-Endpoint konfiguriert ist. Back-End-Subnetz – Geben Sie das Subnetz an, das für das Back-End-Subnetz des Gateways verwendet werden soll. Ein CIDR von mindestens /27 ist erforderlich. Front-End-Subnetz – Geben Sie das Subnetz an, das für die Herstellung der Verbindung der Unified Access Gateway-Instanzen zum öffentlichen Microsoft Azure-Lastausgleichsdienst des Gateways konfiguriert werden soll.

Option

Beschreibung

Anderes virtuelles Netzwerk verwenden

Dieser Schalter steuert, ob das externe Gateway in seinem eigenen, vom VNet des Pods getrennten VNet bereitgestellt wird.

In den folgenden Zeilen werden die unterschiedlichen Szenarien beschrieben.

Hinweis: Wenn Sie im ersten Schritt des Assistenten angegeben haben, dass ein anderes Abonnement für das externe Gateway verwendet werden soll, ist dieser Schalter standardmäßig aktiviert. Sie müssen in diesem Fall ein VNet für das Gateway auswählen.

Wenn diese Umschaltoption aktiviert ist und die Umschaltoption NTP-Server des Pods erben aktiviert ist, stellen Sie sicher, dass die NTP-Server, die für die Pod-Manager-Instanzen angegeben sind, von dem virtuellen Netzwerk aus erreichbar sind, das Sie für die Bereitstellung des externen Gateways auswählen.

Anderes virtuelles Netzwerk verwenden – deaktiviert

Wenn die Umschaltoption deaktiviert ist, wird das externe Gateway im VNet des Pods bereitgestellt. In diesem Fall müssen Sie das DMZ-Subnetz angeben.

DMZ-Subnetz – Wenn im Schritt des Assistenten für die Pod-Einrichtung Vorhandenes Subnetz verwenden aktiviert wird, werden unter DMZ-Subnetz die Subnetze aufgeführt, die auf dem für das Virtuelle Netzwerk ausgewählten VNet verfügbar sind. Wählen Sie das vorhandene Subnetz aus, das Sie als DMZ-Subnetz des Pods verwenden möchten.
Wichtig: Wählen Sie ein leeres Subnetz aus, mit dem keine anderen Ressourcen verknüpft sind. Wenn das Subnetz nicht leer ist, können unerwartete Ergebnisse während des Bereitstellungsvorgangs oder während Pod-Vorgängen auftreten.
DMZ-Subnetz (CIDR) – Wenn Vorhandenes Subnetz verwenden im vorherigen Schritt des Assistenten deaktiviert wurde, geben Sie das Subnetz (in CIDR-Notation) für das DMZ-Netzwerk (entmilitarisierte Zone) ein, das konfiguriert wird, um die Unified Access Gateway-Instanzen mit dem öffentlichen Microsoft Azure-Lastausgleichsdienst des Gateways zu verbinden.

Anderes virtuelles Netzwerk verwenden – aktiviert

Wenn der Schalter aktiviert ist, wird das externe Gateway in seinem eigenen VNet bereitgestellt. In diesem Fall müssen Sie das zu verwendende VNet auswählen und dann die drei erforderlichen Subnetze angeben. Aktivieren Sie den Schalter Vorhandenes Subnetz verwenden, um aus Subnetzen auszuwählen, die Sie im Voraus auf dem angegebenen VNet erstellt haben. Geben Sie andernfalls die Subnetze in CIDR-Notation an.

Wichtig: Wählen Sie leere Subnetze aus, mit denen keine anderen Ressourcen verknüpft sind. Wenn die Subnetze nicht leer sind, können unerwartete Ergebnisse während des Bereitstellungsvorgangs oder während Pod-Vorgängen auftreten.

In diesem Fall werden das VNet des Gateways und das VNet des Pods als Peers miteinander verbunden. Es wird empfohlen, die Subnetze im Voraus zu erstellen und die CIDR-Einträge hier nicht zu verwenden. Siehe 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.

Verwaltungssubnetz – Geben Sie das Subnetz an, das für das Verwaltungssubnetz des Gateways verwendet werden soll. Ein CIDR von mindestens /27 ist erforderlich. Dieses Subnetz muss über den Microsoft.SQL-Dienst verfügen, der als Dienst-Endpoint konfiguriert ist.
Back-End-Subnetz – Geben Sie das Subnetz an, das für das Back-End-Subnetz des Gateways verwendet werden soll. Ein CIDR von mindestens /27 ist erforderlich.
Front-End-Subnetz – Geben Sie das Subnetz an, das für die Herstellung der Verbindung der Unified Access Gateway-Instanzen zum öffentlichen Microsoft Azure-Lastausgleichsdienst des Gateways konfiguriert werden soll.

(Optional) Verwenden Sie im Abschnitt Bereitstellung den Schalter, um optional eine vorhandene Ressourcengruppe auszuwählen, in der der Bereitsteller die Ressourcen für die externe Gateway-Konfiguration bereitstellen soll.
Dieser Schalter wird angezeigt, wenn Sie im ersten Schritt des Assistenten angegeben haben, dass ein anderes Abonnement für das externe Gateway verwendet werden soll. Wenn Sie den Schalter aktivieren, wird ein Feld angezeigt, in dem Sie nach der Ressourcengruppe suchen und diese auswählen können.

Um ein internes Gateway hinzuzufügen, aktivieren Sie den Schalter Internes UAG aktivieren? und füllen Sie die Felder im Abschnitt Internes UAG aus.

Option	Beschreibung
Internes Gateway aktivieren?	Legt fest, ob der Pod über eine interne Gateway-Konfiguration verfügt. Die interne Konfiguration bietet vertrauenswürdigen Zugriff auf Desktops und Anwendungen für HTML Access-(Blast-)Verbindungen für Benutzer außerhalb Ihres Unternehmensnetzwerks. Der Pod enthält eine Azure-Lastausgleich-Ressource und Unified Access Gateway-Instanzen, um diesen Zugriff bereitzustellen. Standardmäßig ist der Lastausgleich-Typ dieses Gateways privat. Der Lastausgleich ist mit einer privaten IP-Adresse konfiguriert.
FQDN	Geben Sie den erforderlichen vollqualifizierten Domänennamen (FQDN) ein, wie z. B. `ourOrg.example.com`, über den die Endbenutzer auf den Dienst zugreifen. Sie müssen der Eigentümer dieses Domänennamens sein und ein Zertifikat im PEM-Format besitzen, das diesen FQDN validieren kann. 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.
DNS-Adressen	Geben Sie optional durch Kommas getrennte Adressen für zusätzliche DNS-Server ein, die Unified Access Gateway für die Namensauflösung verwenden kann. Wenn Sie diese interne Unified Access Gateway-Konfiguration für die Verwendung der Zwei-Faktor-Authentifizierung mit einem Zwei-Faktor-Authentifizierungsserver konfigurieren, der sich außerhalb der VNet-Topologie befindet, in der die Unified Access Gateway-Instanzen bereitgestellt werden, geben Sie die Adresse eines DNS-Servers an, der den Hostnamen dieses Authentifizierungsservers auflösen kann. Beispiel: Wenn sich Ihre Zwei-Faktor-Authentifizierung lokal befindet, geben Sie einen DNS-Server ein, der den Namen dieses Authentifizierungsservers auflösen kann. Wie in den Bereitstellungsvoraussetzungen beschrieben, muss die VNet-Topologie, die für die Horizon Cloud on Microsoft Azure-Bereitstellung verwendet wird, in der Lage sein, mit Ihrem DNS-Server zu kommunizieren, der die externe Namensauflösung während der Bereitstellung der Unified Access Gateway-Instanzen und für deren laufenden Betrieb bereitstellen soll. Standardmäßig wird der DNS-Server verwendet, der in dem VNet konfiguriert ist, in dem die Instanzen bereitgestellt werden. Wenn Sie Adressen in DNS-Adressen angeben, verwenden die bereitgestellten Unified Access Gateway-Instanzen diese Adressen zusätzlich zu den DNS-Serverinformationen in der VNet-Konfiguration.
Routen	Geben Sie optional benutzerdefinierte Routen zu zusätzlichen Gateways an, die die bereitgestellten Unified Access Gateway-Instanzen für die Auflösung von Netzwerk-Routen für den Endbenutzerzugriff verwenden sollen. Die angegebenen Routen werden verwendet, damit Unified Access Gateway das Netzwerk-Routing auflösen kann, z. B. für die Kommunikation mit Servern für die Zwei-Faktor-Authentifizierung. Wenn Sie den Pod so konfigurieren, dass er eine Zwei-Faktor-Authentifizierung mit lokalem Authentifizierungsserver verwendet, müssen Sie die korrekte Route eingeben, über die die Unified Access Gateway-Instanzen diesen Server erreichen können. Beispiel: Wenn Ihr Authentifizierungsserver lokal 10.10.60.20 als IP-Adresse verwendet, würden Sie 10.10.60.0/24 und Ihre standardmäßige Route-Gateway-Adresse als benutzerdefinierte Route eingeben. Sie können Ihre standardmäßige Route-Gateway-Adresse über die Express-Route oder VPN-Konfiguration für diese Umgebung ermitteln. Geben Sie die benutzerdefinierten Routen als eine durch Kommas getrennte Liste in der Form `ipv4-network-address/bits ipv4-gateway-address` an, z. B.: `192.168.1.0/24 192.168.0.1, 192.168.2.0/24 192.168.0.2`.
NTP-Server des Pods erben	Diese Umschaltoption ist standardmäßig aktiviert, damit die Unified Access Gateway-Instanzen denselben NTP-Server verwenden, der für die Pod-Manager-Instanzen angegeben ist. Es wird dringend empfohlen, diese Umschaltoption aktiviert zu lassen. 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.
VM-Modell	Wählen Sie das Modell aus, das für die Unified Access Gateway-Instanzen verwendet werden soll. Sie müssen sicherstellen, dass das von Ihnen für diesen Pod angegebene Microsoft Azure-Abonnement die Kapazität für zwei VMs des ausgewählten Modells bereitstellen kann. Wichtig: In der aktuellen Dienstversion kann das von diesen Instanzen verwendete VM-Modell nicht einfach geändert werden, nachdem die Gateway-Konfiguration in Ihrem Abonnement bereitgestellt wurde. Zum Ändern des VM-Modells nach der Bereitstellung muss die Gateway-Konfiguration gelöscht und erneut bereitgestellt werden. Wenn Sie erwarten, dass Ihre Umgebung auf 2.000 Sitzungen pro Pod skaliert werden soll, wählen Sie `F8s_v2` aus. Wie in Grenzwerte des VMware Horizon Cloud Service on Microsoft Azure-Diensts angegeben, reicht das `A4_v2`-VM-Modell nur für Proof-of-Concept (PoCs), Pilotumgebungen oder kleinere Umgebungen aus, in denen Sie wissen, dass Sie 1.000 aktive Sitzungen auf dem Pod nicht überschreiten werden.
Zertifikat	Laden Sie das Zertifikat im PEM-Format hoch, mit dem Unified Access Gateway den Clients die Herstellung vertrauenswürdiger Verbindungen mit Unified Access Gateway-Instanzen ermöglicht, die in Microsoft Azure ausgeführt werden. Das Zertifikat muss auf dem eingegebenen FQDN basieren und von einer vertrauenswürdigen Zertifizierungsstelle signiert sein. Die PEM-Datei muss die gesamte Zertifikatskette und den privaten Schlüssel enthalten: SSL-Zertifikat, Zwischenstellen-Zertifikate, Stamm-Zertifizierungsstellenzertifikat, privater Schlüssel.
Blast Extreme-TCP-Port	Wählen Sie den TCP-Port aus, der in der Blast Extreme TCP-Einstellung innerhalb der Unified Access Gateway-Konfiguration verwendet werden soll. Diese Einstellung bezieht sich auf Blast Extreme über Blast Secure Gateway auf Unified Access Gateway für den vom Client gesendeten Datenverkehr. Port 8443 wird bevorzugt, da er effizienter ist, eine bessere Leistung bietet und weniger Ressourcen auf den Unified Access Gateway-Instanzen verwendet. Aus diesen Gründen hat der Assistent 8443 als Standardwert festgelegt. Die Alternative, 443, ist weniger effizient, weniger leistungsfähig und verursacht eine CPU-Belastung in den Instanzen, was bei den Endbenutzer-Clients zu spürbaren Verzögerungen beim Datenverkehr führen kann. Der Wert 443 sollte nur verwendet werden, wenn Ihre Organisation clientseitige Einschränkungen festgelegt hat, z. B. wenn Ihre Organisation nur 443 für ausgehende Verbindungen zulässt. Hinweis: Der für Blast Extreme verwendete UDP-Port ist von dieser Einstellung nicht betroffen und ist immer UDP 8443.
Verschlüsselungs-Suites	Obwohl in fast allen Fällen die Standardeinstellungen ausreichen, bietet Unified Access Gateway diese Funktion zur Angabe der kryptografischen Algorithmen, die zum Verschlüsseln der Kommunikation zwischen Clients und den Unified Access Gateway-Appliances verwendet werden. Mindestens eine Verschlüsselungs-Suite muss aus der Liste auf dem Bildschirm ausgewählt werden. Die Liste auf dem Bildschirm zeigt die Verschlüsselungs-Suites an, die für die Horizon Cloud on Microsoft Azure-Bereitstellung zulässig sind.

Wenn Sie im Abschnitt für das Gateway, das Sie hinzufügen, optional die Desktops der Endbenutzer für die Verwendung der Zwei-Faktor-Authentifizierung konfigurieren möchten, befolgen Sie die Schritte unter Aktivieren der 2-Faktor-Authentifizierung auf den Gateways eines Horizon Cloud-Pods.
Wenn Sie im Abschnitt Azure Resource-Tags Ressourcen-Tags für die Gateway-bezogenen Ressourcengruppen angeben möchten, die sich von denen unterscheiden, die für die anderen Ressourcengruppen des Pods angegeben wurden, deaktivieren Sie die Umschaltoption Pod-Tags erben und geben Sie die Tags in den angezeigten Feldern an.
Eine Beschreibung der Felder Azure Resource-Tags finden Sie unter First-Gen-Mandanten – Angeben der Gateway-Konfiguration des Horizon Cloud-Pods. Auf dem Pod wird für beide Gateway-Typen derselbe Tag-Satz verwendet.
Klicken Sie auf Speichern und Beenden.
Es erscheint eine Bestätigungsmeldung, in der Sie aufgefordert werden, den Start des Workflows zu bestätigen.
Klicken Sie auf Ja, um den Workflow starten.

Ergebnisse

Bis zum Abschluss der Bereitstellung der Elemente für das Gateway wird auf der Zusammenfassungsseite des Pods im Abschnitt für den Konfigurationstyp der Status Ausstehend angezeigt. Sie können auch keine zusätzlichen workflowbezogenen Aktivitäten im Zusammenhang mit der Pod-Bearbeitung durchführen, bevor das System seine Aktionen zum Bereitstellen des Gateways abgeschlossen hat.

Sobald der Workflow abgeschlossen ist, werden der Status Bereit und der Lastausgleich-FQDN auf der Seite angezeigt.

Hinweis: Wenn dieser Workflow für einen Pod in Microsoft Azure China ausgeführt wird, kann der Prozess länger als eine Stunde dauern. Der Prozess unterliegt geografischen Netzwerkproblemen, die langsame Download-Geschwindigkeiten verursachen können, wenn die Binärdateien aus der Cloud-Steuerungsebene heruntergeladen werden.

Nächste Maßnahme

Wichtig: Bevor Ihre Endbenutzer das neu hinzugefügte Gateway verwenden können, müssen Sie die folgenden Aufgaben ausführen.

Stellen Sie für die neu hinzugefügte Gateway-Konfiguration sicher, dass in Ihrem DNS-Server ein CNAME-Eintrag vorhanden ist, der den von der Konfiguration bereitgestellten Lastausgleich dem vollqualifizierten Domänennamen (FQDN) zuordnet, den Sie im Bereitstellungsassistenten angegeben haben. Weitere Informationen dazu finden Sie unter So rufen Sie die Lastausgleich-Informationen des Horizon Cloud-Pod-Gateways für die Zuordnung im DNS-Server ab.
Wenn Sie die Zwei-Faktor-Authentifizierung für das hinzugefügte Gateway angegeben haben, müssen Sie diese Aufgaben ausführen:
- Wenn das externe Gateway des Pods eine Zwei-Faktor-Authentifizierung konfiguriert hat und der Zwei-Faktor-Authentifizierungsserver nicht innerhalb derselben VNet-Topologie erreichbar ist, in der die Unified Access Gateway-Instanzen des Gateways bereitgestellt werden, konfigurieren Sie diesen Zwei-Faktor-Authentifizierungsserver so, dass er die Kommunikation von der IP-Adresse des Lastausgleichsdiensts des externen Gateways zulässt.
  In diesem Szenario, in dem der Zwei-Faktor-Authentifizierungsserver innerhalb derselben VNet-Topologie wie die Gateway-Bereitstellung nicht erreichbar ist, versuchen die Unified Access Gateway-Instanzen, mithilfe dieser Lastausgleichsadresse Kontakt mit diesem Server herzustellen. Um diesen Kommunikationsdatenverkehr zuzulassen, stellen Sie sicher, dass die IP-Adresse der Lastausgleichsdienstressource, die sich in der Ressourcengruppe des externen Gateways befindet, in der Konfiguration des Zwei-Faktor-Authentifizierungsservers als ein Client oder als registrierter Agent angegeben ist. Informationen zum Zulassen dieser Kommunikation finden Sie in der Dokumentation Ihres Zwei-Faktor-Authentifizierungsservers.
- Wenn Ihr Zwei-Faktor-Authentifizierungsserver innerhalb derselben VNet-Topologie erreichbar ist, konfigurieren Sie den Zwei-Faktor-Authentifizierungsserver so, dass er die Kommunikation von den entsprechenden Netzwerkkarten zulässt, die für die Unified Access Gateway-Instanzen der Bereitstellung in Microsoft Azure erstellt wurden.
  Ihr Netzwerkadministrator bestimmt die Netzwerksichtbarkeit des Zwei-Faktor-Authentifizierungsservers für die Azure-VNet-Topologie und die für die Bereitstellung verwendeten Subnetze. Der Zwei-Faktoren-Authentifizierungsserver muss die Kommunikation von den IP-Adressen der Netzwerkkarten der Unified Access Gateway-Instanzen zulassen, die dem Teilnetz entsprechen, für das Ihr Netzwerkadministrator dem Zwei-Faktoren-Authentifizierungsserver Netzwerksichtbarkeit gewährt hat.
  Die Ressourcengruppe des Gateways in Microsoft Azure hat vier Netzwerkkarten, die diesem Subnetz entsprechen, zwei, die derzeit für die beiden Unified Access Gateway-Instanzen aktiv sind, und zwei, die im Leerlauf sind und zu aktiven Netzwerkkarten werden, nachdem der Pod und seine Gateways eine Aktualisierung durchlaufen haben.
  Um den Kommunikationsdatenverkehr zwischen dem Gateway und dem Zwei-Faktor-Authentifizierungsserver sowohl für laufende Pod-Vorgänge als auch nach jeder Pod-Aktualisierung zu unterstützen, stellen Sie sicher, dass die IP-Adressen dieser vier Netzwerkkarten in der Konfiguration des Servers als Clients oder als registrierte Agenten angegeben sind. Informationen zum Zulassen dieser Kommunikation finden Sie in der Dokumentation Ihres Zwei-Faktor-Authentifizierungsservers.
Informationen zum Abrufen dieser IP-Adressen finden Sie unter Aktualisieren Ihres Zwei-Faktor-Authentifizierungssystems mit den erforderlichen Horizon Cloud-Pod-Gateway-Informationen.