Verwenden Sie die Informationen auf dieser Seite in Verbindung mit dem Abschnitt „Neuigkeiten“ in den Versionshinweisen. Zusätzlich zu den Aspekten, die im Dokument „Versionshinweise“ aufgelistet sind, ist diese Seite an diejenigen gerichtet, die bereits vor der Dienstaktualisierung vom Oktober 2020 ein Onboarding von mit der Cloud verbundenen Pods in ihrer Umgebung vorgenommen haben oder die bereits mit den Horizon Cloud-Funktionen und -Workflows vertraut sind. Auf dieser Seite wird beschrieben, was die neuen Funktionen und Änderungen für Sie und diese Pods bedeuten. Es werden nur wesentliche Änderungen an den Funktionen und Workflows beschrieben. Kleinere Änderungen, z. B. neue Layouts und Farbschemata in der Verwaltungskonsole, die die Workflows nicht wesentlich ändern, werden hier nicht detailliert beschrieben.

Aktuelle Informationen zu den verschiedenen Workflows, die Sie in Ihrer Horizon Cloud-Mandantenumgebung ausführen, finden Sie in den Dokumentationsthemen in den einzelnen Leitfäden, die auf der Horizon Cloud Service Dokumentationsseite verknüpft sind.

Wichtig: Schlagen Sie wichtige Informationen zum Verständnis von Begriffen, die auf dieser Seite verwendet werden, im Dokument „Versionshinweise“ nach, bevor Sie die Informationen auf dieser Seite lesen. Das Dokument „Versionshinweise“ enthält wichtige Informationen, z. B. die aktuelle Manifestnummer für Pods, die in Microsoft Azure bereitgestellt werden. Beachten Sie auch, dass die im folgenden Abschnitt beschriebenen wichtigen Fakten für jede Horizon Cloud-Version gelten.

Die folgenden Abschnitte gehen zum September 2019 zurück. Ähnliche Informationen für frühere Versionen sind für die Veröffentlichung nicht verfügbar.

Fünf wichtige Fakten zu jeder Horizon Cloud-Version

  • Alle neuen Funktionen, die auf der Cloud-Ebene basieren und nicht von der Pod-Manifest-, Horizon Cloud Connector-, Horizon-Pod-Versionsebene oder regionalen Unterschieden in der Steuerungsebene abhängig sind, werden automatisch sowohl für vorhandene als auch für neue Kunden bereitgestellt. Beispielsweise ist eine neue Funktion, die bei API-Aufrufen zwischen der Cloud-Ebene und den Pods nicht von neuen APIs abhängt bzw. sich nicht auf Horizon Cloud Connector bezieht, für Kunden sichtbar und nutzbar, sofern dies im Folgenden oder in den Produkthandbüchern nicht anders angegeben ist. Eine dieser Funktionen ist z. B. die verbesserte Übermittlung von Feedback in der Konsole. Auch wenn dieses Feedback-Symbol erstmals seit 9. Juli 2020 verfügbar ist, stehen das Symbol und das Schema für die Verwendung in Mandantenumgebungen zur Verfügung, die bereits vor dem 9. Juli 2020 und sogar noch vor dem Aktualisieren der Pods oder von Horizon Cloud Connector auf die neuesten Versionen existierten.
  • Ausgehend von dem Zeitpunkt, an dem diese Manifestversion in der Cloud-Steuerungsebene ausgeführt wird, stellt der Pod-Bereitsteller beim Bereitstellen von Pods in Microsoft Azure die Pods immer mit der neuesten Pod-Manifestversion bereit.
  • Bereits bereitgestellte Pods, die vor dem Zeitpunkt der Einführung einer neuen Pod-Manifestversion in Ihrem Dienstmandanten vorhanden sind, werden weiterhin mit ihrer vorhandenen Manifestversion ausgeführt, bis sie auf das neue Manifest für die Version aktualisiert werden. Es gilt Folgendes:
    • Neue Dienstfunktionen mit null Abhängigkeiten auf APIs, für die die neueste Manifestebene erforderlich ist, werden für diese vorhandenen Pods verfügbar sein.
    • Neue Dienstfunktionen, die auf APIs der neuesten Manifestebene basieren, stehen erst dann für diese vorhandenen Pods zur Verfügung, wenn diese Pods aktualisiert wurden.
    • Einige neue Dienstfunktionen hängen möglicherweise von der Region der Cloud-Ebene ab, in der sich Ihr Mandantenkonto befindet. Derartige Funktionen werden ggf. in der Dokumentation vermerkt. Ihre Steuerungsebenenregion ist in der Begrüßungs-E-Mail für den Horizon-Dienst angegeben, die beim Erstellen des Kundenkontos wie unter Integration in Horizon Cloud für Microsoft Azure, Horizon 7 lokal und Horizon 7 on VMware Cloud on AWS beschrieben gesendet wird.
  • Der Assistent der Konsole zum Importieren von VMs aus Marketplace verwendet den Horizon Agents Installer (HAI), der in das Pod-Manifest integriert ist. Infolgedessen ist in die Pods, die mit der aktuellen Manifestversion bereitgestellt werden, der neueste HAI integriert. Zudem werden beim Ausführen des Assistenten zum Importieren von VMs und beim Auswählen eines Pods der neuesten Ebene die Agenten des aktuellen HAI installiert. Für Pods, die noch nicht auf die neueste Manifestebene aktualisiert wurden, verwendet der Assistent zum Importieren von VMs aus Marketplace die HAI-Version, die bei der Erstellung der entsprechenden Pod-Manifeste verfügbar war.
  • Horizon Pods sind für zwei primäre Anwendungsfälle in Horizon Cloud integriert: die Aktivierung der Nutzung einer Abonnementlizenz mit diesen Pods und die Nutzung von cloudverbundenen Diensten, die Horizon Cloud für Horizon-Pods bereitstellt. Das Onboarding aller Pods erfolgt mit dem Horizon Cloud Connector. Der Ursprung des Onboarding-Vorgangs von Horizon-Pods in Horizon Cloud begann mit Horizon 7-Umgebungen der Version 7.6 und Horizon Cloud Connector 1.0 zur Aktivierung von Abonnementlizenzen für Horizon-Pods. Mit jeder neuen Version von Horizon in Kombination mit einer neuen Version von Horizon Cloud Connector werden zusätzliche cloudgehostete Dienste für cloudverbundene Horizon-Pods verfügbar, auf denen die neueste Horizon-Version in Verbindung mit der neuesten Horizon Cloud Connector-Version ausgeführt wird. Es wird empfohlen, dass Kunden mit früheren Versionen von Horizon Cloud Connector eine Aktualisierung auf diese neueste Version durchführen, um neue Funktionen sowie Sicherheits- und Stabilitätskorrekturen zu nutzen. Im Tool für VMware-Produkt-Interoperabilitätsmatrizen finden Sie Informationen zur Matrix der derzeit unterstützten Versionen von Horizon-Pod-Software mit Horizon Cloud Connector. Wenn Sie eine Kombination aus Horizon-Verbindungsserver und einer Horizon Cloud Connector-Version ausführen, die nicht mehr mit dieser Matrix übereinstimmt, aktualisieren Sie diese so schnell wie möglich auf eine unterstützte Kombination.

