In diesem Artikel werden die Anforderungen beschrieben, die Ihre Horizon Cloud-Mandantenumgebung erfüllen muss, bevor Sie den Übergang von Einzel-Pod-Broker zu Universal Broker planen und durchführen können. Es enthält auch Anleitungen zu den Planungs- und Vorbereitungsschritten für die Unterstützung des neuen Verbindungs-FQDN für Universal Broker.

Um den Übergangsprozess und den laufenden Betrieb der von Universal Broker vermittelten Multi-Cloud-Zuweisungen nach dem Übergang zu unterstützen, stellen Sie sicher, dass Ihre Mandantenumgebung die folgenden Anforderungen erfüllt.

Anforderungen für Horizon Cloud-Pods (Pods in nativem Microsoft Azure)

Stellen Sie sicher, dass Ihre in der nativen Microsoft Azure-Cloud bereitgestellten Pods (auch als Horizon Cloud-Pods bezeichnet) die folgenden Anforderungen erfüllen.

  • Mindestens ein Horizon Cloud-Pod wird für Ihre Mandantenumgebung bereitgestellt.
  • Alle Pods werden mit Pod-Manifest 2298.0 oder höher ausgeführt. Die folgenden Anforderungen gelten auch für bestimmte Anwendungsfälle.
    • Wenn Sie eine bestehende Integration zwischen Ihrem Horizon Cloud-Mandanten und Workspace ONE Access haben, müssen alle Ihre Pods mit Manifest 2474.0 oder höher ausgeführt werden. Nach Abschluss des Broker-Übergangs müssen Sie die Integration aktualisieren, um die Verwendung von Universal Broker zu ermöglichen, wie unter Horizon Cloud-Umgebung mit Universal Broker – Integrieren des Mandanten in Workspace ONE Access und Intelligent Hub-Dienste beschrieben.
    • Wenn Sie die Funktion zur Aufgabenstornierung oder die Löschschutzfunktion nach dem Broker-Übergang verwenden möchten, müssen alle Ihre Pods mit Manifest 2474.0 oder höher ausgeführt werden. Diese Funktionen werden nicht unterstützt, wenn Ihre Pods mit einer früheren Version als Manifest 2474.0 ausgeführt werden.
    Wichtig: Stellen Sie sicher, dass alle Ihre Pods in Microsoft Azure online sind und sich in einem ordnungsgemäßen, einsatzbereiten Zustand befinden. Der Universal Broker-Dienst muss mit den Pods kommunizieren und einige Konfigurationsschritte auf den Pods ausführen, um den Einrichtungsvorgang abzuschließen. Wenn einer der Pods offline oder nicht verfügbar ist, können Sie den Übergang nicht planen. Wenn Sie den Übergang planen, aber einer Ihrer Pods später offline geht oder nicht mehr verfügbar ist, während der Übergang läuft, schlägt die Einrichtung von Universal Broker fehl.
  • Es sind keine Pod-Upgrades geplant, die zeitgleich mit dem Übergang stattfinden.
  • Der Pod-Speicherort wird durch Auswahl eines gültigen Speicherorts aus den Menüoptionen im Pod-Konfigurationsassistenten konfiguriert. Wenn Sie den Speicherort des Pods konfiguriert haben, indem Sie ihn manuell in ein Textfeld eingeben, schlägt der Übergang fehl. Um optimale Ergebnisse zu erzielen, öffnen Sie den Konfigurationsassistenten für jeden Pod und konfigurieren Sie seinen Speicherort neu, indem Sie eine gültige Menüoption auswählen.
  • Jeder Pod enthält mindestens eine interne oder externe Unified Access Gateway-Instanz.
    Hinweis: Wenn ein Pod nur eine interne Unified Access Gateway-Instanz enthält, setzt Universal Broker die Netzwerkrichtlinie außer Kraft, die auf der Registerkarte Netzwerkbereiche der Broker-Seite definiert ist, und leitet alle Benutzer zu dieser Unified Access Gateway-Instanz weiter, unabhängig von ihrer IP-Adresse.
    • Jede Unified Access Gateway-Instanz muss auf Version 3.8 oder höher sein.
    • Jede Unified Access Gateway-Instanz darf mit höchstens einem Pod gekoppelt sein.
    • Alle Unified Access Gateway-Instanzen über alle Pods hinweg müssen sich im Bereitschaftszustand befinden.
    Wichtig: Um die Zwei-Faktor-Authentifizierung für Universal Broker nach dem Übergang verwenden zu können, muss jeder Pod über mindestens eine externe Unified Access Gateway-Instanz mit dem entsprechenden RADIUS-Authentifizierungsdienst verfügen. Sie müssen alle externen Unified Access Gateway-Instanzen über alle beteiligten Pods hinweg so konfigurieren, dass sie denselben RADIUS-Authentifizierungsdienst verwenden.

DNS, Ports und Protokollanforderungen zur Unterstützung von Universal Broker

Überprüfen Sie die folgenden Anforderungen.

FQDN-Anforderungen zur Unterstützung von Universal Broker

Bei Einzel-Pod-Broker stellen Endbenutzer einzeln eine Verbindung zum vollqualifizierten Domänennamen (FQDN) jedes Pods her, um auf Zuweisungen von diesem Pod zuzugreifen.

