First-Gen-Mandanten – Behebung von Problemen bei der First-Gen-Horizon Cloud-Pod-Bereitstellung oder der erstmaligen Bindung der Domäne

Wenn das Netzwerk in Ihrer Umgebung nicht ordnungsgemäß für die Verwendung mit dem First-Gen-Horizon Cloud-Pod in Microsoft Azure konfiguriert ist, kann der Vorgang zum Erstellen des Pods mit dem Status AUSSTEHEND hängen bleiben, oder die nach der Bereitstellung durchgeführte Aktion zur Bindung der Domäne an Ihre Active Directory-Umgebung schlägt fehl. Die beiden häufigsten Ursachen sind, dass das Öffnen der erforderlichen ausgehenden Ports fehlschlägt und dass das DNS nicht aktiviert werden kann, um die interne und externe Adresse aufzulösen. Mit den folgenden Schritten zur Fehlerbehebung können Sie einige Tests durchführen, um zu prüfen, ob die erforderlichen ausgehenden Ports geöffnet sind und ob das DNS interne und externe Adressen auflösen kann.

Wichtig: Diese Informationen gelten nur, wenn Sie auf eine First-Gen-Mandantenumgebung in der First-Gen-Steuerungsebene zugreifen können. Wie im KB-Artikel 92424 beschrieben, hat die First-Gen-Steuerungsebene das Ende der Verfügbarkeit (End of Availability, EOA) erreicht. Weitere Informationen finden Sie in diesem Artikel.

Die allgemeinen Netzwerkanforderungen für die erfolgreiche Bereitstellung eines Pods sind in der Checkliste Voraussetzungen aufgeführt und in First-Gen-Mandanten – Konfigurieren der DNS-Servereinstellungen, die von der für die Horizon Cloud-Pods in Microsoft Azure verwendeten VNet-Topologie benötigt werden und First-Gen-Mandanten – Horizon Cloud on Microsoft Azure-Bereitstellungen – Anforderungen an die Auflösung von Hostnamen, DNS-Namen beschrieben. Wenn das Netzwerk Ihrer Umgebung diese Anforderungen nicht erfüllt, werden Sie auf mindestens eines der beiden folgenden Probleme stoßen:

Probleme Häufige Ursachen

Probleme	Häufige Ursachen
Auf der Seite „Erste Schritte“ wird für den Pod der Status „Ausstehend“ angezeigt, und er wird nicht verbunden. In der Regel befindet sich ein Pod etwa 10 Minuten im Zustand „Ausstehend“ (außer wenn Sie einen Pod in der Microsoft Azure China-Cloud bereitstellen, was wiederum länger dauert). Auch wenn der Pod erfolgreich bereitgestellt wurde, schlägt der Schritt zur Bindung der Domäne mit dem Fehler `Unable to register Active Directory` fehl, wenn Sie versuchen, Ihr Active Directory zu registrieren.	Erforderliche ausgehende Ports sind nicht geöffnet oder werden von Ihrer Firewall blockiert. Wenn die erforderlichen ausgehenden Ports nicht geöffnet oder durch die Firewall blockiert sind, kann die Pod-Software nicht sicher in die Microsoft Azure-Cloud-Umgebung heruntergeladen werden, und es kann keine Verbindung mit der Steuerungsebene der Horizon Cloud-Cloud hergestellt werden. Demzufolge tritt das Problem mit Status „Ausstehend“ auf. Der VNet-DNS-Server ist nicht ordnungsgemäß konfiguriert, um auf einen gültigen DNS-Server zu verweisen, der sowohl interne als auch externe Computernamen auflösen kann. Obwohl der VNet-DNS-Server ordnungsgemäß auf einen DNS-Server verweist, kann der DNS-Server weder interne noch externe Computernamen auflösen. Wenn für das VNet keine DNS-Namensauflösung für externe Computernamen bereitgestellt wird, können die Probleme mit dem Status „Ausstehend“ und der Domänenbindung auftreten. Wenn das DNS z. B. keine Auflösung zum Active Directory auf den Domänencontrollern durchführen kann, schlägt die Domänenbindung fehl. Weitere Informationen zur VNet-DNS-Konfiguration finden Sie unter First-Gen-Mandanten – Konfigurieren der DNS-Servereinstellungen, die von der für die Horizon Cloud-Pods in Microsoft Azure verwendeten VNet-Topologie benötigt werden.

Auf der Seite „Erste Schritte“ wird für den Pod der Status „Ausstehend“ angezeigt, und er wird nicht verbunden. In der Regel befindet sich ein Pod etwa 10 Minuten im Zustand „Ausstehend“ (außer wenn Sie einen Pod in der Microsoft Azure China-Cloud bereitstellen, was wiederum länger dauert).
Auch wenn der Pod erfolgreich bereitgestellt wurde, schlägt der Schritt zur Bindung der Domäne mit dem Fehler Unable to register Active Directory fehl, wenn Sie versuchen, Ihr Active Directory zu registrieren.

Erforderliche ausgehende Ports sind nicht geöffnet oder werden von Ihrer Firewall blockiert. Wenn die erforderlichen ausgehenden Ports nicht geöffnet oder durch die Firewall blockiert sind, kann die Pod-Software nicht sicher in die Microsoft Azure-Cloud-Umgebung heruntergeladen werden, und es kann keine Verbindung mit der Steuerungsebene der Horizon Cloud-Cloud hergestellt werden. Demzufolge tritt das Problem mit Status „Ausstehend“ auf.
Der VNet-DNS-Server ist nicht ordnungsgemäß konfiguriert, um auf einen gültigen DNS-Server zu verweisen, der sowohl interne als auch externe Computernamen auflösen kann.
Obwohl der VNet-DNS-Server ordnungsgemäß auf einen DNS-Server verweist, kann der DNS-Server weder interne noch externe Computernamen auflösen.

