Bei laufenden Horizon Cloud-Vorgängen gelten für Pods, die entweder ab der Version von September 2019 oder höher neu in Microsoft Azure bereitgestellt oder auf die Version vom September 2019 aktualisiert wurden, bestimmte Port- und Protokollanforderungen, die sich von denen für unter einer früheren Version bereitgestellten Pods unterscheiden. Pods, die neu bereitgestellt oder auf die Version von 2019 aktualisiert wurden, haben die Manifestversion 1600 oder höher.

Wichtig:

Zusätzlich zu den hier beschriebenen Ports und Protokollen müssen Sie die DNS-Anforderungen erfüllen. Weitere Informationen finden Sie unter Anforderungen an DNS für einen Horizon Cloud-Pod in Microsoft Azure.

Ports und Protokolle, die von Schlüssel-Pod-Komponenten für laufende Vorgänge benötigt werden

Zusätzlich zu den DNS-Anforderungen werden die Ports und Protokolle in den folgenden Tabellen benötigt, damit der Pod für den laufenden Betrieb nach der Bereitstellung ordnungsgemäß funktioniert.

In den nachfolgenden Tabellen bezieht sich der Begriff „Manager-VM“ auf die „Pod-Manager-VM“. Im Microsoft Azure-Portal verfügt diese VM über einen Namen, der einen Teil wie vmw-hcs- podID enthält, wobei podID die UUID des Pods ist, sowie einen node-Teil.

Wichtig: Ein Pod, für den die Hochverfügbarkeit aktiviert ist, verfügt über zwei Manager-VMs. Ein Pod, für den die Hochverfügbarkeit deaktiviert ist, verfügt nur über eine Manager-VM. Wann immer in den nachfolgenden Tabellen die Bezeichnung „Manager-VM“ verwendet wird, bezieht sich diese, sofern nicht anderweitig angegeben, auf sämtliche Manager-VMs in Ihren Pods mit aktivierter Hochverfügbarkeit.

Alle Pods in der Manifest-Version vom September 2019 oder höher verfügen über einen Microsoft Azure-Pod-Lastausgleichsdienst. Die Tabellenzeilen, die den Lastausgleich des Pods beinhalten, gelten für alle Pods auf der Manifestebene 1600 oder höher.

Tabelle 1. Ports und Protokolle für den Pod-Betrieb
Quelle Ziel Ports Protokoll Zweck
Manager-VM Andere Manager-VM des Pods 4101 TCP Für einen Pod, für den die Hochverfügbarkeit aktiviert ist, handelt es sich bei diesem Datenverkehr um eine JMS-Weiterleitung zwischen den Manager-VMs.
Manager-VM Unified Access Gateway-VMs 9443 HTTPS Dieser Port wird von der Pod Manager-VM über das Verwaltungssubnetz verwendet, um die Einstellungen in der Unified Access Gateway-Konfiguration des Pods zu konfigurieren. Diese Portanforderung gilt, wenn Sie einen Pod anfänglich mit einer Unified Access Gateway-Konfiguration bereitstellen und wenn Sie einen Pod dahingehend bearbeiten, dass Sie eine Unified Access Gateway-Konfiguration hinzufügen oder Einstellungen für diese Unified Access Gateway-Konfiguration aktualisieren.
Microsoft Azure-Pod-Lastausgleich Manager-VM 8080 HTTP Integritätsprüfungen der VMs im Backend-Pool des Lastausgleichs. Wenn die Hochverfügbarkeit für einen Pod in der Manifest-Version dieser Version nicht aktiviert ist, verfügt der Lastausgleich für Überprüfungen über eine Manager-VM im Backend-Pool.
Manager-VM Domänencontroller 389 TCP

UDP

LDAP-Dienste. Server, der eine Domänencontrollerrolle in einer Active Directory-Konfiguration enthält. Die Registrierung des Pods bei einem Active Directory ist Voraussetzung.
Manager-VM Globaler Katalog 3268 TCP LDAP-Dienste. Server, der eine globale Katalogrolle in einer Active Directory-Konfiguration enthält. Die Registrierung des Pods bei einem Active Directory ist Voraussetzung.
Manager-VM Domänencontroller 88 TCP

