Die Bestandsliste des Horizon Cloud-Mandanten enthält Assets wie RDSH-Farmen, veröffentlichte Images, Anwendungen und importierte virtuelle Maschinen (VMs). Die Assets sind Bausteine, aus denen die zugewiesenen Desktops und Remoteanwendungen Ihrer Endbenutzer abgeleitet werden. Sie greifen auf diese Bestandsliste und die verschiedenen Assets über den Bestand in der Horizon Universal Console zu.

Nicht vergessen: Wie in Profil der cloudbasierten Horizon Universal Console beschrieben, ist die First-Gen-Konsole dynamisch und spiegelt Funktionen wider, die für die zeitnahe Konfiguration Ihrer First-Gen-Mandantenumgebung geeignet sind. Der Zugriff auf die in dieser Dokumentation beschriebenen Funktionen kann von folgenden Faktoren abhängen:
  • Ob die Funktion vom Systemcode abhängt, der nur im aktuellen First-Gen-Horizon Cloud-Podmanifest, in der Horizon Pod-Version oder in der Horizon Cloud Connector-Version verfügbar ist.
  • Ob der Zugriff auf die Funktion in begrenzter Verfügbarkeit möglich ist, wie in den Versionshinweisen bei der Einführung der Funktion angegeben.
  • Ob die Funktion bestimmte Lizenzen oder SKUs erfordert.

Wenn eine Funktion in dieser Dokumentation erwähnt wird und diese Funktion in der First-Gen-Konsole nicht angezeigt wird, überprüfen Sie zuerst in den Versionshinweisen, ob der Zugriff auf die Funktion eingeschränkt ist und wie Sie die Aktivierung in Ihrem Mandanten anfordern können. Wenn Sie der Meinung sind, dass Sie berechtigt sind, eine in dieser Dokumentation beschriebene Funktion zu verwenden, und diese nicht in der Konsole angezeigt wird, können Sie alternativ Ihren VMware Horizon Cloud Service-Vertreter fragen oder, wenn Sie keinen Vertreter haben, eine Service-Anfrage (Service Request, SR) an das Horizon Cloud Service-Team stellen, wie in Support-Anfrage in Customer Connect (VMware KB 2006985) beschrieben.

Aufgrund der dynamischen Eigenschaften der Konsole werden in Ihrer Live-Umgebung möglicherweise Einträge und Bezeichnungen angezeigt, die Variationen der hier beschriebenen Informationen sind.

Nicht vergessen: Eine Cloud-verbundene Pod-Flotte kann aus zwei verschiedenen Pod-Typen bestehen. Ein Horizon-Pod ist der Pod-Typ, der auf dem Horizon Connection Server basiert und auf einer VMware SDDC-basierten Plattform bereitgestellt wird. Ein Horizon Cloud-Pod ist der Pod-Typ, der auf der Pod-Manager-Technologie basiert und vom Horizon Cloud Pod-Deployer in Microsoft Azure bereitgestellt wird, wie unter Horizon Cloud Pods – Verwenden der Seite „Kapazität“ zum Hinzufügen weiterer Pods beschrieben.

Anwendungs-Assets

Über Bestand erreichen Sie Workflows, die das Hinzufügen von anwendungsbezogenen Assets zur Bestandsliste und die Verwaltung dieser Assets erfordern. Zu diesen anwendungsbezogenen Assets gehören App Volumes-Anwendungen und farmbasierte Remoteanwendungen. Weitere Informationen finden Sie unter Anwendungen in Ihrer Horizon Cloud-Bestandsliste.

Farm-Assets

Über Bestand gelangen Sie zu farmbezogenen Workflows zur Erstellung und Verwaltung von RDSH-Farmen und deren RDSH-VMs. Informationen dazu finden Sie unter Farmen in Horizon Cloud und den entsprechenden Unterthemen.

Image-Assets

Über Bestand gelangen Sie zu Image-bezogenen Workflows. Die tatsächlichen Bezeichnungen und Seiten, die Sie in der Konsole sehen, und die verfügbaren Arbeitsabläufe, die diese Seiten unterstützen, können je nach den Typen der Pods, die sich derzeit in Ihrer Pod-Flotte befinden, variieren.

Wenn Ihre Pod-Flotte ausschließlich cloudverbundene Horizon-Pods enthält:
Cloudverbundene Horizon-Pods unterstützen die Verwendung von Funktionen der Horizon Image-Verwaltungsdienst- und Multi-Pod-Image-Verwaltung. Multi-Pod-Images werden von Horizon Image-Verwaltungsdienst bereitgestellt. Die Workflows zur Verwaltung von Multi-Pod-Images werden im Handbuch Verwaltung von Horizon-Images über die Cloud behandelt.
Wenn Ihre Pod-Flotte mindestens einen Horizon Cloud-Pod in Microsoft Azure enthält
Horizon Cloud-Pods unterstützen die Verwendung von Images auf Basis einzelner Pods in Ihrer Horizon Cloud-Bestandsliste. Weitere Informationen finden Sie in den folgenden Themen, in denen Workflows für Images auf Basis einzelner Pods beschrieben werden:
Wenn ab der Dienstversion vom Juli 2021 alle Ihre Horizon Cloud-Pods das Manifest 2632 oder höher aufweisen und Ihr Mandant für die Verwendung von Universal Broker konfiguriert ist, stehen die Funktionen des Horizon Image-Verwaltungsdienst und der Multi-Pod-Image-Verwaltung zur Verwendung mit diesen Pods zur Verfügung. Die Workflows zur Verwaltung von Multi-Pod-Images werden im Handbuch Verwaltung von Horizon-Images über die Cloud behandelt.

