Informationen zum Übergangsprozess vom Einzel-Pod-Broker zu Universal Broker

In diesem Thema werden der Broker-Übergangsprozess für Ihren Horizon Cloud-Mandanten und die Vorteile vorgestellt, die Sie durch die Durchführung des Übergangs erzielen können. Informieren Sie sich über die Unterschiede zwischen einer Einzel-Pod-Broker- und einer Universal Broker-Umgebung und darüber, was Sie vor, während und nach dem Broker-Übergang erwarten können.

Was ist der Broker-Übergangsprozess?

Wenn Sie den Broker-Übergang abschließen, wechselt Ihre Horizon Cloud-Mandantenumgebung von der Verwendung von Einzel-Pod-Brokering zur Verwendung von Universal Broker, um Ressourcen aus Ihren Endbenutzerzuweisungen zu vermitteln. Als neuer mandantenübergreifender Broker verwaltet Universal Broker die Verbindungsanfragen Ihrer Benutzer und leitet sie an die beste verfügbare Ressource aus der angeforderten Zuweisung weiter.

Der Broker-Übergangsprozess nimmt die folgenden Änderungen an Ihren Endbenutzerzuweisungen vor.

• VDI-Desktop-Zuweisungen werden in Multi-Cloud-Zuweisungen umgewandelt, die von Universal Broker vermittelt werden. Eine Multi-Cloud-Zuweisung kann VDI-Desktops aus mehreren Pods enthalten.
• Sitzungsbasierte Desktop- und Anwendungszuweisungen bleiben unverändert. Eine sitzungsbasierte Desktop- oder Anwendungszuweisung kann nur Ressourcen eines einzelnen Pods umfassen, aber die Zuweisung wird jetzt von Universal Broker vermittelt.

Die Übergangsfunktion steht Ihnen zur Verfügung, wenn Ihre Umgebung derzeit Einzel-Pod-Brokering verwendet und die unter Horizon Cloud – Systemvoraussetzungen für den Übergang zu Universal Broker beschriebenen Voraussetzungen erfüllt.

Warum sollten Sie auf Universal Broker umsteigen?

Wenn Sie auf Universal Broker, die neueste cloudbasierte Brokering-Technologie von VMware, umsteigen, profitieren Sie von den folgenden Hauptvorteilen.

Endbenutzerzuweisungen mit VDI-Desktops aus mehreren Pods

Beim Einzel-Pod-Brokering müssen alle Desktops in einer VDI-Zuweisung aus demselben Pod stammen. Das Desktop-Brokering erfolgt pro Pod.

Mit Universal Broker können Sie eine Zuweisung von VDI-Desktops aus mehreren Pods erstellen, auch bekannt als Multi-Cloud-Zuweisung. Ein Endbenutzer kann auf die Zuweisung zugreifen und einen Desktop von jedem in dieser Zuweisung enthaltenen Pod erhalten. Weitere Informationen finden Sie unter Einführung in VMware Horizon Service Universal Broker und den entsprechenden Unterthemen.

Sie können auch weiterhin Ihre sitzungsbasierten Desktop- und Anwendungszuweisungen wie bisher verwenden. Der Unterschied besteht darin, dass die sitzungsbasierten Desktops und Anwendungen aus diesen Zuweisungen von Universal Broker anstelle von Pro-Pod-Brokering vermittelt werden.

Einzelner Verbindungs-FQDN für alle Remoteressourcen

Beim Einzel-Pod-Brokering müssen Endbenutzer einzeln eine Verbindung zum vollqualifizierten Domänennamen (FQDN) jedes Pods herstellen, um auf Zuweisungen von diesem Pod zuzugreifen. Das Brokering erfolgt pro Pod.

Mit Universal Broker können Benutzer auf alle Zuweisungen zugreifen, indem sie sich mit nur einem FQDN verbinden, den Sie in den Konfigurationseinstellungen von Universal Broker festlegen. Über einen einzigen FQDN können Anwender von jedem Standort in Ihrer Umgebung aus auf Zuweisungen von allen teilnehmenden Pods zugreifen – sowohl von Horizon Cloud-Pods in Microsoft Azure als auch von Horizon-Pods auf einer VMware SDDC-basierten Plattform. Es ist keine interne Vernetzung zwischen Ihren Pods erforderlich.

Globale Pod-Konnektivität und Informationen für eine optimale Leistung

Universal Broker behält die direkte Konnektivität für jeden Pod bei, der an Multi-Cloud-Zuweisungen teilnimmt, und bleibt bezüglich des Verfügbarkeitsstatus der einzelnen Pods auf dem Laufenden. Folglich kann Universal Broker Verbindungsanfragen von Endbenutzern verwalten und direkt über diese Pods an virtuelle Ressourcen weiterleiten. Es besteht keine Notwendigkeit für einen globalen Serverlastausgleich (GSLB) oder eine podübergreifende Netzwerkkommunikation, die zu Leistungseinbußen und Latenzproblemen führen kann.

Intelligentes Brokering

Universal Broker kann Ressourcen aus Zuweisungen entlang der kürzesten Netzwerkroute an Endbenutzer vermitteln, basierend auf der Kenntnis Ihrer geografischen Standorte und Pod-Topologie.

Gibt es einen Grund, nicht umzusteigen?

Diese Version von Universal Broker hat ein paar Funktionseinschränkungen Wenn Ihr Anwendungsfall eine Funktion erfordert, die Universal Broker nicht unterstützt, sollten Sie Ihre Mandantenumgebung mit dem Einzel-Pod-Brokering beibehalten, bis Universal Broker die Funktion unterstützt. Eine Aufstellung der aktuellen Universal Broker-Beschränkungen finden Sie unter Universal Broker – Überlegungen zu Funktionen und bekannte Einschränkungen.

Was passiert während des Broker-Übergangs?

Der Übergangsworkflow besteht aus mehreren Stufen. Eine detaillierte Schritt-für-Schritt-Anleitung zur Durchführung des Übergangs finden Sie unter Planen und Vollziehen des Übergangs vom Einzel-Pod-Broker zu Universal Broker.

Hier finden Sie eine Übersicht über die Prozesse, die vor und während des Übergangs stattfinden.

1. Um den Workflow zu initiieren, müssen Sie zunächst ein Datum und eine Uhrzeit für den Übergang festlegen. Zusammen mit dieser Planungsaufgabe legen Sie die Konfigurationsoptionen fest, mit denen der Universal Broker-Dienst während des Übergangs eingerichtet wird.
2. Schließen Sie mindestens 15 Minuten vor der geplanten Startzeit alle laufenden Vorgänge in der Konsole ab und speichern Sie alle Änderungen, die Sie beibehalten möchten. Schließen Sie alle Konfigurationsassistenten und Dialogfelder. Stellen Sie außerdem sicher, dass alle Ihre Pods in Microsoft Azure online und in einem fehlerfreien, einsatzbereiten Zustand sind.
3. Wenn der Übergang kurz bevorsteht, werden Sie aufgefordert, sich von der Konsole abzumelden und erneut anzumelden.
4. In der ersten Phase des Übergangs können Sie Folgendes erwarten:
   • Sie können auf keines der Bearbeitungselemente der Konsole zugreifen, und die Konsole zeigt ein Banner an, das besagt, dass der Übergang stattfindet.
   • Alle Ihre Pods in Microsoft Azure werden zu einer Site mit dem Namen Standardsite hinzugefügt.
   • Ihre VDI-Desktop-Zuweisungen werden in Multi-Cloud-Zuweisungen umgewandelt, die von Universal Broker vermittelt werden. In den Standard-Zuweisungseinstellungen ist die Verbindungsaffinität auf Nächstgelegene Site und der Scope auf In der Site eingestellt.
   • Ihre sitzungsbasierten Desktop- und Anwendungszuweisungen bleiben unverändert. Nach dem Übergang werden die Ressourcen in diesen Aufträgen von Universal Broker vermittelt.
   • Alle Zuweisungen bleiben für Ihre Endbenutzer verfügbar, und alle aktiven Benutzersitzungen bleiben während dieser Zeit offen und voll funktionsfähig.
   Hinweis: Diese Phase des Übergangs dauert in der Regel etwa 10 Minuten, kann aber bis zu einer Stunde dauern, wenn Ihre Mandantenumgebung eine hohe Anzahl von Zuweisungen enthält.

   Wenn diese Phase des Übergangs abgeschlossen ist, werden Sie aufgefordert, sich von der Konsole abzumelden und erneut anzumelden.

