Voraussetzungen für die Migration eines Horizon Cloud-Pods der ersten Generation

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 vor der Anmeldung bei Ihrer neuen Horizon Cloud-Umgebung und dem Aufrufen der Migrations-Benutzeroberfläche durchgeführt werden.

Einige dieser Bewertungen und Vorbereitungsschritte betreffen die Microsoft Azure-Abonnementumgebung und das Netzwerk, in dem der Pod der ersten Generation bereitgestellt ist. Hierfür benötigen Sie möglicherweise Unterstützung von Ihrem IT-Team, das für diese Umgebung zuständig ist.

Beachten Sie: Zum Zeitpunkt der Erstellung dieses Dokuments ist die Berechtigung für die Migration eines Pods der ersten Generation ein schrittweiser Rollout für Mandanten der ersten Generation. Wenn Sie dazu berechtigt sind, erhalten Sie eine direkte Mitteilung von Horizon Migration Communications.

Terminologie

Der Horizon Cloud Service hat neue Konzepte und eine neue Terminologie. Beim Horizon Cloud Service wird die Bereitstellung als Horizon Edge bezeichnet (anstelle des Begriffs Pod).

Die Self-Service-Migration ist so konzipiert, dass ein Microsoft Azure Horizon Edge in derselben Microsoft Azure-Abonnement bereitgestellt wird, die für den zu migrierenden Pod der ersten Generation verwendet wird, und dass dieselben Abonnementinformationen, VNets und Subnetze verwendet werden.

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 Mandanten der ersten Generation 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 Mandanten der ersten Generation und registriert dieselben in der Horizon Cloud-Umgebung.

Einige Elemente aus dem Pod der ersten Generation 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 Horizon Cloud-Anforderungen zu erfüllen.

Hinweis: Bei Pods mit bestimmten besonderen Merkmalen erfordert der Migrationsprozess möglicherweise die Verwendung eines neuen VNet und eines Management-Subnetzes, die sich von denen des Pods der ersten Generation unterscheiden. 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.

☐	Rufen Sie einen neuen FQDN und ein neues Zertifikat für Horizon Cloud Unified Access Gateway ab.
☐	Überprüfen Sie die Versionen des Pods und des Agents der ersten Generation und aktualisieren Sie sie bei Bedarf.
☐	Stellen Sie sicher, dass alle Images, die migriert werden müssen, gültig sind.
☐	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.
☐	Wenn der Name Ihres Microsoft Azure-Abonnements in der ersten Generation nicht-englische Zeichen enthält, benennen Sie das Abonnement vor der Migration zu Horizon Cloud um, sodass es nur englische Zeichen enthält.
☐	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 – Überprüfen 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.
☐	Bewerten Sie die Azure-Richtlinien für das Abonnement und die Ressourcengruppe des Pods und stellen Sie sicher, dass die Richtlinien die Bereitstellung der Speicherkonten und Dateifreigaben des Horizon Edge Gateway zulassen.
☐	Wenn der Pod über App Volumes-Anwendungen verfügt, befolgen Sie die Anweisungen unter , um sicherzustellen, dass die Richtlinien das Umschalten des Netzwerkzugriffs auf den Speicherkonten zulassen.
☐	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 Horizon Cloud-Umgebung anmelden und die Horizon Cloud 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 für die App-Registrierung Ihres Pods der ersten Generation eine benutzerdefinierte Rolle verwendet wird, aktualisieren Sie die für eine Horizon Cloud-Bereitstellung erforderlichen Berechtigungen gemäß den Anweisungen unter Wenn für die App-Registrierung Ihres Pods der ersten Generation eine benutzerdefinierte Rolle verwendet wird.

Rufen Sie einen neuen FQDN und ein neues Zertifikat für Horizon Cloud Unified Access Gateway ab