Nach dem Übergang zu Universal Broker können Benutzer auf jede Aufgabe – von jedem Pod in jeder Site in Ihrer Umgebung – zugreifen, indem sie sich mit dem einen FQDN des Universal Broker-Cloud-Dienstes verbinden. Universal Broker leitet jede Benutzeranfrage an den individuellen FQDN des am besten geeigneten Pods weiter, der die Anfrage erfüllen kann.

Den FQDN von Universal Broker legen Sie in den Konfigurationseinstellungen von Universal Broker fest, wie in Planen und Vollziehen des Übergangs vom Einzel-Pod-Broker zu Universal Broker beschrieben. Sie können den FQDN erstellen, indem Sie Ihre gültige Unterdomäne der von VMware bereitgestellten Standarddomäne voranstellen, oder Sie können einen vollständig benutzerdefinierten FQDN konfigurieren.

Hinweis: Wenn Sie sich für die Konfiguration eines benutzerdefinierten FQDN entscheiden, bedenken Sie, dass dieser FQDN Ihr Unternehmen oder Ihre Organisation repräsentiert. Stellen Sie sicher, dass Sie der Eigentümer des im benutzerdefinierten FQDN angegebenen Domänennamens sind, ein Zertifikat vorlegen können, das diese Domäne bestätigt, und über die richtige Berechtigung zur Verwendung des benutzerdefinierten FQDN verfügen. Der benutzerdefinierte FQDN für Universal Broker muss eindeutig und verschieden von den FQDNs aller Unified Access Gateway-Instanzen innerhalb Ihrer Pods sein.

Planen und Vorbereiten des Broker-Übergangs

Da der Broker-Übergang wichtige Änderungen an Ihrem Netzwerk- und Zuweisungs-Workflow mit sich bringt, stellen Sie sicher, dass Sie die notwendigen Maßnahmen ergreifen, um Ihre Umgebung und Benutzer auf den neuen Workflow vorzubereiten. Im folgenden Planungsleitfaden finden Sie die entsprechenden Schritte zur Vorbereitung und zum Änderungsmanagement auf der Grundlage Ihres Anwendungsfalls für den Übergang.

Anwendungsfall „Übergang“ Schritte zur Planung und Vorbereitung
Ihre Umgebung besteht aus einem einzelnen Pod, und Sie möchten den vorhandenen FQDN dieses Pods als FQDN des Universal Brokers verwenden
  1. Bestimmen Sie während der Konfigurationsphase des Übergangsplanungsprozesses den vorhandenen FQDN des Pods als benutzerdefinierten FQDN für den Universal Broker-Dienst.
  2. Wählen Sie für den Übergang ein Datum und eine Uhrzeit, die eine minimale Unterbrechung des Arbeitsaufkommens Ihrer Endbenutzer verursachen.
  3. Benachrichtigen Sie Ihre Endbenutzer und bereiten Sie sie auf den bevorstehenden Übergang vor. Erinnern Sie sie daran, ihre Arbeit zu speichern und sich von ihren aktiven Verbindungssitzungen abzumelden, wenn die Übergangszeit naht.
  4. Weisen Sie dem Pod kurz vor dem Übergang eine neue IP-Adresse und einen FQDN zu.
  5. Informieren Sie Ihre Endbenutzer nach Abschluss des Übergangs, dass sie ihre Verbindungssitzungen unter Verwendung des früheren FQDN des Pods, der jetzt der Universal Broker-FQDN ist, wieder aufnehmen können.
Ihre Umgebung besteht aus mehreren Pods, und Sie möchten einen neuen FQDN als Universal Broker-FQDN konfigurieren
  1. Aktualisieren Sie Ihre Runbooks, um die notwendigen Abläufe vor, während und nach dem Übergangsprozess zu berücksichtigen.
  2. Konfigurieren Sie in der Konfigurationsphase des Übergangsplanungsprozesses den neuen FQDN für den Universal Broker-Dienst.
  3. Wählen Sie für den Übergang ein Datum und eine Uhrzeit, die eine minimale Unterbrechung des Arbeitsaufkommens Ihrer Endbenutzer verursachen. Planen Sie ausreichend Zeit für die Benutzerschulung und die Neukonfiguration der Client-Software ein, je nach Umfang Ihrer Pod-Installationen.
  4. Benachrichtigen Sie Ihre Endbenutzer und bereiten Sie sie auf den bevorstehenden Übergang vor. Erinnern Sie sie daran, ihre Arbeit zu speichern und sich von ihren aktiven Verbindungssitzungen abzumelden, wenn die Übergangszeit naht.
  5. Konfigurieren Sie während oder kurz nach dem Übergang Horizon Client auf den Client-Systemen Ihrer Benutzer neu, um eine Verbindung mit dem neuen Universal Broker-FQDN herzustellen, anstatt mit den FQDNs der einzelnen Pods.
  6. Informieren Sie Ihre Endbenutzer darüber, dass sie nun den neuen Broker-Verbindungs-FQDN verwenden müssen und dadurch universellen Zugriff auf alle Pods in Ihrer Umgebung erhalten können.