Oktober 2020 – v2010

Verwenden Sie die folgenden Informationen, wenn Sie ein bestehender Kunde mit cloudverbundenen Pods vor Oktober 2020 sind und wenn Sie die Auswirkungen der Funktionen nachvollziehen möchten, die unter „Neuigkeiten“ der Versionshinweise vom Oktober 2020 beschrieben sind.

Im Oktober 2020 wurden neue Versionen der folgenden Schlüssel-Binärdateien eingeführt: eine neue Pod-Manifestversion für per Dienst bereitgestellten Pods, neue Versionen von Horizon Cloud Connector, vom Universal Broker-Plug-In-Installationsprogramm und vom Horizon Agents Installer (HAI).

Diese Liste basiert auf den im Abschnitt Neuerungen im Oktober 2020 aufgeführten Elementen auf der Seite „Versionshinweise“.

Neue Elemente im Zusammenhang mit Horizon Cloud Connector und deren Verwendung mit Horizon-Pods
  • Horizon Cloud Connector-Version 1.8 wird in den OVA- und VHD-Formularen veröffentlicht.
  • Horizon Cloud Connector 1.8 bietet die Möglichkeit, ein Bereitstellungsprofil auszuwählen, das entweder nur mit Abonnementlizenzunterstützung oder mit Horizon Cloud-Funktionen aktiviert wird. Diese Auswahl wird während der Bereitstellung der Appliance getroffen.
  • Horizon Cloud Connector unterstützt nun Horizon-Pods, die in Azure VMware Solution (AVS) bereitgestellt werden. Momentan ist diese Unterstützung für die Verwendung Ihrer Abonnementlizenz mit diesen Bereitstellungen vorgesehen. Der vollständige Satz von Cloud-gehosteten Diensten wurde für diese Bereitstellungstypen noch nicht bereitgestellt.
Neue Elemente im Zusammenhang mit vom Dienst bereitgestellten Pods in Microsoft Azure
Horizon Cloud on Microsoft Azure-Pods unterstützen nun die Möglichkeit, während einer Pod- oder Gateway-Bereitstellung benutzerdefinierte Azure Resource-Tags anzugeben. Der Pod-Bereitsteller wendet die angegebenen Tags auf die vom Pod erstellten Ressourcengruppen an. Eine Beschreibung der vom Pod-Bereitsteller erstellten finden Sie unter Ressourcengruppen für einen in Microsoft Azure bereitgestellten Pod. Diese neue Funktion ist nicht von der Pod-Manifestversion abhängig.

