Grundlegendes zum Übergangsprozess von 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. Erfahren Sie mehr ü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 aus einem einzelnen Pod enthalten, 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 – Systemanforderungen für den Übergang zu Universal Broker beschriebenen Voraussetzungen erfüllt.

Warum sollten Sie zu Universal Broker wechseln?

Wenn Sie auf Universal Broker umsteigen, profitieren Sie von den folgenden wichtigen Vorteilen.

• Endbenutzerzuweisungen mit VDI-Desktops aus mehreren Pods

Beim Single-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, was auch als Multi-Cloud-Zuweisung bezeichnet wird. Ein Endbenutzer kann auf die Zuweisung zugreifen und einen Desktop von jedem Pod erhalten, der in dieser Zuweisung enthalten ist. Weitere Informationen finden Sie unter Einführung in Horizon Service Universal Broker und den zugehörigen 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 durch Universal Broker und nicht durch 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 Universal Broker-Konfigurationseinstellungen definieren. Über einen einzigen FQDN können Benutzer von jedem Standort in Ihrer Umgebung aus auf Zuweisungen aller teilnehmenden Pods zugreifen – sowohl Horizon Cloud-Pods in Microsoft Azure als auch Horizon-Pods auf einer vSphere-basierten SDDC-Plattform. Es ist keine interne Vernetzung zwischen Ihren Pods erforderlich.

• Globale Pod-Konnektivität und Bewusstsein für optimale Leistung

Universal Broker behält die direkte Konnektivität mit jedem Pod bei, der an Multi-Cloud-Zuweisungen teilnimmt, und bleibt über den Verfügbarkeitsstatus jedes Pods informiert. Daher kann Universal Broker die Verbindungsanforderungen von Endbenutzern verwalten und direkt von diesen Pods aus an virtuelle Ressourcen weiterleiten. Ein globaler Serverlastausgleich (GSLB) oder eine podübergreifende Netzwerkkommunikation, die zu Leistungseinbußen und Latenzproblemen führen kann, ist nicht erforderlich.

• 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 weist einige Funktionseinschränkungen auf. Wenn Ihr Anwendungsfall eine Funktion erfordert, die Universal Broker nicht unterstützt, sollten Sie Ihre Mandantenumgebung mit Einzel-Pod-Brokering beibehalten, bis Universal Broker die Funktion unterstützt. Eine Liste der aktuellen Einschränkungen für Universal Broker finden Sie unter Universal Broker – Überlegungen zu Funktionen und bekannte Einschränkungen.

Was passiert während des Broker-Übergangs?

Der Übergangs-Workflow besteht aus mehreren Phasen. Eine detaillierte Schritt-für-Schritt-Anleitung zum Durchführen des Übergangs finden Sie unter Planen und Abschließen des Übergangs von 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 definieren Sie die Konfigurationsoptionen, die zum Einrichten des Universal Broker-Diensts während des Übergangs verwendet werden.
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 sind und sich in einem ordnungsgemäßen, einsatzbereiten Zustand befinden.
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 Bearbeitungssteuerelemente 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 Standard-Site hinzugefügt.
• Ihre VDI-Desktop-Zuweisungen werden in Multi-Cloud-Zuweisungen umgewandelt, die von Universal Broker vermittelt werden. In den Standardzuweisungseinstellungen ist die Verbindungsaffinität auf Nächstgelegene Site und der Geltungsbereich auf Innerhalb der Site festgelegt.
• 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 Einrichtungsvorgang ab und wird vollständig aktiviert. Sie können auf alle Bearbeitungsvorgänge in der Konsole zugreifen, außer auf das Erstellen und Bearbeiten von Zuweisungen.

Hinweis: Diese Phase des Übergangs dauert in der Regel bis zu 30 Minuten. Abhängig von Ihren System- und Netzwerkbedingungen und der Gesamtzahl der Zuweisungen und dedizierten Benutzer-zu-Desktop-Zuordnungen 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 Neue Funktionen in Ihrer Mandantenumgebung nach dem Übergang zu Universal Broker.

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

