Self-Service-Migration von Horizon Cloud on Microsoft Azure-Bereitstellungen der ersten Generation zu Horizon Cloud

Sobald Ihre Horizon Cloud-Umgebung für Sie aktiviert ist, können Sie die Self-Service-Migration einer Horizon Cloud on Microsoft Azure-Bereitstellung, die sich in der Horizon Cloud Control Plane der ersten Generation befindet, zu Horizon Cloud initiieren.

Hinweis: Zum Zeitpunkt der Erstellung dieses Dokuments sind Umgebungen der ersten Generation, in denen die Pod-Flotte ausschließlich aus Horizon 8-Pods (Pods vom Typ „Verbindungsserver“) besteht, nicht in diesem Self-Service-Migrationsprozess oder in diesem begleitenden Migrationshandbuch enthalten. Der Migrationsprozess für diese Umgebungen unterscheidet sich von dem für Horizon Cloud on Microsoft Azure Pods. Informationen zur Migration von Horizon 8 Pods erhalten Sie von Ihrem Horizon 8-Vertreter.

So fangen Sie an

Wählen Sie je nachdem, wie weit Sie den Migrationsprozess bereits selbst oder mit dem Horizon-Migrationsteam durchgeführt haben, einen der folgenden Links aus.

Achtung: Die Self-Service-Migration für Horizon Cloud auf Microsoft Azure-Pods ist ein schrittweiser Rollout, der vom Horizon-Migrationsteam schrittweise durchgeführt wird. Wenn Sie dazu berechtigt sind, erhalten Sie eine direkte Mitteilung von Horizon Migration Communications.

• Was ist, wenn ich keine E-Mail vom Horizon-Migrationsteam erhalten habe?

  Überprüfen Sie die aktuellen Berechtigungskriterien 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.

Kontrollkästchen	Wenn...	Nächste Schritte
☐	Sie haben eine E-Mail vom Horizon-Migrationsteam über die Migration zu Horizon Cloud erhalten, aber... Sie haben noch keine Einführung in den Prozess erhalten. Sie haben das erste Onboarding für Horizon Cloud noch nicht durchgeführt.	Vorgehensweise: Erfüllen Sie die in diesem Leitfaden beschriebenen Voraussetzungen Vorgehensweise: Bestätigen Sie mit dem Migrationsteam, dass Ihre Horizon Cloud-Umgebung für das erste Onboarding bereit ist und führen Sie die ersten Onboarding-Schritte durch
☐	Sie haben das erste Onboarding für Horizon Cloud durchgeführt und sehen die Migrations-Benutzeroberfläche, aber... Sie haben den Identitätsanbieter für Horizon Cloud nicht konfiguriert. Sie haben Ihren Mandanten der ersten Generation noch nicht mit Horizon Cloud gekoppelt.	Vorgehensweise: Konfigurieren Sie den Identitätsanbieter. Vorgehensweise: Koppeln Sie Mandanten.
☐	Nachdem Sie den Identitätsanbieter und die Kopplung konfiguriert haben, aber... das Wartungsfenster für einen Pod noch nicht geplant haben.	Vorgehensweise: Planen Sie das Wartungsfenster.
☐	Nachdem das Wartungsfenster geplant wurde, aber bevor das Datum erreicht ist.	Überprüfen: Lesen Sie die Informationen zum Ablauf der Präbuild-Phase. Vorgehensweise: Konfigurieren Sie DNS-Datensätze, wenn Sie sehen, dass die neuen Unified Access Gateway-Instanzen auf der Horizon Cloud-Benutzeroberfläche aufgelistet werden. Vorgehensweise: Verwenden Sie die vorgefertigten Testpools, um das Verhalten vorab zu validieren. Für jeden flexiblen Desktop-Pool der ersten Generation erstellt das System einen Testpool mit einem Desktop in Horizon Edge, der die Einstellungen des Pools seines Gegenstücks der ersten Generation widerspiegelt. Sie können diese Testpools verwenden, um vorab zu überprüfen, ob sich die einzelnen schwebenden Desktop-Pools Ihren Erwartungen entsprechend verhalten.
☐	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.	Vorgehensweise: Schließen Sie die Migration ab. Vorgehensweise: Überprüfen Sie die Konfiguration des privaten Endpoints für das App Volumes-Anwendungsspeicherkonto und konfigurieren Sie sie bei Bedarf. Wenn Sie über zusätzliche Pods verfügen, planen Sie die Migration des nächsten Pods ein.

Hinweis: Die Begriffe „Horizon Cloud on Microsoft Azure-Bereitstellungen“ und „Horizon Cloud“ beziehen sich auf die erste Generation von Horizon Cloud und die Cloud-Steuerungsebene dieser Generation. Andere Begriffe, wie z. B. v1 und erste Generation, beziehen sich auf die erste Generation von Horizon Cloud. Die nächste Generation der Dienst- und Steuerungsebene wird offizielle als Horizon Cloud bezeichnet.

Browsererfahrung

Die Horizon Cloud 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 Horizon Cloud Horizon Universal Console durchgeführt werden, werden mit diesen Browserversionen unterstützt.

Verwenden Sie für Migrationsaktivitäten, die in der Horizon Universal Console der ersten Generation durchgeführt werden, wie z. B. das Abrufen des Kopplungsschlüssels, Browser-Versionen, die mit der Horizon Universal Console der ersten Generation kompatibel sind, wie im Bereitstellungshandbuch für die erste Generation beschrieben.

Phase 1 – Anfängliches Onboarding in der Horizon Cloud-Umgebung

In dieser Phase führen Sie die ersten Onboarding-Schritte in der Horizon Cloud-Umgebung durch. Diese Schritte sind fast die gleichen wie die Schritte bei einer brandneuen Greenfield-Bereitstellung in der Horizon Cloud-Umgebung.

Hinweis: Wenn Sie zuvor ein Onboarding in Ihrer Horizon Cloud-Umgebung durchgeführt haben, können Sie diese Phase überspringen. Wenn das erstmalige Onboarding abgeschlossen ist, Sie sich bei der Horizon Cloud Console anmelden und die Seite Migration nicht sofort angezeigt wird, können Sie in der linken Navigation auf den Eintrag Migration klicken, um die Seite anzuzeigen.

Führen Sie die Onboarding-Schritte aus, die auf der Seite Onboarding für Horizon Cloud 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.

Wichtig: Nachdem Sie in diesem Schritt eine Region ausgewählt und gespeichert haben, kann diese nicht mehr geändert werden.

Wenn Sie sicherstellen möchten, dass die Metadaten Ihrer Steuerungsebene in derselben geografischen Region verbleiben, die für Ihren Mandanten der ersten Generation verwendet wurde, wählen Sie dieselbe geografische Region aus, die der Region Ihres Mandanten der ersten Generation entspricht.

Der folgende Screenshot veranschaulicht den Schritt zur Regionsauswahl mit der Auswahl USA.

Sie können Ihre Auswahl der Horizon Cloud-Region an die Region anpassen, die Sie für Ihren Mandanten der ersten Generation verwendet haben. Auf diese Weise können Sie feststellen, welche Region der Steuerungsebene der ersten Generation Sie verwenden.