5. In der zweiten Phase des Übergangs schließt der Universal Broker-Dienst seinen Einrichtungsprozess ab und wird vollständig aktiviert. Sie können in der Konsole auf alle Bearbeitungsvorgänge zugreifen, außer auf das Erstellen und Bearbeiten von Zuweisungen.
   Hinweis: Diese Phase des Übergangs dauert normalerweise bis zu 30 Minuten. Abhängig von Ihren System- und Netzwerkbedingungen und der Gesamtzahl der Zuweisungen und dedizierten Benutzer-zu-Desktop-Zuweisungen in Ihrer Umgebung kann dieser Schritt jedoch mehrere Stunden in Anspruch nehmen.

   Wenn diese Phase des Übergangs abgeschlossen ist, wird auf der Seite Einstellungen > Broker der Status Aktiviert mit einem grünen Punkt angezeigt.

   Zu diesem Zeitpunkt ist der gesamte Broker-Übergang abgeschlossen.

Was können Sie nach dem Broker-Übergang erwarten?

Eine detaillierte Liste der Änderungen, die nach dem Broker-Übergang an Ihrer Mandantenumgebung vorgenommen wurden, finden Sie unter Was ist neu in Ihrer Mandantenumgebung nach dem Übergang zu Universal Broker?.

Nachdem Sie den Übergang abgeschlossen haben, können Sie beginnen, die Vorteile zu nutzen, die eine Universal Broker-Umgebung bietet. Die folgende Liste enthält einen kurzen Überblick über die nächsten Schritte und Links zu Detailseiten.

• Ändern Sie Ihre Standort- und Multi-Cloud-VDI-Zuweisungseinstellungen, um die Möglichkeiten von Universal Broker voll auszuschöpfen. Sie können z. B. weitere Pods zu einem bestehenden Auftrag hinzufügen oder die Site-Einstellungen anpassen, um eine Feinabstimmung der Zuweisung von Ressourcen an Benutzer durch Universal Broker vorzunehmen. Ausführliche Informationen finden Sie unter Erstellen und Verwalten von Zuweisungen in Ihrer Universal Broker-Umgebung und Arbeiten mit Sites in einer Universal Broker-Umgebung.
• Wenn Sie eine bestehende Integration zwischen Ihrem Horizon Cloud-Mandanten und Workspace ONE Access haben, müssen Sie die Integration aktualisieren, um die Verwendung von Universal Broker zu ermöglichen. Eine vollständige Anleitung finden Sie unter Horizon Cloud-Umgebung mit Universal Broker – Integrieren des Mandanten in Workspace ONE Access und Intelligent Hub-Dienste.
  Hinweis: Wie vom VMware Workspace ONE Access-Produktteam bestätigt, wird die Funktion „Sammlungen virtueller Apps“ des VMware Workspace ONE Access-Produkts in dieser Konfiguration nicht unterstützt, wenn Universal Broker mit Ihren Horizon Cloud on Microsoft Azure-Bereitstellungen verwendet wird. Der Grund dafür ist, dass die Universal Broker-Technologie moderner als das alte „Pro Pod“-Brokering ist. Dies bedeutet, dass die Integration von Universal Broker in Workspace ONE Access die Verwendung der veralteten Sammlungen virtueller Pro-Pod-Apps für Horizon Cloud on Microsoft Azure-Bereitstellungen ersetzt. Daher verfügt Universal Broker überhaupt nicht über ein „Sammlungen virtueller Apps“-Konzept für Horizon Cloud on Microsoft Azure-Bereitstellungen. Dadurch wird die Verwendung von Sammlungen virtueller Apps mit den Universal Broker- und Horizon Cloud on Microsoft Azure-Konfigurationen nicht unterstützt.

  Wenn Universal Broker für Ihre Horizon Cloud on Microsoft Azure-Bereitstellungen konfiguriert ist und Sie planen, Workspace ONE Access- und Intelligent Hub-Dienste mit diesen Horizon Cloud on Microsoft Azure-Bereitstellungen zu verwenden, müssen Sie beim Integrationsprozess im Rahmen der Aktion Bereinigen der Konsole alle vorhandenen Sammlungen virtueller Apps bereinigen, über die diese Bereitstellungen möglicherweise verfügen. Wenn Sie die Bereinigungsaktivitäten abschließen, funktionieren dieselben Anwendungen weiterhin in Workspace ONE Access- und Intelligent Hub-Diensten, indem sie die modernen Funktionen des integrierten Universal Broker sowie der Workspace ONE Access- und Intelligent Hub-Dienste verwenden.

Horizon Cloud – Systemvoraussetzungen für den Übergang zu Universal Broker

In diesem Artikel werden die Anforderungen beschrieben, die Ihre Horizon Cloud-Mandantenumgebung erfüllen muss, bevor Sie den Übergang Ihres Mandanten von Einzel-Pod-Brokering 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.

Vorsicht: Wenn die Pod-Flotte Ihres Mandanten eine Kombination aus Horizon-Pods enthält, die bereits Universal Broker- und Horizon Cloud-Pods mit Einzel-Pod-Brokering verwenden, müssen Sie besonders beachten, dass die Einstellungen für die Zwei-Faktor-Authentifizierung in den bereits konfigurierten Universal Broker-Einstellungen mit den Horizon Cloud-Pods übereinstimmen.

• Falls Ihre Horizon Cloud-Pods nicht die Kriterien für das minimale Pod-Manifest und die Aktivierung der RSA SecurID-Option in Ihrer Mandantenumgebung erfüllen, unterstützen diese Pods nur RADIUS-Authentifizierung. (Weitere Informationen finden Sie unter Best Practices bei der Implementierung der Zwei-Faktor-Authentifizierung in einer Universal Broker-Umgebung.)
• Wenn die Horizon Cloud-Pods die Kriterien für die Konfiguration von RSA SecurID auf ihren externen Gateways nicht erfüllen, müssen Sie zur Verwendung von Zwei-Faktor-Authentifizierung mit allen Pods (Horizon- und Horizon Cloud-Pods) in Ihrer Flotte für jeden Pod ein externes Unified Access Gateway mit RADIUS-Zwei-Faktor-Authentifizierung konfigurieren.

Anforderungen für Horizon Cloud-Pods

Stellen Sie sicher, dass Ihre Horizon Cloud-Pods in Microsoft Azure die folgenden Anforderungen erfüllen.