• Ändern Sie Ihre Standort- und Multi-Cloud-VDI-Zuweisungseinstellungen, um die Universal Broker-Funktionen vollständig nutzen zu können. Beispielsweise können Sie weitere Pods zu einer vorhandenen Zuweisung hinzufügen oder die Site-Einstellungen anpassen, um eine Feinabstimmung der Ressourcenzuteilung durch Universal Broker an Ihre Benutzer vorzunehmen. Detaillierte 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 über eine bestehende Integration zwischen Ihrem Horizon Cloud-Mandanten und Omnissa Access verfügen, müssen Sie die Integration aktualisieren, um die Verwendung von Universal Broker zu ermöglichen. Vollständige Anweisungen finden Sie unter Horizon Cloud-Umgebung mit Universal Broker – Integrieren des Mandanten in Omnissa Access und Intelligent Hub-Dienste.

Hinweis: Wie vom Access-Produktteam bestätigt, wird die Funktion "Sammlungen virtueller Apps" des Access-Produkts mit 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. Dies bedeutet, dass die Integration von Universal Broker in Access die Verwendung der veralteten Sammlungen virtueller Pro-Pod-Apps für Horizon Cloud on Microsoft Azure-Bereitstellungen ersetzt. Aus diesem Grund verfügt Universal Broker überhaupt nicht über ein Konzept von Sammlungen virtueller Apps für Horizon Cloud on Microsoft Azure-Bereitstellungen, wodurch die Verwendung von Sammlungen virtueller Apps mit den Universal Broker- und Horizon Cloud on Microsoft Azure-Konfigurationen nicht unterstützt wird.

Wenn Universal Broker für Ihre Horizon Cloud on Microsoft Azure-Bereitstellungen konfiguriert ist und Sie Access- und Intelligent Hub-Dienste mit diesen Horizon Cloud on Microsoft Azure-Bereitstellungen verwenden möchten, 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 Apps weiterhin in Access- und Intelligent Hub-Diensten, indem die modernen Funktionen des integrierten Universal Broker und der Access- und Intelligent Hub-Dienste verwendet werden.

Horizon Cloud – Systemanforderungen 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 der Verwendung von Einzel-Pod-Brokering zu Universal Broker planen und durchführen können. Außerdem werden Sie durch die Planungs- und Vorbereitungsschritte für die Unterstützung des neuen Verbindungs-FQDN für Universal Broker geführt.

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 verwenden, und Horizon Cloud-Pods mit Einzel-Pod-Brokering, müssen Sie besonders beachten, dass die Einstellungen für die Zwei-Faktor-Authentifizierung in den bereits konfigurierten Universal Broker-Einstellungen mit denen der Horizon Cloud-Pods übereinstimmen.

• Wenn 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 die 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 diese Kriterien für die Konfiguration von RSA SecurID auf ihren externen Gateways nicht erfüllen, müssen Sie zur Verwendung der Zwei-Faktor-Authentifizierung mit allen Pods in Ihrer Flotte (sowohl Horizon-Pods als auch Horizon Cloud-Pods) für jeden Pod ein externes Unified Access Gateway mit konfigurierter RADIUS-Zwei-Faktor-Authentifizierung verwenden.

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 dem 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 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 Access und Intelligent Hub-Dienste beschrieben.

• Wenn Sie die Funktion zum Abbrechen von Aufgaben 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 Manifesten vor Manifest 2474.0 ausgeführt werden. Wichtig: Stellen Sie sicher, dass alle Horizon Cloud-Pods online sind und sich in einem fehlerfreien, einsatzbereiten Zustand befinden. Der Universal Broker-Dienst muss mit diesen Pods kommunizieren und einige Konfigurationsschritte auf den Pods durchführen, um den Übergangsprozess 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 gleichzeitig mit dem Übergang stattfinden.