Wenn für das VNet keine DNS-Namensauflösung für externe Computernamen bereitgestellt wird, können die Probleme mit dem Status „Ausstehend“ und der Domänenbindung auftreten. Wenn das DNS z. B. keine Auflösung zum Active Directory auf den Domänencontrollern durchführen kann, schlägt die Domänenbindung fehl. Weitere Informationen zur VNet-DNS-Konfiguration finden Sie unter First-Gen-Mandanten – Konfigurieren der DNS-Servereinstellungen, die von der für die Horizon Cloud-Pods in Microsoft Azure verwendeten VNet-Topologie benötigt werden.

Um einige Tests durchzuführen, die überprüfen, ob die DNS-Konfiguration interne und externe Namen auflösen kann und ob die erforderlichen ausgehenden Ports geöffnet sind, stellen Sie eine kleine virtuelle Testmaschine (VM) in Ihr Microsoft Azure-Abonnement ein und verwenden diese VM dann zur Ausführung dieser Netzwerktests. Die allgemeine Abfolge der Schritte zur Fehlerbehebung sieht wie folgt aus:

Erstellen eines SSH-Schlüsselpaars.
Erstellen der Test-VM in Ihrem Microsoft Azure-Abonnement.
Herstellen der Verbindung mit der Test-VM.
Ausführen der Netzwerk-Tests.
Wenn der Test abgeschlossen ist, löschen Sie die Test VM und alle testbezogenen Artefakte, die in Ihrer Microsoft Azure Umgebung für die Fehlerbehebung erstellt wurden.

Hinweis: Wenn Sie die testbezogenen Artefakte nicht löschen und den Pod später mit der Aktion Löschen der Konsole löschen, kann es zu unerwarteten Ergebnissen kommen. Beim Löschen eines Pods prüft das System die Subnetze des Pods, um sicherzustellen, dass alles, was mit den Subnetzen verbunden ist, zum Pod selbst gehört (entsprechend der ID des Pods). Wenn das System ermittelt, dass weitere VMs, VM-Festplatten, IPs oder andere Artefakte mit den Subnetzen des Pods verbunden sind, kann das System den Pod nicht sauber löschen.

Einzelheiten zur Durchführung der Tests zur Fehlerbehebung finden Sie in den folgenden Abschnitten.

Wichtig: Auch wenn alle diese manuellen Tests erfolgreich sind, kann die Pod-Bereitstellung im Status „Ausstehend“ hängen bleiben, wenn Sie den gesamten Datenverkehr über Ihr lokales Netzwerk leiten und nur authentifizierten Datenverkehr zulassen, aber keine Werte für die Verwendung eines Proxys im Pod-Bereitstellungsassistenten angegeben haben. Wenn diese Beschreibung auf Ihre Situation zutrifft, müssen Sie den Pod von der Seite „Erste Schritte“ löschen, den Pod-Bereitstellungsassistenten erneut ausführen und die erforderlichen Proxy-Informationen angeben.

Fehlerbehebung bei der Horizon Cloud-Pod-Bereitstellung – SSH-Schlüsselpaar erstellen

Im Rahmen dieser Fehlerbehebung wird eine Linux-Test-VM in Ihrem Microsoft Azure-Abonnement bereitgestellt. Für die Authentifizierung bei der Linux-Test-VM benötigen Sie ein SSH-Schlüsselpaar. Das Schlüsselpaar erstellen Sie auf dem System, das die SSH-Verbindung zur Test-VM herstellt. Dieser Schritt ist optional, wenn Sie bereits ein Schlüsselpaar auf diesem System haben.

Um dieses SSH-Schlüsselpaar zu erstellen, können Sie ein Microsoft Windows- oder ein Linux-System verwenden. Hier finden Sie eine Beschreibung der Schritte für beide Systemtypen. Wählen Sie die für Ihre Situation geeigneten Schritte aus.

Erstellen eines SSH-Schlüsselpaars auf einem Microsoft Windows-System

Führen Sie diese Schritte aus, wenn Sie ein Microsoft Windows-System verwenden, um eine SSH-Verbindung zur Linux-Test-VM herzustellen, die in Ihrem Microsoft Azure-Abonnement bereitgestellt wird.

Wenn Sie die Test-VM in Microsoft Azure erstellen, benötigen Sie den Inhalt der generierten Datei des öffentlichen Schlüssels. Wenn auf dem Microsoft Windows-System, mit dem Sie die Verbindung zur Test-VM herstellen möchten, bereits ein SSH-Schlüsselpaar vorhanden ist, können Sie diesen Schritt überspringen und mit dem Erstellen der Test-VM fortfahren. Die erforderlichen Schritte werden unter Erstellen der Test-VM in Ihrem Microsoft Azure-Abonnement beschrieben.

Mit den folgenden Schritten generieren Sie das SSH-Schlüsselpaar, kopieren den Inhalt der Datei des öffentlichen Schlüssels, damit Sie diesen beim Erstellen der Test-VM verwenden können, und laden den privaten Schlüssel in das PuTTY-Tool „Pageant“. Pageant ist ein SSH-Authentifizierungsagent, der Ihren privaten Schlüssel im Arbeitsspeicher ablegt. Durch das Ablegen des privaten Schlüssels im Arbeitsspeicher wird der private Schlüssel automatisch auf alle SSH-Sitzungen des Microsoft Windows-Systems angewendet, was die Verwendung erleichtert.

Voraussetzungen