Hinweis: Der FQDN für die Horizon Cloud Unified Access Gateway-Bereitstellung muss sich von dem FQDN unterscheiden, der bereits für die zu migrierende Bereitstellung der ersten Generation verwendet wird. Um in seltenen Fällen von Problemen nach der Migration ein Rollback zur Bereitstellung der ersten Generation zu ermöglichen, müssen der FQDN des Gateways der Bereitstellung der ersten Generation und dessen SSL-Zertifikat wie für die Bereitstellung der ersten Generation konfiguriert bleiben. Sie können den FQDN und das SSL-Zertifikat der Horizon Cloud-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 Horizon Cloud-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.

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 Unified Access Gateway des Edge nach der Migration auf Interner und externer Zugriff festgelegt, wobei der externe FQDN und der interne FQDN standardmäßig auf denselben FQDN gesetzt sind (den FQDN, den Sie im Planungsassistenten eingeben). Wenn Sie nach der Migration einen anderen FQDN für den internen Zugriff verwenden möchten, bearbeiten Sie zu diesem Zeitpunkt die Unified Access Gateway-Details des Edge, um den internen FQDN in den gewünschten FQDN zu ändern, und konfigurieren Sie die Netzwerkbereiche für interne Benutzer entsprechend. Beachten Sie , dass das hochgeladene Zertifikat sowohl den externen FQDN als auch den internen FQDN in den Zertifikatsinformationen enthalten muss (z. B. muss der interne FQDN in den Daten für den alternativen Namen des Antragstellers enthalten sein).

Pod- und Agent-Versionen der ersten Generation 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 Azure-Pod muss das Pod-Manifest 5041.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 muss Horizon Agents Installer Version 24.2.0 oder höher ausgeführt werden.

Sicherstellen, dass alle zu migrierenden Images gültig sind

Um Probleme während der Prebuild-Phase der Migration zu vermeiden, stellen Sie sicher, dass alle Images der ersten Generation, die migriert werden müssen, den Status „Veröffentlicht“ aufweisen und dass ihre VMs und Snapshots in Microsoft Azure intakt sind.

Feststellen, ob das VNet oder die verbundenen Netzwerke des Pods IP-Adressen mit AKS-Beschränkung enthalten

Wichtig: Das Ergebnis Ihrer Feststellung gibt Ihnen eine Orientierungshilfe, welche Art der Horizon Edge Gateway-Bereitstellung Sie für die Migration verwenden sollten. Die Typen werden im nächsten Abschnitt mit dem Titel Auswählen des Edge Gateway-Bereitstellungstyps beschrieben.

Stellen Sie fest, ob das Management-Subnetz oder die VNet des Pods der ersten Generation oder die Netzwerke, mit denen die VNet verbunden ist (z. B. Ihr über ExpressRoute verbundenes lokales Netzwerk), 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 Pods der ersten Generation in die Horizon Cloud-Umgebung stellt das System ein sogenanntes Horizon Edge Gateway in der 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“. Dadurch werden Bereitstellungen von Pods der ersten Generation unterstützt, 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:
1. 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?
2. 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.	Der Einzel-VM-Typ hat keine besonderen Anforderungen, die über die auf der Seite „Voraussetzungen für die Migration eines Horizon Cloud-Pods der ersten Generation“ und in allen Unterabschnitten dieser Seite aufgeführten Anforderungen 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.	Der Einzel-VM-Typ hat keine besonderen Anforderungen, die über die auf der Seite „Voraussetzungen für die Migration eines Horizon Cloud-Pods der ersten Generation“ und in allen Unterabschnitten dieser Seite aufgeführten Anforderungen 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 Verbindung zu den Endpoints, Ports und Protokollen ermöglichen, die für Horizon Cloud Horizon Edge erforderlich sind.

Die vom Horizon Cloud Service benötigten Endpunkt-URLs und Ports unterscheiden sich wahrscheinlich von denen, die Ihr Netzwerkteam bereits für den Pod der ersten Generation zugelassen hat.

Eine Liste der erforderlichen Endpunkte, Ports und Protokolle finden Sie auf den folgenden Seiten im Handbuch Verwenden von Horizon Cloud. Legen Sie anschließend fest, welche Änderungen in der Umgebung des Pods der ersten Generation vorgenommen werden müssen.

Informationen zu Situationen, in denen die Verwendung von URLs nicht möglich ist, finden Sie im KB-6000374 – IP-Adressen für Dienstkomponenten.

