EnglishFrançaisDeutschEspañolItaliano日本語한국어NederlandsPortuguês (Brasil)中文 (简体)中文 (繁體, 台灣)
Skip to main content

1. September 2026

Einführung in Horizon Service Universal Broker

Dieser Artikel ist eine kurze Einführung in Universal Broker, einen der Dienste der Horizon-Steuerungsebene. Der Universal Broker ist ein cloudbasierter Dienst, der die Vermittlung von Ressourcen ermöglicht, die sich über mehrere Pod-Bereitstellungen erstrecken, unabhängig von der Infrastruktur, auf der sie ausgeführt werden. Der Dienst trifft auch intelligente Brokering-Entscheidungen basierend auf den geografischen Standorten der Benutzer und Pods.

Übersicht über Universal Broker

Universal Broker, die cloudbasierte First-Gen-Brokering-Technologie von Omnissa, kann verwendet werden, wenn Ihr Mandant über mindestens eine der folgenden Voraussetzungen verfügt:

  • Horizon-Pods – Pods, die auf der Horizon Connection Server-Technologie basieren
  • Horizon Cloud on Microsoft Azure-Pods und alle diese Pods führen das Pod-Manifest 2298.0 oder höher aus.

Detaillierte Informationen dazu, wie die Systemkomponenten der Universal Broker-Lösung zusammenarbeiten, um Verbindungsanforderungen von Benutzern an Zuweisungen zu verwalten, finden Sie unter Systemarchitektur und Komponenten von Universal Broker.

Allgemeines Diagramm der Universal Broker-Systemarchitektur

Hauptmerkmale

Universal Broker bietet die folgenden wichtigen Funktionen:

  • Einzelner Verbindungs-FQDN für alle Remoteressourcen

    Endbenutzer können auf Multi-Cloud-Zuweisungen in Ihrer Umgebung zugreifen, indem sie eine Verbindung mit einem vollqualifizierten Domänennamen (FQDN) herstellen, den Sie in den Universal Broker-Konfigurationseinstellungen definieren. Über den einzelnen Universal Broker-FQDN können Benutzer auf Zuweisungen von jedem teilnehmenden Pod an jeder Site in Ihrer Umgebung zugreifen. Es ist keine interne Vernetzung zwischen Ihren Pods erforderlich.

    Diagramm einer einzelnen FQDN-Verbindung für Universal Broker

  • 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.

Brokering und Endbenutzer-Desktop-Pools und Remoteanwendungen

Zuweisungen sind konzeptionelle Einheiten in der Horizon Universal Console. Mithilfe der -Konsole definieren Sie mithilfe von Zuweisungen Pools von virtuellen Endbenutzer-Desktops und Remoteanwendungen und erteilen sie Ihren Endbenutzern. In der -Konsole erstellen Sie beispielsweise Zuweisungen von VDI-Desktops oder Zuweisungen von RDSH-Ressourcen und erteilen dann Ihren Endbenutzern Berechtigungen für diese Zuweisungen.

Der Universal Broker verwaltet die Verbindungsanforderung eines Clientbenutzers mit einer berechtigten Zuweisung und handelt die Verbindungssitzung mit einer geeigneten Ressource aus, die diese Anforderung erfüllt. Der Universal Broker kennt die geografische Lokalität und die Pod-Topologie. Anhand dieser Informationen sucht der Universal Broker nach den besten Ressourcen, um die Verbindungsanforderungen der Benutzer basierend auf der Site-Konfiguration und der Ressourcenverfügbarkeit zu erfüllen.

In den folgenden Abschnitten finden Sie eine Liste der verfügbaren Zuweisungstypen nach Pod-Typ.

Endbenutzerzuweisungen mithilfe von Ressourcen aus in Microsoft Azure bereitgestellten Horizon Cloud-Pods

Wenn die Universal Broker-Konfiguration für die Horizon Cloud-Pods in Ihrer Pod-Flotte abgeschlossen ist, sind diese Zuweisungstypen möglich:

Endbenutzerzuweisungen, die Ressourcen aus cloudverbundenen Horizon-Pods verwenden

Wenn die Universal Broker-Konfiguration für die Horizon-Pods in Ihrer Pod-Flotte abgeschlossen ist, sind die folgenden Zuweisungstypen möglich:

Hinweise

Wie bei fast jeder Software gibt es auch bei der aktuellen Version einige Überlegungen zu Funktionen und bekannten Einschränkungen. Weitere Informationen finden Sie unter Universal Broker – Überlegungen zu Funktionen und bekannte Einschränkungen.

