Voraussetzungen für die Migration eines First-Gen-Horizon Cloud-Pods

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.

Nicht vergessen: Zum jetzigen Zeitpunkt ist die Berechtigung für die Migration eines First-Gen-Pods ein schrittweiser Rollout für First-Gen-Mandanten. Wenn Sie dazu berechtigt sind, erhalten Sie eine direkte Mitteilung von Horizon Migration Communications.

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.

Hinweis: Bei Pods, die einige besondere Merkmale aufweisen, kann der Migrationsvorgang die Verwendung eines neuen VNet und Management-Subnetzes erfordern, das sich vom First-Gen-Pod unterscheidet. Dieser spezielle Fall wird im Abschnitt dieser Seite beschrieben.

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

Hinweis: Der FQDN für die Next-Gen-Unified Access Gateway-Bereitstellung muss sich von dem FQDN unterscheiden, der bereits für die zu migrierende First-Gen-Bereitstellung verwendet wird. Um im seltenen Fall von Problemen nach der Migration ein Rollback zur First-Gen-Bereitstellung zu unterstützen, müssen der FQDN des Gateways der First-Gen-Bereitstellung und sein SSL-Zertifikat wie für die First-Gen-Bereitstellung konfiguriert bleiben. Sie können den FQDN und das SSL-Zertifikat der Next-Gen-Gateway-Bereitstellung zu einem gegebenen Zeitpunkt erst aktualisieren, wenn Sie die Migration abgeschlossen haben.

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

Wichtig: Das Ergebnis Ihrer Ermittlung gibt Aufschluss darüber, welche Art von Horizon Edge Gateway-Bereitstellung Sie für die Migration verwenden möchten. Die Typen werden im nächsten Abschnitt mit dem Titel Auswählen des Edge Gateway-Bereitstellungstyps beschrieben.

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	Unterstützt bis zu 5K (5.000) Sitzungen. Weniger Voraussetzungen für das Microsoft Azure-Abonnement als für den AKS-Typ Ermöglicht Migrationen von Pods, die die AKS-Anforderungen nicht ohne weiteres erfüllen können. Wenn der bereitgestellte zu einem späteren Zeitpunkt nicht verfügbar ist, führt das folgende Verhalten wie folgt: Endbenutzer müssen sich ohne Single Sign-On (SSO) anmelden. Überwachungsdaten für die Desktops werden während des Zeitraums, in dem die VM nicht verfügbar ist, nicht aufgezeichnet.	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: Die Endbenutzer sehen den Anmeldeablauf ohne SSO-Anmeldeerfahrung. Bevor sie beispielsweise ihren Desktop sehen, müssen sie sich mit ihren Active Directory Anmeldedaten anmelden. Die Überwachungsdaten der Desktops, die an die Edge-Gateway-VM gesendet werden, werden während des Zeitraums, in dem die VM nicht verfügbar ist, nicht aufgezeichnet.
AKS	Unterstützt mehr als 5K (5.000) Sitzungen. Azure Kubernetes Service hat Microsoft-bezogene Anforderungen, die erfüllt werden müssen Unterstützt Pod-Migrationen, die die AKS-Anforderungen erfüllen können. SSO-Anmeldeerfahrung und Überwachungsdatenerfassung werden über replizierte Dienste verarbeitet, die eine hochverfügbare Bereitstellung dieser Funktionen ermöglichen	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
Ja Nein	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“
Ja Ja	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: Ein anderes VNet und Management-Subnetz in diesem VNet im Abonnement des Pods einrichten, das die eingeschränkten IP-Adressen nicht enthält. Sicherstellen, dass das neue VNet und das Management-Subnetz die Anforderungen des AKS Edge Gateway erfüllen. Das neue VNet mit dem bestehenden VNet des Pods peeren 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 Nein	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 Ja	Nein zur ersten Frage bedeutet, dass der Einzel-VM-Typ Ihren Anforderungen entspricht. Sie haben die Wahl zwischen folgenden Optionen: Die einfachste ist die Verwendung eines Einzel-VM-Typs. Eine komplexere Option ist die Umgehung der durch AKS eingeschränkten IPs durch: Einrichten eines anderen VNet und Management-Subnetzes in diesem VNet im Abonnement des Pods, das die eingeschränkten IP-Adressen nicht enthält. Sicherstellen, dass das neue VNet und das Management-Subnetz die Anforderungen des AKS Edge Gateway erfüllen. Peering dieses neuen VNet mit dem bestehenden VNet des Pods Wenn Sie die oben genannten Punkte erfüllen, können Sie sich alternativ für den AKS-Typ entscheiden.	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: Standard_D4s_v3 – 4 vCPU Standard_D4s_v4 – 4 vCPU Standard_D4s_v5 – 4 vCPU
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: Standard_D2s_v3 – 2 vCPU Standard_D2ds_v5 – 2 vCPU Standard_D2a_v4 – 2 vCPU 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	Jedes Image wird dupliziert und zu Next-Gen migriert. Folglich benötigen Sie die doppelte Anzahl an vCPUs pro Image in der Familie. Um beispielsweise ein Image mit Standard_DS2_v2 mit 2 vCPU-Kernen zu migrieren, sind während der Migration zwei zusätzliche vCPU-Kerne erforderlich. Daher muss das Azure-Abonnement über mindestens 4 vCPU-Kerne der Standard-DSv2-Familie in der entsprechenden Region verfügen. Da die Images jedoch in Batches von 20 migriert werden, darf diese Zusatzquote nicht mehr als das 20-fache der Anzahl der vCPU-Kerne pro Image betragen. Mit anderen Worten: Sie benötigen Ihr bestehendes Kontingent plus ein zusätzliches Kontingent in Höhe des 20-fachen der vCPU des Images, nicht nur ein Kontingent in Höhe des 20-fachen der vCPU des 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.