Verwendung eines Proxys durch den Pod der ersten Generation:
* Sie müssen die URL softwareupdate.omnissa.com in Ihrer Firewall zulassen, da Proxy-Datenverkehr für diese URL derzeit nicht unterstützt wird. Ohne diese Einstellung funktioniert der Agent-Aktualisierungsvorgang nicht.
* Wenn Sie über dedizierte Pools verfügen, müssen Sie während des geplanten Migrationsfensters (Wartungsfenster) den globalen VM-Hub und die entsprechenden regionalen VM-Hub-Endpoints in Ihrer Firewall für das Mandanten-Subnetz (Desktop-Subnetz) zulassen. Der Grund dafür ist, dass dedizierte VMs der ersten Generation die Proxy-Konfiguration nicht automatisch erhalten und die Agents in diesen VMs die VM Hub- Endpoints für agentenbezogene Vorgänge erreichen müssen, z. B. die Signierung von Zertifikaten mit VM Hub und deren Erneuerung. Wenn Sie die VM-Hub-Endpoints in Ihrer Firewall nicht für die Migration zulassen möchten, können Sie vor der Ausführung der Migration die Proxy-Konfiguration direkt in der Registry der dedizierten VMs der ersten Generation mithilfe von Befehlen festlegen. Auf diese Weise können die Agents der dedizierten VMs mit den VM-Hub-Endpoints kommunizieren. Weitere Informationen finden Sie in der Horizon Cloud-Dokumentation in den Abschnitten DNS-Hostname des globalen VM-Hubs und DNS-Hostnamen des regionalen VM-Hubs.

Wenn ein Pod der ersten Generation mit einem Proxy konfiguriert ist, erben migrierte Pools die Proxy-Konfiguration. Während der Migration müssen dedizierte Desktop-Pools eine direkte Verbindung zu bestimmten URLs über das Internet herstellen und den Proxy umgehen. Wenn eine Firewall für ausgehende Konnektivität aus dem Desktop-VDI-Subnetz eingerichtet ist, müssen diese URLs während des Migrationsvorgangs zulässig sein. Nach Abschluss der Migration können Sie diese URLs aus der Positivliste entfernen.

URLs, die für dedizierte VMs während der Migration zugelassen werden sollen
USA: cloud-sg-us-r-westus2.horizon.omnissa.com cloud-sg-us-r-eastus2.horizon.omnissa.com EU: cloud-sg-eu-r-northeurope.horizon.omnissa.com cloud-sg-eu-r-germanywestcentral.horizon.omnissa.com cloud-sg-eu-r-uksouth.horizon.omnissa.com JP: cloud-sg-jp-r-japaneast.horizon.omnissa.com cloud-sg-jp-r-australiaeast.horizon.omnissa.com cloud-sg-jp-r-centralindia.horizon.omnissa.com

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

Sicherstellen, dass Ihre Azure-Richtlinien die Bereitstellung von Speicherkonten und Dateifreigaben zulassen

Bevor Sie die Migration planen, vergewissern Sie sich beim Besitzer des Azure-Abonnements des Pods, dass die Microsoft Azure-Richtlinien auf Abonnementebene oder in der Ressourcengruppe des Pods die Bereitstellung von Speicherkonten und Dateifreigaben in der Ressourcengruppe des Pods der ersten Generation nicht blockieren, verweigern oder einschränken.

Wenn Sie einen Pod zu einem vorhandenen Horizon Edge migrieren, stellen Sie sicher, dass die Microsoft Azure-Richtlinien auf dem Abonnement und der Ressourcengruppe des vorhandenen Horizon Edge die Bereitstellung von Speicherkonten und Dateifreigaben nicht blockieren, verweigern oder einschränken.

Eine erfolgreiche Horizon Edge Gateway-Bereitstellung erfordert die Bereitstellung des App Volumes-Speicherkontos und der Dateifreigaben.

Wenn der Pod der ersten Generation über App Volumes-Anwendungen verfügt, stellen Sie sicher, dass Ihre Azure-Richtlinien das Umschalten des Netzwerkzugriffs auf die Speicherkonten zulassen

Wenn der Pod der ersten Generation App Volumes-Anwendungen enthält, vergewissern Sie sich beim Besitzer des Azure-Abonnements des Pods, dass die Microsoft Azure-Richtlinien auf Abonnementebene oder in der Ressourcengruppe des Pods das Umschalten des öffentlichen Netzwerkzugriffs nicht blockieren, verweigern oder einschränken.

Die Migration App Volumes-Anwendungen durch das System beinhaltet das Kopieren dieser Ressourcen aus dem Azure-Speicherkonto des Pods in das Speicherkonto des Horizon Edge Gateways.

Um dieses Kopieren zu vereinfachen, benötigt der Migrationsvorgang Zugriff auf beide Speicherkonten. Während der Migration schaltet das System vorübergehend den öffentlichen Netzwerkzugriff auf die Speicherkonten ein und schaltet ihn dann nach Abschluss des Kopiervorgangs aus.

