Auf dieser Seite werden die Elemente beschrieben, die derzeit vom Self-Service-Migrationsprozess für die Migration von First-Gen-Horizon Cloud on Microsoft Azure-Bereitstellungen zu einem Horizon Cloud Service - next-gen-Mandanten ausgeschlossen sind. Auf dieser Seite werden auch einige Sonderfälle von First-Gen-Bereitstellungen beschrieben.

Hinweis: Dieser Inhalt ist ein fortlaufendes Dokument. Diese Informationen werden aktualisiert, sobald zusätzliche Unterstützung verfügbar wird.

Aktuelle Hauptausschlüsse

Wichtig: In diesem Inhalt werden nicht alle möglichen Ausschlüsse genannt. Es handelt sich hier um die wichtigsten Merkmale, die derzeit vom Migrationsprozess ausgeschlossen sind.

Diese erste Liste enthält die eingeschlossenen Elemente und die folgende Liste die ausgeschlossenen Elemente.

Eingeschlossen ab dem 25. April 2024
Zum Zeitpunkt der Erstellung dieses Dokuments kann ein Horizon Cloud on Microsoft Azure-Pod, der die folgenden Kriterien erfüllt, migriert werden.
  • Er wird in einer kommerziellen Azure-Umgebung bereitgestellt.
  • Verfügt über Zuweisungen innerhalb dieses einzelnen Pods. Das heißt, wenn eine Zuweisung auf Pod-1 vorgenommen wird, existiert dieselbe Zuweisung nicht für andere Pods.

    Beispiel: Zuweisung-A verwendet sowohl Pod-1 als auch Pod-2 und Zuweisung-B verwendet nur Pod-3; Pod-3 kann migriert werden.

  • Auf dem Horizon Cloud on Microsoft Azure-Pod muss eine Mindestversion des Pod-Manifests ausgeführt werden, der Status auf der Kapazitätsseite der First-Gen-Konsole muss Online (grün) sein, und die Agents müssen eine Mindestversion ausführen. Weitere Informationen finden Sie im Abschnitt Sicherstellen, dass die First-Gen-Bereitstellung und die Agents den für die Migration erforderlichen Versionsstand aufweisen.
  • Interne Gateway-Konfigurationen, die der Pod-Bereitsteller der ersten Generation für Pods der ersten Generation bereitgestellt hat.
  • Externe Gateway-Konfigurationen, die der Pod-Bereitsteller der ersten Generation für Pods der ersten Generation bereitgestellt hat.
  • Wenn die Subnetze oder das VNet eines Pods Konflikte mit sogenannten AKS-eingeschränkten IP-Bereichen aufweisen oder sich mit diesen überschneiden, kann der Pod migriert werden, sofern Sie entweder den Bereitstellungstyp Einzelne virtuelle Maschine wählen oder die Problemumgehung implementieren, indem Sie ein neues VNet und Management-Subnetz für die Next-Gen-Bereitstellung erstellen. Weitere Informationen zu diesem Szenario finden Sie unter Feststellen, ob das VNet oder die verbundenen Netzwerke des Pods IP-Adressen mit AKS-Beschränkung enthalten.
  • Pods, die Remoteanwendungen für die Bestandsliste des Mandanten bereitstellen, sind für die Migration geeignet. Sowohl automatisch geprüfte Remoteanwendungen als auch Remoteanwendungen, die der Bestandsliste mit der Option Manuell von Farm hinzugefügt wurden, können zu diesem Zeitpunkt migriert werden. Gemäß der Beschreibung in der First-Gen-Dokumentation werden diese Remoteanwendungen von Anwendungsfarmen über den Pod bereitgestellt.
    Hinweis: Wenn Sie die manuellen Apps direkt auf den First-Gen-Farm-VMs installiert haben, werden diese Apps nicht standardmäßig auf den Pool-VMs der Next-Gen-Umgebung installiert, auch wenn ihre Metadaten als Teil des Migrationsvorgangs migriert werden. Solche Apps müssen auf den Pool-VMs in genau den spezifischen Pfaden neu installiert werden, in denen sie auf den First-Gen-Farm-VMs installiert waren.

    Weitere Informationen zum Aussehen der migrierten Anwendungsfarmen in der Next-Gen-Horizon Universal Console nach der Migration finden Sie im Abschnitt Nach dem Wartungsfenster in diesem Migrationshandbuch.

  • Die Proxy-Konfigurationseinstellungen, die der First-Gen-Dienst auf First-Gen-Pods unterstützt. Während der Migration werden dieselben Proxy-Einstellungen auf der resultierenden Horizon Edge Gateway-Appliance konfiguriert.
    Hinweis: Wenn Sie sich für eine Migration unter Verwendung des AKS-Bereitstellungstyps entscheiden und der First-Gen-Pod einen authentifizierten Proxy verwendet, bei dem die Proxy-Einstellungen einen Benutzernamen und ein Kennwort für die Authentifizierung enthalten, wird während des Migrationsvorgangs nur die Proxy-URL auf die Horizon Edge Gateway-Appliance kopiert. Der Grund dafür ist, dass der AKS-Typ den Microsoft Azure Kubernetes Service (AKS) verwendet, der zurzeit keinen authentifizierten Proxy unterstützt.

    Wenn Sie mit dem AKS-Bereitstellungstyp migrieren und der First-Gen-Pod einen authentifizierten Proxy verwendet, müssen Sie die Authentifizierung auf Ihrem Proxy deaktivieren, bevor Sie die Benutzeroberfläche des Planungsassistenten ausführen und die Migration planen. Nach Abschluss des Wartungsfensters für die Migration können Sie die Authentifizierung auf Ihrem Proxy erneut aktivieren, indem Sie die Konfigurationseinstellungen von Horizon Edge aktualisieren.

    Weitere Informationen zur Auswahl des Horizon Edge Gateway-Bereitstellungstyps für die Migration finden Sie unter Auswählen des Horizon Edge Gateway-Bereitstellungstyps.

  • Wenn die Pod-Flotte des First-Gen-Mandanten neben einem Horizon Cloud on Microsoft Azure-Pod auch Horizon-Pods umfasst, kann der Horizon Cloud on Microsoft Azure-Pod am Self-Service-Migrationsprozess teilnehmen, solange diese Horizon-Pods nur die Abonnementlizenzierung und keine anderen cloudbasierten Dienste nutzen.

    In diesem Szenario können Sie den in diesem Handbuch beschriebenen Self-Service-Migrationsprozess verwenden, um den Horizon Cloud on Microsoft Azure-Pod zu Ihrer Next-Gen-Umgebung zu migrieren. Nach der Migration des Horizon Cloud on Microsoft Azure-Pods verbleiben die Horizon-Pods in der Umgebung des First-Gen-Mandanten und erhalten ihre Abonnementlizenzierung über den First-Gen-Mandanten. Ein Self-Service-Migrationsprozess für Horizon-Pods wurde noch nicht bereitgestellt.

  • Horizon Thin Clients, die für Horizon Cloud Service next-gen in der VMware-Kompatibilitätsmatrix aufgeführt sind, werden nach der Migration unterstützt. Wenn Sie einen Anwendungsfall haben, bei dem Ihre Endbenutzer Horizon Thin Clients verwenden, überprüfen Sie die Kompatibilitätsmatrix zwischen Ihrem Horizon Thin Client-Gerät und -Modell und Horizon Cloud Service next-gen, bevor Sie mit der Migration fortfahren. Nur Horizon Thin Clients, die als kompatibel mit Horizon Cloud Service next-gen aufgeführt sind, werden nach der Migration unterstützt.

    Kompatibilitätsmatrix zwischen Horizon Thin Clients und Horizon Platform Version = Horizon Cloud Service next-gen befindet sich hier: https://www.vmware.com/resources/compatibility/search.php?deviceCategory=vdm&details=1&horizonVersion=666&page=1&display_interval=10&sortColumn=Partner&sortOrder=Asc