Auf einem Microsoft Windows-System ist standardmäßig keine Software für das Erstellen von SSH-Schlüsselpaaren installiert. Prüfen Sie, ob auf dem System, das Sie verwenden möchten, eine Software für das Erstellen von SSH-Schlüsselpaaren installiert ist. Sie können eine beliebige Software verwenden, die SSH-Schlüsselpaare generiert. Die folgenden Schritte beschreiben, wie Sie das SSH-Schlüsselpaar mit der PuTTY-Software unter Microsoft Windows erstellen. Die PuTTY-Software erhalten Sie unter www.putty.org. Nach der Installation sind die PuTTY-Tools verfügbar. Der folgende Screenshot zeigt die PuTTY-Tools im Startmenü.

Screenshot der PuTTY-Tools im Startmenü von Microsoft Windows 10

Prozedur

Starten Sie PuTTYgen (den Schlüsselgenerator von PuTTY) in Ihrem Microsoft Windows-System.
Das Fenster „PuTTY Key Generator“ wird geöffnet. Wie im folgenden Screenshot gezeigt, geht es darum, ein Paar aus öffentlichem und privatem Schlüssel zu generieren – vom Typ SSH-2 RSA und einer Schlüssellänge von 2048 Bit.
Prüfen Sie, ob SSH-2 RSA ausgewählt und 2048 für die Anzahl der Bits festgelegt ist. Klicken Sie anschließend auf Generate. Das Fenster „Schlüssel“ mit der Fortschrittsanzeige wird geöffnet.
Folgen Sie den Anweisungen auf dem Bildschirm, um den Cursor innerhalb des leeren Bereichs unter der Fortschrittsanzeige willkürlich hin und her zu bewegen. Wie in der PuTTY-Benutzeroberfläche angegeben, fügt das Bewegen des Cursors im Bereich die erforderliche Zufälligkeit in den Prozess ein.
Speichern Sie den privaten Schlüssel im System, indem Sie eine Schlüsselpassphrase eingeben, und klicken Sie auf Privaten Schlüssel speichern.

Hinweis: Die Verwendung einer Schlüsselpassphrase ist optional, wird aber empfohlen. Wenn Sie ohne Eingabe einer Schlüsselpassphrase auf Privaten Schlüssel speichern klicken, müssen Sie in einem Popup-Fenster bestätigen, dass Sie den privaten Schlüssel ohne Schlüsselpassphrase speichern möchten.

Der private Schlüssel wird als PPK-Datei gespeichert. Nachdem Sie auf Privaten Schlüssel speichern geklickt haben, können Sie zu einem Verzeichnis im lokalen System navigieren, einen Dateinamen eingeben und die Datei speichern.
Verwenden Sie die Schaltfläche Öffentlichen Schlüssel speichern, um den öffentlichen Schlüssel an einem Speicherort zu speichern, von dem Sie ihn kopieren können, wenn Sie die Test-VM erstellen.
Starten Sie Pageant, den PuTTY SSH-Authentifizierungsagent.
Auf einem Windows 10-System wird das Pageant-Symbol in die Taskleiste geladen.
Fügen Sie Ihren privaten Schlüssel zu Pageant hinzu, indem Sie mit der rechten Maustaste auf das Taskleistensymbol klicken, Schlüssel hinzufügen auswählen und im Fenster für die Dateiauswahl zur gespeicherten PPK-Datei mit dem privaten Schlüssel navigieren.

Hinweis: Wenn Sie beim Speichern der Datei des privaten Schlüssels eine Schlüsselpassphrase angegeben haben, wird ein Fenster für die Eingabe der Passphrase geöffnet.

Ergebnisse

Der private Schlüssel wird jetzt in Pageant geladen. Mit der Option View Keys des Aktionsmenüs können Sie den Schlüssel in der Liste der geladenen Schlüssel anzeigen. Wenn Sie eine SSH-Sitzung mit PuTTY starten, ruft PuTTY den Schlüssel automatisch aus Pageant ab und verwendet ihn zur Authentifizierung, ohne dass Sie Ihre Passphrase eingeben müssen. Wenn Sie mit den SSH-Sitzungen fertig sind und Pageant beenden möchten, wählen Sie im Kontextmenü des Pageant-Taskleistensymbols Exit aus.

Nächste Maßnahme

Erstellen Sie die Test-VM, indem Sie die unter Erstellen der Test-VM in Ihrem Microsoft Azure-Abonnement beschriebenen Schritte ausführen.

Erstellen eines SSH-Schlüsselpaars auf einem Linux-System

Führen Sie diese Schritte aus, wenn Sie die SSH-Verbindung mit der Test-Linux-VM, die Sie in Ihrem Microsoft Azure-Abonnement bereitstellen möchten, über ein Linux-System herstellen.

Sie verwenden in den Schritten zum Erstellen der Test-VM in Microsoft Azure den Inhalt der generierten Datei für den öffentlichen Schlüssel. Wenn auf dem Linux-System, mit dem Sie die Verbindung mit der Test-VM herstellen möchten, bereits ein SSH-Schlüsselpaar vorhanden ist, können Sie diesen Schritt überspringen und mit der Erstellung der Test-VM fortfahren, wie unter Erstellen der Test-VM in Ihrem Microsoft Azure-Abonnement beschrieben.

Voraussetzungen

Bevor Sie diese Schritte ausführen, müssen Sie sicherstellen, dass Sie kein vorhandenes SSH-Schlüsselpaar überschreiben, das Sie für andere Zwecke behalten möchten. Auf Linux-Systemen werden die öffentlichen und privaten SSH-Schlüsseldateien standardmäßig in dem Linux-Verzeichnis ~/.ssh/id_rsa erstellt. Wenn in diesem Verzeichnis ein SSH-Schlüsselpaar vorhanden ist und Sie denselben Dateinamen verwenden, wenn Sie diesen Befehl ausführen oder einen anderen Speicherort im Befehl eingeben, an dem bereits ein SSH-Schlüsselpaar vorhanden ist, wir das vorhandene Schlüsselpaar überschrieben.