Juli 2020 – v3.1

Verwenden Sie die folgenden Informationen, wenn Sie über cloudverbundene Pods vor Juli 2020 verfügen und wenn Sie die Auswirkungen der Funktionen nachvollziehen möchten, die unter „Neuigkeiten“ der Versionshinweise vom Juli 2020 beschrieben sind.

Speziell für vorhandene cloudverbundene Horizon-Pods
Einführung von Horizon Cloud Connector 1.7. Informationen zu den dazugehörigen Funktionen finden Sie unter „Neuigkeiten“ in den Versionshinweisen vom Juli 2020.
Speziell für vorhandene Pods in Microsoft Azure
Für die folgenden neuen Funktionen, die im Abschnitt „Neuigkeiten“ des Dokuments „Versionshinweise“ vom Juli 2020 beschrieben sind und die für einen bereits vorhandenen Pod verwendet werden sollen, muss dieser Pod zunächst auf die Manifestversion 2298.0 oder höher aktualisiert werden, um die Funktion verwenden zu können.
  • Mehrere Mandantensubnetze für Farmen und VDI-Desktop-Zuweisungen Diese Funktion ist noch nicht für die Verwendung mit Multi-Cloud-Desktop-Zuweisungen verfügbar, die in einem mit Universal Broker konfigurierten Mandanten verwendet werden.
  • Lastausgleich für erweiterte Sitzungen bei RDSH-Farmen.
  • Möglichkeit, sowohl Desktop- als auch Farmerweiterungsaufgaben, die sich in einer Warteschlange befinden oder gerade ausgeführt werden, abzubrechen – mit Unterstützung der automatischen Desktop-Zuweisung und Farmgrößenanpassung. Diese Funktion ist noch nicht für die Verwendung mit Multi-Cloud-Desktop-Zuweisungen verfügbar, die in einem mit Universal Broker konfigurierten Mandanten verwendet werden.
  • Um die Anmeldezeiten für Endbenutzer zu verbessern, wurde die Zeit verkürzt, die eine VM benötigt, bis sie für Agenten bereit ist. Dies betrifft Desktop-VMs, die von Pods bereitgestellt werden, die ausgeschaltet wurden und eingeschaltet werden müssen, um die Anforderung eines Endbenutzers nach einem Desktop zu erfüllen.
  • Verwendung der App Volumes-Funktionen – die Pods müssen auf das Manifest dieser Version aktualisiert werden, und Ihr Kundenkonto muss sich in einer der folgenden Horizon Cloud-Steuerungsebenenregionen befinden: USA-2 (PROD1_NORTHCENTRALUS2_CP1), Europe-2 (PROD1_NORTHEUROPE_CP1) oder Australia-2 (PROD1_AUSTRALIAEAST_CP1). Ihre Steuerungsebenenregion wird in Ihrer Begrüßungs-E-Mail für den Horizon Cloud Service angezeigt.

Wenn Sie eine Gateway-Konfiguration auf Ihrem Pod bereitstellen, haben Sie zusätzlich zur VM-Größe Standard_A4_v2 in früheren Versionen jetzt die Möglichkeit, die VM-Größe Standard_F8s_v2 zu verwenden, die mehr vCPUs für jede Unified Access Gateway-Instanz bietet. Bei vorhandenen Pods ist diese neue Funktion verfügbar, wenn der Pod bearbeitet wird, um eine neue Gateway-Konfiguration hinzuzufügen.

Weitere Hinweise für aktuelle Kunden
Eine verbesserte Übermittlung von Produkt-Feedback ist jetzt für alle bestehenden Kunden in der Kopfzeile der Konsole verfügbar.

Pods mit Hochverfügbarkeitsfunktion (HA) werden jetzt für Microsoft Azure Government (US Gov Virginia, US Gov Arizona, US Gov Texas) unterstützt. Wenn Sie über einen vorhandenen Pod in der Microsoft Azure Government verfügen, für den Sie diese Funktion verwenden möchten, wenden Sie sich bezüglich dieser Aktivierung an Ihren VMware-Vertreter.

März 2020 – v3

Verwenden Sie die folgenden Informationen, wenn Sie über cloudverbundene Pods vor März 2020 verfügen und wenn Sie die Auswirkungen der Funktionen nachvollziehen möchten, die unter „Neuigkeiten“ der Versionshinweise vom März 2020 beschrieben sind.