• Ihr Mandant verfügt über mindestens einen Horizon Cloud-Pod. Ein Horizon Cloud-Pod basiert auf der Pod-Manager-Technologie, die in Microsoft Azure ausgeführt wird.
• Alle Horizon Cloud-Pods Ihres Mandanten 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 Horizon Cloud-Pods mit Manifest 2474.0 oder höher ausgeführt werden. Diese Funktionen werden nicht unterstützt, wenn die Pods mit einer früheren Version als Manifest 2474.0 ausgeführt werden.
  Wichtig: Stellen Sie sicher, dass alle Ihre Horizon Cloud-Pods online sind und sich in einem ordnungsgemäßen, einsatzbereiten Zustand befinden. Der Universal Broker-Dienst muss mit diesen Pods kommunizieren und einige Konfigurationsschritte auf den Pods ausführen, um den Einrichtungsvorgang abzuschließen. Wenn einer dieser 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 der Speicherort des Pods durch manuelle Eingabe in ein Textfeld konfiguriert wurde, schlägt der Übergang fehl.
  Hinweis: Das Problem mit einem manuell eingegebenen Speicherort tritt eher bei Pods auf, die vor März 2019 bereitgestellt wurden (Dienstversion 1.9). Ab der Version vom März 2019 müssen die Speicherorte über das Menü aus den Werten in der weltweiten Ortsnamendatenbank des Systems ausgewählt werden.

  Um die Wahrscheinlichkeit zu verringern, dass der Übergang aufgrund des konfigurierten Speicherorts des Pods fehlschlägt, navigieren Sie zur Kapazitätsseite der Konsole und prüfen Sie den Wert in der Spalte „Speicherort“ für jeden Horizon Cloud-Pod. Wenn der Wert der Spalte „Speicherort“ wie ein manuell eingegebener Name aussieht, verwenden Sie die Aktion Bearbeiten auf dem Pod, wechseln Sie zum Schritt Pod-Details und bearbeiten Sie das Feld Speicherort, um den Wert auf einen der Werte für den Ortsnamen des Systems festzulegen.

• Wenn Ihr Mandant während des Übergangsworkflows noch nicht über Universal Broker-Einstellungen von Horizon-Pods in Ihrer Pod-Flotte verfügt, werden Sie von der Konsole zur Eingabe Universal Broker-Einstellungen aufgefordert. Wenn Sie planen, die Einstellungen für die Zwei-Faktor-Authentifizierung in den Universal Broker-Einstellungen zu konfigurieren, muss jeder Pod über eine externe Unified Access Gateway-Instanz verfügen und diese Instanz muss mit dem entsprechenden Zwei-Faktor-Authentifizierungstyp konfiguriert werden. (Weitere Hintergrundinformationen finden Sie unter Best Practices bei der Implementierung der Zwei-Faktor-Authentifizierung in einer Universal Broker-Umgebung.)

  Die Anforderungen hängen davon ab, ob Ihre Horizon Cloud-Pods die Kriterien für die Konfiguration des RSA SecurID-Typs auf ihren externen Gateways erfüllen:

  • Wenn Ihre Horizon Cloud-Pods die Kriterien für das minimale Pod-Manifest und die Aktivierung der RSA SecurID-Option in Ihrer Mandantenumgebung erfüllen, konfigurieren Sie alle externen Unified Access Gateway-Instanzen für alle Pods so, dass sie denselben Authentifizierungsdienst verwenden. Darin enthalten sind alle Horizon-Pods Ihres Mandanten, die sich im verwalteten Zustand befinden. Das Ergebnis ist, dass alle einen übereinstimmenden Authentifizierungstyp (RADIUS oder RSA SecurID) verwenden.
  • Wenn die Horizon Cloud-Pods diese Kriterien nicht erfüllen, um RSA SecurID auf ihren externen Gateways zu konfigurieren, müssen Sie bei Verwendung von Zwei-Faktor-Authentifizierung mit allen Pods in Ihrer Flotte (Horizon- und Horizon Cloud-Pods) sämtliche externen Unified Access Gateway-Instanzen in allen Pods so konfigurieren, dass sie denselben RADIUS-Authentifizierungsdienst verwenden. Darin enthalten sind alle Horizon-Pods Ihres Mandanten, die sich im verwalteten Zustand befinden.

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.

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

Überprüfen Sie die folgenden Anforderungen.

• Jeder Pod ist so konfiguriert, dass die erforderlichen DNS-Namen für Ihre regionale Universal Broker-Instanz auflösbar und erreichbar sind. Weitere Informationen finden Sie in der Tabelle „Anforderungen an Pod-Bereitstellung und -Betrieb“ unter Anforderungen an DNS für einen Horizon Cloud-Pod in Microsoft Azure.
• Jeder Pod ist mit den erforderlichen Ports und Protokollen, wie im Abschnitt „Für Universal Broker erforderliche Ports und Protokolle“ unter Port- und Protokollanforderungen für einen Horizon Cloud-Pod mit der Manifestversion vom September 2019 oder höher beschrieben, konfiguriert.

FQDN-Anforderungen zur Unterstützung von Universal Broker

Beim Einzel-Pod-Brokering 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	Bestimmen Sie während der Konfigurationsphase des Übergangsplanungsprozesses den vorhandenen FQDN des Pods als benutzerdefinierten FQDN für den Universal Broker-Dienst. Wählen Sie für den Übergang ein Datum und eine Uhrzeit, die eine minimale Unterbrechung des Arbeitsaufkommens Ihrer Endbenutzer verursachen. 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. Weisen Sie dem Pod kurz vor dem Übergang eine neue IP-Adresse und einen FQDN zu. 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	Aktualisieren Sie Ihre Runbooks, um die notwendigen Abläufe vor, während und nach dem Übergangsprozess zu berücksichtigen. Konfigurieren Sie in der Konfigurationsphase des Übergangsplanungsprozesses den neuen FQDN für den Universal Broker-Dienst. 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. 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. 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. 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.

Planen und Vollziehen des Übergangs vom Einzel-Pod-Broker zu Universal Broker

Dieses Thema führt Sie in Einzelschritten durch die Planung, die Vorbereitung und den Abschluss des Übergangs zu Universal Broker. Im folgenden Verfahren erfahren Sie, wie Sie den Universal Broker-Dienst einrichten, ein Startdatum und eine Startzeit für den Übergang festlegen und die einzelnen Phasen des Prozesses für einen erfolgreichen Übergang reibungslos durchlaufen.

Ein Benachrichtigungsbanner mit einer Schaltfläche Zeitplan wird oben in Horizon Universal Console angezeigt, wenn der Broker-Übergang bereit ist, geplant zu werden.

Hinweis: Wenn das Banner eine Fehlerbedingung anzeigt, die verhindert, dass der Übergang geplant wird, haben Sie wahrscheinlich eine oder mehrere der Voraussetzungen für den Übergang nicht erfüllt. Klicken Sie im Banner auf Fehler anzeigen und dann auf das Fehlersymbol neben dem Link Übergang erforderlich auf der Seite Broker, um Details über die Fehlerbedingung anzuzeigen. Sie müssen die erforderlichen Schritte zur Beseitigung der Fehlerbedingung durchführen, bevor Sie den Übergang planen können.

Voraussetzungen

Vergewissern Sie sich, dass Ihre Mandantenumgebung alle Voraussetzungen erfüllt, die unter Horizon Cloud – Systemvoraussetzungen für den Übergang zu Universal Broker beschrieben sind.

Prozedur