Prozedur

Öffnen Sie über Ihr Linux-System eine Bash-Shell.
Geben Sie in der Bash-Shell den folgenden Befehl ein:
```
ssh-keygen -t rsa -b 2048
```
Folgen Sie den Anweisungen auf dem Bildschirm zur Eingabe einer Datei, in der der Schlüssel gespeichert wird, zur Eingabe einer Passphrase und zur Bestätigung der Passphrase.
Hier ist ein Beispiel für die Anweisungen auf dem Bildschirm. mykey wurde als die Datei eingegeben, in der der Schlüssel gespeichert wird.
```
-bash-4.1$ ssh-keygen -t rsa -b 2048
Generating public/private rsa key pair.
Enter file in which to save the key (/mts-cm/home/user1/.ssh/id_rsa): mykey
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
```
Hinweis: Die Verwendung einer Schlüsselpassphrase ist eine optionale bewährte Methode.
Der private Schlüssel wird in der Datei gespeichert, die Sie angeben, und der öffentliche Schlüssel wird in einer Datei mit demselben Namen und einer PUB-Erweiterung gespeichert. Bei dem Beispiel oben, in dem mykey als Datei eingegeben wird, ist dies die Beispielausgabe:
```
Your identification has been saved in mykey.
Your public key has been saved in mykey.pub.
```

Nächste Maßnahme

Erstellen Sie die Test-VM, indem Sie die Schritte unter Erstellen der Test-VM in Ihrem Microsoft Azure-Abonnement ausführen.

Erstellen der Test-VM in Ihrem Microsoft Azure-Abonnement

Sie verwenden eine virtuelle Test-Linux-Maschine (VM) in Ihrer Microsoft Azure-Umgebung, um die Tests auszuführen, die die für Ihren Horizon Cloud-Pod konfigurierte Netzwerkverbindung überprüfen.

Voraussetzungen

Sie benötigen den öffentlichen SSH-Schlüssel, den Sie nach der Anleitung unter Fehlerbehebung bei der Horizon Cloud-Pod-Bereitstellung – SSH-Schlüsselpaar erstellen erstellt haben. Diesen öffentlichen Schlüssel müssen Sie im Assistenten für die VM-Erstellung angeben, damit die VM die SSH-Verbindungen von dem System, das den zugehörigen privaten Schlüssel besitzt, als vertrauenswürdig erkennt.

Sie benötigen den Namen des virtuellen Netzwerks (VNet), mit dem Sie den Pod bereitstellen. Weitere Informationen finden Sie unter First-Gen-Horizon Cloud – Konfigurieren des erforderlichen virtuellen Netzwerks in Microsoft Azure.

Wenn Sie die Option des Assistenten „Pod hinzufügen“ nicht verwendet haben, um Ihre eigenen benannten Subnetze für den Pod zu verwenden, und stattdessen die CIDRs für die Subnetze eingegeben haben, erstellt der Pod-Bereitsteller das Management-Subnetz des Pods. An dem Punkt, an dem der Bereitstellungsvorgang fehlgeschlagen ist, hat der Prozess möglicherweise bereits das Management-Subnetz des Pods im VNet erstellt.

Wenn der Bereitsteller dieses Management-Subnetz bereits erstellt hat, wird empfohlen, die Test-VM in diesem Subnetz bereitzustellen. Um herauszufinden, ob das Management-Subnetz des Pods im VNet vorhanden ist, melden Sie sich beim Microsoft Azure-Portal an, navigieren Sie zum entsprechenden VNet und prüfen Sie die Liste der vorhandenen Subnetze. Wenn der Pod-Bereitsteller die Subnetze des Pods automatisch erstellt (Sie haben die Option nicht verwendet, um Ihre eigenen benannten Subnetze für den Pod zu verwenden), hat das Management-Subnetz des Pods einen Namen nach dem Muster vmw-hcs-podID-net-management, wobei podID die UUID des Pods ist. Andernfalls ist das Management-Subnetz des Pods dasjenige, das Sie für die Pod-Bereitstellung erstellt haben.
Wenn der fehlgeschlagene Bereitstellungsvorgang das Management-Subnetz des Pods nicht im VNet erstellt hat, können Sie jedes verfügbare Subnetz im VNet auswählen oder für die Test-VM ein neues Subnetz erstellen.

Prozedur

Melden Sie sich beim Microsoft Azure-Portal an.
Erstellen Sie im Portal eine Computing-VM aus Azure Marketplace und legen Sie diese VM auf einen Ubuntu Server LTS-Modelltyp fest.
Zum Zeitpunkt der Erstellung dieses Dokuments stand der Ubuntu Server 20.04 LTS zur Auswahl im Azure Marketplace zur Verfügung.

Wenn Sie diese Test-Linux-VM erstellen, folgen Sie den Schritten auf der Benutzeroberfläche des Assistenten und konfigurieren Sie die erforderlichen Optionen. Stellen Sie sicher, dass Sie die folgenden Elemente wie unten angegeben konfigurieren.