UDP

Kerberos Dienstleistungen. Server, der eine Domänencontrollerrolle in einer Active Directory-Konfiguration enthält. Die Registrierung des Pods bei einem Active Directory ist Voraussetzung.
Manager-VM DNS-Server 53 TCP

UDP

DNS-Dienste
Manager-VM NTP-Server 123 UDP NTP-Dienste. Server, der die NTP-Zeitsynchronisierung ermöglicht.
Manager-VM Echter SSO-Registrierungsserver 32111 TCP Echter SSO-Registrierungsserver. Optional, wenn Sie keine True SSO-Registrierungsserver-Funktionen mit Ihren Pods verwenden.
Manager-VM Workspace ONE Access-Dienst 443 HTTPS Optional, wenn Sie Workspace ONE Access nicht mit dem Pod verwenden. Wird verwendet, um eine Vertrauensbeziehung zwischen dem Pod und dem Workspace ONE Access-Dienst herzustellen. Stellen Sie sicher, dass der Pod die von Ihnen verwendete Workspace ONE Access-Umgebung entweder lokal oder im Cloud-Dienst auf Port 443 erreichen kann. Wenn Sie den Workspace ONE Access-Clouddienst verwenden, informieren Sie sich auch im VMware Knowledge Base-Artikel 2149884 in der Liste der Workspace ONE Access-Dienst-IP-Adressen, auf die der Workspace ONE Access Connector und der Pod Zugriff haben müssen.
Transiente Jump Box-VM Manager-VM 22 TCP Wie zuvor unter Ports und Protokolle, die bei Pod-Bereitstellungen und -Aktualisierungen für die Pod-Jumpbox erforderlich sind beschrieben, wird eine transiente Jump Box bei den Vorgängen zur Pod-Bereitstellung und Pod-Aktualisierung verwendet. Obwohl die laufenden Prozesse diese Ports nicht benötigen, muss diese Jump-Box-VM während der Vorgänge zur Pod-Bereitstellung und Pod-Aktualisierung mit den Manager-VMs über SSH mit dem Port 22 der Manager-VMs kommunizieren. Weitere Informationen zu den Fällen, in denen die Jump-Box-VM diese Kommunikation benötigt, finden Sie unter Ports und Protokolle, die bei Pod-Bereitstellungen und -Aktualisierungen für die Pod-Jumpbox erforderlich sind.
Hinweis: Ein Pod, der sich auf Manifestversion 1600 oder höher befindet und für den die Hochverfügbarkeit aktiviert ist, verfügt über zwei Manager-VMs. Der vorangehende Absatz verwendet den Plural „VMs“, um anzugeben, dass die Jump-Box-VM mit allen Pod-Manager-VMs kommunizieren muss, unabhängig davon, ob der Pod über eine oder zwei Manager-VMs verfügt.
Transiente Jump Box-VM Unified Access Gateway-VMs 9443 HTTPS Dieser Port wird von der Jump Box-VM über das Verwaltungssubnetz verwendet, um die Einstellungen in der Unified Access Gateway-Konfiguration des Pods zu konfigurieren. Diese Portanforderung gilt, wenn Sie einen Pod anfänglich mit einer Unified Access Gateway-Konfiguration bereitstellen und wenn Sie einen Pod dahingehend bearbeiten, dass Sie einem Pod eine Unified Access Gateway-Konfiguration hinzufügen.

Ports und Protokollanforderungen für Connector-VMs des Gateways

Diese Tabelle gilt für die Connector-VM des Gateways, die verwendet wird, wenn Sie das externe Gateway in einem separaten VNet bereitgestellt haben. Zusätzlich zu den DNS-Anforderungen werden die Ports und Protokolle in der folgenden Tabelle benötigt, damit das externe Gateway für den laufenden Betrieb nach der Bereitstellung ordnungsgemäß funktioniert.