1. Klicken Sie im Benachrichtigungsbanner für den Broker-Übergang auf Planen.
   
   
   
   Diese Aktion leitet Sie auf die Broker-Seite weiter. Die Seite zeigt an, dass für Ihren Mandanten derzeit Einzel-Pod-Broker aktiviert ist, und bietet einen Link für die Planung des Broker-Übergangs.

   
   
   
2. Klicken Sie auf der Seite Broker auf den Link Zeitplan.
   Der Konfigurationsassistent für Universal Broker wird angezeigt. Sie müssen die Schritte dieses Assistenten ausführen, um Universal Broker für Ihre Pods in Microsoft Azure einzurichten und den Übergang zu Universal Broker zu planen.

   
   
   
3. Konfigurieren Sie auf der Seite FQDN des Assistenten die Einstellungen für den FQDN Ihrer Broker-Verbindung. Diese Einstellungen definieren die Adresse der dedizierten Verbindung, über die Ihre Endbenutzer auf von Universal Broker zugewiesene Ressourcen zugreifen.
   Hinweis: Wenn Sie eine Unterdomänen- oder FQDN-Einstellung ändern, kann es einige Zeit dauern, bis die Änderung auf allen DNS-Servern wirksam wird.
   1. Wählen Sie unter „Typ“ aus, ob der vollqualifizierte Domänenname (FQDN) Von VMware bereitgestellt oder Benutzerdefiniert werden bzw. sein soll.
   2. Geben Sie zusätzliche Einstellungen für den ausgewählten FQDN-Typ an.
      • Wenn Sie den Typ Von VMware bereitgestellt ausgewählt haben, müssen Sie die folgenden Einstellungen angeben.

        Einstellung	Beschreibung
        Sub Domain	Geben Sie den eindeutigen DNS-Namen einer gültigen Unterdomäne in Ihrer Netzwerkkonfiguration ein, die für Ihr Unternehmen oder Ihre Organisation steht. Dieser Unterdomäne wird der von VMware bereitgestellten Domäne bei der Bildung des Brokering-FQDN als Präfix vorangestellt. Hinweis: Einige Zeichenfolgen sind unzulässig oder vom System reserviert. Zu dieser Kategorie der Zeichenfolgen gehören generische Wörter wie book, bekannte unternehmenseigene Begriffe wie gmail und protocol, coding sowie Open Source-Begriffe wie php und sql. Das System untersagt außerdem eine Kategorie von Mustern dieser Zeichenfolgen, wie mail0, mail1, mail2 usw. Wenn Sie in diesem Feld jedoch einen unzulässigen Namen angeben, wird der Eintrag zu diesem Zeitpunkt nicht vom System validiert. Erst wenn Sie den abschließenden Schritt des Assistenten mit der Zusammenfassung erreichen, validiert das System den hier eingegebenen Namen und zeigt einen Fehler an, sofern der Eintrag mit einem der nicht zulässigen Namen übereinstimmt. Geben Sie in diesem Fall einen anderen und eindeutigeren Namen ein.
        Brokering FQDN	Dieses schreibgeschützte Feld zeigt den konfigurierten FQDN an. Der FQDN hat das Format https://<Ihre Unterdomäne>vmwarehorizon.com. Geben Sie diesen FQDN für Ihre Endbenutzer an, damit diese über Horizon Client eine Verbindung mit dem Universal Broker-Dienst herstellen können. Universal Broker verwaltet den DNS und die SSL-Validierung dieses FQDN.

      • Wenn Sie den Typ Benutzerdefiniert ausgewählt haben, geben Sie die folgenden Einstellungen an.

        Einstellung	Beschreibung
        Brokering FQDN	Geben Sie den benutzerdefinierten FQDN ein, den Ihre Endbenutzer für den Zugriff auf den Universal Broker-Dienst verwenden sollen. Ihr benutzerdefinierter FQDN fungiert als Alias für den automatisch generierten, von VMware bereitgestellten FQDN, der die Verbindung zum Dienst vervollständigt. Sie müssen Besitzer des in Ihrem benutzerdefinierten FQDN angegebenen Domänennamens sein und ein Zertifikat bereitstellen, das diese Domäne validiert. Hinweis: Ihr benutzerdefinierter FQDN, auch als Verbindungs-URL bezeichnet, steht für Ihr Unternehmen oder Ihre Organisation. Stellen Sie sicher, dass Sie über die entsprechende Berechtigung zur Verwendung dieses benutzerdefinierten FQDN verfügen. Hinweis: Ihr benutzerdefinierter FQDN muss eindeutig sein und sich von den FQDNs aller Unified Access Gateway-Instanzen innerhalb Ihrer Pods unterscheiden. Wichtig: Sie müssen auf Ihrem DNS-Server einen CNAME-Datensatz erstellen, der Ihren benutzerdefinierten FQDN dem von VMware bereitgestellten FQDN zuordnet, der die interne Verbindungsadresse des Universal Broker-Dienstes bildet. Der Datensatz könnte beispielsweise vdi.examplecompany.com <automatisch-generierte-zeichenfolge>.vmwarehorizon.com zugeordnet werden.
        Certificate	Klicken Sie auf Durchsuchen und laden Sie das Zertifikat (im kennwortgeschützten PFX-Format) hoch, das Ihren Brokering-FQDN validiert. Das Zertifikat muss alle folgenden Kriterien erfüllen: Zertifikat muss mindestens 90 Tage gültig sein Das Zertifikat muss von einer vertrauenswürdigen Zertifizierungsstelle signiert sein Entweder der allgemeine Name (Common Name, SN) des Zertifikats oder einer seiner alternativen Antragstellernamen (Subject Alternative Names, SANs) muss mit dem FQDN übereinstimmen Der Inhalt des Zertifikats muss dem X.509-Standardformat entsprechen Die PFX-Datei muss die gesamte Zertifikatskette und den privaten Schlüssel enthalten: Domänenzertifikat, Zwischenzertifikate, Stamm-Zertifizierungsstelle, Zertifikat, privaten Schlüssel. Der Universal Broker-Dienst verwendet dieses Zertifikat, um vertrauenswürdige Verbindungssitzungen mit Clients herzustellen.
        Password	Geben Sie das Kennwort für die PFX-Zertifikatdatei ein.
        VMware Provided FQDN	Dieses schreibgeschützte Feld zeigt den von VMware bereitgestellten FQDN an, der automatisch für den Brokering-Dienst generiert wird. Der FQDN hat das Format https://<automatisch-generierte-zeichenfolge>.vmwarehorizon.com. Der von VMware bereitgestellte FQDN ist für Endbenutzer nicht sichtbar und stellt die interne Verbindungsadresse des Universal Broker-Dienstes dar. Ihr benutzerdefinierter FQDN fungiert als Alias für den von VMware bereitgestellten FQDN. Wichtig: Sie müssen eine Aliaszuordnung einrichten, indem Sie einen CNAME-Datensatz auf Ihrem DNS-Server erstellen, der Ihren benutzerdefinierten FQDN dem von VMware bereitgestellten FQDN zuordnet. Der Datensatz könnte beispielsweise vdi.examplecompany.com <automatisch-generierte-zeichenfolge>.vmwarehorizon.com zugeordnet werden.

        
        

        

        
        
   3. Wenn Sie mit der Konfiguration der FQDN-Einstellungen fertig sind, klicken Sie auf Weiter, um mit der nächsten Seite des Assistenten fortzufahren.