Speziell für vorhandene cloudverbundene Horizon-Pods
Mit der Einführung von Horizon Cloud Connector 1.6.x wird ein Befehlszeilendiagnose-Tool bereitgestellt, mit dem Sie den Status der erforderlichen Systemkomponenten und Dienste des Horizon-Pods überprüfen können, die benötigt werden, damit Horizon Cloud Connector den Pod erfolgreich mit Horizon Cloud koppeln kann. Bevor Sie sich beim webbasierten Konfigurationsportal anmelden und den Pod-Konfigurationsassistenten ausführen, können Sie mit diesem Diagnosetool nach Dingen suchen, die möglicherweise ein erfolgreiches Ergebnis verhindern. Wenn Probleme erkannt werden, meldet das Tool den Komponentennamen, die Details und die empfohlenen Schritte zur Abhilfe.
Speziell für vorhandene Pods in Microsoft Azure
Für die folgenden neuen Funktionen, die im Abschnitt „Neuigkeiten“ des Dokuments „Versionshinweise“ vom März 2020 beschrieben sind und die für einen bereits vorhandenen Pod verwendet werden sollen, muss dieser Pod zunächst auf die Manifestversion 1976.0 oder höher aktualisiert werden, um die Funktion verwenden zu können (sofern nicht anderweitig angegeben).
  • Zur Unterstützung erweiterter Bereitstellungskonfigurationen bei Verwendung eines separaten Abonnements für die Unified Access Gateway-Konfiguration können Sie auswählen, dass die Unified Access Gateway-Ressourcen in einer vorhandenen, vom Kunden erstellten Ressourcengruppe bereitgestellt werden, statt in der vom Pod-Bereitsteller erstellten Standardressource. Damit ein vorhandener Pod diese neue Funktion nutzen kann, muss der Pod zuerst mindestens auf ein Manifest der Version 1763 oder höher aktualisiert werden (das Manifest vom Dezember 2019). Anschließend müssen Sie alle dokumentierten Anforderungen zur Verwendung eines separaten Abonnements, VNet und einer separaten benutzerdefinierten Ressourcengruppe für die externe Gateway-Konfiguration erfüllen, einschließlich der Verbindung dieses VNet mit dem VNet des Pods über Peering und der Erstellung der Ressourcengruppe in dem Abonnement. Anschließend müssen Sie die vorhandene externe Unified Access Gateway-Konfiguration des Pods löschen, indem Sie den Workflow der Konsole zum Löschen des vorhandenen externen Gateways verwenden. Wenn der Löschvorgang erfolgreich abgeschlossen wurde, können Sie den Workflow Pod bearbeiten ausführen, um wieder ein externes Gateway mithilfe der neuen Option hinzuzufügen und das externe Unified Access Gateway in Ihrer vorhandenen Ressourcengruppe zu platzieren.
  • Unterstützung für Administratoren, um festzulegen, dass die Namen der dedizierten VDI-Desktop-Zuweisungen auf den Endbenutzer-Clients angezeigt werden, nachdem eine VDI-Desktop-VM dem Endbenutzer zugewiesen wurde, anstatt den Namen der Desktop-VM anzuzeigen. Nachdem ein Endbenutzer eine bestimmte VDI-Desktop-VM beansprucht hat, hat der Client zuvor standardmäßig den Namen der Desktop-VM angezeigt und dieses Verhalten war nicht konfigurierbar. Mit dieser Option werden die angezeigten Inhalte für die Endbenutzerverbindungen, die Workspace ONE Access durchlaufen, nicht geändert. Workspace ONE Access zeigt immer den dedizierten Namen der VDI-Desktop-Zuweisung an. Wenn der Endbenutzer die Desktop-VM aus Workspace ONE Access startet, wird der Desktop-Name auf seinem Endbenutzer-Client angezeigt. Auch wenn die Option für diese Funktion auf der Seite „Allgemeine Einstellungen“ angezeigt wird, muss ein Pod die Manifestversion 1976.0 oder höher ausführen, damit er diese Funktion nutzen kann.
  • Das Pod-Manifest 1976.0 oder höher unterstützt Administratoren beim Versetzen einer einzelnen Farm-VM in den Wartungsmodus, damit der Administrator Wartungsaktionen auf der VM durchführen kann. Damit Sie diese Funktion nutzen können, um den Wartungsmodus für die VM festzulegen, muss der Pod die Manifestversion dieser Version ausführen. Aufgrund eines bekannten Problems in der Konsole werden die Optionen dieser Funktion zwar auf der Registerkarte „Server“ der Farm in der Konsole angezeigt, erlauben die Festlegung des Modus aber erst, wenn die Agenten in den VMs der Farm mit Version 20.1.0 oder höher ausgeführt werden.
Weitere Hinweise für aktuelle Kunden
Verbesserungen der Berichte, die über die Seiten „Berichte“ und „Dashboard“ der Konsole verfügbar sind. Die Daten in diesen Berichten werden vom Cloud-Überwachungsdienst bereitgestellt. Vorhandene Pods können diese Funktion nutzen.

Dezember 2019 – v2.2

Verwenden Sie die folgenden Informationen, wenn Sie über cloudverbundene Pods vor Dezember 2019 verfügen und wenn Sie die Auswirkungen der Funktionen nachvollziehen möchten, die unter „Neuigkeiten“ der Versionshinweise vom Dezember 2019 beschrieben sind.