In der folgenden Tabelle bezieht sich der Begriff „Connector-VM“ auf die Connector-VM des Gateways, die die Verbindung zwischen der Cloud-Verwaltungsebene und dem externen Gateway verwaltet. Im Microsoft Azure-Portal verfügt diese VM über einen Namen, der einen Teil wie vmw-hcs-ID enthält (wobei ID die ID des Gateway-Bereitstellers ist), sowie einen node-Teil.

Tabelle 2. Ports und Protokolle für den Pod-Betrieb
Quelle Ziel Ports Protokoll Zweck
Connector-VM DNS-Server 53 TCP

UDP

DNS-Dienste
Connector-VM NTP-Server 123 UDP NTP-Dienste. Server, der die NTP-Zeitsynchronisierung ermöglicht.
Transiente Jump Box-VM Connector-VM 22 TCP Wie oben unter Ports und Protokolle, die bei Pod-Bereitstellungen und -Aktualisierungen für die Pod-Jumpbox erforderlich sind beschrieben, wird bei den Prozessen zur Bereitstellung und Aktualisierung des externen Gateways eine temporäre Jumpbox verwendet. Obwohl die laufenden Prozesse diese Ports nicht benötigen, muss diese Jumpbox-VM während der Bereitstellungs- und Aktualisierungsprozesse mit der Connector-VM kommunizieren. Dabei verwendet sie SSH und den Port 22 der Connector-VM.

VM-Ports und Protokollanforderungen für Unified Access Gateway

Zusätzlich zum DNS und den oben genannten primären Ports und Protokollanforderungen beziehen sich die Ports und Protokolle in den folgenden Tabellen auf die Gateways, die Sie auf dem Pod konfiguriert haben, um den ordnungsgemäßen Betrieb bei laufenden Prozessen nach der Bereitstellung zu gewährleisten.

Für Verbindungen über einen Pod mit aktivierter Hochverfügbarkeit, der mit Unified Access Gateway-Instanzen konfiguriert ist, muss der Datenverkehr von den Unified Access Gateway-Instanzen des Pods zu den Zielen wie in der folgenden Tabelle aufgeführt zugelassen werden. Während der Pod-Bereitstellung wird in Ihrer Microsoft Azure-Umgebung eine Netzwerksicherheitsgruppe (NSG) erstellt, die von der Unified Access Gateway-Software des Pods verwendet wird.

Tabelle 3. Portanforderungen für den Datenverkehr von Unified Access Gateway-Instanzen des Pods
Quelle Ziel Port Protokoll Zweck
Unified Access Gateway Microsoft Azure-Pod-Lastausgleich 8443 TCP Traffic zur Anmelde-Authentifizierung. Der Datenverkehr von den Unified Access Gateway-Instanzen erreicht die Manager-VM des Pods über den Lastausgleich des Pods.
Unified Access Gateway Horizon Agent in den Desktop- oder Farm-RDSH-VMs 4172 TCP

UDP

PCoIP
Unified Access Gateway Horizon Agent in den Desktop- oder Farm-RDSH-VMs 22443 TCP

UDP

Blast Extreme

Bei der Verwendung von Blast Extreme wird standardmäßig der CDR-Verkehr (Client Drive Redirection) und der USB-Verkehr über diesen Port geleitet. Wenn Sie es vorziehen, kann der CDR-Verkehr auf den TCP 9427-Port und der USB-Umleitungsverkehr auf den TCP 32111-Port aufgeteilt werden.

Unified Access Gateway Horizon Agent in den Desktop- oder Farm-RDSH-VMs 9427 TCP Optional für Client Driver Redirection (CDR) und Multimedia Redirection (MMR) Verkehr.
Unified Access Gateway Horizon Agent in den Desktop- oder Farm-RDSH-VMs 32111 TCP Optional für USB-Umleitungsverkehr.
Unified Access Gateway Ihre RADIUS-Instanz 1812 UDP Wenn Sie mit dieser Unified Access Gateway-Konfiguration die RADIUS-Zwei-Faktor-Authentifizierung verwenden. Der Standardwert für RADIUS wird hier angezeigt.

Für Universal Broker erforderliche Ports und Protokolle