Systemarchitektur und Komponenten von Universal Broker

Dieser Artikel bietet eine detaillierte Darstellung der Systemkomponenten von Universal Broker, die innerhalb der teilnehmenden Pods und auf der Horizon Cloud-Steuerungsebene ausgeführt werden. Universal Broker ist der empfohlene Verbindungs-Broker für Endbenutzerzuweisungen in First-Gen-Horizon Cloud-Bereitstellungen.

Eine Übersicht über die wichtigsten Funktionen von Universal Broker finden Sie unter Einführung in Horizon Service Universal Broker.

Die Systemarchitektur der Universal Broker-Lösung unterscheidet sich geringfügig, je nachdem, ob sich die vermittelten Ressourcen in Horizon-Pods (basierend auf der Horizon Connection Server-Technologie) oder in Horizon Cloud-Pods in Microsoft Azure befinden.

Systemarchitektur von Universal Broker für Horizon-Pods

Die folgenden Komponenten umfassen die Universal Broker-Lösung für das cloudbasierte Brokering von Multi-Cloud-Zuweisungen von Horizon-Pods (basierend auf der Horizon Connection Server-Technologie).

  • Der Universal Broker-Dienst ist ein Cloud-Dienst mit mehreren Mandanten, der in der Universal Broker-Cloud ausgeführt wird, die mit Horizon Cloud verbunden ist. Jeder Kunde stellt mithilfe eines eindeutigen, dedizierten FQDN, der wie unter Konfigurieren von Universal Broker-Einstellungen beschrieben konfiguriert ist, eine Verbindung mit dem Universal Broker-Dienst her.
  • Der Universal Broker-Client wird im Horizon Cloud Connector für jeden Ihrer cloudverbundenen Horizon-Pods ausgeführt. Ab Version 1.5 dieses Connectors ist der Universal Broker-Client Teil dieses Connectors und wird automatisch installiert, wenn Sie den Horizon Cloud Connector mit Ihrem Pod koppeln.
  • Das Universal Broker-Plug-In wird auf dem Horizon Connection Server für jeden mit der Cloud verbundenen Pod ausgeführt, der an Multi-Cloud-Zuweisungen teilnimmt. Sie müssen das Plug-In herunterladen und auf jeder Verbindungsserverinstanz innerhalb eines teilnehmenden Pods installieren, wie unter Horizon-Pods – Installieren des Universal Broker-Plug-Ins auf dem Verbindungsserver beschrieben.

Das folgende Diagramm veranschaulicht, wie Universal Broker mit den Komponenten in Ihrer Horizon-Pod-Umgebung zusammenarbeitet, um Verbindungsanforderungen von Ihren externen Endbenutzern zu Remoteressourcen in einer Zuweisung zu verwalten.

Hinweis: Das dargestellte Szenario umfasst den Horizon Client, der sich in einem externen Netzwerk außerhalb Ihres Unternehmensnetzwerks befindet, wobei ein externes Unified Access Gateway auf dem Pod konfiguriert ist.

Systemarchitektur von Universal Broker für Horizon-Pods

  1. In Horizon Client fordert der Endbenutzer einen virtuellen Desktop an, indem er über den Brokering-FQDN eine Verbindung mit dem Universal Broker-Dienst herstellt. Der Dienst verwendet das XML-API-Protokoll, um den Horizon Client-Benutzer zu authentifizieren und die Verbindungssitzung zu verwalten.
  2. Nachdem ermittelt wurde, dass Pod 1 in Site 1 die beste verfügbare Quelle für den Desktop ist, sendet der Universal Broker-Dienst eine Meldung an den Universal Broker-Client, der auf dem Horizon Cloud Connector ausgeführt wird, der mit Pod 1 gekoppelt ist.
  3. Der Universal Broker-Client leitet die Nachricht an das Universal Broker-Plug-In weiter, das auf jeder der Verbindungsserverinstanzen in Pod 1 ausgeführt wird.
  4. Das Universal Broker-Plug-In identifiziert den besten verfügbaren Desktop, der die Anforderung des Endbenutzers erfüllt.
  5. Der Universal Broker-Dienst gibt eine Antwort an Horizon Client zurück, die den eindeutigen FQDN von Pod 1 (in der Regel der FQDN des Lastausgleichsdiensts von Pod 1) enthält. Horizon Client stellt eine Verbindung mit dem Lastausgleichsdienst her, um eine Protokollsitzung mit dem Desktop anzufordern.
  6. Nach dem Durchlaufen des lokalen Lastausgleichsdiensts wird die Anforderung an das Unified Access Gateway für Pod 1 übergeben. Unified Access Gateway überprüft, ob die Anforderung vertrauenswürdig ist, und bereitet Blast Secure Gateway, PCoIP Secure Gateway und den Tunnelserver vor.
  7. Der Horizon Client-Benutzer erhält den angegebenen Desktop und richtet eine Sitzung basierend auf dem konfigurierten sekundären Protokoll (Blast Extreme, PCoIP oder RDP) ein.