Um die Auswahl der Horizon Cloud-Region mit der Region abzugleichen, die Sie für Ihren Mandanten der ersten Generation verwendet haben, melden Sie sich bei der Horizon Universal Console der ersten Generation 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.

Hinweis: In dieser Tabelle sind die unterstützten Regionen der ersten Generation und die entsprechenden Horizon Cloud-Regionen aufgeführt. Im Laufe der Zeit werden möglicherweise weitere Regionen von Horizon Cloud unterstützt. Diese Regionen werden nicht in diese Tabelle aufgenommen, da sie keine Entsprechung in der ersten Generation haben.

Name der Region der ersten Generation beginnt mit	Entsprechende Horizon Cloud-Regionsauswahl
cloud.horizon. oder cloud-us-2.horizon.	USA
cloud-eu-central-1.horizon. oder cloud-eu-2.horizon.	Irland
cloud-ap-southeast-2.horizon. oder cloud-ap-2.horizon.	Australien
cloud-jp.horizon.	Japan
cloud-uk.horizon.	Großbritannien

Nach der Auswahl der Region

Nach dem Speichervorgang im vorhergehenden Schritt zeigt die Konsole normalerweise den Bildschirm Migration an.

Hinweis: Wenn der Bildschirm „Migration“ nicht angezeigt wird, können Sie über Migration im linken Navigationsbereich dorthin navigieren.

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 – Umgebungen koppeln, um die Migration zwischen Ihren Horizon Cloud- und Umgebungen der ersten Generation zu ermöglichen

Um die Migration einer Horizon Cloud on Microsoft Azure-Bereitstellung in Ihre Horizon Cloud-Umgebung zu ermöglichen, müssen Sie Ihre Umgebung der ersten Generation mit Ihrer Horizon Cloud-Umgebung koppeln.

Hinweis: Um die Schritte in der Horizon Universal Console auszuführen, müssen Sie über die Administrator-Rolle in der Horizon Cloud-Umgebung verfügen. Weitere Informationen finden Sie auf der Seite Zuweisen von Administratorrollen im Horizon Cloud-Handbuch.

Beachten Sie: Derzeit werden das Migrationsbanner, der Assistent für die Horizon Cloud-Migration, das Menü Migration und die Seite „Migration“ in der Konsole nur angezeigt, wenn Ihre Bereitstellungen der ersten Generation vom Horizon-Migrationsteam für die Migration freigegeben wurden.

Informationen zu diesem Kopplungscode

Ein Kopplungscode ist die Methode des Systems, um Ihre Horizon Cloud-Umgebung mit Ihrer Umgebung der ersten Generation zu verknüpfen, damit Ihre Bereitstellungen der ersten Generation migriert werden können.

Sie erhalten einen Kopplungscode aus Ihrer Umgebung der ersten Generation, kopieren diesen Kopplungscode und fügen ihn in das Migrationsfenster in Ihrer Horizon Cloud-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.

1. 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 Assistenten Horizon Cloud-Migration zu starten, und im Schritt Erste Schritte die Option Ja auswählen, um den Kopplungscode anzuzeigen, wie im folgenden Screenshot dargestellt.

     Hinweis: Die Konsole der ersten Generation zeigt diesen Banner und diesen Assistenten nur an, wenn das Horizon-Migrationsteam sie in Ihrer Umgebung der ersten Generation aktiviert hat.

     

   • Klicken Sie auf den in der Konsole angezeigten Kontonamen und wählen Sie Kopplungscode aus.

     

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

3. Wechseln Sie zur Seite Migration in Ihrer Horizon Cloud-Umgebung.

   • Im Assistenten Migration – Erste Schritte können Sie auf Starten klicken, um die Horizon Cloud Console zu starten, auf der die Seite Migration angezeigt wird.

   • Alternativ können Sie ein Browserfenster öffnen, sich bei Cloud Services anmelden, zur Kachel Workspace ONE Cloud navigieren, die Karte in Ihren festgelegten Diensten suchen und dann auf die Aktion klicken, um die Horizon Cloud Console 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.

   

4. Klicken Sie auf den Link Mandanten koppeln.

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

   

6. Klicken Sie auf Koppeln.

   Wenn das System die Mandanten erfolgreich gekoppelt hat, zeigt die Horizon Cloud-Benutzeroberfläche an, dass die Kopplung erfolgreich war.

   

Nächste Schritte

Nachdem Ihr Mandant der ersten Generation und Ihr Horizon Cloud-Mandant gekoppelt sind, befolgen Sie die Anweisungen auf dem Bildschirm und stellen Sie eine Verbindung zu einem Identitätsanbieter her.

Phase 3 – Konfigurieren der erforderlichen Identitätsanbietereinstellungen in Ihrer Horizon Cloud-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 Horizon Cloud-Umgebung.

Kurze Einführung

Die Horizon Cloud-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 Horizon Cloud-Architektur ermöglicht die Integration mit Produkten und Lösungen von Drittanbietern, um Multifaktor-Authentifizierung und SSO-Funktionen bereitzustellen.

Achtung:

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 Horizon Cloud-Umgebung angeben werden.

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-Handbuch beschrieben.

Die Benutzeroberfläche der Horizon Cloud-Mandantenkonsole erfordert die Eingabe eines zusätzlichen Domänenbeitrittskontos. Dies ist ein Unterschied zur Mandantenkonsole der ersten Generation, in 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 Horizon Cloud-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 Horizon Cloud-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-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 Horizon Cloud Console 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 Mandanten der ersten Generation zugreifen, und Ihre Endbenutzer können nicht auf ihre Desktops und Anwendungen zugreifen, die vom migrierenden Pod bereitgestellt werden.

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: Voraussetzungen für den Typ „Einzel-VM“ Voraussetzungen für den Typ „AKS“
☐	Sie haben die Schritte in Phase 3 – Konfigurieren der erforderlichen Identitätsanbietereinstellungen in Ihrer Horizon Cloud-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 Benachrichtigungen in der Horizon Cloud Horizon Universal Console angezeigt.
☐	Vergewissern Sie sich, wie auf der Seite mit den Voraussetzungen beschrieben, dass sich alle Images der Pods der ersten Generation im Status „Veröffentlicht“ befinden und ihre VMs und Snapshots in Microsoft Azure intakt sind.