Hinweis: Die Migration der Desktop-Einstellungen für Endbenutzer, die im Horizon Client für jeden Desktop festgelegt sind, wird derzeit nicht unterstützt. Um die gewünschten Einstellungen nach der Migration abzurufen, können Ihre Endbenutzer diese Einstellungen erneut in ihren Clients festlegen.
Ausgeschlossen
Die folgenden Szenarien werden derzeit für die Migration nicht unterstützt:
  • In Azure Government-Umgebungen bereitgestellte Pods.
  • Diejenigen Horizon Cloud on Microsoft Azure-Pods, die an Zuweisungen mit mindestens zwei Pods teilnehmen.
  • Situationen, in denen Endbenutzer oder deren Clients PCoIP mit der Horizon Cloud on Microsoft Azure-Bereitstellung verwenden müssen.
    Hinweis: Die automatische Self-Service-Migration kann nicht erkennen, ob Sie Endbenutzer haben, die PCoIP wünschen oder benötigen. Sie und Ihre VDI-Administratoren müssen überprüfen, ob diese Situation für Ihre Endbenutzer gilt.
  • Horizon Thin Clients, die nicht in der VMware-Kompatibilitätsmatrix aufgeführt sind, werden für die Verwendung nach der Migration nicht unterstützt. Wenn Sie einen Anwendungsfall haben, bei dem Ihre Endbenutzer Horizon Thin Clients verwenden, überprüfen Sie die Kompatibilitätsmatrix zwischen Ihrem Horizon Thin Client-Gerät und -Modell und Horizon Cloud Service next-gen, bevor Sie mit der Migration fortfahren. Nur Horizon Thin Clients, die als kompatibel mit Horizon Cloud Service next-gen aufgeführt sind, werden unterstützt.

    Kompatibilitätsmatrix zwischen Horizon Thin Clients und Horizon Platform Version = Horizon Cloud Service next-gen befindet sich hier: https://www.vmware.com/resources/compatibility/search.php?deviceCategory=vdm&details=1&horizonVersion=666&page=1&display_interval=10&sortColumn=Partner&sortOrder=Asc