Um die Verwendung von Universal Broker für das Brokering von Endbenutzerzuweisungen von einem Pod zu unterstützen, müssen Sie Port 443 wie in der folgenden Tabelle beschrieben konfigurieren. Der aktive Pod-Manager stellt eine persistente WebSocket-Verbindung mit dem Universal Broker-Dienst über Port 443 her und empfängt Verbindungsanforderungen vom Universal Broker-Dienst über einen zufällig ausgewählten Port.

Tabelle 4. Portanforderungen für Universal Broker
Quelle Quellport Ziel Zielport Protokoll Zweck
Aktiver Pod-Manager Zufällig aus verfügbaren Ports ausgewählt Universal Broker-Dienst 443 Anfangs HTTPS, dann WebSocket Stellt eine persistente WebSocket-Verbindung mit dem Universal Broker-Dienst her

Port- und Protokollanforderungen für Datenverkehr über Endbenutzerverbindungen

Ausführliche Informationen über die verschiedenen Horizon Clients, die Ihre Endbenutzer mit Ihrem Horizon Cloud-Pod verwenden können, finden Sie auf der Horizon Client-Dokumentationsseite unter https://docs.vmware.com/de/VMware-Horizon-Client/index.html. Welche Ports geöffnet sein müssen, damit der Datenverkehr von den Verbindungen der Endbenutzer die vom Pod bereitgestellten virtuellen Desktops und Remoteanwendungen erreicht, hängt von der Wahl ab, die Sie für die Verbindung Ihrer Endbenutzer treffen:

Bei Auswahl der Bereitstelleroption für die Verwendung einer Konfiguration mit externem Gateway im eigenen VNet des Pods
Der Bereitsteller stellt Unified Access Gateway-Instanzen in Ihrer Microsoft Azure-Umgebung zusammen mit einer Microsoft Azure-Lastausgleichsressource für diese Instanzen im Backend-Pool dieses Lastausgleichsdiensts bereit. Dieser Lastausgleich kommuniziert mit den Netzwerkkarten dieser Instanzen im DMZ-Subnetz und ist als öffentlicher Lastausgleich in Microsoft Azure konfiguriert. Das Diagramm Illustration der Horizon Cloud-Pod-Architektur für einen Pod mit aktivierter und konfigurierter Hochverfügbarkeit mit externen und internen Unified Access Gateway-Konfigurationen zeigt die Position dieses öffentlichen Lastausgleichs und der Unified Access Gateway-Instanzen. Wenn Ihr Pod über diese Konfiguration verfügt, wird der Datenverkehr von Ihren Endbenutzern im Internet an diesen Lastausgleich geleitet, der die Anforderungen an die Unified Access Gateway-Instanzen verteilt. Bei dieser Konfiguration müssen Sie sicherstellen, dass diese Endbenutzerverbindungen diesen Lastausgleich über die unten aufgeführten Ports und Protokolle erreichen können. Nach der Bereitstellung befindet sich der Lastausgleichsdienst des externen Gateways in der Ressourcengruppe mit dem Namen vmw-hcs-podID-uag, wobei podID die UUID des Pods ist.
Bei Auswahl der Bereitstelleroption für die Verwendung einer internen Unified Access Gateway-Konfiguration
Eine Konfiguration mit internem Gateway wird standardmäßig im eigenen VNet des Pods bereitgestellt. Der Bereitsteller stellt Unified Access Gateway-Instanzen in Ihrer Microsoft Azure-Umgebung zusammen mit einer Microsoft Azure-Lastausgleichsressource für diese Instanzen in deren Backend-Pool bereit. Dieser Lastausgleich kommuniziert mit den Netzwerkkarten dieser Instanzen im Mandanten-Subnetz und ist als interner Lastausgleich in Microsoft Azure konfiguriert. Das Diagramm Illustration der Horizon Cloud-Pod-Architektur für einen Pod mit aktivierter und konfigurierter Hochverfügbarkeit mit externen und internen Unified Access Gateway-Konfigurationen zeigt die Position dieses internen Lastausgleichs und der Unified Access Gateway-Instanzen. Wenn Ihr Pod über diese Konfiguration verfügt, wird der Datenverkehr von Ihren Endbenutzern in Ihrem Unternehmensnetzwerk an diesen Lastausgleich geleitet, der die Anforderungen an die Unified Access Gateway-Instanzen verteilt. Bei dieser Konfiguration müssen Sie sicherstellen, dass diese Endbenutzerverbindungen diesen Lastausgleich über die unten aufgeführten Ports und Protokolle erreichen können. Nach der Bereitstellung befindet sich der Lastausgleichsdienst des internen Gateways in der Ressourcengruppe mit dem Namen vmw-hcs-podID-uag-internal, wobei podID die UUID des Pods ist.
Bei Auswahl der Bereitstelleroption entweder für eine Konfiguration mit externem Gateway im eigenen VNet statt im VNet der Pods oder für die Verwendung des eigenen Abonnements (wobei es sich um einen Sonderfall der Verwendung des eigenen VNet handelt, das VNets keine Abonnements umfassen)
Der Bereitsteller stellt Unified Access Gateway-Instanzen in Ihrer Microsoft Azure-Umgebung zusammen mit einer Microsoft Azure-Lastausgleichsressource für diese Instanzen im Backend-Pool dieses Lastausgleichsdiensts bereit. Dieser Lastausgleich kommuniziert mit den Netzwerkkarten dieser Instanzen im DMZ-Subnetz und ist als öffentlicher Lastausgleich in Microsoft Azure konfiguriert. Das Diagramm Veranschaulichung der Elemente der Architektur des externen Gateways, wenn das externe Gateway in einem eigenen, vom VNet des Pods getrennten VNet bereitgestellt wird zeigt den Standort dieses öffentlichen Lastausgleichsdiensts und der Unified Access Gateway-Instanzen im eigenen VNet des Gateways. Wenn Ihr Pod über diese Konfiguration verfügt, wird der Datenverkehr von Ihren Endbenutzern im Internet an diesen Lastausgleich geleitet, der die Anforderungen an die Unified Access Gateway-Instanzen verteilt. Bei dieser Konfiguration müssen Sie sicherstellen, dass diese Endbenutzerverbindungen diesen Lastausgleich über die unten aufgeführten Ports und Protokolle erreichen können. Nach der Bereitstellung befindet sich der Lastausgleichsdienst des externen Gateways in der Ressourcengruppe mit dem Namen vmw-hcs-ID-uag, wobei ID der Wert ist, der im Feld Bereitsteller-ID auf der Detailseite des Pods angezeigt wird. Wie im Administratorhandbuch beschrieben, gelangen Sie über die Seite „Kapazität“ der Konsole zur Detailseite des Pods.
Bei der Einstellung von null Unified Access Gateway-Konfigurationen auf dem Pod, z. B. wenn Sie Workspace ONE Access in den Pod integrieren oder internen Benutzern ermöglichen, sich direkt über VPN zu verbinden
Achtung: In Produktionssystemen besteht die Best Practice für den internen Benutzerzugriff darin, eine interne Unified Access Gateway-Gatewaykonfiguration auf dem Pod anstelle von Direktverbindungen zum Pod zu verwenden.
Wenn Workspace ONE Access in den Pod integriert ist, verbinden sich die Endbenutzer in der Regel über Workspace ONE Access. Wenn Workspace ONE Access in einen Horizon Cloud-Pod in Microsoft Azure integriert ist, müssen Sie es so konfigurieren, dass es direkt auf den Pod verweist. In dem Fall wird auf dem Pod keine Unified Access Gateway-Konfiguration benötigt, wenn die Endbenutzer die Verbindung zu ihren auf dem Pod bereitgestellten Ressourcen mit Workspace ONE Access herstellen. Für diese Konfiguration laden Sie ein SSL-Zertifikat von der Übersichtsseite des Pods in der Konsole auf die Pod-Manager-VMs hoch, wie unter Konfigurieren von SSL-Zertifikaten auf den Manager-VMs des Horizon Cloud-Pods beschrieben. Anschließend führen Sie die Schritte zur Integration von Workspace ONE Access in den Pod aus.
Tabelle 5. Ports und Protokolle für externe Endbenutzerverbindungen, wenn die Pod-Konfiguration über externe Unified Access Gateway-Instanzen verfügt
Quelle Ziel Port Protokoll Zweck
Horizon Client Microsoft Azure-Lastausgleich für diese Unified Access Gateway-Instanzen 443 TCP Traffic zur Anmelde-Authentifizierung. Kann auch Client Drive Redirection (CDR), Multimedia Redirection (MMR), USB-Umleitung und getunnelten RDP-Traffic übertragen.