Wichtig: Wenn eine Voraussetzung fehlt, schlagen die Vorabvalidierungsprüfungen des Systems fehl und das System kann nicht in die Präbuild-Phase eintreten, wodurch der Migrationsprozess blockiert wird.

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: FQDN, den Sie in die Benutzeroberfläche des Assistenten eingeben SSL-Zertifikat für die Unified Access Gateway-Konfiguration (PEM- oder PFX-Format), das dem FQDN entspricht 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. Wenn der Pod der ersten Generation sowohl über eine externe Unified Access Gateway-Konfiguration als auch über eine interne Unified Access Gateway-Konfiguration verfügt, werden für den Unified Access Gateway des Edge nach der Migration standardmäßig sowohl der externe FQDN als auch der interne FQDN auf denselben FQDN festgelegt (den FQDN, den Sie hier im Assistenten eingeben). Wenn Sie möchten, dass der interne FQDN vom externen FQDN eindeutig ist, bearbeiten Sie nach der Migration die Details des Unified Access Gateway des Edge, um den internen FQDN in den separaten FQDN zu ändern, und geben Sie Netzwerkbereiche an, um interne Benutzer zu identifizieren. Hinweis: Wenn Sie den internen FQDN so festlegen möchten, dass er sich vom externen FQDN unterscheidet, stellen Sie sicher, dass das SSL-Zertifikat, das Sie in diesem Planungsassistenten angeben, den geplanten internen FQDN in den Zertifikatsdaten widerspiegelt. Andernfalls wird ein Zertifikat benötigt, das beide FQDNs widerspiegelt, wenn Sie die Edge-Details bearbeiten, um einen eindeutigen internen FQDN anzugeben. Derzeit akzeptiert die Benutzeroberfläche ein einzelnes Zertifikat.
☐ Bei Verwendung des AKS-Bereitstellungstyps	Für den AKS-Typ fragt Sie der Assistent nach: NAT-Gateway oder Routentabelle, die mit dem Management-Subnetz verbunden ist und für die ausgehenden Verbindungen des AKS-Clusters von Horizon Edge verwendet wird Dem Benutzer zugewiesene verwaltete Identität Die für den AKS-Cluster des Horizon Edge zu verwendenden CIDRs (Dienst-CIDR, Pod-CIDR) 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“ enthält der Assistent keine spezifischen Eingaben, die für den Bereitstellungstyp „Einzel-VM“ erforderlich sind. In dem seltenen Fall, dass Ihr Netzwerk bereits über einen Active Directory-Server verfügt, der auf einem Netzwerksegment bereitgestellt ist, das sich mit einigen Systemstandards überschneidet, sollten Sie benutzerdefinierte Werte angeben, um die vom System festgelegten Standardwerte zu ersetzen. Weitere Informationen finden Sie im Abschnitt Einzel-VM-Bereitstellungstyp.
☐ Wenn das externe Gateway des Pods eine private IP-Adresse verwendet	Wenn die externe Gateway-Bereitstellung des Pods der ersten Generation für die Verwendung einer privaten IP-Adresse konfiguriert ist, stellen Sie die neue öffentliche IP-Adresse bereit, die für die Horizon Cloud Unified Access Gateway-Bereitstellung verwendet werden soll, wie unter Voraussetzungen für die Migration eines Horizon Cloud-Pods der ersten Generation beschrieben. Im Assistenten werden Sie nach diesen Informationen gefragt.

Einige Site-bezogene Punkte – Universal Broker-Umgebungen

Beachten Sie diese Punkte, wenn Sie über eine Universal Broker-Umgebung der ersten Generation mit mehreren Horizon Cloud-Pods verfügen.

Wie auf der Seite Arbeiten mit Sites in einer Universal Broker-Umgebung des Administrationshandbuchs der ersten Generation beschrieben, können Sie Sites und Start-Sites konfigurieren, wenn Ihr Mandant der ersten Generation Universal Broker verwendet.

• Das System migriert die Site-Konfigurationen, die im Mandanten der ersten Generation vorhanden sind, während der ersten Pod-Migration. Ein Beispiel für Site-bezogene Informationen ist die Zuordnung eines Benutzers zu einer Start-Site.
• Wenn Sie die Migration dieses ersten Pods abschließen und anschließend Änderungen an den Site-bezogenen Informationen in der Umgebung der ersten Generation vornehmen, werden diese Änderungen in der Horizon Cloud-Umgebung erst bei der nächsten Pod-Migration angezeigt.
• Alle vorhandenen Site-zu-Benutzer- und Site-zu-Gruppen-Zuordnungen in der Horizon Cloud-Umgebung der ersten Generation fungieren als Source of Truth, wenn ein Pod migriert wird. Wenn für einen Benutzer oder eine Gruppe sowohl in der Horizon Cloud-Umgebung als auch in der Umgebung der ersten Generation eine Zuordnung zu einer Start-Site vorhanden ist, wird die Zuordnung zur Site der ersten Generation während der Migration ignoriert. Diese Informationen sind im Migrationsbericht enthalten.
• Wenn Sie nach der Migration eines jeden Pods Zuordnungen von Start-Sites hatten, überprüfen Sie nach der Migration jedes Pods die Zuordnungen der Start-Site in der Horizon Cloud-Umgebung und aktualisieren Sie sie entsprechend den Anforderungen Ihres Unternehmens.

Wenn Sie über Zuweisungen mit mehreren Pods verfügen

Möglicherweise haben Sie Zuweisungen der ersten Generation, die mehrere Pods umfassen (in der Dokumentation der ersten Generation wird der Begriff Multi-Cloud-Zuweisungen für solche Zuweisungen verwendet). Es gibt wichtige Dinge, die Sie bei der Migration von Pods beachten müssen, die an Multi-Cloud-Zuweisungen beteiligt sind. Weitere Informationen finden Sie unter Wenn Sie über mehrere Pods in Zuweisungen der ersten Generation verfügen – Wichtige Punkte zur Migration, die Sie beachten sollten

Workflow-Benutzeroberfläche zur Planung der Migration

Klicken Sie auf Start auf der Seite „Migration“, um den Workflow Migration planen anzuzeigen.

Die Konsole zeigt die Gruppe von Horizon Cloud on Microsoft Azure-Bereitstellungen der ersten Generation auf Microsoft Azure an, die sich in der Pod-Flotte des Mandanten der ersten Generation befinden, der mit diesem Horizon Cloud-Mandanten gekoppelt ist.

Das System überprüft automatisch, ob eine Bereitstellung der ersten Generation mit der Self-Service-Migration kompatibel ist. Zu diesen Kriterien gehört die Überprüfung, ob die Pod-Manager-Instanzen eine geeignete Manifestversion ausführen, die Images, VDI-Desktop- und Farm-VMs über die geeigneten Horizon Agent-Versionen verfügen und die in der Bereitstellung der ersten Generation verwendeten Funktionen auch mit den aktuellen Funktionen 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 Bereitstellung der ersten Generation erneut auszuführen. Beispiele für die Kriterien, die die Bereitstellungen erfüllen müssen, finden Sie unter Ausschlüsse und Sonderfallszenarien für die Migration.

Hinweis: Wenn Sie die Aktion Erneut prüfen verwenden, wird die Seite nicht automatisch aktualisiert. Sie müssen auf Aktualisieren klicken, um den aktuellen Status anzuzeigen.

Pod der ersten Generation 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 Umgebung der ersten Generation ü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 Horizon Cloud-Umgebung der ersten Generation 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.