Weitere Informationen zu den Ports, die für die Universal Broker-Kommunikation verwendet werden, finden Sie unter Horizon-Pods – DNS, Ports und Protokollanforderungen für Universal Broker.

Systemarchitektur von Universal Broker für Horizon Cloud Pods in Microsoft Azure

Die folgenden Komponenten umfassen die Universal Broker-Lösung für das cloudbasierte Brokering von VDI- und RDSH-Zuweisungen von Horizon Cloud-Pods in Microsoft Azure.

  • Der Universal Broker-Dienst ist ein Cloud-Dienst mit mehreren Mandanten, der in der Universal Broker-Cloud ausgeführt wird, die mit Horizon Cloud verbunden ist. Jeder Kunde stellt mithilfe eines eindeutigen, dedizierten FQDN, der wie unter Konfigurieren von Universal Broker-Einstellungen beschrieben konfiguriert ist, eine Verbindung mit dem Universal Broker-Dienst her.
  • Der Universal Broker-Client wird in jedem teilnehmenden Horizon Cloud-Pod in Microsoft Azure ausgeführt.

Hinweis: Das dargestellte Szenario umfasst den Horizon Client, der sich in einem externen Netzwerk außerhalb Ihres Unternehmensnetzwerks befindet, wobei ein externes Unified Access Gateway auf dem Pod konfiguriert ist.

Systemarchitektur von Universal Broker für Horizon Cloud-Pods in Microsoft Azure

  1. In Horizon Client fordert der Endbenutzer eine virtuelle Ressource an, indem er über den Brokering-FQDN eine Verbindung mit dem Universal Broker-Dienst herstellt. Der Dienst verwendet das XML-API-Protokoll, um den Horizon Client-Benutzer zu authentifizieren und die Verbindungssitzung zu verwalten.
  2. Nachdem ermittelt wurde, dass Pod 1 in Site 1 über die beste verfügbare Ressource für die Benutzeranforderung verfügt, sendet der Universal Broker-Dienst eine Meldung an den Universal Broker-Client, der in Pod 1 ausgeführt wird.
  3. Der Universal Broker-Client leitet die Nachricht an den aktiven Pod-Manager in Pod 1 weiter.
  4. Der aktive Pod-Manager identifiziert die beste verfügbare Ressource, die die Anforderung des Endbenutzers erfüllt.
  5. Der Universal Broker-Dienst gibt eine Antwort an Horizon Client zurück, die den eindeutigen FQDN von Pod 1 enthält (in der Regel der FQDN des Microsoft Azure-Lastausgleichs für Pod 1). Horizon Client stellt eine Verbindung mit dem Lastausgleichsdienst her, um eine Protokollsitzung mit der Ressource anzufordern.
  6. Nach dem Durchlaufen des Microsoft Azure-Lastausgleichsdiensts wird die Anforderung an das Unified Access Gateway für Pod 1 übergeben. Unified Access Gateway überprüft, ob die Anforderung vertrauenswürdig ist, und bereitet Blast Secure Gateway, PCoIP Secure Gateway und den Tunnelserver vor.
  7. Der Horizon Client-Benutzer erhält die angegebene Ressource und richtet eine Sitzung basierend auf dem konfigurierten sekundären Protokoll (Blast Extreme, PCoIP oder RDP) ein.

Weitere Informationen zu den Ports, die für die Universal Broker-Kommunikation verwendet werden, finden Sie im Abschnitt "Für Universal Broker erforderliche Ports und Protokolle" in Port- und Protokollanforderungen für einen Horizon Cloud-Pod.

Universal Broker – Überlegungen zu Funktionen und bekannte Einschränkungen

