Wenn Ihre Next-Gen-Umgebung für Sie aktiviert ist, können Sie eine Self-Service-Migration einer Horizon Cloud on Microsoft Azure-Bereitstellung, die sich in der Horizon Cloud-Steuerungsebene der ersten Generation befindet, zu Horizon Cloud Service - next-gen einleiten.
So fangen Sie an
Wählen Sie einen der folgenden Links aus, je nachdem, wie viel des Migrationsvorgangs Sie bereits selbst oder mit dem Horizon Migration Team abgeschlossen haben.
- Was ist, wenn ich keine E-Mail vom Horizon Migration Team erhalten habe?
- Überprüfen Sie die aktuellen Berechtigungskriterien unter Ausschlüsse und Sonderfallszenarien für die Migration. Die Berechtigung zur Aktivierung hängt von bestimmten Faktoren ab. Diese Faktoren entwickeln sich im Laufe der Zeit weiter, sodass das Rollout schrittweise erfolgt.
| Wenn... | Nächste Schritte | |
|---|---|---|
| ☐ | Sie haben eine E-Mail vom Horizon Migration Team über die Migration zu Next-Gen erhalten, aber...
|
|
| ☐ | Sie haben das erste Onboarding für Next-Gen durchgeführt und sehen die Migrations-Benutzeroberfläche, aber...
|
|
| ☐ | Nachdem Sie den Identitätsanbieter und die Kopplung konfiguriert haben, aber...
|
|
| ☐ | Nachdem das Wartungsfenster geplant wurde, aber bevor das Datum erreicht ist. |
|
| ☐ | Kurz vor der Migrationswartungszeit bis zum Ende der Wartungsperiode. | Überprüfen: Lesen Sie die Informationen über die Vorgänge während des Wartungsfensters. |
| ☐ | Unmittelbar nach dem Wartungszeitraum. | Vorgehensweise: Führen Sie Aktivitäten nach der Migration durch |
| ☐ | Nach der Durchführung der Aktivitäten nach der Migration. |
|
Browsererfahrung
Die Next-Gen-Horizon Universal Console ist mit der neuesten Version (N) sowie den N-1- und N-2-Versionen von Google Chrome, Mozilla Firefox, Microsoft Edge und Apple Safari kompatibel. Die Migrationsaktivitäten, die mit der Next-Gen-Horizon Universal Console durchgeführt werden, werden mit diesen Browserversionen unterstützt.
Verwenden Sie für Migrationsaktivitäten, die in der First-Gen-Horizon Universal Console durchgeführt werden, wie z. B. das Abrufen des Kopplungsschlüssels, die mit der First-Gen-Horizon Universal Console kompatiblen Browserversionen, wie im First-Gen-Bereitstellungshandbuch beschrieben.
Phase 1 – Anfängliches Onboarding in der Horizon Cloud Service - next-gen-Umgebung
In dieser Phase führen Sie die ersten Onboarding-Schritte in der Next-Gen-Umgebung durch. Diese Schritte sind fast die gleichen wie die Schritte bei einer brandneuen Greenfield-Bereitstellung in der Next-Gen-Umgebung.
Führen Sie die Onboarding-Schritte aus, die auf der Seite Bereitstellung und Onboarding von VMware Horizon Cloud Service - next-gen beschrieben sind, und wählen Sie Ihre Horizon Cloud-Region aus.
Auswahl der Organisation
Beim Schritt des Onboarding-Workflows, bei dem die Benutzeroberfläche Sie auffordert, eine bestehende Organisation auszuwählen oder eine neue zu erstellen, geben Sie die Organisation an, für die Sie sich entschieden haben, indem Sie den Anweisungen unter Festlegen der zu verwendenden Cloud Services-Organisation folgen.
Auswahl der Cloud-Region
Nach der Organisation wird die Benutzeroberfläche für die Regionsauswahl angezeigt.
Wenn Sie sicherstellen möchten, dass Ihre Metadaten der Steuerungsebene in derselben geografischen Region verbleiben, die für Ihren First-Gen-Mandanten verwendet wurde, wählen Sie dieselbe geografische Region aus, die der Region Ihres First-Gen-Mandanten entspricht.
Der folgende Screenshot veranschaulicht den Schritt zur Regionsauswahl mit der Auswahl von USA ausgewählt.
Sie können Ihre Auswahl der Next-Gen-Region mit der Region abgleichen, die Sie für Ihren First-Gen-Mandanten verwendet haben. Auf diese Weise können Sie feststellen, welche Region der First-Gen-Steuerungsebene Sie verwenden. Um die Auswahl der Next-Gen-Region mit der Region abzugleichen, die Sie für Ihren First-Gen-Mandanten verwendet haben, melden Sie sich bei der First-Gen-Horizon Universal Console an und prüfen Sie nach Abschluss des Authentifizierungsvorgangs, wie unter Authentifizierung in einer Horizon Cloud-Umgebung beschrieben, den regionalen DNS-Namen, der im Adressfeld des Browsers angezeigt wird.
| Regionaler First-Gen-Name | Übereinstimmende Auswahl der Next-Gen-Region |
|---|---|
cloud.horizon.vmware.com |
USA |
cloud-eu-central-1.horizon.vmware.com |
Irland |
cloud-ap-southeast-2.horizon.vmware.com |
Australien |
cloud-us-2.horizon.vmware.com |
USA |
cloud-eu-2.horizon.vmware.com |
Irland |
cloud-ap-2.horizon.vmware.com |
Australien |
cloud-jp.horizon.vmware.com |
Japan |
cloud-uk.horizon.vmware.com |
Großbritannien |
cloud-de.horizon.vmware.com |
Deutschland |
Nach der Auswahl der Region
Nach dem Speichervorgang im vorhergehenden Schritt zeigt die Konsole normalerweise den Bildschirm Migration an.
Nächste Schritte
Folgen Sie der Anleitung auf dem Bildschirm. Erfüllen Sie die dokumentierten Migrationsvoraussetzungen und schließen Sie den Kopplungsvorgang ab.
Phase 2 – Koppeln von Umgebungen zur Ermöglichung der Migration zwischen Ihren Next-Gen- und First-Gen-Umgebungen
Um die Migration einer Horizon Cloud on Microsoft Azure-Bereitstellung zu Ihrer Next-Gen-Umgebung zu aktivieren, müssen Sie Ihre First-Gen-Umgebung mit Ihrer Horizon Cloud - next-gen-Umgebung koppeln.
Informationen zu diesem Kopplungscode
Ein Kopplungscode ist die Möglichkeit des Systems, Ihre Horizon Cloud - next-gen-Umgebung mit Ihrer First-Gen-Umgebung zu verknüpfen, um Ihre First-Gen-Bereitstellungen zu migrieren.
Sie erhalten einen Kopplungscode von Ihrer First-Gen-Umgebung, kopieren diesen Kopplungscode und fügen ihn in den Migrationsbereich Ihrer Horizon Cloud - next-gen-Umgebung ein.
Kopplungsschritte
Jedes Mal, wenn Sie den Kopplungscode mithilfe der Konsole generieren, ist der Code 30 Minuten lang gültig. Wenn Sie Schritt 9 nicht vor Ablauf der 30 Minuten abgeschlossen haben, wiederholen Sie einfach Schritt 5, um einen neuen zu erstellen, den Sie kopieren und in Schritt 9 einfügen.
Wenn Sie beide Konsolen gleichzeitig anzeigen möchten, verwenden Sie als Best Practice Browserfenster im privaten oder Inkognito-Modus, um Benutzeroberflächenprobleme zu vermeiden, die durch den Browser-Cache von Bildern oder anderen zwischengespeicherten Seiteninhalten entstehen können.
- Rufen Sie den Kopplungscode mithilfe einer dieser Methoden ab.
- Wenn in Ihrer Konsole das Migrationsbanner angezeigt wird, können Sie auf das Banner AUF GEHT'S klicken, um den Migrationsassistenten Next-Gen-Migration zu starten, und im Schritt Erste Schritte die Option Ja auswählen, um den Kopplungscode anzuzeigen, wie im folgenden Screenshot dargestellt.
Hinweis: Die First-Gen-Konsole zeigt dieses Banner und den Assistenten nur an, wenn VMware sie in Ihrer First-Gen-Umgebung aktiviert hat.
- Klicken Sie auf den in der Konsole angezeigten Kontonamen und wählen Sie Kopplungscode aus.
- Wenn in Ihrer Konsole das Migrationsbanner angezeigt wird, können Sie auf das Banner AUF GEHT'S klicken, um den Migrationsassistenten Next-Gen-Migration zu starten, und im Schritt Erste Schritte die Option Ja auswählen, um den Kopplungscode anzuzeigen, wie im folgenden Screenshot dargestellt.
- Kopieren Sie den Kopplungscode. Der folgende Screenshot zeigt den Code, der aus Datenschutzgründen geschwärzt wurde.
Der Kopplungscode ist 30 Minuten lang gültig.
Wenn der Code abläuft, können Sie über die Konsole mit einer Aktualisierungsaktion einen neuen Code generieren.
- Wechseln Sie zur Seite Migration in Ihrer Horizon Cloud - next-gen-Umgebung.
- Im Assistenten Migration – Erste Schritte können Sie auf Starten klicken, um die Next-Gen-Konsole zu starten, auf der die Seite Migration angezeigt wird.
- Alternativ können Sie ein Browserfenster öffnen, sich bei VMware Cloud Services anmelden und auf der Seite Dienste zum Workspace ONE-Dienst navigieren. Suchen Sie die Horizon Cloud Service-Karte innerhalb Ihrer Workspace ONE Cloud-Dienste und klicken Sie dann auf die Aktion, um die Next-Gen-Konsole von dort aus zu öffnen. Navigieren Sie dann zur Seite Migration, indem Sie den Eintrag Migration im linken Navigationsmenü verwenden.
Der folgende Screenshot veranschaulicht die Seite Migration der Konsole.
- Klicken Sie auf den Link Mandanten koppeln.
- Fügen Sie im daraufhin angezeigten Fenster „Mandanten koppeln“ den kopierten Kopplungscode in das Feld Kopplungscode ein.
Der folgende Screenshot veranschaulicht diesen Schritt. Der eingefügte Code wird hier aus Datenschutzgründen geschwärzt.
- Klicken Sie auf Koppeln.
Wenn das System die Mandanten erfolgreich gekoppelt hat, zeigt die Next-Gen-Benutzeroberfläche an, dass die Kopplung erfolgreich war.
Nächste Schritte
Nachdem Ihr First-Gen-Mandant und Ihr Next-Gen-Mandant gekoppelt sind, folgen Sie den Anweisungen auf dem Bildschirm und stellen Sie eine Verbindung zu einem Identitätsanbieter her.
Phase 3 – Konfigurieren der erforderlichen Identitätsanbietereinstellungen in Ihrer Next-Gen-Umgebung
In dieser Phase des Migrationsworkflows müssen Sie Einstellungen für einen externen Identitätsanbieter eingeben. Diese Einstellungen registrieren den Identitätsanbieter für die Verwendung mit der Next-Gen-Umgebung.
Kurze Einführung
Die Next-Gen-Umgebung ist auf einen externen Identitätsanbieter angewiesen, der die Authentifizierung vornimmt, die erforderlich ist, wenn Endbenutzer versuchen, auf ihre berechtigten Ressourcen zuzugreifen.
Die Verwendung eines externen Identitätsanbieters in der Next-Gen-Architektur ermöglicht die Integration mit Produkten und Lösungen von Drittanbietern, um Multifaktor-Authentifizierung und SSO-Funktionen bereitzustellen.
Stellen Sie vor der Registrierung des Identitätsanbieters sicher, dass die AD-Domäne des zu migrierenden Pods mit Ihrem Identitätsanbieter verbunden ist – demjenigen, den Sie für diese Next-Gen-Umgebung angeben werden.
Videodarstellung
In diesen Tech Zone-Videos wird die Konfiguration eines der unterstützten Identitätsanbietertypen in einer Next-Gen-Umgebung dargestellt:
- Eine Demo mit Microsoft Entra ID finden Sie ab Minute 3 in der Tech Zone: Planen einer Pod-Migration, um die Schritte zum Konfigurieren von Microsoft Entra ID als Identitätsanbieter anzuzeigen.
- Eine Demo mit Workspace ONE Access finden Sie im Video in der Übung: Verbinden von Workspace ONE Access als Benutzeridentitätsanbieter für Horizon Cloud
Vorbereitungen
Stellen Sie sicher, dass Ihr Identitätsanbieter eingerichtet und mit Ihrer AD-Domäne verbunden ist, wie auf der Seite Einrichten Ihres Identitätsanbieters im Horizon Cloud - next-gen-Handbuch beschrieben.
Die Benutzeroberfläche der Next-Gen-Mandantenkonsole erfordert die Eingabe eines zusätzlichen Domänenbeitrittskontos. Dies ist ein Unterschied zur First-Gen-Mandantenkonsole, bei der das zusätzliche Domänenbeitrittskonto optional war. Stellen Sie sicher, dass Sie über den Namen eines zusätzlichen Domänenbeitrittskontos verfügen, bevor Sie die Schritte zur Domänenregistrierung in der Benutzeroberfläche starten.
Erstellen der Identitätsanbieterverbindung
Navigieren Sie in der Konsole für Ihren Next-Gen-Mandanten zur Registerkarte „Identitätsanbieter“, indem Sie auf der Seite „Migration“ auf Verbinden klicken.
Schließen Sie den Identitätsanbieter-Ablauf der Konsole ab, um den Next-Gen-Mandanten mit einem Identitätsanbieter zu verbinden.
Spezifische Anleitungen zur Benutzeroberfläche des Identitätsanbieters finden Sie auf der Seite Verbinden Ihres Identitätsanbieters im Horizon Cloud - next-gen-Handbuch.
Der folgende Screenshot zeigt den abgeschlossenen Zustand, in dem der Identitätsanbieter erfolgreich verbunden ist (einige Werte wurden aus Datenschutzgründen geschwärzt).
Nächste Schritte
Navigieren Sie in der Next-Gen-Konsole zur Seite Migration.
Jetzt, da der Identitätsanbieter verbunden ist, stellt die Konsole die Schaltfläche Starten zur Verfügung. Sie können darauf klicken, um mit der Planung der automatisierten Migration zu beginnen.
Phase 4 : Planen des Wartungsfensters für die Migration eines Pods
In dieser Phase wählen Sie den zu migrierenden Pod aus, geben die erforderlichen Details für den Aufbau des Horizon Edge des Systems an und reservieren einen Kalendersteckplatz, in dem das Wartungsfenster für die Migration stattfinden soll.
Dieser Kalendersteckplatz ist das Wartungsfenster.
Während des Wartungsfensters können Sie und andere Administratoren nicht auf die Horizon Universal Console Ihres First-Gen-Mandanten zugreifen und Ihre Endbenutzer können nicht auf ihre Desktops und Anwendungen zugreifen, die vom migrierenden Pod bereitgestellt wurden.
Bevor Sie mit diesen Schritten beginnen
Bevor Sie diesen Workflow in der Konsole starten, stellen Sie sicher, dass die folgenden Elemente vorhanden sind.
| ☐ | Alle Voraussetzungen sind vorhanden |
| ☐ | Sie haben festgelegt, welcher Horizon Edge Gateway-Bereitstellungstyp – Einzel-VM oder AKS – verwendet werden soll: Auswählen des Bereitstellungstyps und Erfüllen der entsprechenden Anforderungen. |
| ☐ | Zusätzlich zu den Hauptvoraussetzungen haben Sie die Voraussetzungen für den ausgewählten Horizon Edge Gateway-Bereitstellungstyp erfüllt: |
| ☐ | Sie haben die Schritte in Phase 3 – Konfigurieren der erforderlichen Identitätsanbietereinstellungen in Ihrer Next-Gen-Umgebung abgeschlossen. |
| ☐ | Stellen Sie sicher, dass Azure-Richtlinien, die sich auf die Erstellung von Tags und Ressourcengruppen beziehen, aufgehoben (ausgeschaltet) sind und ausgeschaltet bleiben, bis Sie sehen, dass die Horizon Edge Gateway- und Unified Access Gateway-Instanzen erfolgreich im Abonnement des Pods bereitgestellt wurden. Die Bereitstellungsaktivität beginnt, nachdem Sie den Planungsassistenten abgeschlossen haben. Nach erfolgreicher Bereitstellung werden Benachrichtigungsmeldungen in der Next-Gen-Horizon Universal Console angezeigt. |
Die Benutzeroberfläche des Planungsassistenten erfordert die Auswahl oder Eingabe von Werten für die folgenden Elemente.
Stellen Sie sicher, dass diese Informationen und Elemente vorhanden sind, bevor Sie den Assistenten starten. Diese Elemente werden alle auf den Seiten mit den Voraussetzungen beschrieben.
| ☐ | Neue Unified Access Gateway-Elemente:
Wichtig: Stellen Sie sicher, dass der allgemeine Name oder FQDN des Zertifikats genau mit dem FQDN übereinstimmt, den Sie im Assistenten eingeben möchten. Der Assistent validiert die Daten innerhalb des Zertifikats mit dem eingegebenen FQDN. Wenn keine Übereinstimmung vorliegt, verhindert das System die Planung der Migration und der Planungsassistent muss abgebrochen werden.
|
| ☐ Bei Verwendung des AKS-Bereitstellungstyps |
Für den AKS-Typ fragt Sie der Assistent nach:
Hinweis: Wenn Sie ein neues VNet und Management-Subnetz für die Verwendung mit dem AKS-Typ erstellen mussten, um die durch AKS eingeschränkten IP-Adressen zu umgehen, stellen Sie sicher, dass Sie deren Namen kennen, damit Sie sie in der Benutzeroberfläche des Assistenten identifizieren und auswählen können.
|
| ☐ Bei Verwendung des Bereitstellungstyps „Einzel-VM“ |
Für den Typ „Einzel-VM“ fragt der Assistent nicht nach Eingaben. |
| ☐ Wenn das externe Gateway des Pods eine private IP-Adresse verwendet |
Wenn die Bereitstellung eines externen Gateways des Next-Gen-Pods für die Verwendung einer privaten IP-Adresse konfiguriert ist, müssen Sie die neue öffentliche IP-Adresse für die Unified Access Gateway-Next-Gen-Bereitstellung verwenden (siehe Beschreibung unter Voraussetzungen für die Migration eines First-Gen-Horizon Cloud-Pods). Im Assistenten werden Sie nach diesen Informationen gefragt. |
Einige Site-bezogene Punkte – Universal Broker-Umgebungen
Beachten Sie diese Punkte, wenn Sie über eine First-Gen-Universal Broker-Umgebung mit mehreren Horizon Cloud-Pods verfügen.
Gemäß der Beschreibung auf der Seite Arbeiten mit Sites in einer Universal Broker-Umgebung des Next-Gen-Administratorhandbuchs können Sie Sites und Start-Sites konfigurieren, wenn Ihr First-Gen-Mandant Universal Broker verwendet.
- Das System migriert die Site-Konfigurationen, die während der ersten Pod-Migration im First-Gen-Mandanten vorhanden sind. Ein Beispiel für Site-bezogene Informationen ist die Zuordnung eines Benutzers zu einer Start-Site.
- Wenn Sie die Migration des ersten Pods abschließen und anschließend Änderungen an den Site-bezogenen Informationen in der First-Gen-Umgebung vornehmen, werden diese Änderungen erst nach der nächsten Pod-Migration in der Next-Gen-Umgebung angezeigt.
- Alle vorhandenen Site-zu-Benutzer- und Site-zu-Gruppen-Zuordnungen in der Next-Gen-Umgebung fungieren als Source of Truth, wenn ein Pod migriert wird. Wenn eine Start-Site-Zuordnung für einen Benutzer oder eine Gruppe sowohl in der Next-Gen-Umgebung als auch in der First-Gen-Umgebung vorhanden ist, wird die First-Gen-Site-Zuordnung während der Migration ignoriert. Diese Informationen sind im Migrationsbericht enthalten.
- Überprüfen Sie nach der Migration jedes Pods gegebenenfalls die Zuordnungen der Home-Sites in der Next-Gen-Umgebung und aktualisieren Sie sie entsprechend den Anforderungen Ihres Unternehmens.
Workflow-Benutzeroberfläche zur Planung der Migration
Klicken Sie auf Start auf der Seite „Migration“, um den Workflow Migration planen anzuzeigen.
Die Konsole zeigt den Satz der First-Gen-Horizon Cloud on Microsoft Azure-Bereitstellungen an, die sich in der Pod-Flotte des First-Gen-Mandanten befinden, die mit diesem Next-Gen-Mandanten gekoppelt sind.
Das System überprüft automatisch, ob eine First-Gen-Bereitstellung mit der Self-Service-Migration kompatibel ist. Zu diesen Kriterien gehört die Überprüfung, ob auf den Pod-Manager-Instanzen eine geeignete Manifest-Version ausgeführt wird, ob die Images, VDI-Desktops und Farm-VMs über die geeigneten Horizon Agent-Versionen verfügen und ob die bei der First-Gen-Bereitstellung verwendeten Funktionen auch mit den aktuellen Fähigkeiten der Self-Service-Migration kompatibel sind.
Für jede Bereitstellung der ersten Generation gibt die Konsole an, ob die Bereitstellung die Kriterien des Systems für ihre automatisierte Migration erfüllt. Wenn die Kriterien erfüllt sind, zeigt die Benutzeroberfläche Bereit zur Migration an.
Wenn die Bereitstellung die Kriterien nicht erfüllt, können Sie auf die Statusspalte klicken, um ein Fenster anzuzeigen, in dem die Probleme beschrieben werden. Nachdem Sie diese Elemente adressiert haben, können Sie die Aktion Erneut prüfen verwenden, um die Systemprüfung der First-Gen-Bereitstellung erneut auszuführen. Beispiele für die Kriterien, die die Einsätze erfüllen müssen, finden Sie unter Ausschlüsse und Sonderfallszenarien für die Migration.
First-Gen-Pod auswählen
Wenn die Benutzeroberfläche anzeigt, dass der zu migrierende Pod bereit für die Migration ist, wählen Sie den Pod aus und klicken Sie auf Weiter.
Wenn Sie in Ihrer First-Gen-Umgebung über mehrere Pods mit einer Kombination aus rein internen Gateways und externen Gateways verfügen, migrieren Sie zunächst die Pods mit externen Gateways.
Klicken Sie nach der Auswahl eines Pods auf Weiter, um fortzufahren.
Horizon Edge – Neu hinzufügen, Vorhandene auswählen
Wenn Sie auf Weiter klicken, analysiert das System, was in der Next-Gen-Umgebung für einen Horizon Edge verfügbar ist, um den Pod nach der Migration darzustellen.
Der Assistent zeigt Schaltflächen an:
- Neu hinzufügen
- Vorhandene auswählen
Eine abgeblendete Schaltfläche bedeutet, dass sie für diese Migration nicht verwendet werden kann und die vom System gewählte Schaltfläche verwendet werden muss. Der Grund wird in einem Banner angezeigt.
Wenn keine der beiden Schaltflächen abgeblendet ist und eine standardmäßig ausgewählt ist, bedeutet dies, dass das System die Verwendung der vorausgewählten Schaltfläche empfiehlt und Sie die Empfehlung des Systems außer Kraft setzen und die andere Schaltfläche für diese Migration auswählen können.
In den folgenden Abschnitten wird kurz beschrieben, wozu die Schaltflächen Neu hinzufügen und Vorhandene auswählen im Ablauf Migration planen dienen.
Schaltfläche – Vorhandene auswählen
Wenn Vorhandene auswählen ausgewählt ist, zeigt der Assistent eine Liste der vorhandenen Horizon Edges der Umgebung an. Wählen Sie den Horizon Edge aus, der für diese Migration verwendet werden soll, und klicken Sie auf Weiter. Fahren Sie fort mit Schritt 3 – Planen des Migrationszeitraums.
Wenn Sie einen vorhandenen Horizon Edge verwenden, skaliert das System die vorhandene Unified Access Gateway-Bereitstellung mit derselben Anzahl von Unified Access Gateway-Instanzen, die mit dem First-Gen-Pod verbunden sind. Die Höchstgrenze für diese Skalierung liegt bei acht (8) Unified Access Gateway-Instanzen. Wenn diese Grenze im ausgewählten Horizon Edge erreicht ist, wird die Unified Access Gateway-Bereitstellung nicht mehr erweitert.
Beachten Sie auch die folgenden Anwendungsfälle:
- Der First-Gen-Pod verfügt über dasselbe Abonnement, dieselbe Microsoft Azure-Region und eine andere App-ID (Dienstprinzipal) als der ausgewählte Horizon Edge: Das System skaliert den Anbieter des ausgewählten Horizon Edge, indem die App-ID des First-Gen-Pods zu diesem Anbieter hinzugefügt wird.
- Der First-Gen-Pod hat ein anderes Abonnement, dieselbe Microsoft Azure-Region und eine andere App-ID (Dienstprinzipal) als der ausgewählte Horizon Edge: Das System fügt einen sekundären Anbieter zum ausgewählten Horizon Edge hinzu.
Schaltfläche – Neu hinzufügen
Wenn Neu hinzufügen ausgewählt ist, erstellt das System einen neuen Horizon Edge für die Migration dieses First-Gen-Pods.
In diesem Fall werden Sie vom Assistenten aufgefordert, die angezeigten Optionen und Felder für die Konfiguration des neuen Horizon Edge auszufüllen.
| Felder der Benutzeroberfläche | Beschreibung |
|---|---|
| Horizon Edge-Name | Geben Sie einen Namen an, der diesen Horizon Edge innerhalb Ihres Next-Gen-Mandanten eindeutig identifiziert. Der Name muss mit einem Buchstaben [a–Z] beginnen und darf nur Buchstaben, Bindestriche (-) und Ziffern enthalten. |
| Bereitstellungstyp | Klicken Sie auf die Auswahl, die dem Bereitstellungstyp entspricht, den Sie für das Horizon Edge Gateway verwenden möchten. Einzelne virtuelle Maschine ist die Standardeinstellung.
|
Siehe den Abschnitt unten, der dem von Ihnen gewählten Bereitstellungstyp entspricht.
Bereitstellungstyp „Einzelne virtuelle Maschine“
Für eine Bereitstellung vom Typ Einzelne virtuelle Maschine gibt es keine zusätzlichen Felder im Assistenten. Dieser Bereitstellungstyp verwendet das Management-Subnetz des Pods für das Horizon Edge Gateway.
Fahren Sie mit den Unified Access Gateway-Informationen fort.
Bereitstellungstyp „Azure Kubernetes Service“
Füllen Sie die Felder aus. Diese sind alle erforderlich. Die Benutzeroberfläche validiert, dass alle Felder Einträge aufweisen, bevor die Schaltfläche Weiter aktiviert wird.
| Felder der Benutzeroberfläche | Beschreibung |
|---|---|
| Ausgehender Clustertyp | Zwei Optionen: NAT-Gateway oder Benutzerdefinierte Routen. Wählen Sie die Option, die dem entspricht, was Sie oder Ihr IT-Team in Azure eingerichtet haben, um diese Anforderung zu erfüllen, wie im Abschnitt AKS-Typ – Konfigurieren und Verknüpfen eines NAT-Gateways oder einer Routentabelle mit dem Management-Subnetz beschrieben. |
| Vom Benutzer zugewiesene verwaltete Identität | Wählen Sie die Option aus, die der von Ihnen oder Ihrem IT-Team in Azure getroffenen Auswahl entspricht, um diese Anforderung zu erfüllen (siehe Abschnitt AKS-Typ – vom Benutzer zugewiesene verwaltete Identität erstellen). |
| Virtuelles Netzwerk und Management-Subnetz | Wenn beide Felder angezeigt werden, wählen Sie aus, was Sie für die Erfüllung der Voraussetzungen vorbereitet haben. Diese Felder werden angezeigt, wenn die Systemprüfungen ergeben, dass sich das VNet mit den AKS-eingeschränkten IP-Bereichen überschneidet, wie in Feststellen, ob das VNet oder die verbundenen Netzwerke des Pods IP-Adressen mit AKS-Beschränkung enthalten beschrieben. Wählen Sie das neue VNet und das Management-Subnetz in diesem VNet aus. |
| Dienst-CIDR | Geben Sie das CIDR ein, für das Sie oder Ihr IT-Team sich entschieden haben, um die AKS-Dienst-CIDR-Anforderung zu erfüllen, wie auf der Seite AKS-Typ – Erforderliche virtuelle IP-Bereiche reservieren beschrieben. |
| Pod-CIDR | Geben Sie das CIDR ein, für das Sie oder Ihr IT-Team sich entschieden haben, um die AKS-Pod-CIDR-Anforderung zu erfüllen, wie auf der Seite AKS-Typ – Erforderliche virtuelle IP-Bereiche reservieren beschrieben. |
Unified Access Gateway-Informationen
| Felder der Benutzeroberfläche | Beschreibung |
|---|---|
| Unified Access Gateway-FQDN | Geben Sie den FQDN für den Unified Access Gateway ein, den Sie oder Ihr IT-Team für diese Bereitstellung verwendet haben. Die Horizon Agents in den virtuellen Desktops und Apps stellen eine Verbindung zu diesem FQDN her. |
| Zertifikatstyp | Zwei Optionen: PEM oder PFX. Wählen Sie den Typ aus, der dem Zertifikat entspricht, das Sie oder Ihr IT-Team für diese Bereitstellung erhalten haben, und das mit dem Unified Access Gateway-FQDN übereinstimmt. Für PFX wird ein zusätzliches Feld Kennwort angezeigt, in dem Sie das Kennwort für das PFX-Zertifikat eingeben können. |
| Zertifikat | Klicken Sie auf die Schaltfläche, um das Zertifikat hochzuladen. |
| Manuelle öffentliche IP | Dieses Feld wird angezeigt, wenn das System erkennt, dass die externe Gateway-Bereitstellung des First-Gen-Pods für die Verwendung einer privaten IP-Adresse konfiguriert ist. Geben Sie die öffentliche IP-Adresse ein, die Sie für die Next-Gen-Bereitstellung verwenden möchten (siehe Beschreibung unter Voraussetzungen für die Migration eines First-Gen-Horizon Cloud-Pods).
Hinweis: Diese öffentliche IP muss sich von der öffentlichen IP unterscheiden, die bereits für die zu migrierende First-Gen-Bereitstellung verwendet wird, um gegebenenfalls ein Rollback auf den First-Gen-Bereitstellungsstatus zu unterstützen.
Im Rahmen der Präbuild-Aktivitäten stellt das System den Lastausgleichsdienst der Unified Access Gateway-Next-Gen-Bereitstellung mit einer privaten IP-Adresse bereit. Nachdem der Lastausgleichsdienst bereitgestellt wurde und seine private IP-Adresse bekannt ist, muss das Routing so eingerichtet werden, dass diese öffentliche IP den Datenverkehr an die private IP des bereitgestellten Lastausgleichsdiensts weiterleitet. |
Wenn alle Felder ausgefüllt sind, klicken Sie auf die Schaltfläche Weiter, um zum nächsten Schritt zu gelangen.
Schritt 3 – Planen des Migrationszeitraums
In diesem Schritt wählen Sie einen Zeitraum für das Wartungsfenster der Migration aus.
Während des ausgewählten Zeitraums:
- Nehmen Sie keine Änderungen am First-Gen-Pod, seinen Ressourcen, Einstellungen usw. vor.
- Nehmen Sie keine Änderungen an der Bereitstellung der Next-Gen-Umgebung vor.
- Das System verhindert den Zugriff auf die Horizon Universal Console.
- Ihre Endbenutzer können nicht auf ihre Desktops und Anwendungen zugreifen, die vom migrierenden Pod bereitgestellt werden.
- Vermeiden Sie den Zugriff auf die Next-Gen-Umgebung während des ausgewählten Zeitraums, um eine Unterbrechung des Prozesses zu vermeiden.
Die Benutzeroberfläche zeigt eine Kalenderansicht mit den Steckplätzen an, die das System für die Migrationsaktivitäten zur Verfügung stellt.
- Die Kalenderansicht gibt genau an, welche Tage und Zeitfenster für die Migration Ihres ausgewählten First-Gen-Pods verfügbar sind.
- Im Allgemeinen wird der erste Tag, der zur Auswahl steht, mindestens 7 Tage in der Zukunft sein.
- Sie können diese Kalenderansicht nach Bedarf durchblättern, um ein Datum und ein Zeitfenster zu finden, das den Bedürfnissen Ihres Teams und Ihrer Organisation entspricht.
- Jedes Zeitfenster ist ein 6-Stunden-Block.
Der folgende Screenshot veranschaulicht den Kalender der Benutzeroberfläche, der für die Auswahl des Wartungsfensters für die Migration verwendet wird.
Wenn Sie mit dem Mauszeiger über einen der Zeitblöcke fahren, wird ein Popup-Fenster angezeigt, das die Zeit dieses Zeitfensters sowohl in der Ortszeit Ihres Browsers als auch in UTC angibt.
Der folgende Screenshot zeigt einen ausgewählten Block. Das System startet seine Aktivitäten zu diesem Zeitpunkt.
Wenn Sie eines der Zeitfenster ausgewählt haben, klicken Sie auf Speichern, um Ihre Auswahl zu speichern.
Nächste Schritte des Systems
Nachdem Sie Ihr ausgewähltes Zeitfenster gespeichert haben, zeigt das System eine Meldung an, die Ihr ausgewähltes Zeitfenster bestätigt und die nächsten Schritte beschreibt.
Nachdem Sie in der Bestätigungsmeldung auf OK geklickt haben, wird das System:
- Die Präbuild-Aktivitäten durchführen.
- Bei Verwendung von Neu hinzufügen (Migration zu einem neuen Horizon Edge)
- In diesem Fall stellt das System Horizon Edge und die zugehörigen Ressourcen (Horizon Edge Gateway- und Unified Access Gateway-Instanzen sowie zugehörige Lastausgleichsdienste) bereit.
- Bei Verwendung von Vorhandene auswählen (Migration zu einem vorhandenen Horizon Edge)
-
Wenn Sie einen vorhandenen Horizon Edge verwenden, skaliert das System die vorhandene Unified Access Gateway-Bereitstellung mit derselben Anzahl von Unified Access Gateway-Instanzen, die mit dem First-Gen-Pod verbunden sind. Die Höchstgrenze für diese Skalierung liegt bei acht (8) Unified Access Gateway-Instanzen. Wenn diese Grenze im ausgewählten Horizon Edge erreicht ist, wird die Unified Access Gateway-Bereitstellung nicht mehr erweitert.
Beachten Sie auch die folgenden Anwendungsfälle:
- Der First-Gen-Pod hat dasselbe Abonnement, dieselbe Microsoft Azure-Region, eine andere Dienstprinzipal-App-ID: Das System skaliert den ausgewählten Horizon Edge-Anbieter, indem es die App-ID des First-Gen-Pods zu diesem Anbieter hinzufügt.
- Der First-Gen-Pod hat ein anderes Abonnement, dieselbe Microsoft Azure-Region und eine andere Dienstprinzipal-App-ID: Das System fügt dem ausgewählten Horizon Edge einen sekundären Anbieter hinzu.
- Kopieren Sie die veröffentlichten Images und App Volumes-Anwendungen vom First-Gen-Pod auf den Horizon Edge.
Ein bereitgestellter Horizon Edge verfügt über einen Lastausgleichsdienst für die Horizon Edge Gateway-Instanz und einen Lastausgleichsdienst für die Unified Access Gateway-Instanzen.
Im Anwendungsfall Neu hinzufügen können Sie und Ihr IT-Team nach der Bereitstellung des neuen Horizon Edge die IP-Adressen für diese Lastausgleichsdienste abrufen und Ihren DNS aktualisieren, um einen Datensatz hinzuzufügen, der die IP-Adresse des Unified Access Gateway-FQDN-Lastausgleichsdiensts dem im Assistenten „Migration planen“ angegebenen Unified Access Gateway-FQDN zuordnet. Weitere Informationen finden Sie unter Konfigurieren der erforderlichen DNS-Einträge nach der Bereitstellung von Horizon Edge Gateway und Unified Access Gateway in der Next-Gen-Dokumentation.
Klicken Sie in der Bestätigungsmeldung auf OK, um zur Migrationsseite der Konsole zurückzukehren.
Ihre nächsten Schritte
Die meiste Zeit während der Präbuild-Phase des Systems verbringen Sie damit, darauf zu warten, dass das System seine Präbuild-Aktivitäten beendet (siehe Migrationsflussdiagramm).
Während der Präbuild-Phase können Sie die Spalten Migrationsstatus und Bericht auf der Seite Migration der Konsole verwenden.
Auch wenn diese DNS-Einträge nach Abschluss der Wartungsaktionen konfiguriert werden können, ist die migrierte Umgebung ohne die DNS-Einträge, die die angegebenen FQDNs den zugrunde liegenden IP-Adressen zuordnen, die diesen Ressourcen zugeteilt sind, möglicherweise nicht voll funktionsfähig. Siehe Phase 6 – Konfigurieren von DNS-Datensätzen für die in Phase 5 der Self-Service-Migration erstellte Infrastruktur.
Funktionen der Migrationsseite
Da nun ein Pod für die Migration geplant ist, zeigt die Seite „Migration“ der Konsole diesen Status an und stellt Aktionen zum Neuplanen (Neu planen) und Abbrechen (Abbrechen) der geplanten Migrationszeit zur Verfügung.
Wenn Sie eine dieser Aktionen auswählen, folgen Sie den Eingabeaufforderungen auf dem Bildschirm.
Der folgende Screenshot zeigt den ausgewählten Pod und die Verfügbarkeit der Aktionen „Neu planen“ und „Abbrechen“. Die Aktion „Abschließen“ in diesem Screenshot ist nicht verfügbar, da dieser Pod noch nicht migriert wurde.
Phase 5 – Präbuild – Automatisierte Aktionen vor dem Öffnen des Wartungsfensters
Während dieser Phase führt das System automatisch Präbuild-Migrationsaktivitäten vor dem angegebenen Migrationsfenster durch. Diese Vorverlagerung von Aktivitäten zielt darauf ab, den Zeitaufwand für das Wartungsfenster der Migration so gering wie möglich zu halten.
Kurze Einführung
Wie unter Was Sie erwarten können beschrieben, verkürzt die Verwendung eines Präbuilds die Zeit, die für die Migration während des Wartungsfensters benötigt wird.
Für alle Migrationen stellt das System die erforderlichen Ressourcen während der Präbuild-Phase bereit.
Wenn die Migration einen neuen Horizon Edge verwendet, stellt das System auch die Ressourcen für den Horizon Edge zu Beginn des Präbuilds bereit.
Beachten Sie Folgendes:
- Auch wenn die Next-Gen-Konsole Sie nicht daran hindert, Pools in der Next-Gen-Umgebung mit diesen Ressourcen zu erstellen, empfiehlt VMware dringend, die Erstellung von Pools oder andere Erstellungsvorgänge mit diesen neuen Ressourcen erst nach Abschluss der gesamten Migration durchzuführen.
Wenn diese Ressourcen in der Next-Gen-Umgebung vor dem Wartungsfenster für die Migration verwendet werden und Sie anschließend die Migration abbrechen oder die Rollback-Aktion der Benutzeroberfläche verwenden, kann das System die Next-Gen-Umgebung nicht in ihren ursprünglichen Ausgangszustand zurückversetzen. In diesem Szenario müssen Sie möglicherweise zusätzliche manuelle Aktionen in der Umgebung durchführen, um sie in einen Zustand zu versetzen, in dem das System in der Lage ist, Sie den Migrationsvorgang erneut einleiten zu lassen.
- Zunächst dupliziert das System während des Präbuilds vorübergehend jedes veröffentlichte First-Gen-Image in der Ressourcengruppe base-vms des First-Gen-Pods und führt Agent-Aktualisierungen und andere Aktivitäten für diese Duplikate durch, bevor sie in der Next-Gen-Umgebung veröffentlicht werden. Diese temporären VMs verwenden die Benennungskonvention MIGXXXXXXXXXXXX.
Während der Verarbeitung dieser temporären VMs durch das System und bis zu deren Veröffentlichung in der Next-Gen-Umgebung werden die MIGXXXXXXXXXXXX-Images auf der Seite Importierte VMs der First-Gen-Konsole angezeigt.
Die Durchführung beliebiger Aktionen auf diesen temporären VMs muss vermieden werden, da dies zum Fehlschlagen der Präbuild-Phase der Migration führen kann. Schalten Sie die temporären VMs beispielsweise nicht aus.
Dieser Präbuild wirkt sich nicht auf Ihren vorhandenen Pod oder Ihre vorhandenen Benutzersitzungen aus.
Während des Präbuilds
Während des Präbuilds:
- Wenn bei der Migration ein neuer Horizon Edge anstelle eines vorhandenen verwendet wird, stellt das System den Next-Gen-Horizon Edge bereit und verwendet dabei die Eingaben, die Sie in der Benutzeroberfläche Migration planen in Phase 4 gemacht haben.
- Anschließend übernimmt das System die First-Gen-Konfigurationsdaten, die auf Pod-Ebene und in der First-Gen-Steuerungsebene gespeichert sind, wandelt die Daten entsprechend dem Design der Next-Gen-Steuerungsebene um und speichert die umgewandelten Daten entsprechend.
- Wenn diese Migration die erste in die Next-Gen-Umgebung ist, übernimmt das System die Active Directory (AD)-Domänenkonfigurationen des First-Gen-Mandanten und erstellt die entsprechenden Domänenkonfigurationen in der Next-Gen-Umgebung.
In der Next-Gen-Umgebung registriert das System alle registrierten Domänen des First-Gen-Mandanten während der Präbuild-Aktivitäten für die erste geplante Migration. Bei nachfolgenden Pod-Migrationen aus demselben First-Gen-Mandanten überprüft das System erneut, ob die First-Gen-Mandantenkonfigurationen synchronisiert sind, und überspringt die Registrierung von Domänen, die bereits in der Next-Gen-Umgebung vorhanden sind.
Hinweis: Die Next-Gen-Umgebung erfordert Hilfskonten sowohl für das Domänendienst- als auch für das Domänenbeitrittskonto in den Next-Gen-AD-Domänenkonfigurationen. Wenn in der AD-Domänenkonfiguration eines First-Gen-Mandanten ein Hilfsdomänendienstkonto oder ein zusätzliches Domänenbeitrittskonto fehlt, verwendet das System die Informationen des primären Kontos automatisch als Begleit-Hilfskonto in der Next-Gen-AD-Domänenkonfiguration.Als Best Practice sollten Sie Dienstkonten in Ihren AD-Domänen für diese Hilfsdomänendienst- und Domänenbeitrittskonten abrufen und nach den Präbuild-Aktivitäten die AD-Domänenkonfigurationen bearbeiten, um diese Hilfskonten hinzuzufügen.
- Das System kopiert die veröffentlichten Images der First-Gen-Bereitstellung und die auf App Volumes bezogenen Dateien auf den Horizon Edge und konfiguriert die Kopien für die Verwendung mit dem Horizon Edge.
- Für jedes der folgenden First-Gen-Elemente erstellt das System einen Testpool in Horizon Edge.
- RDSH-Desktop-Farmen
- RDSH-App-Serverfarmen
- Flexible Desktop-Zuweisungen (Pools) von Einzel-Pod-Broker-Mandanten. (Multi-Cloud-Zuweisungen haben keine Testpools.)
Jeder Testpool enthält eine Maschine und spiegelt die Konfigurationseinstellungen des Pools von seinem First-Gen-Gegenstück ab.
Sie können diese Testpools verwenden, um vorab zu überprüfen, ob sich die Maschinen des Pools Ihren Erwartungen entsprechend verhalten, bevor der Pool während des Wartungsfensters vollständig migriert wird.Hinweis: Da das System flexible und RDSH-Pools neu erstellt, können bei lizenzierten Lösungen von Drittanbietern in Ihrer Umgebung, bei denen die Lizenz an die Identität der VM gebunden ist, mehr dieser Lizenzen verbraucht werden.
Die Präbuild-Aktivitäten enden an diesem Punkt. Die nächsten Aktivitäten des Systems werden zu Beginn des geplanten Wartungszeitraums gestartet. Zur Vorbereitung auf ein Rollback bleiben die veröffentlichten Images und die auf App Volumes bezogenen Dateien der First-Gen-Bereitstellung bis zur Bestätigung, dass die End-to-End-Migration abgeschlossen ist, erhalten.
Ihre nächsten Schritte
Nachdem die Ressourcen in Ihrem Abonnement erstellt wurden, führen Sie die in den folgenden Abschnitten beschriebenen Aktivitäten aus.
Konfigurierung der erforderlichen DNS-Einträge bei der Migration zu einem neuen Horizon Edge
Sobald Sie sehen, dass die Horizon Edge Unified Access Gateway- und Horizon Edge Gateway-Instanzen betriebsbereit sind, sollten Sie Ihren DNS mit Datensätzen konfigurieren, die die FQDNs, die Sie in der Migrationsbenutzeroberfläche angegeben haben, den entsprechenden IP-Adressen zuordnen. Siehe Phase 6 – Konfigurieren von DNS-Datensätzen für die in Phase 5 der Self-Service-Migration erstellte Infrastruktur.
In der Regel werden diese Instanzen innerhalb von 48 Stunden nach dem geplanten Wartungsfenster für die Migration ausgeführt.
Vorabvalidierung des Poolverhaltens mit Hilfe der Testpools
Suchen Sie die Testpools in der Horizon Universal Console, indem Sie zu navigieren.
Jeder Testpool verfügt über eine einzelne Maschine, die Sie zur Vorabvalidierung der Next-Gen-Erfahrung für diesen Pool verwenden können.
AD-Domänen – Hilfsdomänendienst- und Domänenbeitrittskonten
Wie im vorherigen Abschnitt beschrieben, verwendet das System, wenn in der AD-Domänenkonfiguration eines First-Gen-Mandanten ein Hilfsdomänendienstkonto oder ein zusätzliches Domänenbeitrittskonto fehlt, die Informationen des primären Kontos automatisch als Begleit-Hilfskonto in der Next-Gen-AD-Domänenkonfiguration.
Als Best Practice sollten Sie Dienstkonten in Ihren AD-Domänen für die Hilfsdomänendienst- und Domänenbeitrittskonten abrufen und nach den Präbuild-Aktivitäten die AD-Domänenkonfigurationen bearbeiten, um diese Hilfskonten hinzuzufügen. In der Next-Gen-Konsole bearbeiten Sie die Domänen auf der Seite Integrationen ().
Phase 6 – Konfigurieren von DNS-Datensätzen für die in Phase 5 der Self-Service-Migration erstellte Infrastruktur
In dieser Phase aktualisieren Sie oder Ihr IT-Team Ihren DNS mit Datensätzen, die die FQDNs, die Sie auf der Benutzeroberfläche „Migration planen“ angegeben haben, den entsprechenden IP-Adressen zuordnen.
Wie bei einer Greenfield-Horizon Edge-Bereitstellung sind Sie für die Erstellung der DNS-Datensätze verantwortlich. Die Self-Service-Migration kann diese Aktualisierung nicht in Ihrem Namen durchführen.
Auch wenn die DNS-Datensätze, die die IP-Adressen ihren FQDNs zuordnen, zu einem späteren Zeitpunkt erfolgen können, empfiehlt es sich, diese Datensätze zu erstellen, sobald die IP-Adressen den -Instanzen zugewiesen sind.
Der Grund dafür, die Zuordnung eher früher als später vorzunehmen, liegt darin, dass das Fehlen der Datensätze, die die von Ihnen gewählten FQDNs den zugrunde liegenden IP-Adressen der Instanzen zuordnen, dazu führt, dass Ihre Next-Gen-Umgebung für die Validierungsschritte nach der Migration nicht voll funktionsfähig ist.
Weitere Informationen dazu, welche IP-Adressen den FQDNs zugeordnet werden müssen, finden Sie auf der Seite Konfigurieren der erforderlichen DNS-Einträge nach der Bereitstellung von Horizon Edge Gateway und Unified Access Gateway in der Next-Gen-Dokumentation.
Im Horizon Universal Console werden die FQDNs und die relevanten Lastausgleichsdienst-IPs auf der Detailseite von Horizon Edge angezeigt. Auf der Seite „Kapazität“ der Konsole können Sie einen Drilldown zu den Horizon Edge-Details durchführen ().
Nächste Schritte
Wenn die Startzeit für das geplante Wartungsfenster für die Migration erreicht ist, beginnt das System mit den restlichen Migrationsaktivitäten.
Lesen Sie in dieser Migrationsdokumentation weiter mit Phase 7 – Wartungsfenster für die Migration.
Phase 7 – Wartungsfenster für die Migration
Zum Startzeitpunkt Ihres geplanten Migrationsfensters startet das System automatisch seine letzten automatisierten Migrationsschritte. Während dieses Zeitraums wird der Zugriff von Administratoren und Endbenutzern auf die Verwaltungskonsole und die für Endbenutzer berechtigten Ressourcen im First-Gen-Mandanten verhindert.
Während der Migration wird auf der Seite „Migration“ der Konsole der Status für den migrierten Pod angezeigt.
Eingeschränkte Aktivitäten
Bei geöffnetem Wartungsfenster:
- Nehmen Sie keine Änderungen am First-Gen-Pod, seinen Ressourcen, Einstellungen usw. vor.
- Nehmen Sie keine Änderungen an der Next-Gen-Bereitstellung vor.
- Das System verhindert den Zugriff auf die First-Gen-Horizon Universal Console.
- Ihre Endbenutzer können nicht auf ihre Desktops und Anwendungen zugreifen, die vom migrierenden Pod bereitgestellt werden.
- Vermeiden Sie während des ausgewählten Zeitraums den Zugriff auf die Next-Gen-Umgebung.
Die Self-Service-Migration erfordert die oben genannten Einschränkungen, da das System während dieser Zeit aktiv Ressourcen von der First-Gen-Bereitstellung in die Next-Gen-Umgebung überträgt.
Die automatisierten Aktionen des Systems
Zu den aktiven Vorgängen, die während dieses Wartungsfensters auftreten, gehören:
- Verkleinern der flexiblen First-Gen-Desktop-Pools und -Farmen, bis sie keine Kapazität mehr benötigen.
- Dementsprechend müssen die flexiblen Desktop-Pools und -Farmen in der Next-Gen-Umgebung so erweitert werden, dass sie der Kapazität der First-Gen-Bereitstellung entsprechen.
- Koppeln der Desktop-VMs aus den dedizierten Desktop-Pools der First-Gen-Bereitstellung mit der Next-Gen-Umgebung.
Hinweis: Die Migrationsaktionen für dedizierte Desktops können die Desktop-VMs bei Bedarf automatisch einschalten, auch wenn der Zeitpunkt außerhalb des Energieverwaltungszeitplans des dedizierten Desktop-Pools liegt. Im Rahmen der Migration muss der Horizon Agent in den Desktop-VMs von der First-Gen-Bereitstellung entkoppelt und mit der Next-Gen-Umgebung gekoppelt werden, was möglicherweise das Einschalten der VMs erfordert.
Wenn das System einen Fehler feststellt, versucht es automatisch, die bis zu diesem Zeitpunkt vorgenommenen Änderungen rückgängig zu machen. Weitere Informationen zum Umkehrvorgang finden Sie auf der Seite Rollback einer Migration.
Wenn die Aktionen erfolgreich abgeschlossen wurden und das Ende des Wartungsfensters erreicht ist, wird die Statusänderung Wird migriert des Pods auf der Migrationsseite der Konsole angezeigt.
Spezielle Hinweise zu dedizierten Desktop-VMs
Am Ende des Wartungsfensters, es sei denn, die Migration wird beendet:
- Die Überwachungsdaten für dedizierte Desktop-VMs werden nicht in Workspace ONE Intelligence veröffentlicht.
- Die Next-Gen-Konsole verhindert, dass Sie Agents für dedizierte Desktop-Pools oder dedizierte Desktop-VMs aktualisieren oder neu installieren.
Der Grund für die Aussetzung von Agent-Aktualisierungen bis zum Abschluss der Migration besteht darin, dass Änderungen an den Agents auf den dedizierten Desktops im Fall eines Rollbacks Probleme verursachen können. Wenn Sie ein Rollback der Migration von der Next-Gen-Umgebung auf den First-Gen-Bereitstellungsstatus durchführen und die Agents in der Next-Gen-Umgebung geändert wurden, werden die dedizierten Desktops in der zurückgesetzten First-Gen-Bereitstellung unter Umständen nicht ordnungsgemäß ausgeführt.
Informationen zum Abschließen der Migration finden Sie unter Abschließen der Migration.
Durchführen von Aktivitäten nach der Migration zur Bestätigung des Migrationserfolgs
Wenn das System seine Aktionen im Wartungsfenster für die Migration abgeschlossen hat, befinden sich alle Ressourcen nun in der Next-Gen-Umgebung und Ihre Endbenutzer können auf ihre Desktops und Anwendungen zugreifen.
Zu diesem Zeitpunkt hebt das System die Einschränkungen auf, die es für das Wartungsfenster festgelegt hat.
- Sie und Ihre anderen Administratoren können auf die First-Gen-Horizon Universal Console zugreifen.
- Ihre Endbenutzer können auf ihre Desktops und Anwendungen zugreifen, die jetzt von der Next-Gen-Umgebung bereitgestellt werden.
Vermeiden dieser Aktivitäten bis zum Abschluss der Migration
Während bestimmte Aktivitäten vor dem Abschluss der Migration zulässig sind, kann die Durchführung dieser Aktionen zu Problemen führen.
- Benennen Sie migrierte Sites erst dann um, wenn die Migration abgeschlossen ist.
- Benennen Sie Sites vor Abschluss der Migration nicht um. Nach dem Zurücksetzen der Migration von der Next-Gen-Umgebung auf den First-Gen-Mandanten und der Umbenennung der migrierten Site in der Next-Gen-Umgebung werden in der Next-Gen-Umgebung beide Site-Namen angezeigt, wenn der zurückgesetzte Pod später migriert wird und die Migration endgültig abgeschlossen ist. Bei diesen Site-Namen handelt es sich um den ursprünglichen (jetzt leeren) Namen der First-Gen-Site aus der früheren Migration und den Namen der neuen Site nach der Umbenennung. Löschen Sie in einem solchen Szenario den leeren Namen der ursprünglichen First-Gen-Site aus der Next-Gen-Umgebung.
Empfohlene Aktivitäten und Wissenswertes
Um sicherzustellen, dass die Next-Gen-Umgebung aus der Geschäftsperspektive Ihrer Organisation funktional ist, sollten Sie und Ihre VDI-Administratoren die in den folgenden Abschnitten beschriebenen Aktivitäten durchführen.
In den folgenden Abschnitten werden auch die Merkmale der migrierten Bereitstellung beschrieben. Überprüfen Sie diese Merkmale, um die Dinge zu verstehen, die in der Next-Gen-Umgebung nach der Migration angezeigt werden.
Migrationsbericht herunterladen und prüfen
Laden Sie nach der Migration den Migrationsbericht herunter und prüfen Sie ihn.
Der Migrationsbericht ist in der Spalte Berichte auf der Seite „Migration“ der Konsole verfügbar.
Dieser Migrationsbericht enthält Einzelheiten über die migrierten Ressourcen und darüber, wo während des Migrationsvorgangs Änderungen vorgenommen wurden.
Zu den typischen Änderungen gehört die Änderung des Namens einer Ressource. Die Migration kann den Namen einer Ressource ändern, wenn die Ressource aus der First-Gen-Bereitstellung zu einer Next-Gen-Umgebung migriert wird, in der derselbe Name bereits verwendet wird. In solchen Situationen benennt die Self-Service-Migration diese First-Gen-Ressourcen automatisch um, um Namenskonflikte zu vermeiden.
Endbenutzererfahrung bestätigen
Vergewissern Sie sich, dass die Endbenutzer ihre flexiblen Desktops, dedizierten Desktops und Remoteanwendungen entsprechend ihren Berechtigungen starten können.
Die Endbenutzererfahrung beim Starten von Desktops und Anwendungen in einer Next-Gen-Bereitstellung wird auf diesen Seiten im Handbuch Verwenden von Horizon Cloud Service – next-gen beschrieben:
- Browser – Starten eines Desktops mithilfe von Horizon HTML Access Starten einer Anwendung mithilfe von Horizon HTML Access
- Nativer Horizon Client – Starten eines Desktops mit VMware Horizon Client. Starten einer Anwendung mit VMware Horizon Client.
Die Startadresse der Next-Gen-Umgebung lautet cloud.vmwarehorizon.com.
Der Authentifizierungsprozess unterscheidet sich ebenfalls, da sich die Endbenutzer in einer Next-Gen-Umgebung mit dem konfigurierten Identitätsanbieter anstatt mit dem Workflow für die Active Directory-Domänenanmeldung anmelden müssen, der in der First-Gen-Bereitstellung verwendet wird.
Anmeldeerfahrung für Administratoren bestätigen
Vergewissern Sie sich, dass Administratoren, die sich an der Next-Gen-Konsole anmelden, die Pools und anderen Ressourcen sehen können, die sie von der migrierten First-Gen-Bereitstellung erwarten.
Der Verwaltungszugriff auf die Horizon Universal Console erfolgt über den Workspace ONE Admin Hub.
- Melden Sie sich mit https://console.cloud.vmware.com/ (VMware Cloud Services) an und navigieren Sie zu Meine Dienste, um nach der Karte Workspace ONE zu suchen.
- Starten Sie diesen Dienst, um den Workspace ONE Admin Hub zu öffnen, in dem sich die Karte „Horizon Cloud Services“ befindet. Klicken Sie auf dieser Karte auf Verwalten, um die Horizon Universal Console zu starten.
Einstellung „Mindestanzahl VMs“ aus den VDI-Desktop-Zuweisungen und Farmen des Pods
Der Migrationsprozess ist so konzipiert, dass die First-Gen-VDI-Desktop-Zuweisungen und Farmen über entsprechende Energieverwaltungseinstellungen in ihren entsprechenden Entitäten in der Next-Gen-Umgebung verfügen.
Für die First-Gen-VDI-Desktop-Zuweisungen und Farmen handelt es sich bei den entsprechenden Next-Gen-Entitäten um Pools und Poolgruppen. In der Next-Gen-Umgebung werden die Energieverwaltungseinstellungen auf Poolgruppenebene vorgenommen. In den Energieverwaltungseinstellungen der Poolgruppe basiert die Einstellung Mindestanzahl VMs auf dem Prozentsatz der VMs, die im Verhältnis zu den gesamten VMs in der Poolgruppe eingeschaltet bleiben sollen. In der First-Gen-Umgebung steht die Einstellung Mindestanzahl VMs direkt für die gewünschte Mindestanzahl von VMs in der VDI-Desktop-Zuweisung oder ‑Farm.
Wenn Sie nach der Migration die Poolgruppen bearbeiten, die das System aus der Migration dieser First-Gen-Zuweisungen und ‑Farmen erstellt hat, zeigt die Konsole die Einstellung Mindestanzahl VMs dieser Poolgruppen als den Prozentsatz an, der aus dem Wert Mindestanzahl VMs der First-Gen umgewandelt wurde. Die Funktionalität hält sich weiterhin an die Min. VMs, basierend auf dem umgewandelten Prozentsatz.
AD-Domänenkonfigurationen
Die Next-Gen-Umgebung erfordert Hilfskonten sowohl für das Domänendienst- als auch für das Domänenbeitrittskonto in den Next-Gen-AD-Domänenkonfigurationen.
Wenn während der Präbuild-Aktivitäten in der AD-Domänenkonfiguration eines First-Gen-Mandanten ein zusätzliches Domänendienstkonto oder ein zusätzliches Domänenbeitrittskonto fehlt, verwendet das System automatisch die Informationen des primären Kontos als zusätzliches Konto in der Next-Gen AD-Domänenkonfiguration.
Wenn dies Ihr Szenario ist, erhalten Sie nach der Migration Dienstkonten in Ihren AD-Domänen für die zusätzlichen Domänendienst- und Domänenbeitrittskonten und bearbeiten die AD-Domänenkonfigurationen, um diese zusätzlichen Konten hinzuzufügen. Bearbeiten Sie in der Next-Gen-Konsole die Domänen, indem Sie zu navigieren.
Site-bezogene Einstellungen – Multi-Cloud-Zuweisungen
Wenn in Ihrer First-Gen-Umgebung Multi-Cloud-Zuweisungen vorhanden waren, führen Sie nach der Migration die folgenden Aktionen durch.
- Überprüfen der Zuordnungen der Start-Site
- Überprüfen Sie nach der Migration jedes Pods gegebenenfalls die Zuordnungen der Home-Sites in der Next-Gen-Umgebung und aktualisieren Sie sie entsprechend den Anforderungen Ihres Unternehmens.
- Überprüfen der sitebezogenen Einstellungen in den Poolgruppen, die durch Migration von Multi-Cloud-Zuweisungen erstellt wurden.
-
Während der Migration werden in den Poolgruppen standardmäßig bestimmte Einstellungen verwendet, die durch die Migration der First-Gen-Multi-Cloud-Zuweisungen zu Next-Gen-Poolgruppen erstellt werden. Diese Standardwerte werden gewählt, um sicherzustellen, dass die Endbenutzer nach Ablauf des Migrationsfensters ihre Desktops wieder erreichen können.
Nach der Migration sollten Sie diese Einstellungen sorgfältig überprüfen und sicherstellen, dass die Standardeinstellungen Ihren Anforderungen entsprechen, oder sie nach Bedarf an Ihre organisatorischen Anwendungsfälle anpassen. Diese Einstellungen befinden sich in den Poolgruppeneinstellungen.
- Die Einstellung Geltungsbereich ist standardmäßig auf Alle Sites festgelegt, und die Einstellung zum Anfordern der Start-Site ist deaktiviert.
- Die Außerkraftsetzungen der Start-Site aus der First-Gen-Zuweisung werden nicht zur Poolgruppe migriert.
App Volumes
Nach der Migration:
- App Volumes – Massenanwendungsberechtigungen
- In der Architektur der nächsten Generation verwaltet das System die Berechtigungen anders als in der First-Gen-Architektur. Während des Migrationsvorgangs verarbeitet das System die Auflösung aller Massenanwendungsberechtigungen, die sich in der migrierten First-Gen-Bereitstellung befanden. Diese Lösung stellt sicher, dass die Massenberechtigungen in das Format migriert werden, das für die Verwaltung der Berechtigungen in der Next-Gen-Umgebung geeignet ist. Die Endbenutzer haben weiterhin Zugriff auf denselben Satz von App Volumes-Anwendungen wie in der First-Gen-Umgebung.
- App Volumes – Pod-Migrationen
-
Bei der sukzessiven Migration von
Horizon Cloud-Pods im Laufe der Zeit kümmert sich das System um alle
App Volumes-Entitäten aus den First-Gen-Pods in die Next-Gen-Umgebung.
Beispiel: Sie nutzen Notepad++ als App Volumes-Anwendung, die sowohl in Pod-1 als auch in Pod-2 verwendet wird. Darüber hinaus gibt es mehrere Versionen der Anwendung mit npp v7.8.1 in Pod-1, npp v7.8.2 in Pod-1 und Pod-2 und npp v7.8.3 in Pod-2.
Während des Präbuilds der Migration von Pod-1 kopiert das System die App Volumes-Anwendung Notepad++ zusammen mit npp v7.8.1 und npp v7.8.2 in die Next-Gen-Umgebung, da dies die beiden in Pod-1 verwendeten Versionen sind. Der andere Pod (Pod-2) muss zu diesem Zeitpunkt noch migriert werden.
Jetzt haben Sie beide Umgebungen und möchten Änderungen an den App Volumes-Entitäten sowohl in der First-Gen-Umgebung als auch in der Next-Gen-Umgebung vornehmen. Bei diesen Entitäten löscht das System während der Migration nicht, was es bereits in die Next-Gen-Umgebung kopiert hat. Bei Konflikten zwischen den App Volumes-Entitäten der First-Gen- und der Next-Gen-Umgebung hat die Entität in der Next-Gen-Umgebung Vorrang.
Zur Veranschaulichung: In der First-Gen-Umgebung löschen Sie das Paket npp v7.8.2 in Pod-2 vor der Migration und fügen ein neues Paket npp v7.8.4 hinzu. Wenn Sie dann die Migration von Pod-2 planen, kopiert das System die derzeit von Pod-2 verwendeten Pakete (npp v7.8.3 und npp v7.8.4) in die Next-Gen-Umgebung. Das Paket npp v7.8.2 in der Next-Gen-Umgebung, das während der Migration von Pod-1 dorthin kopiert wurde, verbleibt in der Next-Gen-Umgebung, auch wenn dieses npp v7.8.2 aus der First-Gen-Umgebung gelöscht wurde.
Remoteanwendungen aus First-Gen-Anwendungsfarmen
Gemäß der Beschreibung in der First-Gen-Dokumentation werden Remoteanwendungen von Anwendungsfarmen über den First-Gen-Pod bereitgestellt. In der Next-Gen-Horizon Universal Console wird neue Terminologie eingeführt, die sich in den Bezeichnungen widerspiegelt.
Nach der Migration:
- Die 1:1-Zuordnung wird zwischen der First-Gen-Anwendungsfarm und dem resultierenden Pool in next-gen beibehalten.
- Für jede migrierte Farm wird ein Pool mit dem Namen der Farm erstellt.
- Während der Migration wird auch eine Poolgruppe für jeden Pool mit dem Namen des Pools erstellt, der bei dieser Migration dem Namen der ursprünglichen Farm entspricht.
- In jeder Poolgruppe werden Informationen zu den Benutzerberechtigungen angezeigt, die aus den First-Gen-Anwendungszuweisungen migriert wurden und den Anwendungen entsprechen, die mit dem Pool dieser Poolgruppe verknüpft sind.
- Der Name der First-Gen-Anwendungszuweisung wird in der Next-Gen-Konsole nicht angezeigt. Wenn eine First-Gen-Anwendungszuweisung Remoteanwendungen aus mehreren Farmen enthält, können Sie zum Anzeigen der Remoteanwendungen und Endbenutzerberechtigungen in der Next-Gen-Konsole alle mit den Farmnamen erstellten Poolgruppen anzeigen oder die Optionen der Konsole verwenden.
Hinweis: Wenn Sie die manuellen Apps direkt auf den First-Gen-Farm-VMs installiert haben, werden diese Apps nicht standardmäßig auf den Pool-VMs der Next-Gen-Umgebung installiert, auch wenn ihre Metadaten als Teil des Migrationsvorgangs migriert werden. Solche Apps müssen auf den Pool-VMs in genau den spezifischen Pfaden neu installiert werden, in denen sie auf den First-Gen-Farm-VMs installiert waren.
Beachten Sie Folgendes:
- Die First-Gen-Anwendungszuweisung Assign-1 verfügt über die Apps app1 und app2 aus Farm Farm-1, und Benutzer User-1 verfügt über Berechtigungen für app1 und app2.
- Die First-Gen-Anwendungszuweisung Assign-2 verfügt über die Apps app1 aus Farm-1 und app3 aus Farm Farm-2, und Benutzer User-2 verfügt über Berechtigungen für app1 und app3.
- Dies bedeutet, dass app1 sowohl über Berechtigungen für User-1 als auch über Berechtigungen für User-2 verfügt, während app2 lediglich über Berechtigungen für User-1 und app3 lediglich über Berechtigungen für User-2 verfügt.
Nach der Migration zu next-gen:
- Es werden ein Pool mit der Bezeichnung Farm-1 und eine für diesen Pool erstellte Poolgruppe mit der Bezeichnung Farm-1 angezeigt. In dieser Poolgruppe werden die Anwendungen app1 und app2 angezeigt (hierbei handelte es sich um die Anwendungen aus dieser First-Gen-Farm).
- Es werden auch ein Pool mit der Bezeichnung Farm-2 und eine für diesen Pool erstellte Poolgruppe mit der Bezeichnung Farm-2 angezeigt. In dieser Poolgruppe befindet sich die Anwendung app3.
- Zu den migrierten Berechtigungen gehören:
- app1 aus Poolgruppe Farm-1 mit Berechtigungen für User-1 und User-2
- app2 aus Poolgruppe Farm-1 mit Berechtigungen für User-1
- app3 aus Poolgruppe Farm-2 mit Berechtigungen für User-2
Aktivitäten nach der Migration – Abschließen
Wenn Sie sich vergewissert haben, dass die Next-Gen-Umgebung zufriedenstellend funktioniert, besteht die letzte Aktion der Pod-Migration darin, die Migration abzuschließen.
Während des Abschlusses werden die Azure-Ressourcen, die der First-Gen-Pod noch von Ihrem Azure-Abonnement verbraucht, gelöscht.
Nach der Migration eines Pods werden Sie bei jeder Anmeldung bei der Horizon Universal Console von der Benutzeroberfläche aufgefordert, die Migration dieses Pods abzuschließen.
Abschließen der Migration
Das Abschließen der Migration ist der letzte Schritt bei der Migration eines First-Gen-Horizon Cloud on Microsoft Azure-Pods.
Vorteile des Abschlusses
Durch das Abschließen der Migration erreichen Sie Folgendes:
- Sie vermeiden zusätzliche Microsoft Azure-Kosten, da durch den Abschluss die verbleibenden, vom First-Gen-Pod verbrauchten Ressourcen in Azure gelöscht werden.
- Das System hebt die Einschränkungen auf, die es zu Beginn des Wartungsfensters für dedizierte Desktops festgelegt hat:
- Die Überwachungsdaten für dedizierte Desktop-VMs werden in Workspace ONE Intelligence veröffentlicht.
- Sie können die Aktualisierungs- und Neuinstallationsvorgänge für den Agent auf dedizierten Pools und VMs ausführen.
- Sie können Aktualisierungen an den migrierten Images und Pools vornehmen, ohne sich über die Auswirkungen auf das Rollback Gedanken machen zu müssen.
Nach dem Abschluss kann für die Migration kein Rollback von der Next-Gen-Umgebung auf den First-Gen-Bereitstellungsstatus durchgeführt werden.
Vor dem Abschluss – Empfohlene Aktivitäten nach der Migration durchführen
Vor dem Abschluss der Migration sollten Sie sicherstellen, dass die empfohlenen Aktivitäten nach der Migration durchgeführt werden. Diese Aktivitäten werden auf der Seite Durchführen von Aktivitäten nach der Migration zur Bestätigung des Migrationserfolgs beschrieben.
Best Practice – Abschluss innerhalb weniger Tage nach der Migration
Aus folgenden Gründen empfiehlt es sich, die Migration jedes Pods innerhalb weniger Tage nach Abschluss des Migrationsvorgangs abzuschließen:
- Bis der First-Gen-Pod durch Abschluss der Migration gelöscht wird, entstehen Ihnen Microsoft Azure-Abonnementkosten für den Betrieb der First-Gen-Ressourcen, einschließlich Pod-Manager- und Unified Access Gateway-Instanzen.
- Bis zum Abschluss der Migration werden Sie von der Next-Gen-Horizon Universal Console daran gehindert, die Agent-Aktualisierung auf dedizierten Poolgruppen und die Agent-Neuinstallation auf dedizierten VMs ( oder ) zu verwenden.
Achtung: Wenn Ihre Next-Gen-Umgebung eine nicht abgeschlossene Migration aufweist, verhindert die Konsole die Ausführung der Agent-Aktualisierung und -Neuinstallation für alle dedizierten Poolgruppen und dedizierten VMs. Dabei spielt es keine Rolle, ob diese aus First-Gen migriert oder in der Next-Gen-Umgebung neu erstellt wurden. In diesem Szenario wird in der Konsole eine Meldung mit dem Hinweis angezeigt, dass die Migration abgeschlossen werden muss.
Der Grund für die Aussetzung von Agent-Aktualisierungen bis zum Abschluss der Migration besteht darin, dass Änderungen an den Agents auf den Desktops im Fall eines Rollbacks Probleme verursachen können. Wenn Sie ein Rollback der Migration von der Next-Gen-Umgebung auf den First-Gen-Bereitstellungsstatus durchführen und die Agents in der Next-Gen-Umgebung geändert wurden, werden die Desktops in der zurückgesetzten First-Gen-Bereitstellung unter Umständen nicht ordnungsgemäß ausgeführt.
- Je mehr Zeit verstreicht, während Sie und Ihre VDI-Administratoren Änderungen in der Next-Gen-Umgebung vornehmen, desto weniger ist es möglich, die migrierte Umgebung auf einen Zustand der First-Gen-Bereitstellung zurückzusetzen, der Ihre Endbenutzer zufrieden stellt. Wenn Sie beispielsweise dedizierte Desktop-Pools in der Next-Gen-Umgebung erweitern und Endbenutzer neuen Desktops zuweisen und dann versuchen, ein Rollback auf den First-Gen-Pod durchzuführen, können Probleme bei diesen neuen Desktops auf der First-Gen-Seite auftreten.
Abschließende Schritte
Sie schließen die Migration mithilfe der Aktion Abschließen auf der Migrationsseite der Next-Gen-Konsole ab.
Nachdem Sie auf Abschließen geklickt haben, zeigt die Konsole ein Genehmigungsfenster an, in dem Sie das Löschen des quellseitigen First-Gen-Pods genehmigen können.
Um den Migrationsvorgang abzuschließen und dem System zu bestätigen, dass der First-Gen-Pod jetzt gelöscht werden kann, klicken Sie auf Genehmigen.
Nach dem Abschluss – Status des privaten Endpoints für das App Volumes-Anwendungsspeicherkonto überprüfen und bei Bedarf konfigurieren
Nach dem Abschluss der Migration wird dringend empfohlen, den privaten Microsoft Azure-Endpoint für das App Volumes-Anwendungsspeicherkonto zu konfigurieren, sofern dieser nicht bereits für Horizon Edge konfiguriert ist.
Obwohl die migrierte Umgebung ohne diese Konfiguration des privaten Endpoints funktioniert, wird durch die Konfiguration des privaten Endpoints die Sicherheit für dieses Speicherkonto weiter erhöht. Wenn der Migrationsvorgang einen neuen Horizon Edge bereitstellt, ist in der Standardkonfiguration dieses Speicherkontos der öffentliche Netzwerkzugriff über alle Netzwerke aktiviert. (Diese Voreinstellung unterscheidet sich von den Einstellungen des First-Gen-Pods).
Um den Status in der Next-Gen-Horizon Universal Console zu überprüfen, navigieren Sie zu den Horizon Edge-Details und suchen Sie nach dem Abschnitt „App Volumes-Anwendungsspeicher“.
Wenn Nicht konfiguriert angezeigt wird, folgen Sie den Anweisungen, die an diesen Stellen im Next-Gen-Handbuch Verwenden beschrieben sind.
- Seite Private Azure-Endpoints für App Volumes-Anwendungsspeicherkonten
- Die Schritte im Abschnitt Konfigurieren des privaten Endpoints für ein App Volumes-Anwendungsspeicherkonto auf der Seite Anzeigen bereitgestellter Horizon Edges.
Zur Veranschaulichung zeigt der folgende Screenshot die Benutzeroberfläche eines einzelnen Speicherkontos, auf der Sie sehen können, ob der private Endpoint konfiguriert ist. In diesem Fall ist der private Endpoint noch nicht für dieses Speicherkonto konfiguriert.
Der folgende Screenshot zeigt die Position des Menüs zum Konfigurieren des privaten Endpoints. Klicken Sie auf die Option „Konfigurieren“ und folgen Sie den Anweisungen auf dem Bildschirm. Die Schritte werden im Abschnitt Konfigurieren des privaten Endpoints für ein App Volumes-Anwendungsspeicherkonto erläutert.
Der folgende Screenshot zeigt, wann der private Endpoint konfiguriert wurde.
Abschluss der Pod-Migration
Eine abgeschlossene Migration ist eine erfolgreiche Migration. Herzlichen Glückwunsch!
Weitere Informationen zu Tag-2-Vorgängen finden Sie im Handbuch Verwenden von VMware Horizon Cloud Service – next-gen.