Option	Beschreibung
Abonnement	Stimmen Sie mit derjenigen überein, die Sie im Assistenten „Pod hinzufügen“ für Ihren Pod ausgewählt haben.
Ressourcengruppe	Es wird empfohlen, eine neue Ressourcengruppe für die Test-VM zu erstellen. Folgen Sie den Anweisungen auf dem Bildschirm, um eine neue Ressourcengruppe zu erstellen. Auch wenn es möglich ist für diese Test-VM eine vorhandene Ressourcengruppe zu verwenden, empfiehlt es sich, eine speziell für die Test-VM und die zugehörigen Artefakte erstellte Ressourcengruppe zu verwenden. So können Sie nach den Tests die VM und die zugehörigen Artefakte löschen, indem Sie einfach die gesamte Ressourcengruppe löschen.
Region	Stimmen Sie mit derjenigen überein, die Sie im Assistenten „Pod hinzufügen“ für Ihren Pod ausgewählt haben.
Größe	Sie können eine beliebige Größe auswählen, da es sich um eine kurzlebige VM handelt, die nur verwendet wird, um die Verifizierungstests abzuschließen. Da jedoch kleinere Größen in der Regel mit geringeren Kosten in Microsoft Azure verbunden sind, ist es üblich, eine kleine Größe für die Test-VM zu wählen, z. B. ein Modell mit 2 vCPU.
Benutzername	Notieren Sie sich diesen Namen, da Sie ihn später benötigen werden.
Authentifizierungstyp	Wählen Sie Öffentlicher SSH-Schlüssel aus.
Quelle: Öffentlicher SSH-Schlüssel	Wählen Sie Vorhandenen öffentlichen Schlüssel verwenden aus. Das Feld „Öffentlicher SSH-Schlüssel“ wird mit dieser Auswahl angezeigt, und Sie können Ihren öffentlichen SSH-Schlüssel einfügen.
Öffentlicher SSH-Schlüssel	Fügen Sie in dieses Feld Ihren öffentlichen SSH-Schlüssel ein, den Sie mit dem SSH-Schlüsselpaar erstellt haben. Der eingefügte Inhalt muss mit der Zeile `---- BEGIN SSH2 PUBLIC KEY ----` beginnen und mit der Zeile `---- END SSH2 PUBLIC KEY ----` Ihres öffentlichen Schlüssels enden.
Öffentliche eingehende Ports	Lassen Sie den ausgewählten SSH-Port (22) zu, damit Sie die Tests mit dieser Test-VM durchführen können.
Virtuelles Netzwerk	Wählen Sie dasselbe VNet aus, das für die fehlgeschlagene Pod-Bereitstellung verwendet wurde.
Subnetz	Wenn Sie bereits einen Versuch unternommen haben, den Pod bereitzustellen, der fehlgeschlagen ist, kann es sein, dass das Management-Subnetz des Pods bereits im virtuellen Netzwerk erstellt wurde. Wenn das Subnetz vorhanden ist, empfiehlt es sich, dieses Subnetz für diesen Test-VM auswählen. Klicken Sie auf Subnetz, um zu den im ausgewählten virtuellen Netzwerk vorhandenen Subnetzen zu navigieren. Wenn Sie den Mauszeiger über ein Subnetz bewegen, wird der vollständige Namen in einer QuickInfo angezeigt. Wenn bei der Pod-Bereitstellung das Management-Subnetz des Pods nicht im VNet erstellt wurde, wählen Sie in Ihrem VNet das Subnetz aus, das Sie für die Test-VM verwenden möchten (gemäß den oben beschriebenen Voraussetzungen). Hinweis: Wenn der Pod erfolgreich bereitgestellt wurde, es aber noch Probleme mit dem Domänenbeitritt gibt, können Sie für die Test-VM anstelle des Management-Subnetzes das Desktop-Subnetz des Pods auswählen, da bei Domänenbeitrittsvorgängen die Desktop-Images verwendet werden, die mit diesem Desktop-Subnetz verbunden werden.
Öffentliche IP	Wählen Sie diese Option aus, damit der erstellten Test-VM eine öffentliche IP-Adresse zugewiesen wird. Mit einer öffentlichen IP-Adresse können Sie zu ihr eine Verbindung über ein WAN (Wide Area Network) herstellen. Hinweis: Möglicherweise erlaubt Ihre Netzwerkkonfiguration die Verwendung einer öffentlichen IP-Adresse aus technischen Gründen nicht. Wenn Sie die Test VM nicht mit einer öffentlichen IP erstellen können, benötigen Sie eine Netzwerkverbindung von Ihrem lokalen System zu dem Subnetz, das Sie im Feld Subnetz ausgewählt haben, oder Sie müssen eine Verbindung zu einer anderen Maschine in Ihrem Netzwerk herstellen und dann eine eingehende Verbindung zur Test VM einrichten.

Überprüfen Sie im letzten Schritt des Assistenten, ob die wichtigsten Informationen (Abonnement, regionaler Standort, virtuelles Netzwerk und Subnetz) mit denen übereinstimmen, die Sie für Ihren Pod verwenden, und senden Sie dann die Anfrage ab, um die VM zu erstellen.

Verwendung von SSH für Verbindungen mit der Test-VM

Stellen Sie eine Secure Shell-Verbindung (SSH) mit der Test-VM her, damit Sie die Netzwerkkonnektivitätstests in Ihrer Microsoft Azure-Umgebung ausführen können.

Herstellen einer SSH-Verbindung zur Test-VM aus einem Microsoft Windows-System

Diese Verbindung wird von dem Microsoft Windows-System hergestellt, das über den privaten Schlüssel verfügt, der zu dem öffentlichen Schlüssel gehört, den Sie beim Erstellen der Test-VM angegeben haben.

Voraussetzungen

Stellen Sie sicher, dass Sie die IP-Adresse der Test-VM und den Benutzernamen besitzen, den Sie beim Erstellen der VM angegeben haben.

Auf einem Microsoft Windows-System wird in der Regel PuTTY verwendet. Damit PuTTY Ihren privaten Schlüssel problemlos laden kann, wenn Sie die SSH-Sitzung starten, bevor Sie PuTTY starten, starten Sie Pageant, wie unter Erstellen eines SSH-Schlüsselpaars auf einem Microsoft Windows-System beschrieben und fügen Sie den privaten SSH-Schlüssel zur Schlüsselliste von Pageant hinzu. Der private SSH-Schlüssel muss zu dem öffentlichen Schlüssel passen, den Sie beim Erstellen der Test-VM angegeben haben. Wenn der private Schlüssel in Pageant geladen wird, verwendet die PuTTY-SSH-Sitzung automatisch diesen privaten Schlüssel.