Diese Dokumentationsseite enthält einige Überlegungen zu Funktionen im Zusammenhang mit Universal Broker und eine Liste der Horizon-Funktionen, die eingeschränkt oder nicht unterstützt werden.

Überlegungen zu Funktionen

  • In einer Pod-Flotte, die sowohl Horizon-Pods als auch Horizon Cloud-Pods enthält, muss jede von Ihnen erstellte Endbenutzerzuweisung aus VDI-Desktops mit nur einem Pod-Typ bestehen. Beispielsweise können Sie eine Zuweisung bestehend aus Desktops erstellen, die sich über mehrere Horizon-Pods erstrecken, oder eine Zuweisung bestehend aus Desktops, die sich über mehrere Horizon Cloud-Pods erstrecken. Sie können jedoch keine Zuweisung erstellen, die aus Desktops besteht, die sich über eine Kombination aus Horizon-Pods und Horizon Cloud-Pods erstrecken.
  • Zusätzliche Überlegungen gelten, wenn Sie Ihren Mandanten von einer Einzel-Pod-Broker-Konfiguration auf Universal Broker umgestellt haben. Weitere Informationen finden Sie unter Neuheiten in Ihrer Mandantenumgebung nach dem Übergang zu Universal Broker.

Maximale Anzahl von Pods pro VDI Multi-Cloud-Zuweisungsgrenzwert

Die unterstützte maximale Anzahl von Pods in einer VDI-Multi-Cloud-Zuweisung beträgt fünf (5). Dieser Grenzwert gilt sowohl für Pods vom Typ Horizon Connection Server als auch für Pods vom Typ Horizon Cloud on Microsoft Azure. Die Verwendung von mehr als fünf erhöht die gleichzeitige Last auf Universal Broker. Das Erhöhen dieser gleichzeitigen Last kann dazu führen, dass bei Endbenutzern Fehler auftreten, wenn sie auf die angezeigte Kachel der Zuweisung im Client klicken und der Dienst versucht, den Benutzer beim virtuellen Desktop anzumelden.

Virtuelle Ressourcen

Für das Brokering virtueller Ressourcen unterstützt diese Version von Universal Broker ausschließlich Windows-Betriebssysteme. Linux-basierte Desktops werden nicht unterstützt.

Diese Version unterstützt keine vom Administrator erstellten Verknüpfungen zu Desktops und Anwendungen.

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.

Horizon Web Client und Horizon Client für Chrome

Endbenutzer können Anforderungen für Ressourcen an den Universal Broker-Dienst stellen, indem sie Horizon Web Client in einem unterstützten Webbrowser ausführen oder indem sie Horizon Client für Chrome 5.4 oder höher ausführen. Wenn der Universal Broker-Dienst die Anforderung an eine Unified Access Gateway-Instanz umleitet, die ein selbstsigniertes Zertifikat verwendet, zeigt die Clientanwendung eine Fehlermeldung mit dem Hinweis an, dass die Zertifizierungsstelle ungültig ist.

Dieses Verhalten entspricht dem Design. Zum Herstellen einer Verbindung mit der angeforderten Ressource kann der Benutzer das selbstsignierte Zertifikat akzeptieren, indem er die Anweisungen in der Zertifikatfehlermeldung befolgt.

Authentifizierungsmethoden

Diese Version von Universal Broker unterstützt die Clientbenutzerauthentifizierung über den Windows-Benutzernamen und das zugehörige Kennwort im UPN- und NetBIOS-Format.

Die Zwei-Faktor-Authentifizierung über RADIUS oder RSA wird je nach aktuellem Status der Pod-Flotte des Mandanten ebenfalls unterstützt, wie in der folgenden Liste dargestellt.