Bei Verwendung eines vorhandenen Horizon Edge skaliert das System die vorhandene Unified Access Gateway-Bereitstellung mit derselben Anzahl von Unified Access Gateway-Instanzen, die dem Pod der ersten Generation zugeordnet 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 Pod der ersten Generation 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 es die App-ID des Pods der ersten Generation zu diesem Anbieter hinzufügt.
• Pod der ersten Generation verfügt über ein anderes Abonnement, dieselbe Microsoft Azure-Region und eine andere app ID (Dienstprinzipal) als der ausgewählte Horizon Edge: Das System fügt dem ausgewählten Horizon Edge einen sekundären Anbieter 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 Pods der ersten Generation.

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 Horizon Cloud-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. Einzelne virtuelle Maschine – Stellt den Typ „Einzel-VM“ bereit. Azure Kubernetes Service – Stellt den Typ „AKS“ bereit.

Siehe den Abschnitt unten, der dem von Ihnen gewählten Bereitstellungstyp entspricht.

Bereitstellungstyp „Einzelne virtuelle Maschine“

Für den Bereitstellungstyp Einzelne virtuelle Maschine sind keine erforderlichen Felder vorhanden, außer in dem seltenen Fall, der im folgenden Hinweis beschrieben wird. Dieser Bereitstellungstyp verwendet das Management-Subnetz des Pods für das Horizon Edge Gateway.

Hinweis: Ein seltener Fall tritt ein, wenn Sie beispielsweise einen Active Directory-Server bereits in einem Netzwerksegment bereitgestellt haben, dessen IP-Adressbereich sich mit den Systemstandardwerten überschneidet. In diesem seltenen Fall können Netzwerkprobleme auftreten, wenn die Edge-Gateway-Module versuchen, Active Directory zu erreichen. Um solche Konflikte zu vermeiden, enthält der Abschnitt Erweitert des Assistenten Felder, in denen Sie benutzerdefinierte Werte angeben können, um Konflikte mit den systemseitigen internen Netzwerkbereichen zu vermeiden. Weitere Informationen finden Sie unter Optionale erweiterte Einstellungen.

Als Nächstes folgen die Informationen zum Unified Access Gateway.

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. Wenn der Pod der ersten Generation sowohl über eine externe Unified Access Gateway-Konfiguration als auch über eine interne Unified Access Gateway-Konfiguration mit unterschiedlichen FQDNs und Zertifikaten verfügt, die auf diesen Gateway-Konfigurationen konfiguriert sind, sind für die Unified Access Gateway des Edge nach der Migration sowohl der externe FQDN als auch der interne FQDN standardmäßig auf denselben FQDN festgelegt (der FQDN, den Sie hier im Assistenten eingeben). Nach der Migration können Sie die Unified Access Gateway-Details des Edge bearbeiten, um den internen FQDN in einen FQDN zu ändern, den Sie für interne Benutzer verwenden möchten, und Netzwerkbereiche konfigurieren, um interne Benutzer zu identifizieren. Hinweis: Wenn Sie den internen FQDN so aktualisieren möchten, dass er vom externen FQDN nach der Migration eindeutig ist, stellen Sie sicher, dass das hochgeladene Zertifikat sowohl den FQDN widerspiegelt, den Sie in den Assistenten eingeben, als auch Ihren geplanten internen FQDN in den Daten des Zertifikats. Andernfalls müssen Sie nach der Migration ein Zertifikat hochladen, das sowohl den externen FQDN als auch den internen FQDN widerspiegelt.
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 Pods der ersten Generation für die Verwendung einer privaten IP-Adresse konfiguriert ist. Geben Sie die öffentliche IP-Adresse ein, die Sie für die Horizon Cloud-Bereitstellung verwenden möchten, wie unter „Voraussetzungen für die Migration eines Horizon Cloud Pod der ersten Generation“ beschrieben. Hinweis: Diese öffentliche IP muss sich von der öffentlichen IP unterscheiden, die bereits für die zu migrierende Bereitstellung der ersten Generation verwendet wird, um ein Rollback auf den Bereitstellungsstatus der ersten Generation zu unterstützen, wenn ein Rollback erforderlich ist. Im Rahmen der Präbuild-Aktivitäten stellt das System den Lastausgleichsdienst der Horizon Cloud Unified Access Gateway-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.

Optionale erweiterte Einstellungen – Interne Netzwerkbereiche für die Einzel-VM

Innerhalb der Einzel-VM werden systemseitig festgelegte Standardwerte für interne Netzwerkbereiche verwendet. Diese interne Netzwerke werden von Kubernetes innerhalb der VM verwendet und sind außerhalb der VM nicht zugänglich. Diese sollten auf den systemseitig festgelegten Standardwerten belassen werden, sofern sie sich nicht mit Ihren internen Netzwerken überschneiden. In seltenen Fällen, in denen sich vorhandene Netzwerksegmente mit den internen Bereichen der VM überschneiden, geben Sie im Abschnitt Erweitert des Assistenten benutzerdefinierte Werte an.

Geben Sie die CIDRs ein, die Sie oder Ihr IT-Team festgelegt haben, um die Anforderungen in diesem speziellen Fall zu erfüllen, wie unter Anforderungen für die Bereitstellung einer einzelnen VM beschrieben.

• Dienst-CIDR – Mindestens /27 ist erforderlich.
• Dienst-CIDR – Mindestens /21 ist erforderlich.

Wenn alle erforderlichen Felder des Assistenten Einträge enthalten

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 an der Pod der ersten Generation, ihren Ressourcen, Einstellungen usw. vor.
• Nehmen Sie keine Änderungen an der Bereitstellung der Horizon Cloud-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 Horizon Cloud-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 Pods der ersten Generation 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:

1. 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)

Bei Verwendung eines vorhandenen Horizon Edge skaliert das System die vorhandene Unified Access Gateway-Bereitstellung mit derselben Anzahl von Unified Access Gateway-Instanzen, die dem Pod der ersten Generation zugeordnet 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 Pod der ersten Generation hat dasselbe Abonnement, dieselbe Microsoft Azure-Region, eine andere Dienstprinzipal-app ID: Das System skaliert den Anbieter des ausgewählten Horizon Edge, indem es die App-ID des Pods der ersten Generation zu diesem Anbieter hinzufügt.
• Pod der ersten Generation hat ein anderes Abonnement, dieselbe Microsoft Azure-Region und eine andere Dienstprinzipal-app ID: Das System fügt einen sekundären Anbieter zum ausgewählten Horizon Edge hinzu.

2. Kopieren Sie die veröffentlichten Images und App Volumes-Anwendungen aus dem Pod der ersten Generation in 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 Horizon Cloud-Dokumentation.

Hinweis: Wenn Sie eine Manuelle öffentliche IP eingegeben haben, müssen Sie sicherstellen, dass Sie das Routing von dieser öffentlichen IP-Adresse zur privaten IP-Adresse des installierten Lastausgleichsdiensts einrichten.

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.

Während der Präbuild-Phase können Sie die Spalten Migrationsstatus und Bericht auf der Seite Migration der Konsole verwenden.

Tipp: Wenn bei der Migration ein neuer Horizon Edge hinzugefügt wird, empfiehlt das Horizon-Migrationsteam, die erforderlichen DNS-Einträge zu konfigurieren, wenn Sie sehen, dass die Unified Access Gateway-Instanzen und der Lastausgleichsdienst bereitgestellt werden.

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. Weitere Informationen finden Sie unter Phase 6 – Konfigurieren von DNS-Datensätzen für die in Phase 5 der Self-Service-Migration erstellte Infrastruktur.