4. (Optional) Konfigurieren Sie auf der Seite Authentifizierung des Assistenten die Zwei-Faktor-Authentifizierung.
   Standardmäßig authentifiziert Universal Broker Benutzer ausschließlich über ihren Active Directory-Benutzernamen und das zugehörige Kennwort. Sie können die Zwei-Faktor-Authentifizierung implementieren, indem Sie eine zusätzliche Authentifizierungsmethode angeben. Weitere Informationen finden Sie unter Best Practices bei der Implementierung der Zwei-Faktor-Authentifizierung in einer Universal Broker-Umgebung.
   Wichtig: Um die Zwei-Faktor-Authentifizierung für Universal Broker zu verwenden, müssen Sie zuerst den entsprechenden Authentifizierungsdienst in den einzelnen externen Unified Access Gateway-Instanzen für jeden teilnehmenden Pod konfigurieren. Die Konfigurationen der externen Unified Access Gateway-Instanzen müssen innerhalb der und über die teilnehmenden Pods hinweg identisch sein.

   Wenn Sie beispielsweise die RADIUS-Authentifizierung verwenden möchten, müssen Sie den RADIUS-Dienst auf jeder externen Unified Access Gateway-Instanz für alle teilnehmenden Horizon-Pods und Pods in Microsoft Azure konfigurieren.

   Löschen Sie keine Unified Access Gateway-Instanzen innerhalb der teilnehmenden Pods. Da Universal Broker auf Unified Access Gateway für den Protokolldatenverkehr zwischen Horizon Client und virtuellen Ressourcen vertraut, können Benutzer nicht auf bereitgestellte Ressourcen von einem teilnehmenden Pod zugreifen, wenn Sie die Unified Access Gateway-Instanz auf diesem Pod löschen.

   Einstellung	Beschreibung
   Two-Factor Authentication	Um die Zwei-Faktor-Authentifizierung zu verwenden, aktivieren Sie diesen Schalter. Wenn Sie den Schalter aktivieren, werden Ihnen zusätzliche Optionen zum Konfigurieren der Zwei-Faktor-Authentifizierung angezeigt.
   Maintain User Name	Aktivieren Sie diesen Schalter, um den Active Directory-Benutzernamen des Benutzers während der Authentifizierung bei Universal Broker beizubehalten. Falls aktiviert: Muss der Benutzer für die zusätzliche Authentifizierungsmethode über dieselben Anmeldedaten (Benutzernamen) wie für die Active Directory-Authentifizierung für Universal Broker verfügen. Kann der Benutzer den Benutzernamen auf dem Client-Anmeldebildschirm nicht ändern. Wenn dieser Schalter ausgeschaltet wird, kann der Benutzer auf dem Anmeldebildschirm einen anderen Benutzernamen eingeben.
   Type	Geben Sie neben dem Active Directory-Benutzernamen und -Kennwort die Authentifizierungsmethode an, die der Universal Broker mit den Endbenutzern verwenden soll. Auf der Benutzeroberfläche werden zwei Auswahlmöglichkeiten RADIUS und RSA SecurID angezeigt. Diese Einstellung gilt für alle Mandanten. Das Verhalten im Endbenutzer-Client hängt wie folgt von der Zusammensetzung der Pod-Flotte des Mandanten und dem Zwei-Faktor-Authentifizierungstyp auf den Gateways der Pods ab: Nur Horizon-Pods Der hier ausgewählte Typ ist der im Client verwendete Typ. Nur Horizon Cloud-Pods Wählen Sie den Typ aus, der mit dem Typ übereinstimmt, der auf den externen Gateways der Pods konfiguriert ist. Mischung aus Horizon-Pods und Horizon Cloud on Microsoft Azure-Bereitstellungen Wenn in einer gemischten Flotte RADIUS ausgewählt ist, werden die RADIUS-Authentifizierungsanforderungen der Benutzer über die Unified Access Gateway-Instanzen beider Pod-Typen ausgeführt. Wenn in einer gemischten Flotte RSA SecurID ausgewählt wird, hängt das Clientverhalten davon ab, ob Ihre Horizon Cloud on Microsoft Azure-Bereitstellungen mit RSA SecurID auf ihren externen Gateways konfiguriert sind. Wenn für Ihre Horizon Cloud on Microsoft Azure-Bereitstellungen auf ihren Gateways kein RSA SecurID-Typ konfiguriert ist und hier RSA SecurID ausgewählt ist, werden die RSA-Authentifizierungsanforderungen der Benutzer nur über die Unified Access Gateway-Instanzen Ihrer Horizon-Pods ausgeführt. Die Authentifizierungsanforderungen für den Benutzernamen und das Kennwort für Active Directory werden über die Unified Access Gateway-Instanzen von Horizon-Pods oder Horizon Cloud-Pods gestellt. Wenn für Ihre Horizon Cloud on Microsoft Azure-Bereitstellungen der RSA SecurID-Typ konfiguriert ist, werden die RSA-Authentifizierungsanforderungen der Benutzer über die Unified Access Gateway-Instanzen beider Pod-Typen ausgeführt.
   Show Hint Text	Aktivieren Sie diesen Schalter, um eine Textzeichenfolge zu konfigurieren, die auf dem Anmeldebildschirm des Clients angezeigt wird, um den Benutzer zur Eingabe seiner Anmeldedaten für die zusätzliche Authentifizierungsmethode aufzufordern.
   Custom Hint Text	Geben Sie die Textzeichenfolge ein, die im Client-Anmeldebildschirm angezeigt werden soll. Der angegebene Hinweis wird dem Endbenutzer als Enter your DisplayHint user name and password angezeigt, wobei DisplayHint der Text ist, den Sie in dieses Textfeld eingeben. Hinweis: Universal Broker lässt die folgenden Zeichen im benutzerdefinierten Hinweistext nicht zu: & < > ' ". Wenn Sie eines dieser unzulässigen Zeichen in den Hinweistext aufnehmen, schlagen Benutzerverbindungen zum Universal Broker-FQDN fehl. Dieser Hinweis kann Benutzern bei der Eingabe der richtigen Anmeldedaten helfen. Beispiel: Wenn Sie den Ausdruck Firmenbenutzername und Domänenkennwort darunter für eingeben, wird für den Endbenutzer die folgende Aufforderung angezeigt: Enter your Company user name and domain password below for user name and password.
   Skip Two-Factor Authentication	Aktivieren Sie diesen Schalter, um die Zwei-Faktor-Authentifizierung für interne Netzwerkbenutzer zu umgehen, die eine Verbindung zum Universal Broker-Dienst herstellen. Stellen Sie sicher, dass Sie die öffentlichen IP-Bereiche, die zu Ihrem internen Netzwerk gehören, angegeben haben, wie unter Interne Netzwerkbereiche für Universal Broker definieren beschrieben. Wenn dieser Schalter aktiviert ist, müssen interne Benutzer nur ihre Active Directory-Anmeldedaten eingeben, um sich beim Universal Broker-Dienst zu authentifizieren. Externe Benutzer müssen Ihre Active Directory-Anmeldedaten und Ihre Anmeldedaten für den zusätzlichen Authentifizierungsdienst eingeben. Wenn dieser Schalter ausgeschaltet ist, müssen sowohl interne als auch externe Benutzer Ihre Active Directory-Anmeldedaten und Ihre Anmeldedaten für den zusätzlichen Authentifizierungsdienst eingeben.
   Public IP Ranges	Dieses Feld wird bei Aktivierung von Zwei-Faktor-Authentifizierung überspringen angezeigt. Wenn bereits ein oder mehrere öffentliche IP-Bereiche auf der Registerkarte „Netzwerkbereiche“ der Seite „Broker“ angegeben sind, ist dieses Feld schreibgeschützt und listet diese IP-Bereiche auf. Wenn auf der Registerkarte „Netzwerkbereiche“ der Seite „Broker“ noch keine öffentlichen IP-Bereiche angegeben wurden, können Sie in diesem Feld die öffentlichen IP-Bereiche festlegen, die Ihr internes Netzwerk repräsentieren, um die Aufforderungen zur Zwei-Faktor-Authentifizierung für Datenverkehr aus diesen Bereichen zu überspringen. Universal Broker berücksichtigt, dass alle Benutzer, die über eine IP-Adresse innerhalb eines dieser Bereiche verbunden sind, interne Benutzer sind. Weitere Informationen zum Zweck der Angabe dieser Bereiche finden Sie unter Definieren interner Netzwerkbereiche für Universal Broker.

   Wenn Sie mit der Konfiguration der Zwei-Faktor-Authentifizierung fertig sind, klicken Sie auf Weiter, um mit der nächsten Seite des Assistenten fortzufahren.