SSL (HTTPS-Zugang) ist standardmäßig für Clientverbindungen aktiviert. Port 80 (HTTP-Zugriff) kann in einigen Fällen verwendet werden. Weitere Informationen finden Sie unter Grundlegendes zur URL-Inhaltsumleitung.

Horizon Client Microsoft Azure-Lastausgleich für diese Unified Access Gateway-Instanzen 4172 TCP

UDP

PCoIP über PCoIP Secure Gateway auf Unified Access Gateway
Horizon Client Microsoft Azure-Lastausgleich für diese Unified Access Gateway-Instanzen 443 TCP Blast Extreme über Blast Secure Gateway auf Unified Access Gateway für den Datenverkehr.
Horizon Client Microsoft Azure-Lastausgleich für diese Unified Access Gateway-Instanzen 443 UDP Blast Extreme über das Unified Access Gateway für den Datenverkehr.
Horizon Client Microsoft Azure-Lastausgleich für diese Unified Access Gateway-Instanzen 8443 UDP Blast Extreme über Blast Secure Gateway auf Unified Access Gateway für den Datenverkehr (adaptiver Datenverkehr).
Browser Microsoft Azure-Lastausgleich für diese Unified Access Gateway-Instanzen 443 TCP HTML Access
Tabelle 6. Ports und Protokolle für interne Endbenutzerverbindungen, wenn die Pod-Konfiguration über interne Unified Access Gateway-Instanzen verfügt
Quelle Ziel Port Protokoll Zweck
Horizon Client Microsoft Azure-Lastausgleich für diese Unified Access Gateway-Instanzen 443 TCP Traffic zur Anmelde-Authentifizierung. Kann auch Client Drive Redirection (CDR), Multimedia Redirection (MMR), USB-Umleitung und getunnelten RDP-Traffic übertragen.

SSL (HTTPS-Zugang) ist standardmäßig für Clientverbindungen aktiviert. Port 80 (HTTP-Zugriff) kann in einigen Fällen verwendet werden. Weitere Informationen finden Sie unter Grundlegendes zur URL-Inhaltsumleitung.

Horizon Client Microsoft Azure-Lastausgleich für diese Unified Access Gateway-Instanzen 4172 TCP

UDP

PCoIP über PCoIP Secure Gateway auf Unified Access Gateway
Horizon Client Microsoft Azure-Lastausgleich für diese Unified Access Gateway-Instanzen 443 TCP Blast Extreme über Blast Secure Gateway auf Unified Access Gateway für den Datenverkehr.
Horizon Client Microsoft Azure-Lastausgleich für diese Unified Access Gateway-Instanzen 443 UDP Blast Extreme über das Unified Access Gateway für den Datenverkehr.
Horizon Client Microsoft Azure-Lastausgleich für diese Unified Access Gateway-Instanzen 8443 UDP Blast Extreme über Blast Secure Gateway auf Unified Access Gateway für den Datenverkehr (adaptiver Datenverkehr).
Browser Microsoft Azure-Lastausgleich für diese Unified Access Gateway-Instanzen 443 TCP HTML Access
Tabelle 7. Ports und Protokolle für interne Endbenutzerverbindungen bei Verwendung von direkten Pod-Verbindungen, z. B. über VPN
Quelle Ziel Port Protokoll Zweck
Horizon Client Microsoft Azure-Pod-Lastausgleich 443 TCP Traffic zur Anmelde-Authentifizierung. Der Datenverkehr von den Clients erreicht die Manager-VMs des Pods über den Lastausgleich des Pods.
Horizon Client Horizon Agent in den Desktop- oder Farm-RDSH-VMs 4172 TCP