Wichtig: Wenn es sich bei Ihrem Mandanten der ersten Generation um eine Universal Broker-Umgebung handelt, nehmen Sie keine Änderungen an den Site-bezogenen Konfigurationen für Benutzer und Gruppen vor, die bereits im Mandanten der ersten Generation festgelegt sind.

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.

Achtung: Da das System in dieser Präbuild-Phase Ressourcen erstellt, werden in dieser Zeit wahrscheinlich neue Ressourcen in Ihrem Azure-Abonnement und in Ihrer Horizon Cloud-Umgebung erscheinen.

Beachten Sie Folgendes:

• Auch wenn die Horizon Cloud Console Sie nicht daran hindert, Pools in der Horizon Cloud-Umgebung mit diesen Ressourcen zu erstellen, empfehlen wir Ihnen dringend, die Erstellung von Pools oder andere Erstellungsworkflows mit diesen neuen Ressourcen zu vermeiden, bis die gesamte Migration abgeschlossen ist.

  Wenn diese Ressourcen in der Horizon Cloud-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 Horizon Cloud-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 Image der ersten Generation in der Ressourcengruppe base-vms des Pods der ersten Generation und führt Agent-Updates und andere Aktivitäten für diese Duplikate durch, bevor sie in der Horizon Cloud-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 Horizon Cloud-Umgebung werden die MIGXXXXXXXXXXXX-Images auf der Seite Importierte VMs der Konsole der ersten Generation 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.

Wichtig: Wenn es sich bei Ihrem Mandanten der ersten Generation um eine Universal Broker-Umgebung handelt, nehmen Sie keine Änderungen an den Site-bezogenen Konfigurationen für Benutzer und Gruppen vor, die bereits im Mandanten der ersten Generation festgelegt sind.

Während des Präbuilds

Während des Präbuilds:

1. Wenn bei der Migration ein neuer Horizon Edge anstelle eines vorhandenen verwendet wird, stellt das System den Horizon Cloud Horizon Edge bereit und verwendet dabei die Eingaben, die Sie in der Benutzeroberfläche Migration planen in (Phase 4) gemacht haben.

2. Das System übernimmt die Konfigurationsdaten der ersten Generation, die auf Pod-Ebene und in der Steuerungsebene der ersten Generation gespeichert sind, wandelt die Daten entsprechend dem Design der Horizon Cloud Control Plane um und speichert die umgewandelten Daten entsprechend.

3. Wenn dies die erste Migration in die Horizon Cloud-Umgebung ist, übernimmt das System die Active Directory (AD)-Domänenkonfigurationen des Mandanten der ersten Generation und erstellt die entsprechenden Domänenkonfigurationen in der Horizon Cloud-Umgebung.

   In der Horizon Cloud-Umgebung registriert das System alle registrierten Domänen des Mandanten der ersten Generation während der Präbuild-Aktivitäten für die erste geplante Migration. Bei nachfolgenden Pod-Migrationen vom selben Mandanten der ersten Generation überprüft das System erneut, ob die Konfigurationen des Mandanten der ersten Generation synchron sind, und überspringt die Registrierung von Domänen, die bereits in der Horizon Cloud-Umgebung vorhanden sind.

   Hinweis: Die Horizon Cloud-Umgebung erfordert Hilfskonten sowohl für das Domänendienst- als auch für das Domänenbeitrittskonto in den Horizon Cloud-AD-Domänenkonfigurationen. Wenn in der AD-Domänenkonfiguration eines Mandanten der ersten Generation 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 Horizon Cloud-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.

4. Das System kopiert die veröffentlichten Images der Bereitstellung der ersten Generation und die auf App Volumes bezogenen Dateien auf den Horizon Edge und konfiguriert die Kopien für die Verwendung mit dem Horizon Edge.

5. Für jedes der folgenden Elemente der ersten Generation 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 verfügen nicht über Testpools.) Jeder Testpool enthält eine Maschine und spiegelt die Konfigurationseinstellungen des Pools aus seinem Gegenstück der ersten Generation.

   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 Bereitstellung der ersten Generation 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 feststellen, dass die Unified Access Gateway- und Horizon Edge Gateway-Instanzen des neuen Horizon Edge ausgeführt werden, sollten Sie Ihr DNS mit Einträgen konfigurieren, die den in der Migrationsbenutzeroberfläche angegebenen FQDN den entsprechenden IP-Adressen zuordnen. Weitere Informationen finden Sie unter 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.

Hinweis: Wenn Ihr Pod der ersten Generation sowohl über eine externe Unified Access Gateway-Konfiguration als auch über eine interne Unified Access Gateway-Konfiguration verfügt, wird der Zugriffstyp des resultierenden Unified Access Gateway des Edge standardmäßig auf Interner und externer Zugriff festgelegt, wobei sowohl der externe FQDN als auch der interne FQDN standardmäßig auf denselben FQDN gesetzt sind (den FQDN, den Sie im Planungsassistenten eingegeben haben). Wenn Sie einen anderen FQDN für den internen Zugriff verwenden möchten, bearbeiten Sie die Details des Unified Access Gateway des Edge, um den internen FQDN in den gewünschten FQDN zu ändern. Beachten Sie, dass das Zertifikat diesen internen FQDN in den Zertifikatsinformationen enthalten muss.

Vorabvalidierung des Poolverhaltens mit Hilfe der Testpools

Suchen Sie die dynamischen Testpools in der Horizon Universal Console, indem Sie zu Ressourcen > Pools navigieren.

Jeder Testpool verfügt über eine einzelne Maschine, die Sie zur Vorabvalidierung der Horizon Cloud-Erfahrung für diesen Pool verwenden können.

Hinweis: Um die für die RDSH-App-Serverfarmen der ersten Generation erstellten Testpools vorab zu validieren, müssen Sie Benutzern oder Gruppen innerhalb der Horizon Cloud-Umgebung ausdrücklich Berechtigungen für diese Testpools erteilen. Bei RDSH-App-Serverfarmen der ersten Generation werden die Berechtigungen für Benutzer oder Gruppen der ersten Generation während des Präbuild-Prozesses nicht auf die Testpools repliziert.

AD-Domänen – Hilfsdomänendienst- und Domänenbeitrittskonten

Wie im vorherigen Abschnitt beschrieben, verwendet das System, wenn in der AD-Domänenkonfiguration eines Mandanten der ersten Generation ein Hilfsdomänendienstkonto oder ein zusätzliches Domänenbeitrittskonto fehlt, die Informationen des primären Kontos automatisch als Begleit-Hilfskonto in der Horizon Cloud-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 Horizon Cloud Console bearbeiten Sie die Domänen auf der Seite Integrationen (Integrationen > Verwalten > Domänen).

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.

Hinweis: Sie können diesen Schritt zum Konfigurieren von DNS-Datensätzen überspringen, wenn die Migration einen vorhandenen Horizon Edge verwendet.

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 Horizon Cloud-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 Horizon Cloud-Dokumentation.