5. Konfigurieren Sie auf der Seite Einstellungen des Konfigurationsassistenten die Einstellungen unter Dauer für Horizon Client.
   Diese Zeitüberschreitungseinstellungen gelten für die Verbindungssitzung zwischen Horizon Client und dem von Universal Broker zugewiesenen Desktop. Diese Einstellungen gelten nicht für die Anmeldesitzung des Benutzers beim Gastbetriebssystem des zugewiesenen Desktops. Wenn Universal Broker die durch diese Einstellungen festgelegten Zeitüberschreitungsbedingungen erkennt, schließt es die Horizon Client-Verbindungssitzung des Benutzers.

   Einstellung	Beschreibung
   Client Heartbeat Interval	Steuert das Intervall in Minuten zwischen Horizon Client-Taktsignalen und den Zustand der Verbindung des Benutzers mit Universal Broker. Diese Taktsignale melden an Universal Broker, wie viel Leerlaufzeit während der Horizon Client-Verbindungssitzung vergangen ist. Die Leerlaufzeit wird gemessen, wenn keine Interaktion mit dem Endpoint-Gerät stattfindet, auf dem Horizon Client ausgeführt wird. Inaktivität bei der Anmeldesitzung auf dem Gastbetriebssystem, das dem Benutzer zugewiesenen Desktop zugrunde liegt, wirkt sich nicht auf diese Leerlaufzeit aus. Bei großen Desktop-Bereitstellungen kann eine Erhöhung des Client-Taktsignalintervalls dazu führen, dass der Netzwerkdatenverkehr verringert und die Leistung dadurch verbessert wird.
   Client Idle User	Maximale Leerlaufzeit (in Minuten), die während einer Verbindungssitzung zwischen Horizon Client und Universal Broker zulässig ist. Wenn die maximale Zeit erreicht ist, läuft der Authentifizierungszeitraum des Benutzers ab und Universal Broker alle aktiven Horizon Client-Sitzungen werden geschlossen. Um eine Verbindungssitzung erneut zu öffnen, muss der Benutzer seine Anmeldedaten für die Authentifizierung auf dem Anmeldebildschirm von Universal Broker erneut eingeben. Hinweis: Damit Benutzer nicht unerwartet von ihren zugewiesenen Desktops getrennt werden, legen Sie als Zeitüberschreitungswert für Client-Leerlaufbenutzer am besten einen Wert fest, der mindestens doppelt so groß ist wie der Wert für das Client-Taktsignalintervall.
   Client Broker Session	Maximale zulässige Dauer einer Horizon Client-Verbindungssitzung (in Minuten), bevor die Authentifizierung des Benutzers abläuft. Die Zeit läuft ab der Authentifizierung des Benutzers bei Universal Broker. Wenn die Zeitüberschreitung der Sitzung eintritt, kann der Benutzer weiterhin auf dem zugewiesenen Desktop arbeiten. Wenn der Benutzer jedoch eine Aktion (z. B. das Ändern von Einstellungen) durchführt, die die Kommunikation mit Universal Broker erfordert, fordert Horizon Client Sie auf, Ihre Anmeldedaten für Universal Broker erneut einzugeben. Hinweis: Die Zeitüberschreitung für die Client-Broker-Sitzung muss größer oder gleich der Summe aus dem Wert für das Client-Taktsignalintervall und der Zeitüberschreitung für Client-Leerlaufbenutzer sein.
   Client Credential Cache	Steuert, ob Benutzeranmeldedaten im Cache des Clientsystems zwischengespeichert werden sollen. Geben Sie 1 ein, um Benutzeranmeldedaten im Cache zwischenzuspeichern. Geben Sie 0 ein, wenn Sie keine Benutzeranmeldedaten im Cache zwischenspeichern möchten.

   Wenn Sie mit der Konfiguration der „Dauer“-Einstellungen fertig sind, klicken Sie auf Weiter, um mit der nächsten Seite des Assistenten fortzufahren.
6. Verwenden Sie auf der Seite Zeitplan des Assistenten die Steuerelemente, um ein Datum und eine Startzeit für den Broker-Übergang festzulegen, der stattfinden soll.
   
   

   

   
   
   Sie können eine Startzeit planen, die mindestens eine Stunde vor Ihrer aktuellen Ortszeit und bis zu 3 Monate vor dem aktuellen Datum liegt. Die Startzeit muss die volle Stunde sein.
   Berücksichtigen Sie bei der Einstellung der Startzeit genügend Zeit, damit der Übergang ohne Unterbrechung ablaufen kann.
   Wenn Sie fertig sind, klicken Sie auf Weiter, um zum nächsten Schritt des Universal Broker-Konfigurationsassistenten zu gelangen.
   Hinweis: Wenn die Konsole in einer Meldung anzeigt, dass die angegebene Startzeit nicht verfügbar ist, kehren Sie zu den Einstellungen Datum und Startzeit zurück, um eine andere Zeit für Ihren Übergang anzugeben.
7. Überprüfen Sie Ihre Einstellungen auf der Seite Zusammenfassung, und klicken Sie dann auf Fertigstellen, um die Universal Broker Konfiguration und die Zeitplaneinstellungen zu speichern.
   Es wird eine Meldung angezeigt, die bestätigt, dass Sie den Übergang erfolgreich geplant haben.
   
   

   

   
   
   Nachdem der Übergang geplant ist:

   • Auf der Broker-Seite werden Details über den bevorstehenden Übergang angezeigt. Wenn die Startzeit mehr als eine Stunde entfernt ist, können Sie den Übergang neu planen, indem Sie auf den Link Zeitplan klicken.
   • Wenn Sie einen geplanten Übergang stornieren oder einen Übergang, der in weniger als einer Stunde beginnt, neu planen möchten, müssen Sie sich an den VMware Support wenden. Beachten Sie, dass der VMware Support einen Übergang, der in weniger als 15 Minuten beginnt, nicht stornieren oder neu planen kann.
   • Die Konsole zeigt weiterhin ein Benachrichtigungsbanner über den bevorstehenden Übergang an, bis die Startzeit erreicht ist. Wenn Sie im Banner auf Details anzeigen klicken, werden Sie auf die Broker-Seite weitergeleitet.
   • Benachrichtigungs- und Erinnerungsnachrichten über den bevorstehenden Übergang werden an das primäre E-Mail-Konto gesendet, das für Ihren Mandanten registriert ist.