UDP

PCoIP
Horizon Client Horizon Agent in den Desktop- oder Farm-RDSH-VMs 22443 TCP

UDP

Blast Extreme
Horizon Client Horizon Agent in den Desktop- oder Farm-RDSH-VMs 32111 TCP USB-Umleitung
Horizon Client Horizon Agent in den Desktop- oder Farm-RDSH-VMs 9427 TCP Client-Drive-Umleitung (CDR) und Multimedia-Umleitung (MMR)
Browser Horizon Agent in den Desktop- oder Farm-RDSH-VMs 443 TCP HTML Access

Anforderungen an Port und Protokolle für den Datenverkehr vom Horizon Agent in der Basis-VM, in VDI-Desktop-VMs und Farm-RDSH-VMs

Die folgenden Ports müssen den Datenverkehr zwischen der in den Basis-VMs, Desktop-VMs und Farm-RDSH-VMs installierten Horizon Agent-bezogenen Software und den Manager-VMs des Pods zulassen.

Quelle Ziel Port Protokoll Zweck
Horizon Agent in der Basis-Master-VM, in Desktop-VMs, Farm-RDSH-VMs Manager-VM 4001 TCP Java Message Service (JMS, Nicht-SSL), der vom Agenten in der VM zur Kommunikation mit dem Pod als Teil der Verifizierung des Zertifikatfingerabdrucks und zum Austausch verwendet wird, um eine SSL-Verbindung mit dem Pod zu sichern. Nachdem die Schlüssel ausgehandelt und zwischen der VM und dem Pod-Manager ausgetauscht wurden, verwendet der Agent Port 4002, um eine gesicherte SSL-Verbindung zu erstellen. Beispielsweise erfordert die Aktion Agentenpaarung zurücksetzen auf der Seite „Importierte VMs“ die Kommunikation über Port 4001 für den Workflow zur Agentenpaarbildung zwischen der Basis-Master-VM und dem Pod.
Hinweis: Die beiden Ports 4001 und 4002 sind für Vorgänge mit einem stabilen Zustand erforderlich. Es gibt Zeiten, in denen der Agent möglicherweise eine erneute Schlüsselerstellung für den Pod benötigt, sodass Port 4001 offen gehalten werden muss.
Horizon Agent in der Basis-Master-VM, in Desktop-VMs, Farm-RDSH-VMs Manager-VM 4002 TCP Java Message Service (JMS, SSL), der vom Agenten in diesen VMs verwendet wird, um über eine gesicherte SSL-Verbindung mit dem Pod zu kommunizieren.
FlexEngine-Agent (der Agent für VMware Dynamic Environment Manager) auf den Desktop- oder Farm-RDSH-VMs Die Dateifreigaben, die Sie für die Verwendung durch den FlexEngine-Agent eingerichtet haben, der in Desktop- oder Farm-RDSH-VMs ausgeführt wird 445 TCP FlexEngine-Agent-Zugriff auf Ihre SMB-Dateifreigaben, wenn Sie die VMware Dynamic Environment Manager-Funktionen verwenden.

Im Rahmen des Pod-Bereitstellungsvorgangs erstellt der Bereitsteller Netzwerksicherheitsgruppen (NSGs) auf den Netzwerkkarten (NICs) auf allen bereitgestellten VMs. Einzelheiten zu den in diesen NSGs definierten Regeln finden Sie unter Standardmäßige Netzwerk-Sicherheitsgruppenregeln für die VMs in einem in Microsoft Azure bereitgestellten Horizon Cloud-Pod.

Hinweis: Anstatt DNS-Namen, IP-Adressen, Ports und Protokolle in einem Horizon Cloud Knowledge Base-Artikel (KB) aufzulisten, haben wir sie hier als Teil der Horizon Cloud-Hauptdokumentation bereitgestellt.