In der 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 (Ressourcen > Kapazität > Horizon Edges).

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.

Phase 7 – Wartungsfenster für die Migration

Zum Startzeitpunkt Ihres geplanten Migrationsfensters startet das System automatisch seine letzten automatisierten Migrationsschritte. Während dieser Zeit wird der Zugriff von Administratoren und Endbenutzern auf die Verwaltungskonsole und die für Endbenutzer berechtigten Ressourcen im Mandanten der ersten Generation 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 Pod der ersten Generation, seinen Ressourcen, Einstellungen usw. vor.
• Nehmen Sie keine Änderungen an der Horizon Cloud-Bereitstellung vor.
• Das System verhindert den Zugriff auf die Horizon Universal Console der ersten Generation.
• 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 Horizon Cloud-Umgebung.

Die Self-Service-Migration erfordert die oben genannten Einschränkungen, da das System während dieser Zeit aktiv Ressourcen von der Bereitstellung der ersten Generation in die Horizon Cloud-Umgebung überträgt.

Die automatisierten Aktionen des Systems

Zu den aktiven Vorgängen, die während dieses Wartungsfensters auftreten, gehören:

• Verringern Sie die Größe der flexiblen Desktop-Pools und Farmen der Bereitstellung der ersten Generation, bis sie keine Kapazität mehr belegen.

• Dementsprechend müssen die flexiblen Desktop-Pools und -Farmen in der Horizon Cloud-Umgebung so erweitert werden, dass sie der Kapazität der Bereitstellung der ersten Generation entsprechen.

• Koppeln Sie die Desktop-VMs aus den dedizierten Desktop-Pools der Bereitstellung der ersten Generation mit der Horizon Cloud-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 Bereitstellung der ersten Generation entkoppelt und mit der Horizon Cloud-Umgebung gekoppelt werden. Dazu müssen die VMs möglicherweise eingeschaltet werden.

  Wenn Sie während des Wartungsfensters auf die Horizon Cloud Console zugreifen, wird auf der Benutzeroberfläche „Pools“ möglicherweise der Status Error für die Migration dedizierter Pools angezeigt. Dieses Verhalten wird während des Wartungsfensters erwartet.

Wenn das System einen Fehler feststellt, versucht es automatisch, die bis zu diesem Zeitpunkt vorgenommenen Änderungen rückgängig zu machen. Ausführliche Informationen zum Rückgängigmachen des Vorgangs finden Sie unter Rollback einer Migration.

Wenn die Aktionen erfolgreich abgeschlossen wurden und das Ende des Wartungsfensters erreicht ist, wird die Statusänderung Migrating des Pods auf der Migrationsseite der Konsole angezeigt.

Tipp: Das System zeigt diesen Status an, da die Pod-Infrastruktur der ersten Generation der Pod-Manager-Instanz und der Unified Access Gateway-Instanzen weiterhin vorhanden ist, bis Sie die Löschung des Pods bestätigen.

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 Omnissa Intelligence veröffentlicht.

• Die Horizon Cloud Console 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 versuchen, einen Rollback der Migration von der Horizon Cloud-Umgebung zum Bereitstellungsstatus der ersten Generation durchzuführen, und die Agents in der Horizon Cloud-Umgebung geändert wurden, werden die dedizierten Desktops in der zurückgesetzten Bereitstellung der ersten Generation möglicherweise 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 Horizon Cloud-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 Horizon Universal Console der ersten Generation zugreifen.
• Ihre Endbenutzer können auf ihre Desktops und Anwendungen zugreifen, die jetzt von der Horizon Cloud-Umgebung bereitgestellt werden.

Wichtig: Da die URL oder Serveradresse für den Zugriff auf Endbenutzerressourcen in der Horizon Cloud-Umgebung unterschiedlich ist, müssen Sie Ihre Endbenutzer über die neue Adresse informieren, die sie in ihren Horizon Clients und bei Verwendung des Horizon Web Clients (Browser) verwenden müssen. Weitere Informationen finden Sie auf der Seite Starten eines Desktops in der Horizon Cloud-Dokumentation.

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 Horizon Cloud-Umgebung auf den Mandanten der ersten Generation und der Umbenennung der migrierten Site in der Horizon Cloud-Umgebung werden in der Horizon Cloud-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 Site der ersten Generation und 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 Site der ersten Generation aus der Horizon Cloud-Umgebung.

Empfohlene Aktivitäten und Wissenswertes

Um sicherzustellen, dass die Horizon Cloud-Umgebung aus der geschäftlichen Perspektive Ihrer Organisation funktioniert, sollten Sie und Ihre VDI-Administratoren die folgenden 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 Horizon Cloud-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 Bereitstellung der ersten Generation zu einer Horizon Cloud-Umgebung migriert wird, in der derselbe Name bereits verwendet wird. In solchen Situationen benennt die Self-Service-Migration diese Ressourcen der ersten Generation 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.

Tipp: Eine Videodarstellung der Endbenutzererfahrung finden Sie im Tech Zone-Video unter Anmelden bei einem Horizon Cloud-Desktop oder einer -App als Endbenutzer.

Die Endbenutzererfahrung beim Starten von Desktops und Anwendungen in einer Horizon Cloud-Bereitstellung wird auf diesen Seiten im Handbuch Verwenden von Horizon Cloud:

• Browser: Starten eines Desktops mit Horizon Web Client und Starten einer Anwendung mithilfe von Horizon Web Client
• Nativer Horizon Client: Starten eines Desktops mit Horizon Client und Starten einer Anwendung mit Horizon Client.

Wenn Sie die Endbenutzer-Client-URL für Ihre Horizon Cloud-Umgebung nicht angepasst haben, lautet die Standardstartadresse cloud.omnissahorizon.com. Wenn die Client-URL oder Unterdomäne angepasst wurde, verwenden Sie die benutzerdefinierte URL. Die Anpassung wird in der Horizon Cloud-Dokumentation unter Konfigurieren von Branding beschrieben.

Der Horizon Cloud-Authentifizierungsablauf unterscheidet sich auch von dem der ersten Generation, denn in einer Horizon Cloud-Umgebung müssen sich die Endbenutzer über den konfigurierten Identitätsanbieter anmelden und nicht über den Anmeldeworkflow der Active Directory-Domäne, der in der ersten Generation verwendet wird.

Denken Sie daran: Wie unter Ausschlüsse und Sonderfälle für die Migration beschrieben, wird die Migration der Desktop-Einstellungen des Endbenutzers, die im Horizon Client für jeden Desktop festgelegt wurden, bei dieser Self-Service-Migration derzeit nicht unterstützt. Nach der Migration können Ihre Endbenutzer die gewünschten Einstellungen erneut in ihren Clients auswählen, wenn sie dies möchten.

Anmeldeerfahrung für Administratoren bestätigen

Stellen Sie sicher, dass Administratoren, die sich bei der Horizon Cloud Console anmelden, die Pools und anderen Ressourcen sehen können, die sie von der migrierten Bereitstellung der ersten Generation erwarten.