Hinweis: Diese öffentliche IP muss sich von der öffentlichen IP unterscheiden, die bereits für das Gateway des zu migrierenden Pods verwendet wird, um gegebenenfalls ein Rollback auf den First-Gen-Bereitstellungsstatus zu unterstützen.

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.

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.

Hinweis: Der Identitätsanbieter, den Sie für Ihre Next-Gen-Umgebung auswählen, sollte mit den Active Directory-Domänen der First-Gen-Pods verbunden sein, die in Ihrem First-Gen-Mandanten registriert sind.

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.

Tipp: Eine Videodarstellung der Konfiguration von Microsoft Entra ID als Identitätsanbieter finden Sie ab Minute 3 in diesem Tech Zone-Video Planen der Migration eines Horizon Cloud on Microsoft Azure-Pods.

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: Genehmigen der angeforderten Berechtigungen Erteilen der Zustimmung für die gesamte Organisation 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.

Tipp: Eine Darstellung der Konfiguration von Workspace ONE Access als Identitätsanbieter finden Sie im Video in der Tech Zone-Übung: Verbinden von Workspace ONE Access als Benutzeridentitätsanbieter für Horizon Cloud.

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: Genehmigen der angeforderten Berechtigungen Erteilen der Zustimmung für die gesamte Organisation
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.

Wichtig: Entfernen Sie keine Vorgänge, die in der benutzerdefinierten Rolle bereits zulässig sind.

Obligatorische Next-Gen-Berechtigungen

Tabelle 1. Microsoft Azure-Ressourcenvorgänge, die in der benutzerdefinierten Rolle bei der Zuweisung von Berechtigungen auf Abonnementebene zulässig sein müssen
	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. Microsoft.Authorization//read Microsoft.Compute//read Microsoft.Compute/availabilitySets/* Microsoft.Compute/disks/* Microsoft.Compute/galleries/read Microsoft.Compute/galleries/write Microsoft.Compute/galleries/delete Microsoft.Compute/galleries/images/* Microsoft.Compute/galleries/images/versions/* Microsoft.Compute/images/* Microsoft.Compute/locations/* Microsoft.Compute/snapshots/* Microsoft.Compute/virtualMachines/* Microsoft.Compute/virtualMachineScaleSets/* Microsoft.MarketplaceOrdering/offertypes/publishers/offers/plans/agreements/read Microsoft.MarketplaceOrdering/offertypes/publishers/offers/plans/agreements/write Microsoft.Network/loadBalancers/* Microsoft.Network/networkInterfaces/* Microsoft.Network/networkSecurityGroups/* Microsoft.Network/virtualNetworks/read Microsoft.Network/virtualNetworks/write Microsoft.Network/virtualNetworks/checkIpAddressAvailability/read Microsoft.Network/virtualNetworks/subnets/* Microsoft.Network/virtualNetworks/virtualNetworkPeerings/read Microsoft.Resources/deployments/* Microsoft.Resources/subscriptions/resourceGroups/* Microsoft.ResourceHealth/availabilityStatuses/read Microsoft.Storage//read Microsoft.Storage/storageAccounts/

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.

Tabelle 2. Zur Unterstützung von Next-Gen-Funktionen werden Microsoft Azure-Ressourcenvorgänge benötigt, die für benutzerdefinierte Rollen bei der Zuweisung von Berechtigungen auf Abonnementebene erforderlich sind
	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. Microsoft.KeyVault//read Microsoft.KeyVault/vaults/ Microsoft.KeyVault/vaults/secrets/* Microsoft.Network/publicIPAddresses/*	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.

Hinweis: Diese Informationen werden hier der Einfachheit halber hinzugefügt, um einen Ausblick auf die Next-Gen-Umgebung nach der Migration zu geben. Wenn Sie die Berechtigungen vor der Pod-Migration aktualisieren, können Sie in Erwägung ziehen, diese Berechtigung gleichzeitig mit aufzunehmen.

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.