8. Achten Sie darauf, dass Sie die folgenden Vorbereitungsaufgaben mindestens 15 Minuten vor dem geplanten Beginn der Umschaltung erledigen. Während des Übergangs können Sie auf keine Bearbeitungsfunktion auf der Konsole zugreifen.
   • Schließen Sie alle laufenden Vorgänge in der Konsole ab und speichern Sie alle Änderungen, die Sie beibehalten möchten.
   • Schließen Sie alle Konfigurationsassistenten und Dialogfelder.

   Wichtig: Stellen Sie sicher, dass alle Ihre Horizon Cloud-Pods in Microsoft Azure online sind und sich für die Dauer des Übergangs in einem fehlerfreien Bereitzustand befinden. Der Universal Broker-Dienst muss mit den Pods kommunizieren und einige Konfigurationsschritte auf den Pods durchführen, um die Broker-Aktivierungsphase des Übergangs abzuschließen. Wenn einer der Pods offline oder nicht verfügbar ist, schlägt der Übergang fehl.

   Wichtig: Wenn Sie eine hybride Umgebung haben, die sowohl aus Horizon Cloud-Pods in Microsoft Azure als auch aus Horizon-Pods auf einer VMware SDDC-basierten Plattform besteht, ist der Universal Broker-Dienst für Ihre Horizon-Pods für die Dauer des Übergangs nicht verfügbar. Außerdem können Sie während dieser Zeit den Status eines Horizon Pods nicht von überwacht auf verwaltet ändern.
9. Befolgen Sie kurz vor Beginn des Übergangs die Bildschirmanweisungen, um sich von der Konsole abzumelden und erneut anzumelden.
   
   

   

   
   
10. Lassen Sie die erste Stufe des Übergangs ohne Unterbrechung ablaufen.
    Während dieser Phase des Übergangs gilt:

    • Sie können auf keines der Bearbeitungselemente der Konsole zugreifen, und die Konsole zeigt ein Banner an, das besagt, dass der Übergang stattfindet.
      
      
      
      
    • Alle Ihre Pods in Microsoft Azure werden zu einer Site mit dem Namen Standardsite hinzugefügt.
    • Ihre VDI-Desktop-Zuweisungen werden in Multi-Cloud-Zuweisungen umgewandelt, die von Universal Broker vermittelt werden. In den Standard-Zuweisungseinstellungen ist die Verbindungsaffinität auf Nächstgelegene Site und der Scope auf In der Site eingestellt.
    • Ihre sitzungsbasierten Desktop- und Anwendungszuweisungen bleiben unverändert. Nach dem Übergang werden die Ressourcen in diesen Zuweisungen von Universal Broker vermittelt.
    • Alle Zuweisungen bleiben für Ihre Endbenutzer verfügbar, und alle aktiven Benutzersitzungen bleiben während dieser Zeit offen und voll funktionsfähig.
    Hinweis: Diese Phase des Übergangs dauert in der Regel etwa 10 Minuten, kann aber länger dauern, wenn Ihre Mandantenumgebung eine hohe Anzahl von Zuweisungen enthält. Sie können den Fortschritt überwachen, indem Sie auf Status anzeigen im Benachrichtigungsbanner klicken. Wenn diese Phase nicht innerhalb einer Stunde abgeschlossen ist, wird der Übergang als Fehlschlag gewertet.

    Die folgende Meldung erscheint, wenn diese Phase des Übergangs abgeschlossen ist.
    

    

    
    

    Hinweis: Wenn in dieser Phase des Übergangs ein Fehler auftritt, erhält der Vmware Support eine automatische Benachrichtigung zur Untersuchung und Behebung des Fehlers. Weitere Informationen finden Sie auf der Seite Broker und in den Benachrichtigungen, die an das für Ihren Mandanten registrierte primäre E-Mail-Konto gesendet werden. Nachdem der VMware Support die Ursache des Fehlers behoben hat, können Sie den Link auf der Seite Broker verwenden, um den Übergang neu zu planen.
11. Nachdem Sie sich wieder an der Konsole angemeldet haben, warten Sie, bis der Universal Broker-Dienst seinen Einrichtungsprozess abgeschlossen hat und vollständig aktiviert ist.
    Es dauert in der Regel bis zu 30 Minuten, bis die Konfigurationseinstellungen im Universal Broker-Dienst vollständig wirksam werden, da die DNS-Einträge über die DNS-Server in allen globalen Regionen propagiert werden. Abhängig von Ihren System- und Netzwerkbedingungen und der Gesamtzahl der Zuweisungen und dedizierten Benutzer-zu-Desktop-Zuweisungen in Ihrer Umgebung kann dieser Vorgang jedoch mehrere Stunden in Anspruch nehmen. Wenn der Vorgang nicht innerhalb von vier Stunden abgeschlossen ist, wird der Übergang als Fehlschlag gewertet.

    In dieser Phase des Übergangs können Sie auf alle Bearbeitungsvorgänge in der Konsole zugreifen, außer auf das Erstellen und Bearbeiten von Zuweisungen. Auch der Universal Broker-Dienst ist in dieser Zeit für das Brokering von Zuweisungen nicht verfügbar.

    Wenn die Einrichtung erfolgreich abgeschlossen ist, erscheint in der Konsole eine Benachrichtigung unter dem Glockensymbol. Auf der Seite Einstellungen > Broker wird der Status Aktiviert mit einem grünen Punkt angezeigt.

    Ihre Aufträge werden nun von Universal Broker vermittelt und der Übergang ist abgeschlossen.

    
    
    

    Wichtig: Wenn die Universal Broker-Einrichtung fehlschlägt, wird auf der Seite Einstellungen > Broker der Status Fehler mit einem roten Warnsymbol angezeigt. Um den Konfigurationsfehler zu beheben und den Universal Broker-Dienst einzurichten, wenden Sie sich an den VMware Support, wie im VMware Knowledge Base (KB)-Artikel 2006985 beschrieben.

Nächste Maßnahme

• Wenn Sie eine bestehende Integration zwischen Ihrem Horizon Cloud-Mandanten und Workspace ONE Access haben, müssen Sie die Integration aktualisieren, um die Verwendung von Universal Broker zu ermöglichen. Eine vollständige Anleitung finden Sie unter Horizon Cloud-Umgebung mit Universal Broker – Integrieren des Mandanten in Workspace ONE Access und Intelligent Hub-Dienste.
• Ändern Sie Ihre Standort- und Multi-Cloud-VDI-Zuweisungseinstellungen, um die Möglichkeiten von Universal Broker voll auszuschöpfen. Sie können z. B. weitere Pods zu einem bestehenden Auftrag hinzufügen oder die Site-Einstellungen anpassen, um eine Feinabstimmung für die Vermittlung von Aufträgen durch Universal Broker vorzunehmen. Ausführliche Informationen finden Sie unter Erstellen und Verwalten von Multi-Cloud-Zuweisungen in Ihrer Horizon Cloud Mandantenumgebung und Arbeiten mit Standorten in einer Universal Broker-Umgebung.

Was ist neu in Ihrer Mandantenumgebung nach dem Übergang zu Universal Broker?

Dieser Artikel beschreibt die Änderungen, die Sie in Ihrer Horizon Cloud-Mandantenumgebung erwarten können, nachdem Sie den Übergang von Einzel-Pod-Broker zu Universal Broker erfolgreich abgeschlossen haben. Zu den Änderungen gehören ein neues Funktionsverhalten und einige Funktionseinschränkungen.