Prozedur

Starten Sie PuTTY ().
Das Konfigurationsfenster von PuTTY wird geöffnet.
Geben Sie im PuTTY-Konfigurationsfenster den Hostnamen ein, wählen Sie SSH aus und klicken Sie auf Open.
Geben Sie im PuTTY-Konfigurationsfenster im Feld Host Name eine Zeichenfolge nach dem Muster
```
testvm_username@testvmip
```
ein. Ersetzen Sie in der Zeichenfolge testvm_username durch den Benutzernamen und testvmip durch die IP-Adresse.
Wichtig: Wenn Sie zum erstmalig eine Verbindung zur Test-VM herstellen, wird nach dem Klicken auf Open eine PuTTY-Sicherheitsmeldung angezeigt, die besagt, dass sich der Hostschlüssel des Servers nicht im Zwischenspeicher befindet. Außerdem wird der Fingerabdruck des rsa2-Schlüssels des Servers angezeigt. Sie können das Herstellen der Verbindung fortsetzen, indem Sie entweder auf Yes klicken, um den Hostschlüssel des Servers zum PuTTY-Cache hinzuzufügen, oder indem Sie auf No klicken, um eine Verbindung herzustellen, ohne den Schlüssel zum PuTTY-Cache hinzuzufügen. Falls Sie vermuten, dass die Verbindung nicht zu Ihrer Test-VM hergestellt wird, klicken Sie auf Cancel, um die Verbindung abzubrechen und zum PuTTY-Konfigurationsfenster zurückzukehren und den angegebenen Hostnamen zu überprüfen.
Der folgende Screenshot zeigt das Fenster mit diesem Beispiel:
```
[email protected]
```

Ergebnisse

Wenn die SSH-Verbindung hergestellt wurde, wird ein Befehlszeilenfenster angezeigt.

Nächste Maßnahme

Da Sie jetzt mit der Test-VM verbunden sind, können Sie die Tests zur Prüfung der Netzwerkkonnektivität in Ihrer Microsoft Azure-Umgebung durchführen. Führen Sie die unter Ausführen der Netzwerktests in Ihrer Microsoft Azure-Umgebung beschriebenen Schritte aus.

Herstellen einer SSH-Verbindung mit der Test-VM über ein Linux-System

Sie stellen diese Verbindung über das Linux-System her, das über den privaten Schlüssel verfügt, der dem öffentlichen Schlüssel entspricht, den Sie beim Erstellen der Test-VM angegeben haben.

Voraussetzungen

Vergewissern Sie sich, dass Sie über die Test-VM-IP-Adresse und den Benutzernamen verfügen, die Sie angegeben haben, als Sie die virtuelle Maschine erstellt haben.

Prozedur

Öffnen Sie eine Bash-Shell.
Geben Sie in die Eingabeaufforderung $ der Bash-Shell wie unten gezeigt den Befehl „ssh“ ein und ersetzen Sie dabei die Test-VM-IP-Adresse und den Benutzernamen durch testvmip und testvm_benutzername in dem Befehl:
```
ssh testvm_benutzername@testvmip
```
Wenn Sie beispielsweise die Test-VM-Details aus den Beispielen in Erstellen der Test-VM in Ihrem Microsoft Azure-Abonnement verwenden, muss der Beispielbefehl wie folgt lauten:
```
ssh [email protected]
```

Ergebnisse

Wenn die SSH-Verbindung hergestellt ist, wird ein Befehlszeilenfenster ähnlich wie im folgenden Screenshot angezeigt.

Nächste Maßnahme

Sie sind jetzt mit der Test-VM verbunden und können die Tests zur Überprüfung der Netzwerkkonnektivität in Ihrer Microsoft Azure-Umgebung ausführen. Befolgen Sie die Schritte unter Ausführen der Netzwerktests in Ihrer Microsoft Azure-Umgebung.

Ausführen der Netzwerktests in Ihrer Microsoft Azure-Umgebung

Mit diesen Tests prüfen Sie, ob zwei Netzwerkbereiche richtig konfiguriert sind: ob das DNS interne und externe Adressen auflösen kann und ob die erforderlichen ausgehenden Ports offen sind. Diese Tests führen Sie mit Ihrer Test-VM durch.

Der Pod nutzt das DNS, um sowohl interne als auch externe Adressen aufzulösen. Mit den beiden ersten Tests wird geprüft, ob das in Ihrer Netzwerkumgebung konfigurierte DNS bekannte FQDNs für interne und externe Adressen auflösen kann.

Voraussetzungen

Stellen Sie vor dem Ausführen der Tests sicher, dass Sie in Ihrem Microsoft Azure-Abonnement eine Test-VM erstellt haben und damit eine SSH-Verbindung herstellen können. Weitere Informationen finden Sie unter Erstellen der Test-VM in Ihrem Microsoft Azure-Abonnement und Verwendung von SSH für Verbindungen mit der Test-VM.

Sie benötigen die IP-Adressen und die vollständig qualifizierten Domänennamen (FQDNs) für Server, die sich intern in Ihrem Netzwerk befinden und vom VNet erreichbar sein sollen, wie Ihr Active Directory-Domänencontroller. Diese Informationen benötigen Sie bei der DNS-Überprüfung.

Prozedur