Wenn eine Azure-Richtlinie verhindert, dass der Migrationsprozess den öffentlichen Netzwerkzugriff auf die Speicherkonten aktiviert, bevor mit dem Kopieren der App Volumes-Anwendungen begonnen wird, schlägt die Migration fehl. Das System muss während der Buildout-Phase der Migration und während des Wartungsfensters den Netzwerkzugriff ein- und ausschalten können.

Wenn Sie über eine öffentliche IP-Adresse für den Unified Access Gateway-Lastausgleichsdienst verfügen

Wenn Ihr Pod der ersten Generation eine öffentliche IP-Adresse für den Lastenausgleichsdienst der externen Unified Access Gateway-Konfiguration verwendet, richtet das System Horizon Cloud Horizon Edge so ein, dass eine öffentliche IP-Adresse für die Unified Access Gateway-Konfiguration von Horizon Edge verwendet wird.

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 Ihrer externen Unified Access Gateway-Bereitstellung der ersten Generation eine private IP-Adresse verwendet, rufen Sie die öffentliche IP-Adresse ab, die an den Lastausgleichsdienst der Horizon Cloud-Bereitstellung weitergeleitet werden soll.

Wenn die zu migrierende externe Gateway-Konfiguration der ersten Generation 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 Bereitstellungen der ersten Generation 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 Konfiguration der ersten Generation während des Scanvorgangs, wenn es den Status Ready to migrate ermittelt.

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 für die Horizon Cloud Unified Access Gateway-Bereitstellung verwendet werden soll.

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

Wenn Sie über diese Konfiguration verfügen, sollten Sie daher eine neue öffentliche IP-Adresse verwenden, die sich von der Adresse unterscheidet, die derzeit für das externe Gateway des Pods der ersten Generation verwendet wird.

Prüfen Sie, ob Sie sich bei Ihrer neuen Horizon Cloud-Umgebung anmelden und die Horizon Cloud Horizon Universal Console anzeigen können.

Versuchen Sie, sich bei connect.omnissa.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 Dienste. Ihr spezifischer Satz von Karten kann abweichen.

Wenn Sie auf diese Horizon Cloud-Karte klicken, wird die Horizon Cloud Horizon Universal Console geöffnet.
- Wenn Sie zuvor ein Onboarding in Ihrer Horizon Cloud-Umgebung durchgeführt haben, wird die Horizon Cloud Horizon Universal Console mit dem verfügbaren Migrationsbildschirm angezeigt.
- Wenn Sie das Onboarding für Ihre Horizon Cloud-Umgebung noch nicht abgeschlossen haben, zeigt das System die Benutzeroberfläche für die Regionsauswahl an, wie im Abschnitt Auswahl der Cloud-Region beschrieben. 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 Horizon Cloud Horizon Universal Console führen und Sie bereits mit dem Horizon-Migrationsteam zusammenarbeiten, wenden Sie sich bitte an die Person aus diesem Team, mit der Sie zusammenarbeiten. Wenn Sie noch nicht mit dem Horizon-Migrationsteam zusammenarbeiten, wenden Sie sich bitte an den globalen Support und fordern Sie Unterstützung für die Horizon Cloud-Migration an.

Der folgende Screenshot veranschaulicht, wie der obere Teil der Navigationsseite der Horizon Cloud Console 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 Horizon Cloud Console.

Screenshot des oberen Bereichs der Navigation für die Horizon Cloud Console.

Auswählen des Identitätsanbieters und Synchronisieren von AD-Benutzern und -Gruppen mit diesem Identitätsanbieter

In der Horizon Cloud-Umgebung ist der Dienst auf die Verwendung eines externen Identitätsanbieters und einer Active Directory-Domäne angewiesen.

Hintergrund

In Ihrem Mandanten der ersten Generation 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 Apps zu authentifizieren.

In der Horizon Cloud-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 Pods der ersten Generation zu Horizon Cloud Horizon Edge verwendet Horizon Edge nach der Migration Ihre Active Directory-Domäne für die Maschinenidentität, genau wie in der Umgebung der ersten Generation. 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 Horizon Cloud-Umgebung auswählen, sollte mit den Active Directory-Domänen der Pods der ersten Generation verbunden sein, die in Ihrem Mandanten der ersten Generation registriert sind.

Auswählen des zu verwendenden Identitätsanbieters