Der Verwaltungszugriff auf die Horizon Universal Console erfolgt über Omnissa Connect (connect.omnissa.com).

1. Melden Sie sich bei https://connect.omnissa.com/ an und navigieren Sie zu Meine Dienste, um die Workspace ONE Cloud-Karte zu finden.

   

2. Starten Sie diesen Dienst, damit die Karte unter Ihren Diensten angezeigt wird. Klicken Sie auf dieser Karte auf Verwalten, um die Horizon Universal Console zu starten.

Aktualisieren und erneutes Veröffentlichen von Images mit Administratorkennwörtern mit weniger als 12 Zeichen

Duplizieren Sie die VM des Images, ändern Sie das Administratorkennwort auf mindestens 12 Zeichen, veröffentlichen Sie die VM und löschen Sie die ursprüngliche VM.

Einstellung „Mindestanzahl VMs“ aus den VDI-Desktop-Zuweisungen und Farmen des Pods

Der Migrationsprozess ist so konzipiert, dass die VDI-Desktop-Zuweisungen und -Farmen der ersten Generation über gleichwertige Energieverwaltungseinstellungen in ihren entsprechenden Entitäten in der Horizon Cloud-Umgebung verfügen.

Für die VDI-Desktop-Zuweisungen und -Farmen der ersten Generation handelt es sich bei den entsprechenden Horizon Cloud-Entitäten um Pools und Poolgruppen. In der Horizon Cloud-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 Umgebung der ersten Generation 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 Zuweisungen und Farmen der ersten Generation erstellt hat, zeigt die Konsole die Einstellung Min. VMs dieser Poolgruppen als den Prozentsatz an, der aus dem Wert Min. VMs der ersten Generation umgewandelt wurde. Die Funktionalität hält sich weiterhin an die Min. VMs, basierend auf dem umgewandelten Prozentsatz.

AD-Domänenkonfigurationen

Die Horizon Cloud-Umgebung erfordert Hilfskonten sowohl für das Domänendienst- als auch für das Domänenbeitrittskonto in den Horizon Cloud-AD-Domänenkonfigurationen.

Wenn während der Präbuild-Aktivitäten in der AD-Domänenkonfiguration eines Mandanten ersten Generation 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 Horizon Cloud-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 Horizon Cloud Console die Domänen, indem Sie zu Integrationen > Verwalten > Domänen navigieren.

Achtung: Sobald das System die AD-Domänenkonfiguration des Mandanten der ersten Generation während der Migration des ersten Pods in die Horizon Cloud-Umgebung migriert hat, sind Sie für die Pflege aller Attributänderungen für die konfigurierten Domänen sowohl in der Umgebung der ersten Generation als auch in der Horizon Cloud-Umgebung verantwortlich. Das System hat nicht automatisch Änderungen, die Sie in einer Umgebung vornehmen, an die andere weitergegeben. Wenn Sie beispielsweise das Kennwort für das Domänendienstkonto in Ihrem Mandanten der ersten Generation aktualisieren, müssen Sie dieselbe Aktualisierung in der gekoppelten Horizon Cloud-Umgebung durchführen.

Site-bezogene Einstellungen – Multi-Cloud-Zuweisungen

Wenn in Ihrer Umgebung der ersten Generation Multi-Cloud-Zuweisungen vorhanden waren, führen Sie nach der Migration die folgenden Aktionen durch.

• Überprüfen der Zuordnungen der Start-Site

  Wenn Sie nach der Migration eines jeden Pods Zuordnungen von Start-Sites hatten, überprüfen Sie nach der Migration jedes Pods die Zuordnungen der Start-Site in der Horizon Cloud-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.

  Bei der Migration werden einige der Einstellungen in den Poolgruppen, die durch die Migration der Multi-Cloud-Zuweisungen der ersten Generation zu Horizon Cloud-Poolgruppen erstellt werden, standardmäßig festgelegt. 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 Zuweisung der ersten Generation werden nicht zur Poolgruppe migriert.

Wenn Ihre Umgebung der ersten Generation Multi-Cloud-Zuweisungen mit mehreren Pods enthält, beachten Sie auch die Hinweise unter Wenn Sie über mehrere Pods in Zuweisungen der ersten Generation verfügen – Wichtige Punkte zur Migration, die Sie beachten sollten.

App Volumes – Nach der Migration

Nach der Migration:

• App Volumes – Massenanwendungsberechtigungen

  In der Horizon Cloud-Architektur verwaltet das System die Berechtigungen anders als in der Architektur der ersten Generation. Während des Migrationsprozesses übernimmt das System die Auflösung aller Massenanwendungsberechtigungen, die in der migrierten Bereitstellung der ersten Generation enthalten waren. Diese Lösung stellt sicher, dass die Massenberechtigungen in das Format migriert werden, das für die Verwaltung der Berechtigungen in der Horizon Cloud-Umgebung geeignet ist. Endbenutzer haben weiterhin Zugriff auf denselben Satz an App Volumes-Anwendungen, auf die sie in der Umgebung der ersten Generation berechtigt waren.

• App Volumes: Pod-Migrationen

  Während der sukzessiven Migration von Horizon Cloud-Pods im Laufe der Zeit übernimmt das System alle App Volumes-Entitäten aus den Pods der ersten Generation in die Horizon Cloud-Umgebung.

  Beispiel: Sie haben die Anwendung Notepad++ als App Volumes-Anwendung in Ihren Pods der ersten Generation, die sowohl in Pod-1 als auch in Pod-2 verwendet wird, und es gibt mehrere Versionen der Anwendung: 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 Horizon Cloud-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 Umgebung der ersten Generation als auch in der Horizon Cloud-Umgebung vornehmen. Bei diesen Entitäten löscht das System während der Migration nicht, was es bereits in die Horizon Cloud-Umgebung kopiert hat. Bei Konflikten zwischen App Volumes-Entitäten der ersten Generation und der Horizon Cloud-Umgebung haben die in der Horizon Cloud-Umgebung vorhandenen Entitäten Vorrang.

  Zur Veranschaulichung: In der Umgebung der ersten Generation 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 Horizon Cloud-Umgebung. Das npp v7.8.2-Paket in der Horizon Cloud-Umgebung, das während der Migration von Pod-1 dorthin kopiert wurde, verbleibt in der Horizon Cloud-Umgebung, auch wenn dieses npp v7.8.2 aus der Umgebung der ersten Generation gelöscht wurde.

Remote-Apps aus Anwendungsfarmen der ersten Generation

Wie in der Dokumentation zur ersten Generation hier beschrieben , werden Remote-Apps von Anwendungsfarmen aus dem Pod der ersten Generation bereitgestellt. In der Horizon Cloud Horizon Universal Console wird neue Terminologie eingeführt, die sich in den Bezeichnungen widerspiegelt.

Nach der Migration:

• Die 1:1-Zuordnung zwischen der Anwendungsfarm der ersten Generation und dem resultierenden Pool in Horizon Cloud bleibt erhalten.