Prüfen Sie, ob das DNS in Ihrer Umgebung funktioniert und interne FQDNs auflöst, indem Sie den Befehl dlg ausführen, um einen bekannten Domänenname abzufragen, der intern in Ihrem VNet in Microsoft Azure vorhanden ist.
Geben Sie im Fenster für die SSH-Verbindung den Befehl dig ein, um den Domänennamen eines Servers abzufragen, von dem Sie wissen, dass er sich intern in Ihrem Netzwerk befindet, z. B. Ihr Active Directory-Domänencontroller.
```
dig internal-domain-name
```
Wobei internal-domain-name der vollqualifizierte Domänenname eines Servers ist, von dem Sie wissen, dass er sich intern in Ihrem Netzwerk befindet.
dig (Domain Informationen Groper) ist ein Befehlszeilentool für die Behandlung von Netzwerkproblemen. Wenn Sie diesen Befehl mit einem internen Hostnamen ausführen, wird geprüft, ob Ihre DNS-Konfiguration interne Adressen ordnungsgemäß auflösen kann. Wenn Ihre DNS-Konfiguration den im Befehl verwendeten internal-domain-name auflösen kann, wird die korrekte IP-Adresse zurückgegeben, die dem Domänenname zugeordnet ist.
Angenommen, das VNet ist mit einem internen Active Directory-Server konfiguriert, der einen Active Directory-Domänencontroller mit dem DNS-Eintrag skylo.local und der IP-Adresse 192.168.0.15 besitzt. Wenn Sie dig skylo.local ausführen, wird geprüft, ob die VNet-DNS-Konfiguration diesen internen Servernamen skylo.local auflösen kann:
```
testvmadmin@HCS-testingVM:~$ dig skylo.local

; <<>> DiG 9.10.3-P4-Ubuntu <<>> skylo.local
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64899
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;skylo.local.                   IN      A

;; ANSWER SECTION:
skylo.local.            600     IN      A       192.168.0.15

;; Query time: 1 msec
;; SERVER: 192.168.0.15#53(192.168.0.15)
;; WHEN: Mon Mar 26 20:58:01 UTC 2018
;; MSG SIZE  rcvd: 56

testvmadmin@HCS-testingVM:~$
```
Der Test ist erfolgreich, wenn unter ANSWER SECTION angegeben wird, dass der angegebene Hostname mit der IP-Adresse aufgelöst wurde, die Sie für diesen Hostnamen erwarten.
Hinweis: Das DNS ist manchmal nicht 100 % zuverlässig und manche Anforderungen verlaufen fehlerfrei, während andere fehlschlagen. Wenn der Befehl beim ersten Mal fehlschlägt, führen Sie den Befehl zehn bis zwanzig mal aus und prüfen Sie, ob Sie jedes Mal eine zuverlässige Antwort erhalten.
Prüfen Sie, ob das DNS in Ihrer Umgebung externe FQDNs auflösen kann, indem Sie mit dem Befehl dlg einen bekannten externen Domänennamen abfragen.
Geben Sie im Fenster für die SSH-Verbindung den Befehl dig ein, um einen externen Domänenname, der dem Industriestandard entspricht, abzufragen, z. B. vmware.com oder microsoft.com.
```
dig external-domain-name
```
Dabei ist external-domain-name ein vollqualifizierter Domänenname, der sich außerhalb Ihres VNet befindet. Der Befehl dig vmware.com prüft z. B., ob die VNet-DNS-Konfiguration diesen externen Namen auflösen kann:
```
testvmadmin@HCS-testingVM:~$ dig vmware.com

; <<>> DiG 9.10.3-P4-Ubuntu <<>> vmware.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38655
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;vmware.com.                    IN      A

;; ANSWER SECTION:
vmware.com.             150     IN      A       107.154.105.19
vmware.com.             150     IN      A       107.154.106.19

;; Query time: 28 msec
;; SERVER: 192.168.0.15#53(192.168.0.15)
;; WHEN: Mon Mar 26 21:14:29 UTC 2018
;; MSG SIZE  rcvd: 71

testvmadmin@HCS-testingVM:~
```
Im obigen Beispiel wird unter ANSWER SECTION angezeigt, dass der externe Domänenname vmware.com korrekt in zwei IP-Adressen aufgelöst wurde.
Hinweis: Sie können diesen Test mit verschiedenen externen Domänennamen wiederholen, z. B. mit azure.com oder microsoft.com, um sicherzustellen, dass Ihr DNS verschiedene externe Namen auflösen kann.
Wenn die DNS-Tests fehlschlagen, prüfen Sie Ihre Netzwerkkonfigurationen und Ihren DNS-Server. Prüfen Sie, ob Sie Ihren DNS-Server zu Ihrem VNet hinzugefügt haben.
Wichtig: Wenn Sie feststellen, dass Sie Ihren DNS-Server zu Ihrem VNet hinzufügen oder die DNS-Server-Konfiguration des VNet ändern müssen, müssen Sie alle VMs neu starten, die mit dem VNet verbunden sind, damit die Änderungen übernommen werden. Wenn Sie die DNS-Serverkonfiguration des VNet ändern und keinen Neustart aller mit dem VNet verbundenen VMs durchführen, werden die Änderungen nicht korrekt in das VNet übertragen.
Prüfen Sie, ob die erforderlichen ausgehenden Ports verfügbar sind, indem Sie den Befehl netcat ausführen.
Für Horizon Cloud müssen einige ausgehende Ports geöffnet sein, damit die Pod-Software sicher in Ihre Microsoft Azure-Umgebung heruntergeladen werden kann und der Pod wieder eine Verbindung zurück in die Horizon Cloud-Steuerungsebene herstellen kann. Wie unter First-Gen-Mandanten – Horizon Cloud on Microsoft Azure-Bereitstellungen – Anforderungen an die Auflösung von Hostnamen, DNS-Namen beschrieben, müssen die folgenden ausgehenden TCP-Ports vom Management-Subnetz des Pods geöffnet sein: Port 80, 443 und 11371. Indem Sie den Befehl netcat wie unten angegeben ausführen, können Sie prüfen, ob die ausgehenden Ports offen sind.
Führen Sie im Fenster für die SSH-Verbindung die folgenden Befehle aus (ein Befehl pro Port).
Hinweis: Für den folgenden Befehl für den Test von Port 11371 wird packages.microsoft.com angegeben, um diese Verbindung zu testen, während die beiden anderen Zeilen die ausgehende Verbindung mit der Horizon Cloud-Steuerungsebene testen.
```
testvmadmin@HCS-testingVM:~$ netcat -v -w 3 cloud.horizon.vmware.com 80
Connection to cloud.horizon.vmware.com 80 port [tcp/http] succeeded!
testvmadmin@HCS-testingVM:~$ netcat -v -w 3 cloud.horizon.vmware.com 443
Connection to cloud.horizon.vmware.com 443 port [tcp/https] succeeded!
testvmadmin@HCS-testingVM:~$ netcat -v -w 3 packages.microsoft.com 11371
Connection to packages.microsoft.com 11371 port [tcp/hkp] succeeded!
```
Wenn ein Port ordnungsgemäß geöffnet ist, gibt der Befehl netcat für den Test die Zeile succeeded! zurück.
Wenn die netcat-Befehle Fehler zurückgeben, prüfen Sie Ihre Microsoft Azure-Netzwerkverbindungen, die Netzwerksicherheitsgruppen in Ihrem Abonnement und alle möglicherweise vorhandenen Firewalls. Stellen Sie sicher, dass Ihre Netzwerkkonfiguration die DNS-, Port- und Protokollanforderungen erfüllt, die der Pod für die Bereitstellung benötigt, wie in First-Gen-Mandanten – Horizon Cloud on Microsoft Azure-Bereitstellungen – Anforderungen an die Auflösung von Hostnamen, DNS-Namen beschrieben.

