Auf dieser Seite werden die Bereiche beschrieben, die Sie vor Beginn der ersten Pod-Migration bewerten, vorbereiten und bei Bedarf aktualisieren sollten.
Einführung
Die meisten dieser Bewertungen und Vorbereitungsschritte können jederzeit durchgeführt werden, bevor Sie sich bei Ihrer neuen Next-Gen-Umgebung anmelden und die Migrations-Benutzeroberfläche angezeigt wird.
Einige dieser Bewertungen und Vorbereitungsschritte betreffen die Microsoft Azure-Abonnementumgebung und das Netzwerk, in dem der First-Gen-Pod bereitgestellt wird. Hierfür benötigen Sie möglicherweise Unterstützung von Ihrem IT-Team, das für diese Umgebung zuständig ist.
Terminologie
Der Next-Gen-Dienst hat neue Konzepte und eine neue Terminologie. Beim Next-Gen-Dienst wird die Bereitstellung als Horizon Edge bezeichnet (anstelle des Begriffs Pod).
Die Self-Service-Migration dient zur Bereitstellung eines Microsoft Azure Horizon Edge in demselben Microsoft Azure-Abonnement, das für die Migration des First-Gen-Pods verwendet wird, und verwendet dieselben Abonnementinformationen, VNets und Subnetze.
Wenn jeder Pod migriert wird, verwendet der Prozess standardmäßig die folgenden Elemente aus diesem Pod:
- Microsoft Azure-Abonnement-ID, Verzeichnis-ID, Dienstprinzipalanwendungs-ID und geheimer Schlüssel.
- VNet
- Management-Subnetz, Mandantensubnetz, DMZ-Subnetz
- Active Directory-Domäneninformationen und Domänendienst- und Domänenbeitrittsdienstkonten, die im First-Gen-Mandanten registriert sind (Domänendienst- und Domänenbeitrittsbenutzer, Hilfsdomänendienst- und Domänenbeitrittsbenutzer).
Wenn die Migration Ihres ersten Pods geplant ist, kopiert das System alle Informationen zu den registrierten Active Directory-Domänen und Dienstkonten des First-Gen-Mandanten und registriert dieselben in der Next-Gen-Umgebung.
Einige Elemente aus dem First-Gen-Pod werden nicht wiederverwendet. Für einige dieser Ressourcen müssen Sie neue, zusätzliche Ressourcen einrichten.
Aus diesem Grund müssen Sie die folgenden Bereiche bewerten und nach Bedarf vorbereiten, um die Next-Gen-Anforderungen zu erfüllen.
Tabelle der Voraussetzungen
In den folgenden Abschnitten dieser Tabelle finden Sie die Einzelheiten zu jeder dieser Voraussetzungen. Diese Tabelle ist als praktische Übersicht beigefügt.
☐ | Beziehen Sie einen neuen FQDN und ein Zertifikat für Next-Gen-Unified Access Gateway. |
☐ | Bewerten Sie die First-Gen-Pod- und Agent-Versionen und aktualisieren Sie sie nach Bedarf. |
☐ | Legen Sie fest, ob das VNet oder verbundene Netzwerke des Pods AKS-eingeschränkte IP-Adressen enthalten. |
☐ | Legen Sie Ihren Bereitstellungstyp fest und erfüllen Sie die entsprechenden Anforderungen. |
☐ | Stellen Sie fest, ob das Microsoft Azure-Abonnement des Pods über Richtlinien für Ressourcengruppen-Tags verfügt. Falls ja, erstellen Sie einen Plan, wie Sie die Migrationsanforderung handhaben. |
☐ | Netzwerk – Bewerten Sie die vorhandenen Einstellungen für Ihren Netzwerkdatenverkehr und aktualisieren Sie sie nach Bedarf. |
☐ | Stellen Sie sicher, dass der zugehörige geheime Anwendungsschlüssel des Pods noch gültig ist. |
☐ | VNet – Bewerten Sie das aktuelle Routing, das Sie für den internen Zugriff auf Desktops verwenden. |
☐ | Bewerten Sie die Kontingente der Microsoft Azure vCPU-Familie und erhöhen Sie sie nach Bedarf. |
☐ | Wenn Sie über eine öffentliche IP für den Unified Access Gateway-Lastausgleichsdienst verfügen, befolgen Sie die Anleitung unter Wenn Sie eine öffentliche IP für diesen Lastausgleichsdienst verwenden. |
☐ | Wenn Sie über eine private IP-Adresse für den Unified Access Gateway-Lastausgleichsdienst verfügen, befolgen Sie die Anleitung unter Wenn Sie eine private IP für diesen Lastausgleichsdienst verwenden. |
☐ | Prüfen Sie, ob Sie sich bei Ihrer neuen Next-Gen-Umgebung anmelden und die Next-Gen-Horizon Universal Console anzeigen können. |
☐ | Legen Sie Ihren Identitätsanbieter fest und synchronisieren Sie AD-Benutzer und -Gruppen mit diesem. |
☐ | Überprüfen Sie die Verwendung von integrierten Active Directory-Benutzern oder -Gruppen und aktualisieren Sie sie bei Bedarf. |
☐ | Überprüfen Sie die Verwendung von App Volumes-Anwendungszuweisungen. |
☐ | Sonderfall: Wenn die App-Registrierung Ihres First-Gen-Pods eine benutzerdefinierte Rolle verwendet, aktualisieren Sie die für eine Next-Gen-Bereitstellung erforderlichen Berechtigungen anhand der Anleitung unter Wenn die App-Registrierung Ihres First-Gen-Pods eine benutzerdefinierte Rolle verwendet. |
Beziehen Sie einen neuen FQDN und ein Zertifikat für Next-Gen-Unified Access Gateway
Die Benutzeroberfläche des Planungsassistenten erfordert, dass Sie diesen FQDN im Assistenten angeben und das auf diesem FQDN basierende SSL-Zertifikat bereitstellen.
In der Next-Gen-Umgebung kann das SSL-Zertifikat entweder im PEM- oder PFX-Format vorliegen.
Der im Zertifikat festgelegte allgemeine Name oder FQDN muss mit dem FQDN übereinstimmen, den Sie in den Planungsassistenten eingeben möchten. Der Assistent überprüft, ob die Daten im Zertifikat mit dem im Assistenten eingegebenen FQDN übereinstimmen.
First-Gen-Pod- und Agent-Versionen bewerten und bei Bedarf aktualisieren
Bevor ein Pod migriert werden kann, müssen die Pod- und Agent-Versionen die folgenden Kriterien erfüllen:
- Auf dem Horizon Cloud-Pod muss das Pod-Manifest 4136.0 oder höher ausgeführt werden. Wenn ein früheres Manifest ausgeführt wird, initiieren Sie eine Dienstanforderung, um den Pod zu aktualisieren.
- Auf den dedizierten VDI-Desktops des Pods müssen Agent-Versionen ausgeführt werden, die vom Migrationsvorgang unterstützt werden, d. h. Horizon Agents Installer Version 23.1.0.22973254 und höher. Wenn auf dedizierten VDI-Desktops Agents mit einer früheren Version als 23.1.0.22973254 ausgeführt werden, aktualisieren Sie die Agents vor der Migration auf Version 23.1.0.22973254 oder höher.
- Flexible VDI-Desktops und -Images können über Agents vor Version 22.3.x verfügen, solange die Agent-Versionen der VMware-Interoperabilitätsmatrix für Horizon Cloud on Microsoft Azure Version 2210 entsprechen.
Feststellen, ob das VNet oder die verbundenen Netzwerke des Pods IP-Adressen mit AKS-Beschränkung enthalten
Stellen Sie fest, ob das Management-Subnetz des First-Gen-Pods oder das VNet oder die Netzwerke, mit denen das VNet verbunden ist (z. B. Ihr lokales Netzwerk, das über ExpressRoute verbunden ist), IP-Adressen aus den hier aufgelisteten Bereichen mit AKS-Einschränkungen enthalten:
- 169.254.0.0/16
- 172.30.0.0./16
- 172.31.0.0/16
- 192.0.2.0/24
Wenn ja, müssen Sie für die Migration dieses Pods zunächst prüfen, ob Ihre Anforderungen durch den Bereitstellungstyp „Einzel-VM“ erfüllt werden können oder ob Sie Anforderungen haben, die nur durch den Bereitstellungstyp „AKS“ erfüllt werden können.
- Entweder Sie verwenden den Bereitstellungstyp „Einzel-VM“, um diesen Pod zu migrieren, oder
- Wenn Sie aufgrund Ihrer Anforderungen den AKS-Bereitstellungstyp verwenden müssen, müssen Sie in diesem VNet innerhalb des Pod-Abonnements ein neues VNet und ein Management-Subnetz mit einem Mindest-CIDR von /26 einrichten und dieses neue VNet mit dem vorhandenen VNet des Pods peeren. Das Mindest-CIDR von /26 wird für den AKS-Bereitstellungstyp dringend empfohlen.
Stellen Sie sicher, dass das neuen VNet keine IP-Adressen aus den eingeschränkten Bereichen enthält oder verwendet. Mit dem neuen VNet und dem neuen Management-Subnetz können Sie den AKS-Bereitstellungstyp verwenden, der HA bereitstellt.
Eine ausführliche Anleitung finden Sie im nächsten Abschnitt zur Festlegung des Edge Gateway-Bereitstellungstyps.
Der Grund, warum diese spezifischen Bereiche AKS-eingeschränkte Bereiche sind, liegt darin, dass Microsoft diese Regel in Bezug auf seine Azure Kubernetes Service (AKS)-Cluster auferlegt, die für den AKS-Typ der Horizon Edge Gateway-Bereitstellung verwendet werden.
Wenn diese eingeschränkten IPs im Management-Subnetz oder VNet des Pods oder im lokalen Netzwerk enthalten sind, das mit dem VNet verbunden ist, kann der Migrationsvorgang mit dem AKS-Typ das vorhandene VNet des Pods nicht wiederverwenden.
Auswählen des Bereitstellungstyps und Erfüllen der entsprechenden Anforderungen
Bei der Migration eines First-Gen-Pods zur Next-Gen-Umgebung stellt das System ein sogenanntes Horizon Edge Gateway im Microsoft Azure-Abonnement des Pods bereit.
Für die Bereitstellung gibt es zwei Typen – entweder den Typ „Einzelne virtuelle Maschine (Einzel-VM)“ oder den Typ „Azure Kubernetes Service (AKS)“.
Das System ermöglicht es Ihnen, den zu verwendenden Typ für die Migration jedes Pods anzugeben.
Daher müssen Sie anhand der folgenden Tabelle entscheiden, welcher Typ entsprechend der benötigten Eigenschaften verwendet werden soll.
Edge Gateway-Bereitstellung | Schlüsselqualitäten | Details |
---|---|---|
Einzel-VM |
|
Der Einzel-VM-Typ bietet mehr Einfachheit bei der Migration eines Pods der ersten Generation über den AKS-Typ. Der Grund, warum die Auswahl dieser Option zu einer Vereinfachung des Prozesses führt, besteht darin, dass der Typ „Einzel-VM“ weniger neue Anforderungen an das Azure-Abonnement des Pods stellt als der Typ „AKS“. Daher eignet er sich für First-Gen-Pod-Bereitstellungen, die die Anforderungen des AKS-Typs nicht ohne weiteres erfüllen können. Zusätzlich zur Einfachheit unterscheidet sich der Einzel-VM-Typ vom AKS-Typ in seinem Verhalten, wenn die bereitgestellte VM nicht mehr verfügbar ist. Wenn nicht verfügbar:
|
AKS |
|
AKS ist ein Microsoft Azure-Standard für cloudnative Unternehmensanwendungen in Microsoft Azure-Datencentern. Der AKS-Typ stellt ein Edge-Gateway einer geclusterten Architektur bereit, die replizierte Dienste bereitstellt, die die SSO-Anmeldeerfahrung und die Überwachung der Datenerfassung unterstützen. |
- Zwei Fragen für die folgende Entscheidungstabelle:
-
- Benötigen Sie mehr als 5.000 Sitzungen oder sollen die SSO-Anmeldung und die Erfassung von Überwachungsdaten durch Dienste mit vollständiger Failover-Fähigkeit bei einem Ausfall unterstützt werden?
- Verfügen Sie über einen der AKS-eingeschränkten IP-Bereiche, die im Management-Subnetz des Pods oder im VNet des Pods enthalten sind oder von Maschinen verwendet werden, die mit diesem VNet bekannt sind, die mit Ihrem lokalen Netzwerk verbunden sind?
Ihre Antworten | Ansatz zur Verwendung | Zu erfüllende Voraussetzungen |
---|---|---|
|
Die Beantwortung der ersten Frage mit Ja erfordert den AKS-Typ. Wenn Sie mehr als 5.000 Sitzungen benötigen und die Anforderungen an die SSO-Anmeldung und die Datenerfassungsüberwachung erfüllen müssen, ist der AKS-Typ erforderlich. |
Voraussetzungen für den Typ „AKS“ |
|
Die Beantwortung der ersten Frage mit Ja erfordert den AKS-Typ. In diesem Fall benötigen Sie den AKS-Typ, um mehr als 5.000 Sitzungen bereitzustellen und die Anforderungen an die SSO-Anmeldung und die Überwachungsdatenerfassung zu erfüllen. Das VNet des Pods steht jedoch im Widerspruch zu den IP-Adressbeschränkungen des AKS-Typs. Um die Anforderungen des AKS-Typs zu unterstützen, müssen Sie:
Wählen Sie dann beim Ausführen des Migrationsassistenten das neue VNet und Management-Subnetz sowie die Option „Azure Kubernetes Service“ aus. |
Voraussetzungen für den AKS-Typ |
|
Nein zur ersten Frage bedeutet, dass der Einzel-VM-Typ Ihren Anforderungen entspricht. Da das VNet des Pods die IP-Einschränkungen des AKS-Typs erfüllt, können Sie alternativ den AKS-Typ für die Migration verwenden. |
Für den Einzel-VM-Typ gibt es keine spezifischen Anforderungen, die über die auf der Seite Voraussetzungen für die Migration eines First-Gen-Horizon Cloud-Pods und in den Unterabschnitten beschriebenen hinausgehen. |
|
Nein zur ersten Frage bedeutet, dass der Einzel-VM-Typ Ihren Anforderungen entspricht. Sie haben die Wahl zwischen folgenden Optionen:
|
Für den Einzel-VM-Typ gibt es keine spezifischen Anforderungen, die über die auf der Seite Voraussetzungen für die Migration eines First-Gen-Horizon Cloud-Pods und in den Unterabschnitten beschriebenen hinausgehen. |
Feststellen, ob das Microsoft Azure-Abonnement des Pods über Richtlinien für Ressourcengruppen-Tags verfügt
Zum Zeitpunkt der Erstellung dieses Dokuments erfordert der Bereitstellungsprozess für Horizon Edge, dass das Microsoft Azure-Abonnement die Erstellung von Ressourcengruppen ohne Tags erlaubt.
Unmittelbar nachdem Sie Tag und Uhrzeit des Migrationswartungsfensters festgelegt haben, erstellt das System Ressourcengruppen für die Horizon Edge Gateway- und Unified Access Gateway-Instanzen.
Wenn das Abonnement des Pods über Microsoft Azure-Richtlinien verfügt, die die Erstellung von Ressourcengruppen ohne Tags blockieren, oder wenn das Abonnement irgendeine Art von Ressourcen-Tag-Anforderung enthält, schlägt der Migrationsvorgang kurz nach diesem Planungsschritt fehl.
Wenn das Abonnement über eine solche Richtlinie verfügt, können Sie diese Anforderung verwalten, indem Sie planen, diese Azure-Richtlinie kurz vor dem Abschluss des Migrationsplanungsassistenten zu deaktivieren und die Richtlinie deaktiviert zu lassen, bis die Horizon Edge Gateway- und Unified Access Gateway-Instanzen im Abonnement bereitgestellt werden. Wenn die Horizon Edge Gateway- und Unified Access Gateway-Instanzen erfolgreich bereitgestellt wurden, kann die Azure-Richtlinie für die Anforderung von Tags beim Erstellen von Ressourcengruppen wieder aktiviert werden, ohne die Migrationsaktivitäten zu beeinträchtigen.
Netzwerk – Bewerten und Aktualisieren der bestehenden Einstellungen für Ihren Netzwerkverkehr bei Bedarf
Prüfen Sie, ob Ihre aktuellen Firewall-Einstellungen die Konnektivität zu den Endpoints, Ports und Protokollen zulassen, die für den Next-Gen-Horizon Edge erforderlich sind.
Die für den Next-Gen-Dienst erforderlichen Endpoint-URLs und -Ports unterscheiden sich wahrscheinlich von denen, die Ihr Netzwerkteam bereits für den First-Gen-Pod zugelassen hat.
Eine Liste der erforderlichen Endpoints, Ports und Protokolle finden Sie auf den folgenden Seiten im Handbuch Verwenden von Horizon Cloud Service - next-gen, und bestimmen Sie die Änderungen, die Sie in der Umgebung des First-Gen-Pods vornehmen müssen.
Überprüfen, ob der zugehörige geheime Anwendungsschlüssel des Pods noch gültig ist
Melden Sie sich beim Azure-Portal für Ihre Pod-Bereitstellung an und überprüfen Sie, ob der vom Pod verwendete Anwendungsschlüssel noch gültig ist.
Das Azure-Portal verwendet den Begriff „Geheimer Clientschlüssel“ im Bereich „App-Registrierung“. Suchen Sie nach der App-Registrierung, die mit dem Pod verknüpft ist.
VNet – Bewerten des Routings für den internen Zugriff auf Desktops
Je nach dem Routing, das Sie für den Pod der ersten Generation und den internen Zugriff auf Desktops eingerichtet haben, müssen Sie dieses Routing möglicherweise anpassen, damit der interne Zugriff auf Desktops im Next-Gen-Horizon Edge weiterhin möglich ist.
Bewerten der Kontingente für die Microsoft Azure vCPU-Familie und ggf. deren Erhöhung
Je nach den aktuellen Kontingenten für vCPU-Familien im Microsoft Azure-Abonnement Ihres First-Gen-Pods müssen Sie möglicherweise das Kontingent für bestimmte vCPU-Familien erhöhen, um den Migrationsvorgang zu unterstützen.
Bei der Migration wird ein Horizon Edge bereitgestellt, das aus mindestens einem Horizon Edge Gateway und zwei Unified Access Gateway-Instanzen besteht.
Ein in Microsoft Azure bereitgestellter Horizon Edge verfügt über ein Horizon Edge Gateway mit dem Bereitstellungstyp „Einzel-VM“ oder „AKS“.
Sie entscheiden, welchen Typ Sie für die Pod-Migration verwenden möchten, wie in Auswählen des Edge Gateway-Bereitstellungstyps beschrieben.
Zweck | Zusätzliche vCPU-/Kontingentanforderungen |
---|---|
Unified Access Gateway-Instanzen | Zusätzliches Kontingent für zwei (2) Standard_F8s_v2 |
Horizon Edge Gateway – Bereitstellungstyp „Einzel-VM“, wenn Sie sich für diesen Typ entscheiden | Zusätzliches Kontingent für 1 VM der folgenden VM-SKU-Größen:
|
Horizon Edge Gateway – Bereitstellungstyp „AKS“, wenn Sie sich für diesen Typ entscheiden | Zusätzliches Kontingent für 5 der folgenden VM-SKU-Größen:
Wenn das Pod-Abonnement über Kapazitäten für fünf (5) der oben aufgeführten VM-SKU-Größen verfügt, ist die Migrationsanforderung des Edge Gateways (AKS) mit vier Knoten erfüllt und die Anforderung von einem Knoten für künftige Upgrades des AKS ist ebenfalls erfüllt. Der Hintergrund dieser VM-SKU-Anforderungen ist, dass eine Edge Gateway-Bereitstellung (AKS) einen Azure Kubernetes Service-Cluster (AKS) nutzt, der vier VM-Knoten einer der folgenden aufgeführten VM-Größen für die Kapazität benötigt. Dann wird ein (1) zusätzlicher Knoten benötigt und während des Upgrade-Vorgangs verwendet. Insgesamt werden also 5 dieser VM-SKUs benötigt. |
Images |
|
Wenn Sie über eine öffentliche IP-Adresse für den Unified Access Gateway-Lastausgleichsdienst verfügen
Wenn Ihr First-Gen-Pod eine öffentliche IP-Adresse für den Lastausgleichsdienst seiner externen Unified Access Gateway-Konfiguration verwendet, richtet das System den Next-Gen-Horizon Edge so ein, dass er eine öffentliche IP-Adresse für die Unified Access Gateway-Konfiguration des Horizon Edge verwendet.
Das Abonnement des Pods benötigt in diesem Fall eine zusätzliche öffentliche IP-Adresse. Stellen Sie daher vor dem Planen der Migration sicher, dass das Abonnement über Kapazität verfügt, um diese zusätzliche öffentliche IP-Adresse bereitzustellen.
Wenn Sie über eine private IP-Adresse für den Unified Access Gateway-Lastausgleichsdienst verfügen
Wenn der Lastausgleichsdienst der externen Unified Access Gateway-First-Gen-Bereitstellung eine private IP verwendet, rufen Sie die öffentliche IP-Adresse ab, die an den Lastausgleichsdienst der Next-Gen-Bereitstellung weitergeleitet werden soll.
Wenn die zu migrierende externe First-Gen-Gateway-Konfiguration eine private IP für den Lastausgleichsdienst verwendet und eine öffentliche IP an diese private IP weitergeleitet wird, erkennt das System diese Konfiguration zu Beginn der Migrationsplanung.
Dieses Szenario wurde in First-Gen-Bereitstellungen verwendet, wenn vor dem Azure-Lastausgleichsdienst der externen Gateway-Konfiguration eine Firewall oder NAT konfiguriert wurde, um den internetbasierten Datenverkehr zu steuern, bevor der Zugriff auf die Unified Access Gateway-Appliances der externen Gateway-Konfiguration zugelassen wurde.
Das System erkennt die First-Gen-Konfiguration während des Scanvorgangs beim Festlegen des Status Bereit zur Migration.
Wenn das System diese Konfiguration erkennt, wird auf der Benutzeroberfläche des Assistenten für die Migrationsplanung das Feld Manuelle öffentliche IP angezeigt. In diesem Feld geben Sie die öffentliche IP-Adresse ein, die Sie für die Unified Access Gateway-Next-Gen-Bereitstellung verwenden möchten.
Wenn Sie daher über diese Konfiguration verfügen, rufen Sie eine neue öffentliche IP-Adresse zur Verwendung ab, die sich von der Adresse unterscheidet, die aktuell für das externe Gateway des First-Gen-Pods verwendet wird.
Bewerten der Fähigkeit, sich bei der neuen Next-Gen-Umgebung anzumelden und die Next-Gen-Horizon Universal Console anzuzeigen
Versuchen Sie, sich bei console.cloud.vmware.com anzumelden. Überprüfen Sie nach der Anmeldung, ob eine Karte mit der Bezeichnung Workspace ONE Cloud auf der Benutzeroberfläche „Dienste“ angezeigt wird. Der folgende Screenshot ist ein Beispiel.
- Überprüfen Sie zunächst, ob eine Karte mit der Bezeichnung Workspace ONE Cloud auf der Benutzeroberfläche „Dienste“ angezeigt wird. Der folgende Screenshot ist ein Beispiel.
- Bei Anzeige dieser Karte klicken Sie auf den Link Dienst starten und überprüfen dann, ob eine Karte mit der Bezeichnung Horizon Cloud angezeigt wird. Dieser Screenshot veranschaulicht diese Karte innerhalb der Workspace ONE-Dienste. Ihr spezifischer Satz von Karten kann abweichen.
Wenn Sie auf diese Horizon Cloud-Karte klicken, wird die Next-Gen-Horizon Universal Console geöffnet.
- Wenn Sie zuvor ein Onboarding in Ihrer Next-Gen-Umgebung durchgeführt haben, wird die Next-Gen-Horizon Universal Console mit dem verfügbaren Migrationsbildschirm angezeigt.
- Wenn Sie das Onboarding für Ihre Next-Gen-Umgebung noch nicht abgeschlossen haben, zeigt das System die Benutzeroberfläche für die Regionsauswahl an, wie im Abschnitt Auswahl der Cloud-Regionbeschrieben. Sie können die dort beschriebenen Schritte durchführen, um das Onboarding abzuschließen und die Konsole mit dem verfügbaren Migrationsbildschirm anzuzeigen.
Wenn die oben genannten Schritte nicht zur Anzeige der Next-Gen-Horizon Universal Console führen und Sie bereits Kontakt mit dem VMware Horizon Migration-Team haben, wenden Sie sich an die Person in diesem Team, mit der Sie zusammenarbeiten. Wenn Sie noch nicht mit dem VMware Horizon Migration-Team zusammenarbeiten, wenden Sie sich an VMware Horizon Migration und fordern Sie Hilfe bei der Horizon Cloud-Migration an.
Der folgende Screenshot veranschaulicht, wie der obere Teil der Navigationsseite der Next-Gen-Konsole am Ende des obigen Schritts 2 aussieht. Der Hauptbereich enthält unter Umständen den in diesem Screenshot angezeigten Begrüßungsinhalt. Im Hauptbereich wird möglicherweise automatisch der Migrationsbildschirm angezeigt. Wenn Sie diese Art der Navigation sehen, befinden Sie sich in der Next-Gen-Konsole.
![Screenshot des oberen Bereichs der Navigation für die Next-Gen-Konsole.](images/GUID-0E1AF221-D6B3-4281-9DD7-0E9E47800A20-low.png)
Auswählen des Identitätsanbieters und Synchronisieren von AD-Benutzern und -Gruppen mit diesem Identitätsanbieter
In der Next-Gen-Umgebung ist der Dienst auf die Verwendung eines externen Identitätsanbieters und einer Active Directory-Domäne angewiesen.
Hintergrund
In Ihrem First-Gen-Mandanten wurden Ihre registrierten Active Directory-Domänen sowohl für die Maschinen- als auch für die Benutzeridentität verwendet, um den Zugriff der Endbenutzer auf Desktops und veröffentlichte Anwendungen zu authentifizieren.
In der Next-Gen-Umgebung stellen Sie dem Dienst einen externen Identitätsanbieter zur Verfügung, der den Teil der Benutzeridentität übernimmt.
Die Verwendung eines externen Identitätsanbieters ermöglicht die Integration mit Drittanbieterlösungen, um Funktionen wie die Multifaktor-Authentifizierung bereitzustellen.
Bei der Migration eines First-Gen-Pods zu einem Next-Gen-Horizon Edge verwendet Horizon Edge nach der Migration Ihre Active Directory-Domäne für die Maschinenidentität, genau wie in der First-Gen-Umgebung. Die migrierten virtuellen Desktops und die virtuellen Maschinen, die veröffentlichte (Remote-)Anwendungen bereitstellen, werden mit der Active Directory-Domäne verbunden.
Auswählen des zu verwendenden Identitätsanbieters
Der Identitätsanbieter, den Sie für die Registrierung beim Next-Gen-Dienst auswählen, muss die Anforderungen von Horizon Cloud Service - next-gen erfüllen.
Zum Zeitpunkt der Erstellung dieses Dokuments:
- Nur ein Identitätsanbieter kann in der Next-Gen-Umgebung verwendet werden.
- Unterstützte Typen sind:
- Microsoft Entra ID
- Workspace ONE Access (Cloud oder lokal)
Weitere Hintergrundinformationen finden Sie unter Einrichten Ihres Identitätsanbieters in der Horizon Cloud Service next-gen-Dokumentation.
Voraussetzungen – Microsoft Entra ID
Sie führen einen Assistenten in der Next-Gen-Horizon Universal Console aus, um die Next-Gen-Einstellungen für die Verwendung von Microsoft Entra ID zu konfigurieren.
Sie benötigen die folgenden Elemente, um diesen Assistenten abzuschließen.
Erforderliches Element | Details |
---|---|
Benutzer mit den Rechten eines globalen Administrators | Dieser Benutzer in Microsoft Entra ID wird für die folgenden Aufgaben benötigt:
Als Teil der Benutzeroberfläche des Assistenten generieren Sie einen Link, über den sich dieser Benutzer bei Microsoft Entra ID anmelden kann, um die Berechtigungen zu genehmigen und die Zustimmung zu erteilen, dass der Next-Gen-Dienst auf die Benutzerinformationen in Microsoft Entra ID zugreifen kann. Als globaler Administrator in Ihrer Microsoft Entra ID werden Sie vom Assistenten aufgefordert, sich bei Microsoft Entra ID anzumelden, um die Berechtigungen zu genehmigen und die Zustimmung zu erteilen. Folgen Sie der Anleitung auf dem Bildschirm. |
Mandanten-Unterdomäne | Der Assistent fordert Sie auf, eine Zeichenfolge in einem Feld mit der Bezeichnung Mandanten-Unterdomäne einzugeben. Sie muss mit einem Buchstaben [a-Z] oder einer Ziffer [0-9] beginnen und enden und darf ausschließlich Buchstaben, Ziffern und Bindestriche [-] enthalten. Diese Zeichenfolge wird von Ihnen und Ihrem Team erstellt und verwendet. In der Regel wird eine Zeichenfolge eingegeben, die mit dem Namen des Unternehmens oder der Organisation oder der Unternehmensdomäne in Verbindung steht. Denken Sie jedoch daran, dass Ihre Endbenutzer diese Zeichenfolge im Feld Unternehmensdomäne verwenden eingeben, wenn sie sich später über die migrierte Next-Gen-Umgebung bei ihren Desktops und Anwendungen anmelden. Dieses Feld wird im Rahmen des Anmeldevorgangs für den Endbenutzer angezeigt.
Tipp: Eine Videodarstellung des Anmeldevorgangs für Endbenutzer, bei dem die Zeichenfolge für die
Mandanten-Unterdomäne verwendet wird, finden Sie ab Minute 3:30 in
diesem Tech Zone-Video, in dem der Anmeldevorgang für Administratoren und Endbenutzer verglichen wird.
|
Voraussetzungen – Workspace ONE Access Cloud oder lokal
Sie führen einen Assistenten in der Next-Gen-Horizon Universal Console aus, um die Next-Gen-Einstellungen für die Verwendung von Workspace ONE Access zu konfigurieren.
Sie benötigen die folgenden Elemente, um diesen Assistenten abzuschließen.
Erforderliches Element | Details |
---|---|
Benutzer mit Administratorrechten | Dieser Benutzer in Workspace ONE Access ist für die folgenden Aufgaben erforderlich:
|
Mandanten-Unterdomäne | Der Assistent fordert Sie auf, eine Zeichenfolge in einem Feld mit der Bezeichnung Mandanten-Unterdomäne einzugeben. Sie muss mit einem Buchstaben [a-Z] oder einer Ziffer [0-9] beginnen und enden und darf ausschließlich Buchstaben, Ziffern und Bindestriche [-] enthalten. Diese Zeichenfolge wird von Ihnen und Ihrem Team erstellt und verwendet. In der Regel wird eine Zeichenfolge eingegeben, die mit dem Namen des Unternehmens oder der Organisation oder der Unternehmensdomäne in Verbindung steht. Denken Sie jedoch daran, dass Ihre Endbenutzer diese Zeichenfolge im Feld Unternehmensdomäne verwenden eingeben, wenn sie sich später über die migrierte Next-Gen-Umgebung bei ihren Desktops und Anwendungen anmelden. Dieses Feld wird im Rahmen des Anmeldevorgangs für den Endbenutzer angezeigt.
Tipp: Eine Videodarstellung des Anmeldevorgangs für Endbenutzer, bei dem die Zeichenfolge für die
Mandanten-Unterdomäne verwendet wird, finden Sie ab Minute 3:30 in
diesem Tech Zone-Video, in dem der Anmeldevorgang für Administratoren und Endbenutzer verglichen wird.
|
Workspace ONE Access-Mandanten-FQDN | Im Assistenten geben Sie den FQDN Ihres Workspace ONE Access-Mandanten ein. Dieser FQDN hat in der Regel das Format yourcompany.workspaceoneaccess.com. Sie können diesen FQDN über Ihre Workspace ONE Access-Konsole abrufen. |
Client-ID und geheimer Clientschlüssel des Workspace ONE Access-Mandanten (bei Verwendung von Workspace ONE Access lokal) | Wenn Sie Workspace ONE Access lokal verwenden, fragt der Assistent nach der OAuth Client-ID und dem geheimen OAuth-Clientschlüssel, die Sie zum Zweck der Integration mit Ihrer Next-Gen-Umgebung konfiguriert haben. |
Synchronisieren Sie die Active Directory (AD)-Benutzer und -Gruppen mit diesem Identitätsanbieter
Stellen Sie vor der Auswahl der zu migrierenden Pods sicher, dass alle AD-Benutzer und AD-Gruppen, die zur Nutzung von Desktops und Anwendungen aus den zu migrierenden Pods berechtigt sind, mit dem von Ihnen gewählten Identitätsanbieter synchronisiert sind.
Während der Prüfungen zur Vorvalidierung des Systems erhält das System den Satz von AD-Benutzern und -Gruppen aus den Desktop- und Anwendungszuweisungen des First-Gen-Pods und überprüft den in der Next-Gen-Umgebung registrierten Identitätsanbieter für diese AD-Benutzer und -Gruppen. Wenn das System keinen dieser AD-Benutzer oder ‑Gruppen im registrierten Identitätsanbieter findet, schlägt der Schritt der Vorvalidierung fehl. Im Fehlerbericht, den Sie über die Benutzeroberfläche abrufen, wird der fehlende AD-Benutzer oder die fehlende AD-Gruppe angegeben.
Bewerten und Aktualisieren der Verwendung von integrierten Active Directory-Benutzern oder -Gruppen bei Bedarf
Wenn Ihre First-Gen-Horizon Cloud on Microsoft Azure-Bereitstellung für die Verwendung von Azure Active Directory (Azure AD) konfiguriert ist, müssen Sie überall dort, wo Sie vor der Migration integrierte Benutzer oder integrierte Gruppen angegeben haben, eine Aktualisierung durchführen und zu nicht integrierten Gruppen und Benutzern wechseln.
Das System überprüft die First-Gen-Pods, um festzustellen, ob sie die Migrationskriterien erfüllen, sammelt dann die Informationen über die Benutzer und Gruppen, die in jeder Zuordnung angegeben sind, und versucht, die äquivalente Konfiguration im konfigurierten Identitätsanbieter der Next-Gen-Umgebung zu erstellen. Wenn Sie Microsoft Azure AD als Ihren Identitätsanbieter in Ihrer Next-Gen-Umgebung verwenden, synchronisiert Microsoft Azure AD Connect Ihre Active Directory-Domäne mit Microsoft Azure AD.
Wie in der Microsoft-Dokumentation angegeben, schließt die Microsoft Azure AD Connect-Synchronisierung, die für die Synchronisierung einer Active Directory-Gruppe mit Azure AD zuständig ist, jedoch integrierte Sicherheitsgruppen von der Verzeichnissynchronisierung aus. Wenn das System versucht, in diesem Identitätsanbieter die äquivalente First-Gen-Konfiguration zu erstellen, in der Sie integrierte Gruppen und integrierte Benutzer verwendet haben, findet das System keine äquivalente Entität in Azure AD, da diese Integrationen nie synchronisiert werden. Das System meldet, dass die Pods, an denen die integrierten Benutzer und integrierten Gruppen beteiligt sind, nicht migriert werden können.
In diesem Szenario erstellen Sie reguläre Active Directory-Gruppen, die dieselben Mitgliedschaften haben wie die integrierten Gruppen und Benutzer. Wo immer Sie die integrierten Gruppen und Benutzer für den Empfang von Desktops oder Remoteanwendungen angegeben haben, aktualisieren Sie diese Einstellungen, um die regulären Active Directory-Gruppen zu verwenden.
Bewerten der Verwendung von App Volumes-Anwendungszuweisungen
Wenn Ihr First-Gen-Mandant über App Volumes-Anwendungszuweisungen verfügt, stellen Sie sicher, dass Ihre Next-Gen-Umgebung über ein gültiges App Volumes-Lizenzabonnement verfügt.
Während der Vorabvalidierungsprüfungen des Systems überprüft das System Ihre Next-Gen-Umgebung auf das Vorhandensein eines gültigen App Volumes-Lizenzabonnements.
Wird kein gültiges Lizenzabonnement gefunden, verhindert das System die Planung der Migration des Pods mit einer Fehlermeldung.
In der Next-Gen-Konsole können Sie das Vorhandensein von Lizenzen in Ihrer Next-Gen-Umgebung überprüfen, indem Sie die unter Verwenden der Horizon Universal Console zur Verfolgung Ihrer Horizon-Lizenzen beschriebenen Schritte durchführen.
Sonderfall – Wenn die App-Registrierung Ihres First-Gen-Pods eine benutzerdefinierte Rolle verwendet
Wenn Ihr First-Gen-Pod zur Verwendung einer benutzerdefinierten Rolle für die Horizon Cloud-App-Registrierung seines Abonnements konfiguriert ist, muss diese benutzerdefinierte Rolle mit den in einer Next-Gen-Umgebung erforderlichen Berechtigungen als Voraussetzung für die Migration aktualisiert werden.
Die Verwendung einer benutzerdefinierten Rolle ist untypisch. Die meisten First-Gen-Pod-Bereitstellungen verwenden die Rolle Beitragender für die Anwendungsregistrierung ihres Horizon Cloud-Dienstprinzipals.
Als Ihr First-Gen-Pod bereitgestellt wurde, hat er möglicherweise eine benutzerdefinierte Rolle verwendet, wie auf der First-Gen-Dokumentationsseite Wenn Ihr Unternehmen eine benutzerdefinierte Rolle verwenden möchte beschrieben.
Wenn dieses Szenario für Ihren Pod zutrifft, muss die vorhandene benutzerdefinierte Rolle mit den Berechtigungen aktualisiert werden, die für die Next-Gen-Umgebung zur Durchführung der erforderlichen API-Aufrufe benötigt werden.
Stellen Sie im Abonnement des First-Gen-Pods sicher, dass die folgenden Vorgänge in der benutzerdefinierten Rolle der Horizon Cloud-App-Registrierung (der vom Pod verwendeten App-Registrierung) zulässig sind.
Einige dieser Vorgänge sind dieselben, die auch für eine First-Gen-Pod-Bereitstellung erforderlich waren. In der Tabelle ist vermerkt, welche Vorgänge für die Next-Gen-Umgebung zusätzlich erforderlich sind.
Obligatorische Next-Gen-Berechtigungen
Betrieb | |
---|---|
Additional new ones to allow for next-gen |
Microsoft.ContainerService/managedClusters/delete Microsoft.ContainerService/managedClusters/read Microsoft.ContainerService/managedClusters/write Microsoft.ContainerService/managedClusters/commandResults/read Microsoft.ContainerService/managedClusters/runcommand/action Microsoft.ContainerService/managedClusters/upgradeProfiles/read Microsoft.ManagedIdentity/userAssignedIdentities/*/assign/action Microsoft.ManagedIdentity/userAssignedIdentities/*/read
Microsoft.ResourceGraph/*
Microsoft.Resources/subscriptions/read
Microsoft.Network/privateEndpoints/read Microsoft.Network/privateEndpoints/write Microsoft.Network/privateEndpoints/delete Microsoft.Network/locations/availablePrivateEndpointTypes/read |
Needed by next-gen which should be already allowed in your first-gen pod's custom role | Wenn einige dieser Vorgänge in der benutzerdefinierten Rolle noch nicht zulässig sind, fügen Sie die fehlenden Vorgänge hinzu, wenn Sie die Rolle für die vorhergehenden Vorgänge aktualisieren.
|
Optionale Berechtigungen
Obwohl die folgenden Berechtigungen für die Bereitstellung von Next-Gen-Horizon Edge in Microsoft Azure nicht zwingend erforderlich sind, funktionieren die Funktionen des Diensts, die von diesen optionalen Berechtigungen abhängen, nicht, wenn Sie sie nicht berücksichtigen.
Betrieb | Zweck | |
---|---|---|
Additional new ones to allow for next-gen |
Microsoft.Network/natGateways/join/action Microsoft.Network/natGateways/read Microsoft.Network/privateEndpoints/write Microsoft.Network/privateEndpoints/read Microsoft.Network/routeTables/join/action Microsoft.Network/routeTables/read |
Microsoft.Network/natGateways/join/action und Microsoft.Network/natGateways/read sind erforderliche Vorgänge, wenn Sie den AKS-Bereitstellungstyp für die Migration verwenden und in den Voraussetzungen für den AKS-Typ die Nutzung eines NAT-Gateways im Management-Subnetz ausgewählt haben. Der Dienst benötigt diese Berechtigungen, um die Ressourcen des privaten Endpoints zu erstellen und zu überprüfen, ob das NAT-Gateway des Management-Subnetzes ordnungsgemäß konfiguriert ist. Diese Berechtigungen für private Endpoints sind erforderlich, wenn Sie den AKS-Bereitstellungstyp für Ihre Migration verwenden. Diese beziehen sich auf die Verwendung von Horizon Edge (AKS) mit dem privaten Azure-Link bei der Migration. Diese Berechtigungen für Routentabellen sind erforderlich, wenn Sie den AKS-Bereitstellungstyp verwenden und in den Voraussetzungen für den AKS-Typ die Nutzung einer Routentabelle im Management-Subnetz ausgewählt haben. Der Dienst benötigt diese Berechtigungen, um die Ressourcen für private Endpoints zu erstellen und die mit dem Management-Subnetz verbundene Routentabelle zu überprüfen, um sicherzustellen, dass die Standardroute ordnungsgemäß konfiguriert ist. |
Needed by next-gen which could be already allowed in your first-gen pod's custom role | Wenn einige dieser Vorgänge in der benutzerdefinierten Rolle noch nicht zulässig sind, fügen Sie die fehlenden Vorgänge hinzu, wenn Sie die Rolle für die vorhergehenden Vorgänge aktualisieren.
|
Schlüsseltresor-Berechtigungen sind für die Festplattenverschlüsselung von Pool-VMs erforderlich. Die Berechtigung „Öffentliche IP-Adresse“ ist für die Bereitstellung einer Horizon Edge-Instanz mit Unified Access Gateway-Instanzen hinter einem Lastausgleichsdienst mit einer öffentlichen IP-Adresse erforderlich. Außerdem ist diese Berechtigung für die Bereitstellung und das Hinzufügen einer öffentlichen IP-Adresse zu einem Image erforderlich. |
Dieses Szenario tritt ein, wenn Ihr Identitätsanbieter für Ihre Next-Gen-Umgebung Microsoft Entra ID ist und Sie diesen für die Maschinenidentität verwenden möchten.
Weitere Informationen finden Sie in der Anmerkung zu Microsoft Entra ID auf der Dokumentationsseite zu next-gen.