• 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 die Informationen zu den Benutzerberechtigungen angezeigt, die aus den Zuweisungen der Anwendungen der ersten Generation migriert wurden, entsprechend den Anwendungen, die mit dem Pool dieser Poolgruppe verknüpft sind.

• Der Name der Zuweisung von Anwendungen der ersten Generation wird in der Horizon Cloud Console nicht angezeigt. Wenn eine Zuweisung von Anwendungen der ersten Generation Remote-Apps aus mehreren Farmen enthält, können Sie die Remote-Apps und Endbenutzerberechtigungen in der Horizon Cloud Console anzeigen, indem Sie jede mit den Farmnamen erstellte Poolgruppe anzeigen oder die Option Desktop- und App-Katalog > Veröffentlichte Apps der Konsole verwenden.

  Hinweis: Wenn Sie die manuellen Apps direkt auf den Farm-VMs der ersten Generation installiert haben, werden diese Apps nicht standardmäßig auf den Pool-VMs der Horizon Cloud-Umgebung installiert, auch wenn ihre Metadaten im Rahmen des Migrationsprozesses migriert werden. Solche Apps müssen auf den Pool-VMs unter genau denselben Pfaden neu installiert werden, unter denen sie in den VMs der Farm der ersten Generation installiert waren.

Beachten Sie Folgendes:

• Die Zuweisung von Anwendungen der ersten Generation Assign-1 verfügt über die Apps app1 und app2 auf Farm Farm-1, und Benutzer User-1 verfügt über Berechtigungen für app1 und app2.
• Die Zuweisung von Anwendungen der ersten Generation 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 für User-1 als auch für User-2 berechtigt ist, app2 nur für User-1 berechtigt ist und app3 nur für User-2 berechtigt is.

Nach der Migration zu Horizon Cloud:

• 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 Farm der ersten Generation).
• 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 Horizon Cloud-Umgebung zufriedenstellend funktioniert, besteht die letzte Phase der Migration darin, die Migration abzuschließen.

Während des Abschlusses werden die Azure-Ressourcen, die der Pod der ersten Generation noch aus Ihrem Azure-Abonnement verbraucht, gelöscht.

Tipp: Sie müssen die Migration so bald wie möglich abschließen, um die Kosten für den parallelen Betrieb der Ressourcen des Horizon Cloud Horizon Edge und des Pods der ersten Generation zu vermeiden. Der Abschluss der Migration senkt Ihre Kosten, da die Azure-Ressourcen, die der Pod der ersten Generation noch verbraucht, gelöscht werden.

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 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 Pod der ersten Generation 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 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 Abschluss der Migration ist es nicht mehr möglich, ein Rollback von der Horizon Cloud-Umgebung zurück zum Bereitstellungsstatus der ersten Generation durchzuführen.

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 Pod der ersten Generation durch den Abschluss der Migration gelöscht wird, fallen Microsoft Azure-Abonnementkosten für die Ausführung der Ressourcen der ersten Generation an, einschließlich Pod-Manager- und Unified Access Gateway-Instanzen.

• Bis Sie die Migration abschließen, verhindert die Horizon Cloud Horizon Universal Console, dass Sie die Agent-Update-Vorgänge für dedizierte Poolgruppen und die Agent-Neuinstallation auf dedizierten VMs verwenden können (Agent > Agent aktualisieren oder Agent > Neu installieren).

  Achtung: Wenn Ihre Horizon Cloud-Umgebung eine nicht abgeschlossene Migration aufweist, verhindert die Konsole die Ausführung der Vorgänge „Agent aktualisieren“ und „Agent neu installieren“ für alle dedizierten Poolgruppen und dedizierten VMs, unabhängig davon, ob diese aus der ersten Generation migriert oder neu in der Horizon Cloud-Umgebung 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 versuchen, einen Rollback der Migration von der Horizon Cloud-Umgebung zum Bereitstellungsstatus der ersten Generation durchzuführen, und die Agents in der Horizon Cloud-Umgebung geändert wurden, werden die Desktops in der zurückgesetzten Bereitstellung der ersten Generation unter Umständen nicht ordnungsgemäß ausgeführt.

• Je mehr Zeit verstreicht, während Sie und Ihre VDI-Administratoren Änderungen an der Horizon Cloud-Umgebung vornehmen, desto weniger ist es möglich, ein Rollback der migrierten Umgebung auf einen Bereitstellungsstatus der ersten Generation durchzuführen, der Ihren Endbenutzern gerecht wird. Wenn Sie beispielsweise dedizierte Desktop-Pools in der Horizon Cloud-Umgebung erweitern und Endbenutzern neue Desktops zuweisen und dann versuchen, ein Rollback auf den Pod der ersten Generation durchzuführen, können Probleme für diese neuen Desktops auf der Seite der ersten Generation auftreten.

Abschließende Schritte

Sie schließen die Migration mithilfe der Aktion Abschließen auf der Migrationsseite der Horizon Cloud Console ab.

Nachdem Sie auf Abschließen geklickt haben, zeigt die Konsole ein Genehmigungsfenster an, in dem Sie das Löschen des quellseitigen Pods der ersten Generation genehmigen können.

Um den Migrationsvorgang abzuschließen und dem System zu bestätigen, dass der Pod der ersten Generation 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 Speicherkonto der App Volumes-Anwendungen zu überprüfen und ihn zu konfigurieren, wenn Sie feststellen, dass er noch nicht 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.

Um den Status in der Horizon Cloud Horizon Universal Console zu überprüfen, navigieren Sie zu den Horizon Edge-Details und suchen Sie den Abschnitt „App Volumes-Anwendungsspeicher“.

Wenn Nicht konfiguriert angezeigt wird oder Sie die Konfiguration ändern möchten, folgen Sie den Anweisungen, die an diesen Stellen im Horizon Cloud-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.

Hinweis: Sie können festlegen, dass der private Endpoint ein anderes Subnetz als das Management-Subnetz von Horizon Edge Gateway sowie gegebenenfalls ein anderes VNet verwenden soll. In diesem Fall müssen Sie sicherstellen, dass Netzwerk-Peering zwischen dem VNet, das Sie für den privaten Endpoint ausgewählt haben, und den VNets, die das Management-Subnetz des Edge Gateways und die VNets der Desktop-Pools enthalten (wenn sich diese Subnetze in anderen VNets als dem Management-Subnetz des Edge Gateways befinden), eingerichtet ist. Weitere Informationen finden Sie auf der Seite Private Azure-Endpoints für App Volumes-Anwendungsspeicherkonten.

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 Horizon Cloud.

Beachten Sie: Wie im Abschnitt Site-bezogene Informationen auf der Seite „Planung“ beschrieben, sollten Sie keine Änderungen an den Site-bezogenen Konfigurationen für Benutzer und Gruppen vornehmen, die bereits im Mandanten der ersten Generation festgelegt sind. Wenn Sie die Migration des ersten Pods abschließen und anschließend Änderungen an den Site-bezogenen Informationen in der Umgebung der ersten Generation vornehmen, werden diese Änderungen in der Horizon Cloud-Umgebung erst bei der nächsten Pod-Migration angezeigt.