Speziell für vorhandene cloudverbundene Horizon-Pods
Neu in dieser Version:
  • Einige Aspekte, die Ihrer Kontrolle unterliegen, können eine erfolgreiche automatische Aktualisierung des Cloud Connectors verhindern, z. B. unzureichender Datenspeicher für die Aktualisierung in Ihrer vCenter-Umgebung. Wenn ab dieser Version die automatische Aktualisierung für Ihr Horizon Cloud-Mandantenkonto aktiviert ist, werden diese Elemente in der Konsole identifiziert, damit Sie diese Elemente adressieren und löschen können.
  • Automatisierte Aktualisierungen von Horizon Cloud Connector werden jetzt für Horizon-Pods unterstützt, die in VMware Cloud on AWS bereitgestellt sind.
  • Verbesserungen im Bildschirm für erfolgreiches Horizon Cloud Connector-Onboarding enthalten eine Zustandsanzeige für die Connector-Komponenten und eine Option zum Aktivieren und Deaktivieren von SSH auf der Horizon Cloud Connector-Appliance.
Speziell für vorhandene Pods in Microsoft Azure
Für die folgenden neuen Funktionen, die im Abschnitt „Neuigkeiten“ des Dokuments „Versionshinweise“ vom Dezember 2019 beschrieben sind und die für einen bereits vorhandenen Pod verwendet werden sollen, muss dieser Pod zunächst auf die Manifestversion 1763.0 oder höher aktualisiert werden, um die Funktion verwenden zu können (sofern nicht anderweitig angegeben).
  • Damit die erweiterten Bereitstellungskonfigurationen unterstützt werden, gibt der Pod-Bereitsteller Optionen für Folgendes an:
    • Verwenden eines separaten VNet für die Unified Access Gateway-Instanzen der externen Gateway-Konfiguration, das vom VNet des Pods und den Core-Pod-Elementen getrennt ist. Die VNets müssen über Peering miteinander verbunden sein.
    • Verwenden Sie ein separates Abonnement für die externe Unified Access Gateway-Konfiguration, getrennt vom Abonnement, das für die Core-Pod-Elemente verwendet wird. Da ein VNet auf ein Abonnement beschränkt ist, entspricht das separate Abonnement-Bereitstellungsszenario auch dem separaten VNet-Szenario. Die VNets müssen über Peering miteinander verbunden sein.
    • Damit ein vorhandener Pod diese Funktion nutzen kann, muss der Pod zunächst auf das Manifest 1763.0 oder höher aktualisiert werden. Anschließend müssen Sie alle dokumentierten Anforderungen zur Verwendung eines separaten VNet für die externe Gateway-Konfiguration erfüllen, einschließlich der Verbindung dieses VNet mit dem VNet des Pods über Peering. Dann müssen Sie die vorhandene externe Unified Access Gateway-Konfiguration des Pods löschen, indem Sie den Workflow der Konsole zum Löschen des vorhandenen externen Gateways verwenden. Wenn der Löschvorgang erfolgreich abgeschlossen wurde, können Sie den Workflow Pod bearbeiten ausführen, um wieder ein externes Gateway mithilfe der neuen Optionen hinzuzufügen.
  • Ab dem Manifest dieser Version können Sie SSD-Festplattentypen für VDI-Desktop-Zuweisungen und RDSH-Farmen verwenden.
  • Ab dem Manifest dieser Version können Sie die Betriebssystem-Festplattengrößen für VDI-Desktop-Zuweisungen und RDSH-Farmen anpassen. Bei früheren Pod-Manifesten wurden die Betriebssystem-Festplattengrößen so festgelegt, dass sie mit dem Basisimage identisch waren. Die Standardeinstellung war 127 GB und konnte nicht geändert werden.
  • Neu in dieser Version wird im Assistenten zum Importieren einer VM vom Download-Center eine Umschaltoption angezeigt, um die Verbindung der resultierenden VM mit einer Active Directory-Domäne auszulassen. Bisher wurde die VM mit diesem Workflow standardmäßig der Domäne hinzugefügt, und Sie konnten dieses Verhalten nicht ändern. Diese neue Umschaltoption ist für vorhandene Pods vor der Manifest-Version dieser Version verfügbar.
  • Mit der Neugestaltung der Seite „Kapazität“ in dieser Version wird die Ansicht „Typ“ entfernt. Nach dem Entfernen der Ansicht „Typ“ von der Seite „Kapazität“ sind zwei Änderungen bei Elementen zu beachten, auf die zuvor von dieser Ansicht aus zugegriffen wurde: Die Aktion zum Anzeigen der aktuellen Nutzung der Microsoft Azure-Grenzwerte durch den Pod wurde auf die Detailseite des Pods verschoben, und die Aktion Abonnement entfernen, die in dieser Ansicht vorhanden war, wurde vollständig entfernt.