Weitere Informationen zu bestimmten Funktionseinschränkungen in einer Universal Broker-Umgebung finden Sie unter Universal Broker – Überlegungen zu Funktionen und bekannte Einschränkungen.

Änderungen an Endbenutzer-Zuweisungen

• Alle Ihre Pods in Microsoft Azure werden zu einer Site mit dem Namen Standardsite hinzugefügt.
• VDI-Desktop-Zuweisungen werden in Multi-Cloud-Zuweisungen umgewandelt, die von Universal Broker vermittelt werden. In den Standard-Zuweisungseinstellungen ist die Verbindungsaffinität auf Nächstgelegene Site und der Scope auf In der Site eingestellt.
  Hinweis: Ein bestimmter Benutzer kann höchstens einen zugewiesenen Desktop aus einer dedizierten von Universal Broker vermittelten Zuweisung empfangen, auch wenn die Zuweisung Desktops aus mehreren Pods enthält.
  Wichtig: Wenn ein Benutzer zuvor mehrere zugewiesene Desktops aus einer dedizierten Zuweisung in einer Einzel-Pod-Broker-Umgebung erhalten hat, kann er nach dem Übergang zu einer Universal Broker-Umgebung nicht mehr auf diese Desktops zugreifen. Um auf die zugewiesenen Desktops zuzugreifen, kann der Benutzer eine direkte Verbindung mit dem FQDN des Pods herstellen, anstatt den FQDN von Universal Broker zu verwenden.
• Sitzungsbasierte Desktop- und Anwendungszuweisungen werden jetzt über Universal Broker vermittelt.

Änderungen an Desktop-Pools mit identischen Namen

Wenn Desktop-Pools in Ihren Pods vor dem Broker-Übergang denselben Namen hatten, werden sie bearbeitet, um ihnen unterschiedliche Namen zu geben. Diese Änderung stellt sicher, dass Sie eindeutig benannte Desktop-Pools aus verschiedenen Pods zu einer einzigen, von Universal Broker vermittelten Zuweisung hinzufügen können.

Nehmen Sie zum Beispiel an, dass Sie vor dem Broker-Übergang das folgende Szenario hatten:

• Pod1 enthielt einen Pool namens TestPoolName.
• Pod2 enthielt einen Pool, der ebenfalls TestPoolName hieß.

Nach dem Übergang ändern sich die Beispiel-Poolnamen wie folgt

• In Pod1 bleibt der Pool-Name TestPoolName.
• In Pod2 wird der Pool in TestPoolName1 umbenannt.

Änderungen am Präfix für VM-Namen

In einer Einzel-Pod-Broker-Umgebung vor dem Übergang kann das Präfix des VM-Namens eines Pools maximal 11 anpassbare Zeichen enthalten. Zur Bildung des Poolnamens wird an das 11-stellige Präfix eine fortlaufende Zahl (mit maximal vier Ziffern) angehängt.

Nach dem Übergang auf Universal Broker kann das Präfix für VM-Namen aus maximal neun anpassbaren Zeichen bestehen. Alle VM-Namenspräfixe, die zuvor länger als neun Zeichen waren, werden nach dem Übergang automatisch abgeschnitten.

Um den Poolnamen in einer Universal Broker-Umgebung zu bilden, werden die folgenden Zeichen an das Präfix mit neun Zeichen angehängt: zwei zufällige alphanumerische oder alphabetische Zeichen, gefolgt von einer fortlaufenden Zahl (mit maximal vier Ziffern).

Wenn mehrere Zuweisungen das gleiche Präfix für VM-Namen verwenden, könnte ein Fehler angezeigt werden, wenn Sie versuchen, eine der Zuweisungen zu bearbeiten. Um den Fehler zu beheben, ändern Sie das Präfix des VM-Namens der Zuweisung im Bearbeitungsassistenten.

Hinweis: Wenn für einen Desktop-Pool die Option Max. Anzahl Desktops auf 0 festgelegt ist, werden das Präfix des VM-Namens und der Poolname in der Horizon Universal Console nach dem Übergang unverändert angezeigt. Um die Konsole so zu aktualisieren, dass das neue VM-Namenspräfix und der Poolname angezeigt werden, aktualisieren Sie die übergegangene Zuweisung mit dem Bearbeitungsassistenten.

Funktionsüberlegungen nach dem Übergang

Die folgenden Überlegungen gelten für bestimmte Funktionen nach dem Übergang zu Universal Broker.

• Anpassungszuweisungen (auch URL-Umleitung-Zuweisungen genannt) werden nicht unterstützt.
• Die Funktion zum Abbrechen von Aufgaben wird nicht unterstützt, wenn Ihre Pods mit einer früheren Version als Manifest 2474.0 ausgeführt werden. Um diese Funktion zu verwenden, müssen Sie Ihre Pods auf Manifest 2474.0 oder höher aktualisieren.
• Wenn die Horizon Cloud on Microsoft Azure-Bereitstellungen über eine vorhandene Integration vor dem Übergang mit Workspace ONE Access verfügen, müssen Sie die Integration in einen Zustand nach dem Übergang aktualisieren, um die Verwendung von Universal Broker zu ermöglichen. Eine vollständige Anleitung finden Sie unter Horizon Cloud-Umgebung mit Universal Broker – Integrieren des Mandanten in Workspace ONE Access und Intelligent Hub-Dienste.

  Beachten Sie, dass Sie beim Aktualisieren dieser Integration den Workflow Horizon Universal Console Bereinigen verwenden müssen, um alle vorhandenen Sammlungen virtueller Apps zu bereinigen, über die diese Bereitstellungen möglicherweise verfügen. Der Bereinigungs-Workflow sorgt dafür, dass dieselben Apps weiterhin in Workspace ONE Access und Intelligent Hub Services funktionieren, indem die modernen Funktionen der integrierten Dienste Universal Broker, Workspace ONE Access und Intelligent Hub Services anstelle der veralteten Funktion für Sammlungen virtueller Pro-Pod-Apps verwendet werden. Wie vom VMware Workspace ONE Access-Produktteam bestätigt, wird die Funktion „Sammlungen virtueller Apps“ des VMware Workspace ONE Access-Produkts in dieser Konfiguration nicht unterstützt, wenn Universal Broker mit Ihren Horizon Cloud on Microsoft Azure-Bereitstellungen verwendet wird. Der Grund dafür ist, dass Universal Broker die modernere Brokering-Technologie als das alte „Pro Pod“-Brokering ist, was bedeutet, dass die Integration von Universal Broker in Workspace ONE Access die Verwendung der veralteten Sammlungen virtueller Apps pro Pod ersetzt. Daher verfügt Universal Broker überhaupt nicht über ein Konzept von Sammlungen virtueller Apps für Horizon Cloud on Microsoft Azure-Bereitstellungen.

Wichtig: Die Löschschutzfunktion für Bestandslistenausfälle wird nicht unterstützt, wenn Ihre Pods mit einer früheren Version als Manifest 2474.0 ausgeführt werden. Um diese Funktion zu verwenden, müssen Sie Ihre Pods auf Manifest 2474.0 oder höher aktualisieren.

Wenn Ihre Pods beispielsweise mit einer früheren Version als Manifest 2474.0 ausgeführt wurden und der Löschschutz vor dem Übergang aktiviert war, funktioniert die Funktion nach dem Übergang nicht mehr. Wenn Sie dann Ihre Pods auf Manifest 2474.0 oder höher aktualisieren, wird die Löschschutzfunktion wieder funktionsfähig.