Hinweis: Wie im VMware KB-Artikel 91183 beschrieben, sind ab dem 30. Juni 2023 die historischen Dashboards und Berichte, die durch den Cloud Monitoring Service (CMS) bereitgestellt wurden, nur noch über Workspace ONE Intelligence verfügbar. Wenn Sie die Schritte des KB-Artikels vor dem 30. Juni 2023 befolgt haben, waren die Daten für den First-Gen- Horizon Cloud on Microsoft Azure-Pod zunächst über die Workspace ONE Intelligence-Konsole verfügbar.

Wenn der Horizon Cloud on Microsoft Azure-Pod der First-Gen zur Next-Gen-Umgebung migriert wird, sind die Zeitreihendaten für diesen Pod auch nach der Migration weiterhin in Workspace ONE Intelligence verfügbar.

Wenn VMware den Zugriff auf den Next-Gen-Migrationsassistenten in der First-Gen-Horizon Universal Console aktiviert hat, werden in diesem Assistenten die Funktionen angezeigt, die in First-Gen-Horizon Cloud on Microsoft Azure verfügbar sind, nach der Migration zu Horizon Cloud Service - next-gen aber nicht mehr bereitstehen.

Administratoren sollten die Endbenutzer über die Migration und darüber informieren, dass sich die Benutzererfahrung von Horizon Cloud Service - next-gen geringfügig von derjenigen von First-Gen-Horizon Cloud on Microsoft Azure unterscheidet. Beispielsweise werden in diesem Tech Zone-Video VMware Horizon Cloud Service-Anmeldeabläufe die Unterschiede bei der Anmeldung dargestellt.

Verwendet Ihre First-Gen-Bereitstellung Funktionen, die Ihnen gezielt zur Verfügung gestellt oder vom VMware Horizon Cloud Operations-Team aktiviert oder mit Workspace ONE Access integriert wurden?