Weitere Hinweise für aktuelle Kunden
  • Verbesserungen bei den Berichten, die über die Seite „Berichte“ der Verwaltungskonsole verfügbar sind. Die Daten in diesen Berichten werden vom Cloud-Überwachungsdienst bereitgestellt.
  • Verbesserungen auf der Seite „Kapazität“ der Horizon Cloud-Verwaltungskonsole. Anstatt einen Drilldown für die Detailseite eines Pods durchzuführen, um die konfigurierbaren Details des Pods zu ändern oder einen Pod aus Ihrer Mandantenumgebung zu löschen, können Sie jetzt den Pod zum Bearbeiten starten und die Pod-Workflows von der Seite „Kapazität“ selbst entfernen. Als Folge dieser Neugestaltung sind die Workflows zum Ändern von Standortinformationen, die zuvor mithilfe der Standortansicht der Seite „Kapazität“ durchgeführt wurden, jetzt Optionen innerhalb der Workflows „Pod zum Bearbeiten“. Um beispielsweise einen neuen Ortsnamen anzugeben, verwenden Sie die Aktion Bearbeiten für einen Pod und Sie können einen neuen Ortsnamen als Option für den entsprechenden Workflow „Pod Bearbeiten“ angeben. Beachten Sie, dass der vorherige Workflow für die Ansicht eines Orts zum Entfernen gespeicherter Microsoft Azure-Abonnementinformationen nicht mehr verfügbar ist, wenn alle zugeordneten Pods des Abonnements gelöscht wurden.
  • Der frühere Produktname „VMware Identity Manager“ wurde jetzt in „VMware Workspace ONE™ Access“ geändert.
  • Der Horizon Agents Installer installiert keinen inaktiven DaaS Agent mehr. In der vorherigen Version hat die HAI die MSI des DaaS Agent auf dem Gastbetriebssystem installiert, sie war jedoch inaktiv und wurde nicht verwendet. In dieser Version ist die MSI-Version überhaupt nicht installiert.

September 2019 – v2.1

Verwenden Sie die folgenden Informationen, wenn Sie über cloudverbundene Pods vor September 2019 verfügen und wenn Sie die Auswirkungen der Funktionen nachvollziehen möchten, die unter „Neuigkeiten“ der Versionshinweise vom September 2019 beschrieben sind.

Speziell für vorhandene cloudverbundene Horizon-Pods
Neu in dieser Version:
  • Die automatische Aktualisierung wird jetzt von den Cloud Connector-Versionen 1.3 und 1.4 unterstützt. Es wird empfohlen, dass Kunden mit früheren Versionen von Cloud Connector eine Aktualisierung auf die neueste Version durchführen, um diese Funktion nutzen zu können.
  • Die Cloudüberwachungsdienste (Cloud Monitoring Services, CMS) mit Details über die Sitzungsnutzung werden als Teil von Horizon Cloud Service bereitgestellt.