Importierte VM-Assets

Über Bestand erreichen Sie die Seite, auf der Sie die automatische Erstellung und den Import einer Basisimage-VM in einem einzelnen Horizon Cloud-Pod in Microsoft Azure initiieren und verschiedene Vorgänge auf den aufgeführten VMs durchführen können, z. B. das Ein- und Ausschalten. Bei den auf dieser Seite aufgeführten virtuellen Maschinen (VMs) handelt es sich VMs, die auf folgende Weise in Ihre Horizon Cloud-Umgebung gebracht wurden:

Bevor eine VM in einer Farm oder einer VDI-Desktop-Zuweisung verwendet werden kann, muss sie in den veröffentlichten Zustand versetzt werden, was auch als Versiegeln des Images bezeichnet wird. Auch wenn auf der Seite „Importierte VMs“ eine Aktion zur Umwandlung einer aufgeführten Basis-VM in den veröffentlichten Zustand vorhanden ist, wird ein versiegeltes, veröffentlichtes Image in der Regel über die Seiten für Images erstellt, die im vorherigen Abschnitt Image-Assets beschrieben sind. Stellen Sie vor dem Versiegeln der VM sicher, dass darauf alle gewünschten Anwendungen und Treiber installiert sind.

Für einen Horizon Cloud-Pod in Microsoft Azure aktualisiert die Aktion Agent-Paarbildung zurücksetzen der Seite den Agent-Status, der den Schlüsselaustausch zwischen dem Pod-Manager und dem Agent in der importierten VM zum Sichern der Verbindungen zwischen beiden steuert. Da diese Verbindungen mithilfe eines Schlüsselpaars gesichert werden, wird der Begriff „Paarbildung“ zum Beschreiben dieses Schlüsselaustauschs verwendet. In der Regel verwenden Sie diesen Workflow in den folgenden Szenarien:

  • Für eine VM, die kürzlich mithilfe des automatisierten Workflows zum Importieren von VMs aus dem Microsoft Azure Marketplace importiert wurde: In diesem Szenario startet diese Aktion die Agent-Software neu, die vom Workflow in der VM installiert wurde, wodurch die Paarbildung abgeschlossen wird.

    Für eine Master-VM, die Sie manuell erstellt und auf der Sie die Agent-Software installiert haben, und zwar unter Verwendung des manuellen Workflows zum Importieren von VMs aus Microsoft Azure: In diesem Szenario startet diese Aktion die Agent-Software neu, die vom Workflow auf der VM installiert wurde, wodurch die Paarbildung abgeschlossen wird.

    Für eine aufgelistete VM, die eine Fehlermeldung in der Spalte „Agent-Status“ anzeigt: In diesem Szenario startet diese Aktion die Agent-Software neu, um den Paarbildungsfehler zu beheben und die Paarbildung abzuschließen.

Einige zusätzliche Hinweise zur Seite „Importierte VMs“:

  • Wenn der Prozess zum Importieren eines Images aus dem Microsoft Azure Marketplace fehlschlägt, generiert das System eine Benachrichtigung über den Fehler und zeigt einen Fehler-Link in der Spalte „Agent-Status“ an. Wenn Sie auf diesen Link klicken, wird die Benachrichtigungsseite geöffnet, auf der Sie die Fehlerursache lesen können.
  • Die Seite „Importierte VMs“ wird nicht automatisch aktualisiert. Nachdem Sie eine Aktion durchgeführt haben, müssen Sie möglicherweise auf die Aktualisierungsaktion klicken, um den aktuellen Status anzuzeigen. Wenn beispielsweise eine VM ausgeschaltet ist und Sie die Aktion Einschalten auswählen, wird auf der Seite In Bearbeitung angezeigt, während der Einschaltvorgang gestartet wird. Dieser Status wird angezeigt, bis Sie die Seite aktualisieren.
  • Wenn die Multi-Pod-Image-Verwaltungsfunktionen in Ihrer Mandantenumgebung verfügbar sind, ist die Aktion Wechsel zu Multi-Pod-Images für die Verwendung auf VMs verfügbar, bei denen es sich um VDI-Images für Einzelsitzungen handelt. Diese Aktion wird in erster Linie für manuell importierte VMs verwendet, um deren Verwendung innerhalb der Multi-Pod-Image-Workflows zu ermöglichen.