Der Identitätsanbieter, den Sie für die Registrierung beim Horizon Cloud Service auswählen, muss die Anforderungen von Horizon Cloud erfüllen.

Zum Zeitpunkt der Erstellung dieses Dokuments:

Nur ein Identitätsanbieter kann in der Horizon Cloud-Umgebung verwendet werden.
Unterstützte Typen sind:
- Microsoft Entra ID Commercial (für kommerzielle Azure-Umgebungen) und Microsoft Entra ID Government (für Azure US Government-Umgebungen). Wenn Ihr Pod der ersten Generation in Azure US Government-Umgebungen bereitgestellt wird, verwenden Sie Microsoft Entra ID Government.
- Omnissa Access (Cloud oder lokal)

Weitere Hintergrundinformationen finden Sie unter Verbinden Ihres Identitätsanbieters in der Horizon Cloud-Dokumentation.

Voraussetzungen – Microsoft Entra ID Commercial oder Microsoft Entra ID Government

Sie führen einen Assistenten in der Horizon Cloud Horizon Universal Console aus, um die Horizon Cloud-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: 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 Horizon Cloud Service 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 Horizon Cloud-Umgebung bei ihren Desktops und Apps anmelden. Dieses Feld wird im Rahmen des Anmeldevorgangs für den Endbenutzer angezeigt.

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 Horizon Cloud Service 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 Horizon Cloud-Umgebung bei ihren Desktops und Apps anmelden. Dieses Feld wird im Rahmen des Anmeldevorgangs für den Endbenutzer angezeigt.

Voraussetzungen – Omnissa Access Cloud oder lokal

Sie führen einen Assistenten in der Horizon Cloud Horizon Universal Console aus, um die Horizon Cloud-Einstellungen für die Verwendung von Access zu konfigurieren.

Sie benötigen die folgenden Elemente, um diesen Assistenten abzuschließen.

Erforderliches Element	Details
Benutzer mit Administratorrechten	Dieser Benutzer in Omnissa 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 Horizon Cloud-Umgebung bei ihren Desktops und Apps anmelden. Dieses Feld wird im Rahmen des Anmeldevorgangs für den Endbenutzer angezeigt.
Access-Mandanten-FQDN	Im Assistenten geben Sie den FQDN Ihres Access-Mandanten ein. Dieser FQDN hat in der Regel das Format `yourcompany.workspaceoneaccess.com`. Sie können diesen FQDN über Ihre Access-Konsole abrufen.
Client-ID und geheimer Clientschlüssel des Access-Mandanten (bei Verwendung von Access lokal)	Wenn Sie 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 Horizon Cloud-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 Vorabvalidierungsprüfungen des Systems ruft das System die Gruppe von AD-Benutzern und -Gruppen aus den Desktop- und Anwendungszuweisungen des Pods der ersten Generation ab und überprüft den in der Horizon Cloud-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 Bereitstellung von Horizon Cloud on Microsoft Azure der ersten Generation für die Verwendung von Azure Active Directory (Azure AD) konfiguriert ist, müssen Sie vor der Migration alle Stellen aktualisieren, an denen Sie integrierte Benutzer oder integrierte Gruppen angegeben haben, und zu nicht integrierten Gruppen und Benutzern wechseln.

Das System überprüft die Pods der ersten Generation, um festzustellen, ob sie die Migrationskriterien erfüllen, sammelt dann die Informationen zu den Benutzern und Gruppen, die in den einzelnen Zuweisungen angegeben sind, und versucht, die entsprechende Konfiguration im konfigurierten Identitätsanbieter der Horizon Cloud-Umgebung zu erstellen. Wenn Sie Microsoft Azure AD als Ihren Identitätsanbieter in Ihrer Horizon Cloud-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 dann versucht, in diesem Identitätsanbieter die entsprechende Konfiguration der ersten Generation zu erstellen, in der Sie integrierte Gruppen und integrierte Benutzer verwendet haben, findet es keine entsprechende Entität in Azure AD, da diese integrierten Elemente niemals 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.

Überprüfen Sie Ihre Verwendung von App Volumes-Anwendungszuweisungen

Wenn Ihr Mandant der ersten Generation über App Volumes-Anwendungszuweisungen verfügt, stellen Sie sicher, dass Ihre Horizon Cloud-Umgebung über ein gültiges App Volumes-Lizenzabonnement verfügt.