Ergebnisse

Wenn die obigen Tests erfolgreich ausgeführt wurden, können Sie Ihren Pod erfolgreich bereitstellen.

Hinweis: Wenn Sie optionale Funktionen für die Verwendung mit Ihrem Pod konfigurieren, wie z. B. True SSO oder Zwei-Faktor-Authentifizierung mit einem Authentifizierungsserver, werden für diese Zwecke möglicherweise zusätzliche Ports benötigt. Sie können die oben genannten Testverfahren für ausgehende Ports verwenden, um sicherzustellen, dass diese Ports ordnungsgemäß geöffnet sind.

Nächste Maßnahme

Wenn Sie den Test abgeschlossen haben, sollten Sie die Test-VM und alle zugehörigen Artefakte wie VM-Festplatte, IP-Adresse und NIC aus Ihrer Microsoft Azure-Umgebung löschen. Im Idealfall hätten Sie eine Ressourcengruppe für die Test-VM angelegt und können diese einfach löschen, um alle Artefakte der VM zu beseitigen. Folgen Sie den unter Löschen der Test-VM nach Abschluss der Tests beschriebenen Schritten.

Wichtig: Wenn Sie nicht alle Artefakte der Test-VM aus Ihrer Microsoft Azure-Umgebung löschen und die VM mit einem der Subnetze des Pods verbunden haben und Sie später versuchen, den Pod mithilfe der Aktion Löschen aus Ihrer Horizon Cloud-Umgebung zu löschen, kann das System den Pod aufgrund dieser verbleibenden verbundenen Artefakte möglicherweise nicht vollständig löschen. Wenn Sie einen Pod mit der Aktion Löschen löschen, werden von Horizon Cloud standardmäßig die Ressourcengruppen und Subnetze gelöscht, die für den Pod angelegt wurden. Microsoft Azure verhindert das Löschen von Subnetzen, die noch verwendet werden. Wenn die Artefakte Ihrer Test-VM mit den Subnetzen des Pods verbunden sind, können diese Subnetze nicht gelöscht werden, und das Löschen des Pods ist unvollständig. Um dies zu verhindern, stellen Sie sicher, dass alle Artefakte der Test-VM gelöscht werden, nachdem Sie Ihren Pod erfolgreich bereitgestellt haben.

Löschen der Test-VM nach Abschluss der Tests

Wenn Sie die Tests zur Überprüfung Ihrer Microsoft Azure-Netzwerkkonfiguration abgeschlossen haben und die Test-VM nicht mehr benötigen, sollten Sie sie und alle zugehörigen Artefakte aus Ihrer Microsoft Azure-Umgebung löschen.

Prozedur

Melden Sie sich beim Microsoft Azure-Portal an.
Wenden Sie das zu Ihrer Bereitstellung passende folgende Verfahren an, um die Test-VM zu löschen.
- Wenn die Test-VM in einer eigenen Ressourcengruppe bereitgestellt wurde und diese Gruppe zu keinem anderen Zweck verwendet wird, können Sie die gesamte Ressourcengruppe löschen.
  Vorsicht: Um nicht versehentlich andere Elemente zu löschen, müssen Sie vor dem Löschen der Ressourcengruppe sicherstellen, dass die Ressourcengruppe wirklich nur Ihre Test-VM und die zugehörigen Objekte enthält, wie die Festplatte und die Netzwerkadapter.
- Wenn Sie die Test-VM löschen müssen, ohne eine gesamte Ressourcengruppe zu löschen, können Sie im Suchfeld des Portals nach dem Namen der Test-VM suchen. In den Suchergebnissen werden die VM und alle zugehörigen Objekte (Festplatten, Netzwerkschnittstellen, öffentliche IP-Adresse usw.) aufgelistet. Löschen Sie dann alle Objekte einzeln.