Lesen Sie auch den folgenden Abschnitt, in dem die Benutzererfahrung beschrieben wird, wenn Universal Broker in ihren Clients verwendet wird und die Zwei-Faktor-Authentifizierung konfiguriert ist. Das aktuelle Verhalten unterscheidet sich von dem Verhalten bei der direkten Verwendung der Gateway-FQDNs eines Pods.

  • Nur Horizon-Pods

    Sowohl die RADIUS- als auch die RSA SecurID-Authentifizierung werden unterstützt.

  • Nur Horizon Cloud on Microsoft Azure-Bereitstellungen

    Wenn alle Pods das Manifest 3139.x oder höher aufweisen und die Optionen RSA SecurID und RADIUS zur Auswahl sichtbar sind, wenn Sie den Assistenten "Pod bearbeiten" auf den Pods ausführen, werden sowohl die RSA SecurID- als auch die RADIUS-Authentifizierung unterstützt. Andernfalls wird nur der RADIUS-Typ unterstützt.

  • Mischung aus Horizon-Pods und Horizon Cloud on Microsoft Azure-Bereitstellungen

    In einer gemischten Flotte hängen die unterstützten Authentifizierungstypen davon ab, ob Ihre Horizon Cloud on Microsoft Azure-Bereitstellungen die Bedingungen erfüllen, für die die RSA SecurID-Option konfiguriert ist:

    • Wenn Ihre Horizon Cloud on Microsoft Azure-Bereitstellungen diese Bedingungen nicht erfüllen, wird nur die RADIUS-Authentifizierung unterstützt.
    • Wenn Ihre Horizon Cloud on Microsoft Azure-Bereitstellungen diese Bedingungen erfüllen, werden sowohl die RADIUS- als auch die RSA SecurID-Authentifizierung unterstützt. Die zu erfüllenden Bedingungen sind die Pods, auf denen Manifest 3139.x oder höher ausgeführt wird. Wenn Sie den Assistenten "Pod bearbeiten" auf den Pods öffnen, werden sowohl die RSA SecurID- als auch die RADIUS-Optionen zur Auswahl angezeigt.

Wenn die Zwei-Faktor-Authentifizierung konfiguriert ist

Bei der Zwei-Faktor-Authentifizierung durchlaufen Ihre Endbenutzer bei Verwendung des Universal Broker-FQDN einen Authentifizierungsablauf, der sich geringfügig von dem Ablauf bei direkter Verwendung des Gateway-FQDN eines Pods unterscheidet.

  • Im Universal Broker-Authentifizierungsablauf werden die Endbenutzer zweimal aufgefordert, ihre Windows Active Directory (AD)-Anmeldedaten einzugeben: einmal, wenn sie zum ersten Mal eine Verbindung mit dem Universal Broker-FQDN herstellen, und dann erneut, nachdem sie die Zwei-Faktor-Authentifizierung mit dem konfigurierten RADIUS- oder RSA SecurID-System erfolgreich abgeschlossen haben.
  • Bei Verwendung des Gateway-Authentifizierungsablaufs eines Pods werden die Endbenutzer aufgefordert, ihre Windows Active Directory (AD)-Anmeldedaten einmal einzugeben, wenn sie zum ersten Mal eine Verbindung mit dem Gateway-FQDN des Pods herstellen.

Hinweis: Um die Anzeige von zwei AD-Eingabeaufforderungen bei der Verwendung von Universal Broker zu vermeiden, sollten Sie die Integration in Access in Betracht ziehen und die Zwei-Faktor-Authentifizierung in Access konfigurieren.

Derzeit nicht unterstützte Benutzerauthentifizierungs- und Zugriffsmethoden

Die folgenden Benutzerauthentifizierungs- und Zugriffsmethoden werden derzeit nicht unterstützt.

  • Smartcard
  • Zertifikat
  • SAML-Authentifizierung (außerhalb der Integration mit Omnissa Access)
  • Als aktueller Benutzer anmelden
  • Anonymer Zugriff

Wenn sich eines der nicht unterstützten Elemente für den Support qualifiziert, wird sein Eintrag aus der vorstehenden Liste entfernt und die Ankündigung des Supports wird auf der Seite mit dem Titel Für aktuelle Kunden mit vorhandenen cloudverbundenen Pods – über Horizon Cloud-Versionen angegeben. Auf dieser Seite wird die Anweisung in dem Abschnitt aufgeführt, der der Version entspricht, in der die Unterstützung hinzugefügt wurde.

Remote-Desktop-Funktionen

Die folgenden Funktionen werden in dieser Version von Universal Broker nicht unterstützt:

  • URL-Inhaltsumleitung
  • Sitzungszusammenarbeit

Weitere Funktionen

Die folgenden Funktionen werden in dieser Version von Universal Broker ebenfalls nicht unterstützt:

  • Kiosk-Modus
  • Timing-Profil (für die Fehlerbehebung bei Benutzersitzungen)
  • OPSWAT-basierte Überprüfungen der Endpoint-Konformität

War diese Seite hilfreich?

Feedback zu diesem Thema geben

War dieses Thema hilfreich?

Bitte geben Sie keine personenbezogenen oder vertraulichen Daten an.

Link wird erstellt…