Einige Funktionen wurden möglicherweise vom VMware Horizon Cloud Operations-Team selektiv für Ihre First-Gen-Bereitstellung aktiviert. Einige Elemente wurden möglicherweise unter speziellen Bedingungen für Sie bereitgestellt, z. B. private APIs.

Überprüfen Sie in Ihrem Team, ob Ihre Bereitstellung eines dieser Elemente umfasst.

  • Ist der Mandant für Single-Pod-Brokering konfiguriert und ist Workspace ONE Access in diesen Mandanten und seine Pods integriert? Wenn Sie noch keinen Kontakt zum VMware Horizon Cloud-Team für die Migration Ihres Pods aufgenommen haben, reichen Sie eine Support-Anfrage ein, um das VMware Horizon Cloud-Team um Hilfe zu bitten.
  • Ist der Mandant mit Universal Broker konfiguriert und in Workspace ONE Access- und Intelligent Hub-Dienste integriert? Wenn Sie noch keinen Kontakt zum VMware Horizon Cloud-Team für die Migration Ihres Pods aufgenommen haben, reichen Sie eine Support-Anfrage ein, um das VMware Horizon Cloud-Team um Hilfe zu bitten.
  • Haben Sie die Aktivierung von Funktionen angefordert, die laut der First-Gen-Dokumentation verfügbar sind, wenn Ihr Mandant explizit für die Nutzung dieser Funktionen auf Anfrage aktiviert ist? Beispiele für solche Funktionen sind die Verwendung von LDAPS bei der Registrierung der Active Directory-Domäne, das Verschieben einzelner VMs zwischen Zuweisungen im selben Pod, Berechtigungen mit eingeschränktem Geltungsbereich für Desktop-Zuweisungen und Farmen für die integrierten vordefinierten Rollen. Wenn die Antwort „Ja“ lautet, stellen Sie bitte eine Support-Anfrage an das VMware Horizon Cloud-Team, um weitere Informationen zu erhalten.
  • Haben Sie Skripte entwickelt, die sich auf APIs stützen, die VMware für die Verwendung mit der First-Gen-Steuerungsebene bereitgestellt hat? Diese Skripte oder Tools müssen mithilfe der APIs der Next-Gen-Steuerungsebene neu geschrieben werden. Informationen zu diesen APIs finden Sie in der Horizon Cloud Service - next-gen-API-Dokumentation.
  • Hat Ihr Team oder das VMware Horizon Cloud Operations-Team in Ihrem Namen bestimmte Funktionen oder Eigenschaften in der Unified Access Gateway-Konfiguration der Bereitstellung konfiguriert? Beispiele für solche Konfigurationen sind Syslog, erweiterte RADIUS-Optionen, benutzerdefiniertes Routing in den Management- oder Mandantensubnetzen und geänderte MTU-Standardgrößen auf den Unified Access Gateway-Instanzen. Wenn die Antwort „Ja“ lautet, stellen Sie bitte eine Support-Anfrage an das VMware Horizon Cloud-Team, um weitere Informationen zu erhalten.
  • Hat das VMware Horizon Cloud Operations-Team in Ihrem Namen bestimmte Eigenschaften im Zusammenhang mit den Pod-Manager-Instanzen der Bereitstellung konfiguriert? Beispiele für solche Konfigurationen sind das Ändern des Standard-Zeitüberschreitungswerts für den Cache-Thread des Benutzers und die Deaktivierung der Berechtigung des Domänenbeitrittskontos. Wenn die Antwort „Ja“ lautet, stellen Sie bitte eine Support-Anfrage an das VMware Horizon Cloud-Team, um weitere Informationen zu erhalten.
  • Gibt es weitere Elemente, die das VMware Horizon Cloud Operations-Team für Ihre Bereitstellung konfiguriert hat, die in der First-Gen-Dokumentation nicht als allgemein verfügbare oder auf Anfrage erhältliche Funktionen beschrieben sind? Wenn die Antwort „Ja“ lautet, stellen Sie bitte eine Support-Anfrage an das VMware Horizon Cloud-Team, um weitere Informationen zu erhalten.