Während der Vorvalidierungsprüfungen des Systems überprüft das System Ihre Horizon Cloud-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 Horizon Cloud Console können Sie das Vorhandensein von Lizenzen in Ihrer Horizon Cloud-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 Pods der ersten Generation eine benutzerdefinierte Rolle verwendet

Wenn Ihr Pod der ersten Generation zur Verwendung einer benutzerdefinierten Rolle für die Horizon Cloud-App-Registrierung seines Abonnements konfiguriert ist, muss diese benutzerdefinierte Rolle mit den in einer Horizon Cloud-Umgebung erforderlichen Berechtigungen als Voraussetzung für die Migration aktualisiert werden.

Die Verwendung einer benutzerdefinierten Rolle ist untypisch. Die meisten Pod-Bereitstellungen der ersten Generation verwenden die Rolle Contributor für die App-Registrierung ihres Horizon Cloud Service-Prinzipals.

Als Ihr Pod der ersten Generation bereitgestellt wurde, hat er möglicherweise eine benutzerdefinierte Rolle verwendet, wie auf der Dokumentationsseite für die erste Generation 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 Horizon Cloud-Umgebung zur Durchführung der erforderlichen API-Aufrufe benötigt werden.

Stellen Sie im Abonnement des Pods der ersten Generation sicher, dass die folgenden Vorgänge in der benutzerdefinierten Rolle der Horizon Cloud-App-Registrierung, die vom Pod verwendet wird, zulässig sind.

Einige dieser Vorgänge sind dieselben, die auch für die Bereitstellung eines Pods der ersten Generation erforderlich waren. In der Tabelle ist vermerkt, welche Vorgänge für die Horizon Cloud-Umgebung zusätzlich erforderlich sind.

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

Obligatorische Horizon Cloud-Berechtigungen

Microsoft Azure-Ressourcenvorgänge, die in der benutzerdefinierten Rolle bei der Zuweisung von Berechtigungen auf Abonnementebene zulässig sein müssen
	Vorgänge
Zusätzliche neue Vorgänge, die für Horizon Cloud zulässig sind	`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`
Erforderlich für Horizon Cloud und sollte bereits in der benutzerdefinierten Rolle Ihres Pods der ersten Generation zulässig sein	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 Horizon Cloud 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.

Zur Unterstützung von Horizon Cloud-Funktionen sind Microsoft Azure-Ressourcenvorgänge erforderlich, die für benutzerdefinierte Rollen beim Zuweisen von Berechtigungen auf Abonnementebene benötigt werden
	Vorgänge	Zweck
Zusätzliche neue Vorgänge, die für Horizon Cloud zulässig sind	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. `Microsoft.Network/privateEndpoints/write` und `Microsoft.Network/privateEndpoints/read` sind erforderlich, wenn Sie den AKS-Bereitstellungstyp für Ihre Migration verwenden und der Pod in einer kommerziellen Azure-Umgebung bereitgestellt wird. Diese Berechtigungen sind erforderlich, um die privaten Endpoint-Ressourcen zu erstellen und zu überprüfen, ob das NAT-Gateway des Management-Subnetzes korrekt konfiguriert ist. Diese Berechtigungen für private Endpoints beziehen sich auf die Verwendung von Horizon Edge (AKS) mit Azure Private Link bei der Migration. Hinweis: Wenn der Pod der ersten Generation in einer Azure US Government-Umgebung bereitgestellt wird und Sie den AKS-Bereitstellungstyp für die Migration verwenden, ist Horizon Edge (AKS) standardmäßig so konfiguriert, dass eine Internetverbindung anstelle von Azure Private Link verwendet wird. Die Verwendung von Azure Private Link in Azure US Government-Umgebungen wird nicht unterstützt. `Microsoft.Network/routeTables/join/action`- und `Microsoft.Network/routeTables/read`-Berechtigungen sind erforderlich, wenn Sie den AKS-Bereitstellungstyp für die Migration 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.
Erforderlich für Horizon Cloud, möglicherweise bereits in der benutzerdefinierten Rolle Ihres Pods der ersten Generation zugelassen	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. Darüber hinaus ist diese Berechtigung für öffentliche IP-Adressen erforderlich, um eine öffentliche IP-Adresse zu einem Image bereitzustellen und hinzuzufügen.

Hinweis Diese Informationen werden hier der Einfachheit halber hinzugefügt, um einen Ausblick auf die Horizon Cloud-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 Horizon Cloud-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 Horizon Cloud-Dokumentationsseite.

War diese Seite hilfreich?