• Der Speicherort des Pods wird konfiguriert, indem ein gültiger Speicherort aus den Menüoptionen im Pod-Konfigurationsassistenten ausgewählt wird. Wenn der Speicherort des Pods durch manuelle Eingabe in ein Textfeld konfiguriert wurde, schlägt der Übergang fehl.

Hinweis: Dieses Problem mit einem manuell eingegebenen Speicherort tritt eher bei Pods auf, die ursprünglich 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 Seite "Kapazität" der Konsole und überprüfen Sie den Wert der Spalte "Speicherort" für jeden Horizon Cloud-Pod. Wenn der Wert der Spalte "Ort" wie ein manuell eingegebener Name aussieht, verwenden Sie die Aktion Bearbeiten für den Pod, gehen Sie zum Schritt Pod-Details und bearbeiten Sie das Feld Ort , 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 von 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. (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 über alle Pods hinweg, um denselben Authentifizierungsdienst zu verwenden. Dazu gehören alle Horizon-Pods Ihres Mandanten, die sich im verwalteten Zustand befinden. Das Ergebnis ist, dass alle einen übereinstimmenden Authentifizierungstyp verwenden – alle verwenden RADIUS oder alle verwenden RSA SecurID.
• Wenn die Horizon Cloud-Pods diese Kriterien nicht erfüllen, um RSA SecurID auf ihren externen Gateways zu konfigurieren, müssen Sie bei Verwendung der Zwei-Faktor-Authentifizierung mit allen Pods in Ihrer Flotte (sowohl Horizon-Pods als auch Horizon Cloud-Pods) alle externen Unified Access Gateway-Instanzen über alle Pods hinweg so konfigurieren, dass sie denselben RADIUS-Authentifizierungsdienst verwenden. Dazu gehören alle Horizon-Pods Ihres Mandanten, die sich im verwalteten Zustand befinden.

Hinweis: Wenn ein Pod nur eine interne Unified Access Gateway-Instanz enthält, überschreibt Universal Broker die Netzwerkrichtlinie, die auf der Registerkarte Netzwerkbereiche der Broker-Seite definiert ist, und leitet alle Benutzer unabhängig von ihrer IP-Adresse an diese Unified Access Gateway-Instanz weiter.

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 "DNS-Anforderungen für Pod-Bereitstellung und -Betrieb" unter DNS-Anforderungen für einen Horizon Cloud-Pod in Microsoft Azure.
• Jeder Pod ist mit den erforderlichen Ports und Protokollen konfiguriert, wie im Abschnitt "Für Universal Broker erforderliche Ports und Protokolle" unter Port - und Protokollanforderungen für einen Horizon Cloud-Pod beschrieben.

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 zugreifen – von jedem Pod in jeder Site in Ihrer Umgebung –, indem sie sich mit dem einen FQDN des Universal Broker-Clouddiensts verbinden. Universal Broker leitet jede Benutzeranforderung an den individuellen FQDN des am besten geeigneten Pods weiter, der die Anforderung erfüllen kann.

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

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

Planen und Vorbereiten des Broker-Übergangs

Da der Broker-Übergang wichtige Änderungen an Ihrem Netzwerk- und Zuweisungsworkflow mit sich bringt, stellen Sie sicher, dass Sie die erforderlichen 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 basierend auf Ihrem Anwendungsfall für den Übergang.

Anwendungsfall "Übergang"	Planungs- und Vorbereitungsschritte
Ihre Umgebung besteht aus einem einzelnen Pod, und Sie möchten den vorhandenen FQDN dieses Pods als Universal Broker-FQDN verwenden	Legen Sie in der Konfigurationsphase des Übergangsplanungsprozesses den vorhandenen FQDN des Pods als benutzerdefinierten FQDN für den Universal Broker-Dienst fest. Planen Sie den Übergang für ein Datum und eine Uhrzeit, die zu minimalen Unterbrechungen bei der Zuweisung Ihrer Endbenutzer führen. 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 darüber, dass sie ihre Verbindungssitzungen mit dem früheren FQDN des Pods fortsetzen können, der jetzt der Universal Broker-FQDN ist.
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 Verfahren 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. Planen Sie den Übergang für ein Datum und eine Uhrzeit, die zu minimalen Unterbrechungen bei der Zuweisung Ihrer Endbenutzer führen. Planen Sie ausreichend Zeit für die Benutzerschulung und die Neukonfiguration der Client-Software ein, entsprechend dem Umfang Ihrer Pod-Bereitstellungen. 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 Clientsystemen 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 Abschließen des Übergangs von Einzel-Pod-Broker zu Universal Broker

Dieses Thema führt Sie durch die Schritte der Planung, Vorbereitung und Durchführung 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 definieren und die Phasen des Prozesses für einen erfolgreichen Übergang reibungslos durchlaufen.

Ein Benachrichtigungsbanner mit einer Schaltfläche Zeitplan wird oben in der 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 zur Fehlerbedingung anzuzeigen. Sie müssen die erforderlichen Schritte ausführen, um den Fehlerzustand zu beseitigen, bevor Sie den Übergang planen können.

Voraussetzungen

Stellen Sie sicher, dass Ihre Mandantenumgebung alle unter Horizon Cloud – Systemanforderungen für den Übergang zu Universal Broker beschriebenen Voraussetzungen erfüllt.

Vorgehensweise

1. Klicken Sie im Benachrichtigungsbanner für den Broker-Übergang auf Zeitplan .

Diese Aktion leitet Sie auf die Seite "Broker" weiter. Die Seite zeigt an, dass Einzel-Pod-Broker derzeit für Ihren Mandanten 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 Brokering-Verbindung. Diese Einstellungen definieren die Adresse der dedizierten Verbindung, die Ihre Endbenutzer für den Zugriff auf von Universal Broker zugewiesene Ressourcen verwenden.

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 als Typ entweder Von Omnissa bereitgestellt oder Benutzerdefinierter vollqualifizierter Domänenname (FQDN) aus.

2. Geben Sie zusätzliche Einstellungen für den ausgewählten FQDN-Typ an.

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

Einstellung	Beschreibung
Unterdomäne	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 vom System bereitgestellten Domäne vorangestellt, um den Brokering-FQDN zu bilden. Hinweis: Einige Zeichenfolgen sind nicht zulässig oder vom System reserviert. Zu dieser Kategorie von Zeichenfolgen gehören allgemeine Wörter wie book, bekannte firmeneigene Begriffe wie gmail und protocol. coding und Open-Source-Begriffe wie PHP und SQL. Das System verbietet auch eine Kategorie von Mustern dieser Zeichenfolgen, wie z. B. mail0, mail1, mail2 usw. Wenn Sie jedoch einen unzulässigen Namen in dieses Feld eingeben, 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, falls Ihr 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 verwendet das Format https://your-sub-domain.firstgen.omnissahorizon.com. Stellen Sie Ihren Endbenutzern diesen FQDN zur Verfügung, damit sie über Horizon Client eine Verbindung mit dem Universal Broker-Dienst herstellen können. Universal Broker verwaltet die DNS- und 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 werden. Ihr benutzerdefinierter FQDN fungiert als Alias für den automatisch generierten, vom System bereitgestellten FQDN, der die Verbindung zum -Dienst abschließt. Sie müssen der Besitzer des Domänennamens sein, der in Ihrem benutzerdefinierten FQDN angegeben ist, und ein Zertifikat bereitstellen, das diese Domäne validieren kann. 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 einen CNAME-Eintrag auf Ihrem DNS-Server erstellen, der Ihren benutzerdefinierten FQDN dem vom System bereitgestellten FQDN zuordnet, der die interne Verbindungsadresse des Universal Broker-Dienstes darstellt. Beispielsweise kann der Datensatz vdi.examplecompany.com automatisch generierten string.firstgen.omnissahorizon.com zuordnen.
Zertifikat	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 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-CA-Zertifikat, privater Schlüssel. Der Universal Broker-Dienst verwendet dieses Zertifikat, um vertrauenswürdige Verbindungssitzungen mit Clients herzustellen.
Kennwort	Geben Sie das Kennwort für das hochgeladene Zertifikat ein.
Von Omnissa bereitgestellter FQDN	Dieses schreibgeschützte Feld zeigt den vom System bereitgestellten FQDN an, der automatisch für den Brokering-Dienst generiert wird. Der FQDN hat das Format https://auto-generated-string.firstgen.omnissahorizon.com. Dieser vom System bereitgestellte FQDN ist für Endbenutzer nicht sichtbar und stellt die interne Verbindungsadresse des Universal Broker-Diensts dar. Ihr benutzerdefinierter FQDN fungiert als Alias für diesen vom System bereitgestellten FQDN. Wichtig: Sie müssen eine Aliaszuordnung einrichten, indem Sie einen CNAME-Datensatz auf Ihrem DNS-Server erstellen, der Ihren benutzerdefinierten FQDN dem vom System bereitgestellten FQDN zuordnet. Beispielsweise kann der Datensatz vdi.examplecompany.com auto-generated-string.firstgen.omnissahorizon.com zuordnen.

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 entsprechende 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 verwenden zu können, müssen Sie zuerst den entsprechenden Authentifizierungsdienst auf jeder externen Unified Access Gateway-Instanz innerhalb jedes teilnehmenden Pods konfigurieren. Die Konfigurationen externer Unified Access Gateway-Instanzen müssen innerhalb der teilnehmenden Pods 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 für den Protokolldatenverkehr zwischen Horizon Client und virtuellen Ressourcen auf Unified Access Gateway angewiesen ist, 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
Zwei-Faktor-Authentifizierung	Um die Zwei-Faktor-Authentifizierung zu verwenden, aktivieren Sie diese Umschaltoption. Wenn Sie den Schalter aktivieren, werden Ihnen zusätzliche Optionen zum Konfigurieren der Zwei-Faktor-Authentifizierung angezeigt.
Benutzernamen beibehalten	Aktivieren Sie diesen Schalter, um den Active Directory-Benutzernamen des Benutzers während der Authentifizierung bei Universal Broker beizubehalten. Wenn aktiviert: Der Benutzer muss für die zusätzliche Authentifizierungsmethode über dieselben Anmeldedaten wie für die Active Directory-Authentifizierung bei Universal Broker verfügen. Der Benutzer kann den Benutzernamen auf dem Client-Anmeldebildschirm nicht ändern. Wenn diese Umschaltoption deaktiviert ist, kann der Benutzer auf dem Anmeldebildschirm einen anderen Benutzernamen eingeben.
Typ	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 angezeigt : RADIUS und RSA SecurID. 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 ab, der auf den Gateways der Pods konfiguriert ist: – Nur Horizon-Pods – Der Typ, den Sie hier auswählen, wird im Client verwendet. 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 RSA SecurID hier ausgewählt ist, werden die RSA-Authentifizierungsanforderungen der Benutzer nur über die Unified Access Gateway-Instanzen Ihrer Horizon-Pods gestellt. 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.
Hinweistext anzeigen	Aktivieren Sie diesen Schalter, um eine Textzeichenfolge zu konfigurieren, die auf dem Client-Anmeldebildschirm angezeigt wird, um den Benutzer zur Eingabe seiner Anmeldedaten für die zusätzliche Authentifizierungsmethode aufzufordern.
Benutzerdefinierter Hinweistext	Geben Sie den Hinweis ein, der auf dem Anmeldebildschirm des Clients angezeigt werden soll. Der angegebene Hinweis wird dem Endbenutzer wie folgt angezeigt: Geben Sie Ihren DisplayHint-Benutzernamen und das Kennwort ein, wobei DisplayHint die Textzeichenfolge ist, die 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 korrekten Anmeldedaten helfen. Beispiel: Wenn Sie den Ausdruck Firmenbenutzername und Domänenkennwort darunter für eingeben , wird der Endbenutzer aufgefordert mit folgendem Inhalt: Geben Sie den Benutzernamen Ihres Unternehmens und das Domänenkennwort unten als Benutzernamen und Kennwort ein.
Zwei-Faktor-Authentifizierung überspringen	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 Definieren interner Netzwerkbereiche für Universal Broker 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 sowohl ihre Active Directory-Anmeldedaten als auch 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.
Öffentliche IP-Bereiche	Dieses Feld wird angezeigt, wenn Zwei-Faktor-Authentifizierung überspringen aktiviert ist. Wenn auf der Registerkarte "Netzwerkbereiche" der Seite "Broker" bereits ein oder mehrere öffentliche IP-Bereiche 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 sind, können Sie dieses Feld verwenden, um die öffentlichen IP-Bereiche anzugeben, die Ihr internes Netzwerk repräsentieren, um die Eingabeaufforderungen für die Zwei-Faktor-Authentifizierung für Datenverkehr aus diesen Bereichen zu überspringen. Universal Broker betrachtet jeden Benutzer, der eine Verbindung über eine IP-Adresse innerhalb eines dieser Bereiche herstellt, als internen Benutzer. 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 für die 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, wird die Horizon Client-Verbindungssitzung des Benutzers geschlossen.

Einstellung	Beschreibung
Client-Taktsignalintervall	Steuert das Intervall in Minuten zwischen Horizon Client-Taktsignalen und den Status der Verbindung des Benutzers mit Universal Broker. Anhand dieser Taktsignale wird Universal Broker mitgeteilt, wie viel Leerlaufzeit während der Horizon Client-Verbindungssitzung vergangen ist. Die Leerlaufzeit wird gemessen, wenn keine Interaktion mit dem Endpunktgerät stattfindet, auf dem Horizon Client ausgeführt wird. Inaktivität bei der Anmeldesitzung beim Gastbetriebssystem, das dem dem Benutzer zugewiesenen Desktop zugrunde liegt, wirkt sich nicht auf diese Leerlaufzeit aus. In großen Desktop-Bereitstellungen kann eine Erhöhung des Client-Taktsignalintervalls den Netzwerkdatenverkehr reduzieren und die Leistung verbessern.
Client-Leerlaufbenutzer	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 schließt alle aktiven Horizon Client-Sitzungen. Um eine Verbindungssitzung erneut zu öffnen, muss der Benutzer seine Authentifizierungsanmeldedaten erneut auf dem Anmeldebildschirm von Universal Broker eingeben. Hinweis: Um zu vermeiden, dass Benutzer unerwartet von ihren zugewiesenen Desktops getrennt werden, legen Sie die Zeitüberschreitung für Client-Leerlaufbenutzer auf einen Wert fest, der mindestens doppelt so groß ist wie der Wert des Client-Taktsignalintervalls.
Client-Broker-Sitzung	Maximal zulässige Zeit (in Minuten) für eine Horizon Client-Verbindungssitzung, bevor die Authentifizierung des Benutzers abläuft. Der Zeitpunkt beginnt, wenn sich der Benutzer bei Universal Broker authentifiziert. Wenn die Zeitüberschreitung der Sitzung eintritt, kann der Benutzer weiterhin auf dem zugewiesenen Desktop arbeiten. Wenn er jedoch eine Aktion (z. B. das Ändern von Einstellungen) durchführt, die eine Kommunikation mit Universal Broker erfordert, fordert Horizon Client ihn auf, seine Universal Broker-Anmeldedaten erneut einzugeben. Hinweis: Die Zeitüberschreitung für die Client-Broker-Sitzung muss größer oder gleich der Summe des Werts für das Client-Taktsignalintervall und der Zeitüberschreitung für Client-Leerlaufbenutzer sein.
Client-Anmeldedaten-Cache	Steuert, ob Benutzeranmeldedaten im Cache des Clientsystems gespeichert werden. Geben Sie 1 ein, um Benutzeranmeldedaten im Cache zu speichern. Geben Sie 0 ein, wenn Sie keine Benutzeranmeldedaten im Cache speichern möchten.

Wenn Sie mit der Konfiguration der Einstellungen für die Dauer 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 anzugeben, 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 zur vollen Stunde liegen.

Planen Sie beim Festlegen der Startzeit genügend Zeit ein, damit der Übergang ohne Unterbrechung ablaufen kann.

Wenn Sie fertig sind, klicken Sie auf Weiter , um mit dem nächsten Schritt des Universal Broker-Konfigurationsassistenten fortzufahren.

Hinweis: Wenn in der Konsole eine Meldung angezeigt wird, die besagt, dass die angegebene Startzeit nicht verfügbar ist, kehren Sie zu den Einstellungen Datum und Startzeit zurück, um eine andere Zeit für den Übergang anzugeben.

7. Überprüfen Sie Ihre Einstellungen auf der Seite Übersicht und klicken Sie dann auf Beenden , 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 Seite "Broker" 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 Horizon Cloud Support wenden. Beachten Sie, dass der Horizon Cloud-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 zur Seite "Broker" 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. Stellen Sie sicher, dass Sie die folgenden Vorbereitungsaufgaben mindestens 15 Minuten vor dem geplanten Beginn des Übergangs abschließen. Während des Übergangs können Sie auf keine Bearbeitungsvorgänge 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, einsatzbereiten Zustand 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 über eine Hybridumgebung verfügen, die sowohl aus Horizon Cloud-Pods in Microsoft Azure als auch aus Horizon-Pods auf einer vSphere-basierten SDDC-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" in "verwaltet" ändern.

9. Befolgen Sie kurz vor Beginn des Übergangs die Anweisungen auf dem Bildschirm, um sich von der Konsole abzumelden und erneut anzumelden.

10. Lassen Sie die erste Stufe des Übergangs ohne Unterbrechung ablaufen.

In dieser Phase des Übergangs gilt Folgendes:

• Sie können auf keines der Bearbeitungssteuerelemente 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 Standard-Site hinzugefügt.
• Ihre VDI-Desktop-Zuweisungen werden in Multi-Cloud-Zuweisungen umgewandelt, die von Universal Broker vermittelt werden. In den Standardzuweisungseinstellungen ist die Verbindungsaffinität auf Nächstgelegene Site und der Geltungsbereich auf Innerhalb der Site festgelegt.
• 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 große Anzahl von Zuweisungen enthält. Sie können den Fortschritt überwachen, indem Sie im Benachrichtigungsbanner auf Status anzeigen klicken. Wenn diese Phase nicht innerhalb einer Stunde abgeschlossen ist, kommt es zu einer Zeitüberschreitung und der Übergang wird als Fehlschlag gewertet.

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

Hinweis: Wenn in dieser Phase des Übergangs ein Fehler auftritt, erhält der Horizon Cloud-Support eine automatische Benachrichtigung und untersucht und behebt die Ursache des Fehlers. Weitere Informationen finden Sie auf der Seite Broker und in den Benachrichtigungen, die an das primäre E-Mail-Konto gesendet werden, das für Ihren Mandanten registriert ist. Nachdem der Horizon Cloud-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 bei der Konsole angemeldet haben, warten Sie, bis der Universal Broker-Dienst seinen Einrichtungsvorgang 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 DNS-Datensätze auf 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-Zuordnungen 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. Außerdem ist der Universal Broker-Dienst in dieser Zeit für das Brokering von Zuweisungen nicht verfügbar.

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

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

Wichtig: Wenn die Einrichtung der Universal Broker 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, öffnen Sie eine Support-Anfrage, wie im KB-Artikel 2006985 beschrieben.

Nächster Schritt

• Wenn Sie über eine bestehende Integration zwischen Ihrem Horizon Cloud-Mandanten und Access verfügen, müssen Sie die Integration aktualisieren, um die Verwendung von Universal Broker zu ermöglichen. Vollständige Anweisungen finden Sie unter Horizon Cloud-Umgebung mit Universal Broker – Integrieren des Mandanten in Access und Intelligent Hub-Dienste.
• Ändern Sie Ihre Standort- und Multi-Cloud-VDI-Zuweisungseinstellungen, um die Universal Broker-Funktionen vollständig nutzen zu können. Beispielsweise können Sie weitere Pods zu einer vorhandenen Zuweisung hinzufügen oder die Site-Einstellungen anpassen, um eine Feinabstimmung der Vermittlung von Zuweisungen 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 Sites in einer Universal Broker-Umgebung.

Neuheiten in Ihrer Mandantenumgebung nach dem Übergang zu Universal Broker

In diesem Artikel werden die Änderungen beschrieben, 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 Endbenutzerzuweisungen

• Alle Ihre Pods in Microsoft Azure werden zu einer Site mit dem Namen Standard-Site hinzugefügt.
• VDI-Desktop-Zuweisungen werden in Multi-Cloud-Zuweisungen umgewandelt, die von Universal Broker vermittelt werden. In den Standardzuweisungseinstellungen ist die Verbindungsaffinität auf Nächstgelegene Site und der Geltungsbereich auf Innerhalb der Site festgelegt.

Hinweis: Ein bestimmter Benutzer kann maximal einen zugewiesenen Desktop aus einer dedizierten Zuweisung empfangen, die von Universal Broker vermittelt wird, 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 Universal Broker-FQDN zu verwenden.

• Sitzungsbasierte Desktop- und Anwendungszuweisungen werden jetzt durch 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 einzelnen von Universal Broker vermittelten Zuweisung hinzufügen können.

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

• Pod1 enthielt einen Pool mit dem Namen TestPoolName.
• Pod2 enthielt einen Pool, der ebenfalls TestPoolName hieß.

Nach dem Übergang ändern sich die Beispielpoolnamen wie folgt:

• In Pod1 bleibt der Poolname 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 aufweisen. Zur Bildung des Poolnamens wird eine fortlaufende Zahl (mit maximal vier Ziffern) an das 11-stellige Präfix angehängt.

Nach dem Übergang zu Universal Broker kann das Präfix für VM-Namen aus maximal neun anpassbaren Zeichen bestehen. Alle Präfixe für VM-Namen, 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 neunstellige Präfix angehängt: zwei zufällige alphanumerische oder alphabetische Zeichen, gefolgt von einer fortlaufenden Zahl (mit maximal vier Ziffern).

Wenn mehrere Zuweisungen dasselbe Präfix für VM-Namen verwenden, kann ein Fehler auftreten, 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 als URL-Umleitungszuweisungen bezeichnet) 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 verwenden zu können, 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 mit Access vor dem Übergang verfügen, müssen Sie die Integration in einen Zustand nach dem Übergang aktualisieren, um die Verwendung von Universal Broker zu ermöglichen. Vollständige Anweisungen finden Sie unter Horizon Cloud-Umgebung mit Universal Broker – Integrieren des Mandanten in Omnissa 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 Access- und Intelligent Hub-Diensten funktionieren, indem die modernen Funktionen des integrierten Universal Broker und der Access- und Intelligent Hub-Dienste anstelle der veralteten Funktion "Sammlungen virtueller Apps pro Pod" verwendet werden. Wie vom Access-Produktteam bestätigt, wird die Funktion "Sammlungen virtueller Apps" des Access-Produkts mit 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 Access die Verwendung der veralteten Sammlungen virtueller Pro-Pod-Apps ersetzt. Aus diesem Grund verfügt Universal Broker überhaupt nicht über ein Konzept der Sammlung 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 verwenden zu können, 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 ein Upgrade Ihrer Pods auf Manifest 2474.0 oder höher durchführen, wird die Löschschutzfunktion wieder funktionsfähig.