Speziell für vorhandene Pods in Microsoft Azure
Für die folgenden neuen Funktionen, die im Abschnitt „Neuigkeiten“ des Dokuments „Versionshinweise“ vom September 2019 beschrieben sind und die für einen bereits vorhandenen Pod verwendet werden sollen, muss dieser Pod zunächst auf die Manifestversion 1600.0 oder höher aktualisiert werden, um die Funktion verwenden zu können (sofern nicht anderweitig angegeben).
  • Die Pod-Architektur wurde in dieser Version geändert. Alle Pods in der Manifestversion vom September 2019 verfügen über einen Microsoft Azure-Lastausgleichsdienst für den Pod und eine Microsoft Azure-Datenbank für die PostgreSQL-Serverinstanz (optimierte Ebene für Gen 5-Arbeitsspeicher). Dies bedeutet, dass Sie vor der Aktualisierung Ihrer vorhandenen Pods auf die Manifestversion dieser Version sicherstellen müssen, dass Ihre vorhandene Netzwerkkonfiguration die DNS, Ports und Protokolle aufweist, die für den Microsoft Azure-Lastausgleichsdienst für den Pod und die Microsoft Azure-Datenbank für die PostgreSQL-Serverinstanz erforderlich sind. Wenn Sie über Firewalls oder Netzwerksicherheitsgruppen verfügen, die bestimmte Ports und Protokolle blockieren, vergleichen Sie Ihre aktuelle Netzwerkkonfiguration mit den Informationen aus den folgenden Themen und aktualisieren Sie Ihre Netzwerkkonfiguration dementsprechend.
  • In dieser Version existieren verbesserte Warnungen für Pod-Aktualisierungsfehler, für deren Behebung eine Aktion durch den Kunden erforderlich ist. Einige vollständig von Ihnen gesteuerte Faktoren, können eine erfolgreiche Pod-Aktualisierung verhindern, z. B. wenn nicht genügend Kerne im zugeordneten Abonnement des Pods vorhanden sind, um die Jump-Box-VM zu erstellen, die die Pod-Aktualisierung orchestriert. Ab dieser Version werden solche Elemente in der Konsole angezeigt, sodass Sie diese Elemente beheben und löschen können.
  • Ab dieser Version können Sie die folgenden gateway-bezogenen Einstellungen auf einem bereits bereitgestellten Pod überarbeiten: Zwei-Faktor-Authentifizierungseinstellungen zu einem Gateway hinzufügen, das Sie nicht hat, Zwei-Faktor-Authentifizierungseinstellungen eines Gateways bearbeiten, die Zeitüberschreitungseinstellungen des Gateways für Broker-Sitzungen ändern. In früheren Versionen mussten Sie die RADIUS-Zwei-Faktor-Authentifizierung bei der ersten Bereitstellung des Pods konfigurieren und konnten diese Einstellungen später nicht ändern. Außerdem können Sie jetzt in dieser Version Gateways aus einem bereits bereitgestellten Pod löschen und einen neuen Pod mit einem externen Gateway bereitstellen, das über keine öffentliche IP-Adresse auf seinem Azure-Lastausgleichsdienst verfügt, sondern stattdessen über eine private IP-Adresse auf diesem Lastausgleichsdienst.
  • Unterstützung für die Definition von Microsoft Azure-Ressourcentags beim Erstellen einer neuen dedizierten oder flexiblen VDI-Desktop-Zuweisung oder einer neuen Farm für Horizon Cloud on Microsoft Azure.
  • Hochverfügbarkeit ist jetzt verfügbar. Zur Unterstützung der Hochverfügbarkeit für Pods in Microsoft Azure wird die Pod-Architektur aktualisiert, damit die Microsoft Azure-Datenbank für den PostgreSQL-Dienst (optimierte Ebene für den aktualisierten Gen 5-Arbeitsspeicher), ein Microsoft Azure-Lastausgleichsdienst und ein Verfügbarkeitssatz verwendet werden. Für einen in dieser Version neu bereitgestellten Pod haben Sie die Möglichkeit, die Hochverfügbarkeit direkt bei der Bereitstellung oder später zu aktivieren. Damit Sie die Hochverfügbarkeit für bereits vor dieser Version vorhandene Pods aktivieren können, müssen Sie diese zunächst auf die Manifestversion 1600.0 oder höher aktualisieren und ebenfalls die Agents in den Images, Farmen und VDI-Desktop-Zuweisungen des Pods auf diese Version aktualisieren. Nach Abschluss der Pod-Aktualisierung und der Agent-Aktualisierungen, können Sie die Hochverfügbarkeit auf dem Pod aktivieren, indem Sie den Pod über die zugehörige Pod-Detailseite in der Verwaltungskonsole bearbeiten. Bei dieser neuen Funktion ergeben sich zusätzliche Anforderungen für die Aktivierung des Microsoft.SQL-Dienst-Endpoints im Management-Subnetz des Pods, wenn Ihr Pod von Ihnen erstellte Subnetze verwendet sowie für das Zulassen des ausgehenden Zugriffs für Port 5432.

    Zum Zeitpunkt September 2019 wurde die Funktion „Hochverfügbarkeit (HA)“ für Pods in Microsoft Azure nur für Pods unterstützt, die in den kommerziellen Microsoft Azure-Regionen bereitgestellt werden (globale Standardregionen). Die HA-Funktion des Pods wird derzeit nicht für in Microsoft Azure China, Microsoft Azure Deutschland und Microsoft Azure Government (US Gov Virginia, US Gov Arizone, US Gov Texas) bereitgestellte Pods unterstützt. Das VMware-Team arbeitet daran, Unterstützung für die HA-Funktion für Pods in diesen zuvor aufgelisteten Cloud-Umgebungen hinzuzufügen. Wenn Sie über einen vorhandenen Pod in Microsoft Azure in China, Microsoft Azure Deutschland oder Microsoft Azure Government verfügen, den Sie ohne die HA-Funktion auf die Manifestversion dieser Version aktualisieren möchten, wenden Sie sich an Ihren VMware-Vertreter, um Unterstützung zu erhalten.

    Bevor Sie einen vorhandenen Pod in einer der globalen Standardregionen von Microsoft Azure auf Manifest 1600 oder höher aktualisieren, müssen Sie sicherstellen, dass die folgenden Aspekte erfüllt sind, da die neue Pod-Architektur die Microsoft Azure-Datenbank für den PostgreSQL-Dienst verwendet:

  • Um die Stabilität des Horizon Agent-Paarbildungsprozesses zu erhöhen, werden in dieser Version die DaaS Agent-Funktionen in Horizon Agent verschoben. Der DaaS Agent wurde jetzt in Horizon Agent integriert. Obwohl der DaaS Agent sowohl beim automatisierten Workflow „Image importieren“ als auch bei der manuellen Installation des Horizon Agents Installer wie in früheren Versionen im Gastbetriebssystem installiert wird, ist der DaaS Agent ab dieser Version inaktiv und wird nicht verwendet. Der Dienst für den DaaS Agent wird jedoch weiterhin in der Liste der Windows-Dienste angezeigt. Starten Sie diesen Dienst nicht oder es könnten unerwartete Ergebnisse auftreten.
  • Durch das Verschieben der DaaS Agent-Funktionen in den Horizon View-Agent wurden sowohl der automatisierte Image-Import aus dem Azure Marketplace-Workflow als auch die Schritte zum manuellen Erstellen einer Basis-VM geändert. Zuvor wurde die aus dem automatisierten Workflow entstandene Basis-VM am Ende des Workflows mit der Cloud gekoppelt, während Sie bei einer manuell erstellten VM manuell einen Bootstrap durchführen und die VM koppeln mussten. Jetzt wird für Basis-VMs in einem neuen oder auf diese Version aktualisierten Pod die entstandene Basis-VM auf der Seite „Importierte VMs“ mit dem Agentenstatus „Nicht gepaart“ aufgeführt. Um die VM zu koppeln, können Sie Folgendes tun:
    • Wenn Sie die auf der Seite „Importierte VMs“ aufgeführte VM vor der Anpassung mit der Cloud koppeln wollen, führen Sie auf ihr die Aktion Agentenpaarbildung zurücksetzen aus.
    • Wenn die VM über alle gewünschten Anpassungen verfügt und Sie bereit sind, sie zu veröffentlichen, führen Sie die Aktion Neues Image direkt auf der VM aus. In diesem Fall führt der Workflow „Neues Image“ zuerst den Paarbildungsvorgang aus, um den Agenten zu aktivieren. Anschließend können Sie die restlichen Felder ausfüllen und auf Veröffentlichen klicken, um das Image zu veröffentlichen.
  • Durch die Verschiebung der DaaS Agent-Funktionen in den Horizon View-Agenten ist der Workflow „Agent-Paarbildung zurücksetzen“ nun für die Verwendung bei importierten VMs, Farm-Server-VMs und Desktop-VMs in dedizierten VDI-Desktop-Zuweisungen verfügbar. Wenn in den Details einer Farm oder einer dedizierten VDI-Desktop-Zuweisung ein Fehlerzustand in der Spalte „Agent-Status“ für eine Farm-Server-VM oder Desktop-VM angezeigt wird, können Sie in der Konsole die Aktion Agent-Paarbildung zurücksetzen verwenden, um den Paarbildungszustand dieser VM zu reparieren. (Die Aktion ist nicht für flexible VDI-Desktop-Zuweisungen verfügbar.) Auf der Seite „Importierte VMs“ können Sie die Aktion Agent-Paarbildung zurücksetzen verwenden, um eine bis jetzt noch nicht gepaarte VM zu paaren oder den Paarbildungstatus für eine zuvor gepaarte VM zu reparieren.
  • Die Funktion für die Festplattenverschlüsselung verwendet jetzt die neuere AzureDiskEncryption v 2.2. Diese neuere Version ermöglicht die Unterstützung der Festplattenverschlüsselung für VMs mit einem im Gastbetriebssystem eingerichteten Proxy, um mit dem Internet zu kommunizieren. Um diese neue Unterstützung zu nutzen, müssen Sie die Agents Ihrer VMs auf Version 19.3.0 oder höher aktualisieren.
  • Aktualisierte Anleitung zur Verwendung von VM-Modellen mit mindestens zwei (2) CPUs für Ihre Farmen und VDI-Desktop-Zuweisungen. VMware Scale-Tests haben gezeigt, dass durch die Verwendung von mindestens 2 CPUs für Produktionsumgebungen unerwartete Probleme bei der Endbenutzerverbindung vermieden werden. Auch wenn das System Sie nicht daran hindert, ein VM-Modell mit einer einzelnen CPU auszuwählen, sollten Sie diese VM-Modelle nur für Tests oder Machbarkeitsnachweise verwenden.
  • Verbesserungen der Benutzerfreundlichkeit der Seite „VM-Typen und -Größen“.
Weitere Hinweise für aktuelle Kunden
  • Verbesserte Benutzerfreundlichkeit und Optimierung der interaktiven Zuordnungsansicht des Unified Dashboards, einschließlich einer genaueren Entsprechung des Pod-Standorts und der Zoomfunktionalität.
  • Verbesserungen bei den Berichten, die über die Seite „Berichte“ der Verwaltungskonsole verfügbar sind. Die Daten in diesen Berichten werden vom Cloud-Überwachungsdienst bereitgestellt.
  • Bei mit der Cloud verbundenen Horizon 7-Pods werden zusätzliche Details auf der Detailseite eines Pods angezeigt. Der Pod und der Cloud Connector müssen auf die neueste Version aktualisiert sein, um diese Funktion sehen zu können.
  • Der frühere Produktname „VMware User Environment Manager™“ wurde jetzt zu „VMware Dynamic Environment Manager™“ geändert.