In diesem Thema werden bekannte Probleme aufgelistet, die bei der Verwendung des Diensts und der bekannten Problemumgehungen (sofern vorhanden) auftreten können.

Wichtig: Diese Informationen gelten nur, wenn Sie auf eine First-Gen-Mandantenumgebung in der First-Gen-Steuerungsebene zugreifen können. Wie im KB-Artikel 92424 beschrieben, hat die First-Gen-Steuerungsebene das Ende der Verfügbarkeit (End of Availability, EOA) erreicht. Weitere Informationen finden Sie in diesem Artikel.

Dieses Dokumentationsthema enthält die bekannten Probleme für Horizon Cloud Connector. Auch wenn Sie den Horizon Cloud Connector verwenden, um Horizon-Pods mit dem Horizon Cloud zu verbinden, sollten Sie sich über bekannte Probleme mit der Software in diesen Horizon-Pods in den Versionshinweisen an folgenden Stellen informieren, je nach Softwareversion des Verbindungsservers des Pods:

Informationen zu bekannten IMS-Problemen (Image Management Service), einschließlich IMS-Funktionen, die in der Produktion für alle Horizon Cloud-Kunden zur Verfügung stehen, finden Sie auf der Seite „Bekannte Probleme“ unter Verwalten von Horizon-Images über die Cloud.

Hinweis: Die für jedes bekannte Problem in Klammern angegebenen Zahlen beziehen sich auf interne VMware-Verfolgungssysteme.

Bekannte Probleme in Zusammenhang mit der Anmeldung

Auch wenn Sie erfolgreich ein Kennwort für Ihr My VMware-Konto erstellt haben, das einen umgekehrten Schrägstrich (\) enthält, schlägt die Anmeldung bei Horizon Cloud mithilfe dieser Anmeldedaten fehl (2595757).
Wenn Sie My VMware-Anmeldedaten verwenden, um sich bei Horizon Cloud anzumelden, werden Kennwörter, die einen umgekehrten Schrägstrich enthalten, nicht unterstützt. Wenn Sie die Liste der unterstützten Sonderzeichen anzeigen möchten, melden Sie sich bei „my.vmware.com“ an und navigieren Sie zum Bereich „Kennwort ändern“ Ihres Profils. Auf dieser Seite werden die unterstützten Sonderzeichen angezeigt. Problemumgehung: Setzen Sie das Kennwort Ihres My VMware-Kontos auf ein neues zurück und stellen Sie sicher, dass das neue Kennwort keinen umgekehrten Schrägstrich (\) enthält.

Bekannte Probleme in Zusammenhang mit Active Directory

Die Sperre eines primären Dienstkontos wird nicht erkannt, solange keine Aktion in Verbindung mit Active Directory in der Verwaltungskonsole ausgeführt wird. (2010669)
Aufgrund des vorliegenden Problems wird für einen Administrator, der bei der webbasierten Verwaltungskonsole angemeldet ist, keine Benachrichtigung über die Sperre eines primären Dienstkontos angezeigt, solange in der Benutzeroberfläche keine Aktion in Verbindung mit Active Directory durchgeführt wird, z. B. eine Suche in Active Directory zum Hinzufügen von Benutzern zu Zuweisungen. Die zugrunde liegenden Dienste erkennen ein gesperrtes Dienstkonto nur, wenn sie eine Kommunikationsanforderung an Active Directory entweder zur Authentifizierung oder zur Suche (nach Benutzern oder Gruppen) senden. Problemumgehung: Keine.
Es dauert bis zu 15 Minuten, bis die webbasierte Verwaltungskonsole eine durchgeführte Sperrung oder Entsperrung des primären Domänendienstkontos anzeigt. (2009434)
Das Verbindungsobjekt des Systems zu Active Directory wird immer für 15 Minuten zwischengespeichert. Es kann deshalb 15 Minuten ab dem Zeitpunkt dauern, an dem das primäre Dienstkonto in den gesperrten Zustand wechselt und das System die Benachrichtigung an den Administrator auslöst, bis die Anzeige aktualisiert wird. Umgekehrt kann es, nachdem der Administrator die Sperrbedingung des Kontos aufgehoben hat, bis zu 15 Minuten dauern, bis das System keine Sperrbenachrichtigungen mehr über das nun entsperrte Konto sendet. Problemumgehung: Keine.
Für Farmen in einem Pod in Microsoft Azure kann die Wiederverwendung eines identischen Farmnamens bei einer anderen Domäne in derselben Active Directory-Gesamtstruktur aufgrund von doppelten Dienstanbieternamen (SPNs) beim Domänenbeitritt zu Fehlern führen. (1969172)
Aufgrund einer neuen Funktion für Domänencontroller unter Windows Server 2012 R2 und höher verursacht eine Überprüfung doppelter SPNs auf dem Domänencontroller Fehler beim Domänenbeitritt. Sehen Sie sich hierzu den KB-Artikel 3070083 von Microsoft an. Umgehungen:
  • Vermeiden Sie es, Farmnamen erneut zu verwenden.
  • Deaktivieren Sie die Überprüfung doppelter SPNs in der Active Directory-Domäne, wie im KB-Artikel von Microsoft beschrieben.
Bei Verwendung von Azure AD Domain Services schlägt der Active Directory-Registrierungs-Workflow beim Schritt des Domänenbeitritts mit der Fehlermeldung fehl, dass die Berechtigung „Kennwort zurücksetzen“ fehlt. (2218180)
Das Horizon Cloud-Team hat bestätigt, dass das Hinzufügen der erforderlichen Berechtigungen für das Domänenbeitrittskonto bei der Verwendung von Azure Active Directory(AD)-Domänendiensten mit Ihrem Pod wie bei anderen Active Directory-Domänenbereitstellungen funktioniert. Weitere Informationen finden Sie im Microsoft-Dokumentationsthema Erstellen einer Organisationseinheit (OE) in einer durch Azure AD Domain Services verwalteten Domain. In diesem werden die integrierten Container-AADDC-Computer beschrieben. Beachten Sie auch den Hinweis „Wichtig“ zur Aktivierung der Kennwort-Hashsynchronisierung mit Azure AD Domain Services zu Beginn dieses Themas. Bevor Sie die Berechtigungen für das Domänenbeitrittsdienstkonto festlegen, ist es wichtig, dass Sie die Microsoft-Dokumentation zur Aktivierung der Kennworthashsynchronisierung für Azure AD Domain Services für die Domänenbeitrittsdienstkonten befolgen. Wenn weiterhin ein Fehler bei den Domänenbeitrittsberechtigungen im Workflow „Active Directory registrieren“ auftritt, nachdem Sie die Microsoft-Dokumentation befolgt haben, wenden Sie sich an den VMware-Support und geben Sie die Problemberichtsnummer 2218180 als Referenz an.

Bekannte Probleme im Zusammenhang mit Microsoft Azure-Abonnements

Nach der Verwendung der Horizon Universal Console zur Aktualisierung des geheimen Schlüssels für die Azure-Abonnementeinstellungen eines Pods müssen die Pod-Manager-VMs neu gestartet werden, damit die neuen Anmeldedaten wirksam werden (2979394, 3007687, 3017415)
Aufgrund dieses bekannten Problems wird der neu eingegebene geheime Schlüssel nach dem Bearbeiten und Speichern der Anwendungsschlüssel-Einstellung im Fenster „Abonnement verwalten“ der Konsole erst dann auf den Pod-Manager-VMs wirksam, wenn der Verwaltungsdienst in den Betriebssystemen der VMs neu gestartet wird. Wenn der Verwaltungsdienst nicht neu gestartet wird, schlagen API-Aufrufe, die der Dienst für die Arbeit mit Ressourcen im Abonnement verwendet, fehl. Problemumgehung: Wenn sich Ihr Pod in einer Situation befindet, in der der geheime Schlüssel für das Abonnement aus irgendeinem Grund aktualisiert werden muss, z. B. bei nahendem oder abgelaufenem Ablaufdatum, öffnen Sie bitte eine Serviceanfrage zur Unterstützung durch den VMware Support und die Horizon Cloud Operations-Teams, um sicherzustellen, dass die Abfolge der Schritte erfolgreich durchgeführt wird. Hier ist eine Übersicht der erforderlichen Schritte:
  1. Generieren Sie im Azure-Portal einen neuen geheimen Schlüssel.
  2. Führen Sie in der Horizon Universal Console die Standardschritte aus, um den geheimen Schlüssel zu aktualisieren, der von dem Pod bzw. den Pods verwendet wird, die mit dem alten Schlüssel verknüpft sind, wie auf der Seite Ändern, Modifizieren und Aktualisieren der Abonnementinformationen für bereitgestellte Horizon Cloud-Pods beschrieben.
  3. Bitten Sie den VMware Support, den Neustart des Verwaltungsdiensts in beiden Pod-Manager-VMs durchzuführen.

Der spezifische Befehl zum Neustart des Verwaltungsdiensts kann hier nicht veröffentlicht werden, da nur die VMware-Teams diesen Befehl ausführen können. Diese Teams können auf das interne Problem 3007687-update-9 verweisen.

Bekannte Probleme im Zusammenhang mit Cloud Connector

Der CSMS-Status (Connection Server Monitoring Service) wird im Bereich „Systemzustand“ des Horizon Cloud Connector-Konfigurationsportals als „Nicht bereit“ angezeigt (3236634).
Wie in VMware KB 91124 beschrieben, wird für Horizon Cloud Connector Version 2.3 nach einem Neustart der Horizon Cloud Connector-Appliance oder nach einem Neustart des Kubernetes-Clusters der Appliance der CSMS-Status als Nicht bereit angezeigt.

Dieses Problem ist in Horizon Cloud Connector ab Version 2.4 behoben. Um das Problem in früheren Versionen zu umgehen, befolgen Sie die Schritte in diesem KB-Artikel.

Problem mit dem Ablauf des Zertifikats (3083444)
Es wurde festgestellt, dass ein Zertifikat in den Horizon Cloud Connector-Versionen vor der Version 2.4 ein Jahr nach dem Zeitpunkt der Bereitstellung des Geräts abläuft. Wenn dieses Zertifikat abläuft, kann der Horizon Cloud Connector die Horizon Cloud Control Plane nicht mehr kontaktieren, sodass die von Horizon Cloud Connector bereitgestellten cloudbasierten Dienste nicht mehr funktionsfähig sind. Weitere Informationen und Schritte zur Standardisierung finden Sie im KB-Artikel 90505.

Ab Horizon Cloud Connector Version 2.4 erneuert das System die Zertifikate automatisch vor Ablauf.

Die Hostkonfiguration ohne Proxy, die im Feld „Kein Proxy für“ angegeben ist, wenn die OVF-Vorlage bereitgestellt wird, wird nicht in der bereitgestellten Appliance gespeichert (2454245, 2466306, 2467017, DPM-5388).
Dieses Problem wurde in den Horizon Cloud Connector-Versionen 1.6 und höher behoben. Wenn Sie den Workflow „OVF-Vorlage bereitstellen“ in Ihrer vSphere-Umgebung ausführen, haben Sie die Möglichkeit, eine Hostkonfiguration ohne Proxy im Feld „Kein Proxy für“ anzugeben. Aufgrund dieses bekannten Problems werden die eingegebenen Einstellungen jedoch nicht in den Konfigurationsdateien der bereitgestellten Appliance erfasst. Daher berücksichtigt die bereitgestellte Appliance nicht die angegebene Hosteinstellung ohne Proxy.

Bekannte Probleme im Zusammenhang mit der Gateway-Konfiguration von Horizon Cloud-Pods

Die Funktion der Horizon Universal Console zur Aktivierung von Syslog-Server-Einstellungen in der Gateway-Konfiguration ist standardmäßig deaktiviert. (3005985, 3023935, 3026855)
Aufgrund eines identifizierten Problems mit dem API-Aufruf des Systems zum Aktualisieren der Unified Access Gateway-Konfiguration mit Syslog-Serverinformationen wird die zuvor freigegebene Funktion von der Verwendung in der Konsole deaktiviert. Problemumgehung: Keine.

Bekannte Probleme im Zusammenhang mit Universal Broker

Der Horizon Universal Broker-Client auf dem Horizon Cloud Connector übernimmt keine Proxy-bezogenen Aktualisierungen, die Sie in der Connector-Appliance nach der anfänglichen Bereitstellung der Appliance vornehmen (HD-35551).
Dieses Problem wurde in den Horizon Cloud Connector-Versionen 1.6 und höher behoben. Der Horizon Universal Broker-Client in der Connector-Appliance nimmt während des erstmaligen Starts der Appliance Proxy-Details auf. Da der erstmalige Start nur während des ersten Einschaltens der Appliance nach der Bereitstellung der OVF-Vorlage ausgeführt wird, werden alle nachfolgenden Änderungen an den Proxy-Konfigurationseinstellungen der Appliance nicht vom Horizon Universal Broker-Client übernommen. Wenn Sie dieses bekannte Problem zusammen mit dem obigen bekannten Problem bezüglich der Konfiguration ohne Proxy während der Bereitstellung der OVF-Vorlage berücksichtigen, bedeutet dies, dass alle Hosts, die sich auf Horizon Universal Broker beziehen, nicht als Hosts ohne Proxy festgelegt werden können.
Die Fehlermeldung „Fehler beim Herstellen einer Verbindung zum Verbindungsserver“ wird angezeigt, wenn Ihr Horizon Client oder Horizon HTML Access im Browser beginnt, eine Verbindung zum Universal Broker herzustellen (2714266)
Dieses Problem betrifft Horizon Cloud-Pods in Microsoft Azure, auf denen Manifest 2632.x ausgeführt wird, in Mandanten, die für die Verwendung von Universal Broker zur Vermittlung von Endbenutzer-Desktops konfiguriert sind. Eine weitere Erscheinungsform dieses Problems ist, dass beide folgenden Dinge gleichzeitig auftreten können:
  • Auf der Pod-Detailseite für den Pod, in dem sich die Desktop-VM befindet, sehen Sie, dass die Integrität der Pod-Manager-VM als Fehler für alle Pod-Manager-VMs des Pods gemeldet wird.
  • Die Fehlermeldung „Dieser Desktop ist derzeit nicht verfügbar. Versuchen Sie später noch einmal, sich mit diesem Desktop zu verbinden, oder wenden Sie sich an Ihren Systemadministrator.“ wird angezeigt, wenn der Horizon Client oder Horizon HTML Access im Browser beginnt, sich mit dem Universal Broker zu verbinden.
Dieses Problem tritt unter Umständen zeitweise bei Horizon Cloud-Pods in Microsoft Azure unter Manifest 2632.x auf, wenn die Pod-Manager-Instanz neu gestartet wurde. Wenn die Pod-Manager-Instanz neu gestartet wurde (eine seltene, untypische Situation), kann der Universal Broker nach dem Einschalten der Pod-Manager-Instanz und dem Versuch, sich mit dem Pod zu verbinden, gelegentlich keine authentifizierte Verbindung herstellen. Problemumgehung: Keine. Wenn Sie auf diese Situation stoßen, öffnen Sie eine Service-Anfrage und geben Sie die interne Problemberichtsnummer 2714266 an.

Für Pods mit Manifest 2747.x und höher wurde dieses Problem behoben.

Bekannte Problem im Zusammenhang mit Images, Farmen und Zuweisungen

Die hier aufgeführten bekannten Probleme beziehen sich auf in Microsoft Azure bereitgestellte Pods.

Während des Image-Veröffentlichungsprozesses tritt ein Zeitüberschreitungsfehler auf, und die VM bleibt eingeschaltet und verhindert, dass der Veröffentlichungsablauf erfolgreich abgeschlossen wird (2954270, 2962049)
Dieses Problem ist das Ergebnis eines Problems im Microsoft Azure-Hypervisor, das auftritt, wenn der Sysprep-Schritt des Veröffentlichungsprozesses ausgeführt wird. Das Problem tritt bei einigen Azure-VM-Modellen auf. Weitere Informationen finden Sie im VMware-Knowledgebase-Artikel KB88343.

Basierend auf der Empfehlung des Microsoft Azure-Teams wird zur Bereitstellung einer Lösung für Horizon Cloud-Kunden das standardmäßige Azure-VM-Modell, das vom automatisierten VM-Import-Assistenten des Diensts verwendet wird, in der Version v2204 des Diensts geändert, um das Standard_DS2_v2-Modell für den automatisierten Import von Nicht-GPU-Windows 10-VMs (sowohl Einzelsitzungen als auch Mehrfachsitzungen) zu verwenden:

  • Für Einzel-Pod-Images wird das Standard-VM-Modell der Automatisierung von dem zuvor verwendeten Standard_D4_v3-VM-Modell in Standard_DS2_v2 geändert.
  • Für Multi-Pod-Images wird das Standard-VM-Modell der Automatisierung von dem zuvor verwendeten Standard_D2_v2-Modell in Standard_DS2_v2 geändert.

Ab der Version v2204 schließen Sie das Kontingent für die Azure DSv2-Serie in die Azure-Abonnements Ihres Pods ein.

VMs und ihre zugehörigen Ressourcen werden im Microsoft Azure-Abonnement möglicherweise nicht vollständig gelöscht. (2824239, 2681761, 2750176)
Dieses Problem wurde für die Pod-Manifeste 2915.x oder höher behoben. Wenn dieses Problem in Pods früherer Manifeste auftritt, können Probleme wie die Erweiterung von VDI-Zuweisungen auftreten. Dieses Problem ist auf ein Problem im Azure Resource Manager (ARM) von Microsoft und Verzögerungen bei der Replizierung des Ressourcenstatus in mehreren Regionen der Microsoft Azure-Cloud zurückzuführen. Aufgrund dieses Microsoft ARM-Problems werden einige dieser VM-bezogenen Ressourcen möglicherweise nicht gelöscht und sind daher nicht an eine VM im Azure-Abonnement angehängt. Beispiele für solche nicht angehängten Elemente sind Festplatten und Netzwerkkarten. Problemumgehung: Dieses Problem wurde für Pods mit Manifesten der Version 2915.x oder höher behoben. Wenn dieses Problem auftritt, reichen Sie bitte eine Service-Anfrage (Service Request, SR) ein, um Unterstützung beim Löschen der veralteten Daten anzufordern und Ihr Pod-Upgrade zu planen, um ein erneutes Auftreten des Problems zu verhindern. Weitere Informationen zum Einreichen einer Service-Anfrage finden Sie im KB-Artikel 2006985.
Bei Pods, die in Abonnements der Microsoft Azure Government-Cloud bereitgestellt werden, schlägt die Verwendung der Festplattenverschlüsselungsfunktion in Farm- und Desktop-Zuweisungen fehl. (2572579)
Wenn sich Ihr Pod in einer Microsoft Azure Government-Cloud befindet und Sie versuchen, eine Farm- oder VDI-Zuweisung mit ausgewählter Festplattenverschlüsselungsfunktion zu erstellen, schlägt der Erstellungsprozess mit dem Fehler Azure error encrypting the VM fehl. Problemumgehung: Keine.
Auf der Registerkarte „Server“ für eine vorhandene Farm erscheint für alle Auswahloptionen für den Benutzeranmeldemodus eine Fehlermeldung, die besagt, dass der Horizon Agent aktualisiert werden muss. (2528295)
Ob die Verwaltungskonsole zum Einrichten des Benutzeranmeldemodus verwendet werden kann, hängt davon ab, ob erkannt wird, dass in der Farm-VM die Agent-Version 20.1.0 ausgeführt wird. Diese Version des Agents ist jedoch möglicherweise noch nicht in der Cloud-Steuerungsebene verfügbar, um sie für die Aktualisierung der Agents in den vorhandenen VMs der Farm zu verwenden. Problemumgehung: Keine. Wenn die 20.1.0-Version des Agenten in der Cloud-Ebene verfügbar ist und Ihre Pods auf die Manifest-Version aktualisiert werden, die diese Agentenversion nutzen kann, können Sie die Farm-VMs auf diesen Agent aktualisieren, um die Optionen für den Anmeldemodus des Benutzers zu verwenden.
Einige Desktop-VMs aus einer großen flexiblen VDI-Desktop-Zuweisung melden manchmal einen unbekannten Agent-Status. (DPM-3201)
Bei flexiblen VDI-Desktop-Zuweisungen mit einer großen Anzahl von Desktop-VMs kann aufgrund eines bekannten Problems eine kleine Anzahl dieser Desktop-VMs in einen unbekannten Agent-Status wechseln, da einige Windows-Dienste, wie der Horizon Agent-Blast-Dienst oder der Microsoft Azure-Dienst, nicht gestartet oder langsam gestartet werden. Infolgedessen wird in der Verwaltungskonsole in der Spalte „Agent-Status“ für diese Desktop-VMs der Status „Unbekannt“ mit Agent-Fehlermeldungen angezeigt. Problemumgehung: Verwenden Sie in der Konsole die Aktion Neustart, um diese VMs neu zu starten.
Der Assistent zum Importieren von VMs aus Marketplace erstellt Windows Server 2012-Images ohne aktivierte Desktopdarstellung. (2101856)
Wenn Sie den automatisierten Assistenten zum Importieren von VMs aus Marketplace verwenden, um ein Image mit einem Windows Server 2012-Betriebssystem zu erstellen, ist die Desktopdarstellung für das resultierende Image aufgrund eines bekannten Problems nicht aktiviert. Problemumgehung: Wenn Sie möchten, dass die Desktopdarstellung für das resultierende Image aktiviert ist, müssen Sie die Desktopdarstellung im resultierenden Image manuell aktivieren. Beachten Sie auch, dass für das Windows Server 2012-Betriebssystem die Desktopdarstellung im Betriebssystem aktiviert sein muss, um Horizon Agent mit der Option für die Scanner-Umleitung zu installieren.
Wenn Sie eine importierte virtuelle Maschine veröffentlichen (der Vorgang wird auch als Versiegeln bezeichnet), kann es aufgrund von Sysprep-Fehlern bei dem Vorgang zu einer Zeitüberschreitung oder anderen Veröffentlichungsfehlern kommen. (2036082, 2080101, 2120508, 2118047)
Nachdem Sie in einer importierten virtuellen Maschine auf Zu Desktop konvertieren und Veröffentlichen geklickt haben, um diese in ein veröffentlichtes (versiegeltes) Image zu konvertieren, werden auf der virtuellen Maschine eine Reihe von Vorgängen durchgeführt. Zu diesen Vorgängen zählen unter anderem der Sysprep-Vorgang zur Windows-Systemvorbereitung sowie das Herunterfahren und Ausschalten der virtuellen Maschine. Aufgrund branchenbekannter Probleme mit dem Sysprep-Vorgang von Windows und dem Anpassen virtueller Maschinen schlägt der Veröffentlichungsvorgang manchmal aus unterschiedlichen Gründen fehl. Auf der Seite „Aktivität“ werden Meldungen angezeigt, dass ein Zeitüberschreitungsfehler aufgetreten ist, weil 20 Minuten auf das Ausschalten der virtuellen Maschine gewartet wurde. Es wird auch eine weitere Meldung zu Sysprep-Fehlern angezeigt.

Sie können solche Sysprep-Probleme im Allgemeinen vermeiden, indem Sie bei der Erstellung der VM den Assistenten zum Importieren von virtuellen Maschinen aus Marketplace verwenden und für die Umschaltoption Windows-Image-Optimierung des Assistenten Ja auswählen. Wenn dieser Fehler für eine importierte VM angezeigt wird, bei der Sie diese Option nicht verwendet haben, oder Sie diese VM manuell erstellt haben, finden Sie unter Microsoft KB 2769827, Microsoft MVP-Artikel 615 Informationen zu bewährten Methoden beim Konfigurieren Ihrer Image-VM, um die Wahrscheinlichkeit von Sysprep-Problemen zu verringern, wenn Sie das Image veröffentlichen. Wenn Sie weiterhin Probleme mit Sysprep erhalten, lesen Sie die Informationen in den Artikeln Festlegen der Windows-Image-Optimierung beim Verwenden des Assistenten zum Importieren einer virtuellen Maschine aus Marketplace und Verwenden der Option zum Entfernen von Windows Store-Apps, um Informationen zu den Methoden zu erhalten, die der Assistent zum Importieren von VMs aus Marketplace zum Reduzieren der Änderungen von Sysprep-Problemen anwendet. Wenn die Zeitüberschreitungsfehler auf der Seite „Aktivität“ angezeigt werden, können Sie diese Problemumgehung ausprobieren: Verwenden Sie auf der Seite „Images“ für das Image die Aktion Image zu Desktop konvertieren. Wenn die Seite „Aktivität“ anzeigt, dass die Konvertierung des Image in einen Desktop erfolgreich war, wechseln Sie zur Seite „Importierte VMs“. Stellen Sie eine Verbindung mit der VM her und wenden Sie die Best Practices an, die in den KBs beschrieben sind. Nach dem Anzeigen der Seite „Importierte VMs“ wird die VM eingeschaltet. Wählen Sie die VM aus und klicken Sie auf In Image konvertieren aus, um den Veröffentlichungsprozess erneut auszuführen.

Während der Erstellung einer Farm bleiben die Server-VMs manchmal beim Anpassungsschritt hängen. (2010914, 2041909)
Manchmal verhindert während eines Sysprep-Vorgangs auf den Server-VMs einer Farm ein Windows-Dienst mit dem Namen tiledatamodelsvc den Zugriff von Sysprep auf Windows-Dateien, die zum Abschluss der Sysprep-Anpassung erforderlich sind. Als Folge davon verbleiben die Server-VMs der Farm im Anpassungsschritt. Das Sysprep-Fehlerprotokoll enthält dann die Zeile „Error SYSPRP setupdigetclassdevs failed with error 0“ (Fehler SYSPRP setupdigetclassdevs mit Fehler 0 fehlgeschlagen). Problemumgehung: Wenn dieses Problem auftritt und diese Fehlermeldung in der Sysprep-Fehlerprotokolldatei angezeigt wird, versuchen Sie, den Dienst tiledatamodelsvc anzuhalten und im Image zu deaktivieren. Erstellen Sie dann die Farm.
Als Agent-Status wird auf der Seite „Importierte VMs“ manchmal „Nicht definiert“ angezeigt, nachdem ein Image dupliziert oder manuell in Microsoft Azure erstellt wurde. (2002798)
Wenn Sie mit der Schaltfläche Duplizieren auf der Seite „Images“ ein veröffentlichtes Image klonen oder eine Image-VM manuell in Microsoft Azure erstellen, wird die daraus resultierende virtuelle Maschine auf der Seite „Importierte VMs“ aufgeführt. Aufgrund des vorliegenden Problems wird dann, auch wenn die virtuelle Maschine vollständig eingeschaltet ist, der Agent-Status manchmal als „Nicht definiert“ angezeigt. Wenn Sie allerdings die virtuelle Maschine auswählen und „In Image konvertieren“ für ihre Veröffentlichung auswählen, wird in der Benutzeroberfläche für den Agent der Status „Aktiv“ angezeigt. Problemumgehung: Keine. Wenn die Workflows Agentenpaarbildung zurücksetzen, Neues Image oder In Image konvertieren den Agenten als „Aktiv“ anzeigen, können Sie den Status „Nicht definiert“ auf der Seite „Importierte VMs“ ignorieren.

Bekannte Probleme mit App Volumes auf Pods in Microsoft Azure

Die hier aufgeführten bekannten Probleme beziehen sich auf in Microsoft Azure bereitgestellte Pods.

Das Hochladen von Anwendungspaketen (.vhd-Dateien) mit demselben Dateinamen an denselben Speicherort (Dateifreigabe), die zu unterschiedlichen Zeiten erfasst werden, kann verhindern, dass der App Volumes-Dienst Anwendungen an die VDI-Desktops anhängt, wenn sich der Benutzer anmeldet (2783560)
Jedes Mal, wenn App Volumes ein Anwendungspaket (.vhd -Datei) erfasst, generiert das System eine eindeutige GUID, um das Volume oder die Erfassungssitzung zu identifizieren. Wenn Sie versuchen, ein Anwendungspaket in die Staging-Dateifreigabe von Horizon Cloud Azure-Pods mit einem (.vhd) Dateinamen hochzuladen, der zuvor hochgeladen wurde, tritt eine Nichtübereinstimmung zwischen den GUIDs auf, die bereits in den Horizon Cloud Azure-Pods und den Cloud-Diensten vorhanden sind.

Der App Volumes Manager-Dienst, der auf den Horizon Cloud Azure-Pods ausgeführt wird, importiert in regelmäßigen Abständen die Anwendungspakete aus der Dateifreigabe. Wenn Sie versuchen, die Anwendungen von der Import-Seite „Bestand > Anwendungen“ der Horizon Universal Console zu importieren, stimmen neu importierte Anwendungspakete und ihre entsprechenden GUIDs nicht mit den GUIDs überein, die im App Volumes Manager-Dienst vorhanden sind, der die Horizon Cloud Azure-Pods ausführt. Aufgrund dieser Nichtübereinstimmung werden zugewiesene Anwendungen nicht an die berechtigten Benutzer angehängt.

Das Entfernen einiger Benutzer oder Gruppen aus einer App Volumes-Zuweisung in der Konsole entfernt möglicherweise die Berechtigungen von einigen der verbleibenden Benutzer oder Gruppen in der Zuweisung (2704889).
Aufgrund dieses Problems kann es in dem Szenario, in dem Sie eine App Volumes-Zuweisung erstellt haben, die eine Reihe von Anwendungen und bestimmte Benutzer oder Gruppen enthält, und in dem Sie dann diese Zuweisung bearbeiten und einige dieser spezifischen Benutzer oder Gruppen entfernen, dazu kommen, dass für einige der Benutzer und Gruppen, die in dieser Zuweisung konfiguriert bleiben, die Anwendungen in ihren berechtigten Desktops nicht angezeigt werden.

Obwohl dieses Problem in Pod-Manifest 2747 und höher behoben ist, kann es in Pods früherer Manifestversionen auftreten. Wenn Sie auf dieses Problem stoßen, können Sie es umgehen, indem Sie eine neue App Volumes-Zuweisung mit den erforderlichen Anwendungen und Benutzern und Gruppen erstellen und die zuvor erstellte App Volumes-Zuweisung löschen.

Wenn Ihre Umgebung über mehrere Pods in Microsoft Azure verfügt, kann der Erfassungsvorgang manchmal in einen unbekannten Zustand versetzt werden, wenn der Vorgang abgeschlossen ist. (2600573)
Wenn Ihre Umgebung über mehrere Pods verfügt, für die Sie App Volumes verwenden, weist die Konsole manchmal nach dem Erfassungsvorgang an, dass sich die Erfassung in einem unbekannten Zustand befindet, obwohl der Erfassungsvorgang auf der VM abgeschlossen ist. Um dieses Problem zu umgehen, importieren Sie das Anwendungspaket über Bestand > Anwendungen > Neu > Importieren neu. Dies führt dazu, dass das Anwendungspaket erfolgreich als eine gesonderte Anwendung importiert wird und die anschließende Zuweisung und der anschließende Anwendungsstart funktionieren.
In einer Microsoft Windows 10 Enterprise-Mehrfachsitzungsbereitstellung wird ein Druckauftrag möglicherweise abgebrochen, wenn sich ein anderer Benutzer an demselben Gerät anmeldet.
Wenn sich in dieser Umgebung ein Benutzer mit einer App-Paket-Zuweisung, die einen Druckertreiber enthält, zum ersten Mal anmeldet, kann ein laufender Druckauftrag für einen anderen Benutzer auf diesem Mehrfachsitzungscomputer in einen Fehlerzustand geraten. Um dieses Problem zu umgehen, warten Sie nach Beendigung des Druckauftrags einige Minuten oder länger und versuchen Sie den Druckauftrag erneut. Informationen zu verwandten Best Practices finden Sie in der Anleitung Verwaltung der Horizon Cloud-Mandantenumgebung und Ihrer Flotte von integrierten Pods.
In einer Microsoft Windows 10 Enterprise Mehrfachsitzungsbereitstellung erhalten Benutzer, denen kein App-Paket zugewiesen wurde, Aspekte der Anwendung.

In dieser Umgebung kommt es gelegentlich vor, dass der aktualisierte Teil der Anwendung versehentlich für alle Benutzer (nicht nur für die, denen die Anwendung zugewiesen ist) auf dem Mehrfachsitzungs-Desktop sichtbar wird, wenn Sie die automatischen Updates für eine Anwendung während der Bereitstellung nicht deaktivieren, z. B. in Form einer Desktopverknüpfung und von Anwendungsbinärdateien. Um dieses Problem zu umgehen, fügen Sie bei Anwendungen mit automatischen Aktualisierungsdiensten den Namen des Anwendungsdienstes in die mehrsträngige svservice-Registrierungskonfiguration „DisableAppServicesList“ ein, um sicherzustellen, dass die automatischen Aktualisierungsdienste nicht gestartet werden. Informationen zu verwandten Best Practices finden Sie in der Anleitung Verwaltung der Horizon Cloud-Mandantenumgebung und Ihrer Flotte von integrierten Pods.

Bekannte Probleme im Zusammenhang mit der Agent-Aktualisierung

Die hier aufgeführten bekannten Probleme beziehen sich auf in Microsoft Azure bereitgestellte Pods.

Wenn Sie versuchen, ein Agent-Update auf einem Image durchzuführen, bei dem ein Windows-Update aussteht, kann der Aktualisierungsvorgang fehlschlagen. (2234964)
Wenn bei dem Image ein Update des Windows-Betriebssystems erforderlich ist, kann dies im Gegensatz zu einem kleineren Nicht-Betriebssystem-Update dazu führen, dass die Betriebssystemressourcen offline und für das Agent-Update nicht verfügbar sind. Problemumgehung: Warten Sie, bis das Windows-Update abgeschlossen ist, und versuchen Sie erneut, das Agent-Update durchzuführen. Um zu bestätigen, dass alle Windows-Updates abgeschlossen sind, können Sie das Image offline schalten, alle ausstehenden Updates durchführen und das Image erneut veröffentlichen, bevor Sie das Agent-Update starten.

Bekannte Probleme bei Berichten und Überwachung

Die hier aufgeführten bekannten Probleme beziehen sich auf in Microsoft Azure bereitgestellte Pods.

Im Bericht „Benutzeraktivität“ ist der angezeigte wöchentliche Durchschnitt (Std.) nicht konsistent. (1817065)
Aufgrund dieses Problems schwanken die wöchentlichen statistischen Daten im Zeitablauf, da die Berechnung durch Division der Dauer in der aktuellen Woche durch sieben (7) erfolgt und nicht auf eine ganze Woche aufgerundet wird. Wenn Sie beispielsweise die letzten 30 Tagen auswählen, ändern sich die Daten für die gesamten Wochen nicht. Die Daten für die aktuelle Woche werden aber durch sieben (7) geteilt. Die aktuelle Formel lautet: wöchentlicher Durchschnitt (Std.) = täglicher Durchschnitt (Std.) * 7 Tage. Dies führt zu einem wöchentlichen Durchschnitt der letzten 30 Tage nach der Formel „(Gesamtdauer/30 Tage) * 7 Tage“. Problemumgehung: Keine
Der Bericht „Desktop-Zustand“ zeigt den aktualisierten Namen einer Farm oder einer VDI-Desktop-Zuweisung erst eine Stunde nach der Namensänderung an. (1756889)
Wenn Sie den Namen einer Farm oder einer VDI-Desktop-Zuweisung ändern, wird der neue Name im Bericht „Desktop-Zustand“ erst nach einer Stunde im Dropdown-Menü „Zuweisung“ und in der Spalte „Zuweisung“ angezeigt. Problemumgehung: Warten Sie eine Stunde, denn erst dann wird der Name im Bericht angezeigt.
Die Formatierungen einiger CSV-Dateien, die Sie über UI-Bildschirme der Seite „Berichte“ exportieren können, entsprechen nicht den Tabellen auf dem Bildschirm. (2015500)
Auf einigen untergeordneten Bildschirmen der Seite „Berichte“ steht eine Exportfunktion zur Verfügung, mit der Sie die angezeigten Daten im CSV-Format exportieren können. Aufgrund des vorliegenden Problems entsprechen die Formatierungen der für die Berichte „Desktop-Zustand“, „Parallelität“ und „Sitzungsverlauf“ exportierten CSV-Dateien jedoch nicht exakt den auf dem Bildschirm angezeigten Formatierungen. Die Spaltenüberschriften können beispielsweise voneinander abweichen und die CSV-Dateien haben möglicherweise mehr Spalten an Daten als in den Tabellen auf dem Bildschirm. Problemumgehung: Keine.

Bekannte Probleme im Zusammenhang mit Identitätsmanagement, Workspace ONE Access und True SSO

Die hier aufgeführten bekannten Probleme beziehen sich auf in Microsoft Azure bereitgestellte Pods.

Wenn ein Pod mit Manifestversionen vor Version 1763 auf Manifest 1763 oder höher aktualisiert wird, für diesen Pod Zwei-Faktor-RADIUS auf den zugehörigen Unified Access Gateway-Instanzen konfiguriert ist und er auch in Workspace ONE Access integriert ist, wird beim Starten eines Desktops von Workspace ONE Access mit dem Browser das RADIUS-Anmeldeformular angezeigt, wobei im Feld für den Benutzernamen der UPN des Benutzers eingetragen ist. (2248160)
Dieses Symptom tritt aufgrund einer Änderung auf, die in VMware Horizon HTML Access 4.10 veröffentlicht wurde. Wenn Ihr Pod in Microsoft Azure aus einer vorherigen Horizon Cloud-Version mit Unified Access Gateway-Instanzen und der RADIUS-Zwei-Faktor-Authentifizierung konfiguriert ist und Sie diesen Pod so konfigurieren, dass Workspace ONE Access verwendet wird, wenn Sie einen Desktop von Workspace ONE Access mit dem Browser starten, fordert das RADIUS-Anmeldeformular zur Eingabe des Benutzernamens und der Kennung auf. Der Endbenutzer würde den Benutzernamen und die Kennung in das Formular eingeben. Aufgrund dieses Problems ist jedoch nach dem Upgrade dieses Pod auf diese Version mit den gleichen Schritten zum Starten des Desktops das Feld für den Benutzernamen im RADIUS-Anmeldeformular bereits mit dem UPN des Domänenbenutzers gefüllt. Dieses Verhalten tritt nur auf, wenn Sie den Browser zum Starten des Desktops verwenden. Es tritt nicht auf, wenn Sie Horizon Client verwenden. Problemumgehung: Wenn diese Situation eintritt, kann der Endbenutzer das vorab ausgefüllte Feld für den Benutzernamen löschen und seine Daten eingeben. In den meisten Umgebungen, die in Workspace ONE Access integriert sind, wird die Zwei-Faktor-Authentifizierung generell in Workspace ONE Access und nicht in den zugrunde liegenden Unified Access Gateway-Instanzen konfiguriert. In diesem Fall tritt das Problem nicht auf.
Das Starten eines zweiten Desktops über Workspace ONE Access mit Horizon Client kann mit folgender Fehlermeldung fehlschlagen: „Sie sind für diesen Desktop oder diese Anwendung nicht berechtigt“. (1813881, 2201599)
Dieses Symptom tritt in der folgenden Situation auf. Der Benutzer verfügt über eine Gruppenberechtigung über Berechtigungen für zwei dedizierte VDI-Zuweisungen. Beide dedizierten VDI-Desktopzuweisungen werden in Workspace ONE Access aufgeführt, wenn sich der Benutzer anmeldet. Der Benutzer startet den ersten Desktop mithilfe von Horizon Client. Es wird eine Verbindung zu diesem Desktop hergestellt. Anschließend versucht der Benutzer, den anderen Desktop aus der anderen Zuweisung ebenfalls mit Horizon Client zu starten. Das Starten des anderen Desktops schlägt fehl. In einer Fehlermeldung wird darauf hingewiesen, dass der Benutzer nicht berechtigt ist. Dieses Problem mit dem zweiten Desktop tritt jedoch nur beim ersten Versuch auf. Wenn der Benutzer den zweiten Desktop mit dem Browser startet, sind nachfolgende Versuche zum Starten des zweiten Desktops mit Horizon Client erfolgreich. Problemumgehung: Wenn es zu dieser Situation kommt, versuchen Sie, den zweiten Desktop mit dem Browser zu starten.
Workspace ONE Access zeigt nicht die Anzeigenamen der Remoteanwendungen an, die Sie in der Horizon Cloud-Verwaltungskonsole festlegen. (2131583)
Dieses Problem wurde mithilfe der Workspace ONE Access Connector-Version 19.03 behoben. Aufgrund eines bekannten Problems in den Versionen von Workspace ONE Access Connector vor 19.03 zeigt Workspace ONE Access die für diese Remoteanwendungen in Horizon Cloud festgelegten Anzeigenamen nicht an, wenn in Workspace ONE Access die Remoteanwendungen angezeigt werden, die Sie über Horizon Cloud synchronisieren. Auch wenn Horizon Cloud die Anzeigenamen an Workspace ONE Access sendet, verwendet Workspace ONE Access stattdessen die Start-IDs der Remoteanwendungen. Daher zeigt Workspace ONE Access die einfachen Namen für die Remoteanwendungen an.

Bekannte Probleme im Zusammenhang mit der Benutzeroberfläche

Falls nicht anders im Text zum bekannten Problem angegeben, beziehen sich die hier aufgeführten bekannten Probleme auf in Microsoft Azure bereitgestellte Pods.

Das im Sitzungs-Dashboard angezeigte Diagramm „Anmeldesegmente“ enthält keine Daten.
Dieses Problem gilt für alle Arten von Pods. Der VMware Logon Monitor-Dienst liefert die Daten für das im Sitzungs-Dashboard angezeigte Diagramm „Anmeldesegmente“. Doch diese Version unterstützt die Verwendung des VMware Logon Monitor-Dienstes nicht, und der VMware Logon Monitor-Dienst ist standardmäßig in allen mit dem Horizon Agents Installer durchgeführten Installationen deaktiviert. Infolgedessen wird das Diagramm „Anmeldesegmente“ im Sitzungs-Dashboard angezeigt, obwohl keine Daten für eine Anzeige im Diagramm „Anmeldesegmente“ bereitgestellt werden. Problemumgehung: Keine.
Wenn Sie die Verwaltungskonsole in einer Browserregisterkarte verwenden und versuchen, einen getrennten Desktop zu starten, den Sie in einer anderen Browserregisterkarte in demselben Browser nutzen, wird das HTML Access-Portal auch abgemeldet. Sie müssen sich dann wieder beim HTML Access-Portal anmelden. (2118293)
Wenn Sie einen Desktop starten und diesen trennen, ohne sich vom Desktop abzumelden, bleiben Sie in der Regel beim HTML Access-Portal selbst angemeldet. Sie können sich dann wieder mit dem getrennten Desktop verbinden, ohne Anmeldeinformationen in das HTML Access-Portal eingeben zu müssen. Aufgrund dieses Problems geschieht Folgendes, wenn Sie sich in einem Browserfenster befinden und in einer Browserregisterkarte bei der Konsole angemeldet sind, während Sie sich mit einer anderen Browserregisterkarte beim HTML Access-Portal anmelden und einen Desktop starten: Wenn Sie sich von diesem Desktop trennen und sich wieder damit verbinden möchten, werden Sie vom HTML Access-Portal abgemeldet. Anschließend müssen Sie erneut Anmeldeinformationen für das HTML Access-Portal eingeben, bevor Sie die Verbindung mit diesem Desktop wiederherstellen können. Problemumgehung: Um dieses Problem zu vermeiden, melden Sie sich mit einem anderen Browserfenster als dem mit dem HTML Access-Portal bei der Verwaltungskonsole an. Dieses Verhalten tritt nur auf, wenn Sie auch bei der Konsole in einer Browserregisterkarte in demselben Browserfenster angemeldet sind, in dem Sie auch das HTML Access-Portal verwenden.
Auf dem Bildschirm „Benutzerkarte“ für einen bestimmten Benutzer werden dedizierte VDI-Desktop-Zuweisungen auf der Registerkarte „Zuweisungen“ entfernt, nachdem der Benutzer den dedizierten Desktop aus der Zuweisung zum ersten Mal gestartet hat. (1958046)
Wenn ein Benutzer in einer dedizierten VDI-Desktop-Zuweisung als einzelner Benutzer angegeben ist und nicht über eine Active Directory-Gruppe, wird diese dedizierte VDI-Desktop-Zuweisung auf der Registerkarte „Zuweisungen“ des Bildschirms „Benutzerkarte“ für diesen Benutzer nur so lange angezeigt, bis der Benutzer den dedizierten Desktop aus dieser Zuweisung zum ersten Mal startet. Nachdem der Benutzer den dedizierten VDI-Desktop aus dieser Zuweisung zum ersten Mal gestartet hat, wird diese dedizierte VDI-Desktop-Zuweisung auf der Registerkarte „Zuweisungen“ der Benutzerkarte nicht mehr angezeigt. Sobald der Benutzer einen dedizierten Desktop zum ersten Mal startet, wird dieser Desktop im zugrunde liegenden Pool, der für diese Zuweisung definiert ist, durch den Benutzer beansprucht, und das System ordnet diesen dedizierten Desktop dem Benutzer zu. Durch die Zuordnung erhält der dedizierte Desktop den Status „Zugewiesen“ und wird auf der Registerkarte „Desktops“ der Benutzerkarte für diesen Benutzer aufgeführt.

Problemumgehung: Statt sich in diesem Fall auf die Registerkarte „Zuweisungen“ der Benutzerkarte zu verlassen, können Sie die Registerkarte „Desktop“ verwenden, um die bereits gestarteten dedizierten VDI-Desktops anzuzeigen, die einem bestimmten Benutzer zugewiesen sind. Wenn Sie die bestimmte dedizierte VDI-Desktop-Zuweisung suchen, in der die Benutzer-Desktop-Zuordnung vorgenommen wurde, rufen Sie den Desktop-Namen auf der Registerkarte „Desktop“ der Benutzerkarte ab, und verwenden Sie die Funktion zur Suche nach VMs im oberen Banner, um diese bestimmte Desktop-VM anzuzeigen. Klicken Sie in den Ergebnissen aus der Suche nach VMs auf den Namen, um die Seite für die Zuweisung zu öffnen, die diesen dedizierten Desktop enthält. Anschließend können Sie den Benutzer in den Details für die Zuweisung suchen.

Der Bildschirm „Neuigkeiten“ wird eingeblendet, obwohl Sie zuvor die Option ausgewählt haben, dass dieser Bildschirm nicht mehr angezeigt werden soll. (2075825)
Dieses Problem bezieht sich auf Umgebungen mit beliebigem Pod-Typ. Aufgrund dieses Problems kann der Bildschirm „Neuigkeiten“ nach der Anmeldung bei der Verwaltungskonsole angezeigt werden, wenn Sie den Cache Ihres Browsers löschen oder einen anderen Browser verwenden als denjenigen, in dem Sie zuvor angegeben haben, dass der Bildschirm „Neuigkeiten“ nicht mehr angezeigt werden soll. Das Flag zur Anzeige des Bildschirms „Neuigkeiten“ wird nicht pro Benutzer gespeichert, sondern im lokalen Cache des Browsers. Problemumgehung: Keine.
Auch wenn der Image-Erstellungsvorgang nicht vollständig abgeschlossen ist, zeigt der Bildschirm „Erste Schritte“ für den Schritt „Image erstellen“ den Status „Abgeschlossen“ an. (2100467)
Aufgrund dieses Problems wird der Schritt „Image erstellen“ vorzeitig als „Abgeschlossen“ markiert. Problemumgehung: Verwenden Sie die Seite „Aktivität“, um sicherzustellen, dass der Image-Erstellungsvorgang abgeschlossen wurde.
Bei Verwendung der Verwaltungskonsole werden möglicherweise Platzhalter statt der tatsächlichen Textzeichenfolgen angezeigt, oder das Klicken auf eine Schaltfläche auf einer Seite hat keine Wirkung. (2045967)
Dieses Problem bezieht sich auf Umgebungen mit beliebigem Pod-Typ. VMware aktualisiert regelmäßig die Verwaltungsumgebung in der Cloud, in der die webbasierte Konsole gehostet wird. Dieses Problem kann auftreten, wenn statischer Inhalt im Browser vor der letzten Aktualisierung in der Cloud zwischengespeichert wurde. Es handelt sich um ein temporäres Problem, das behoben wird, wenn der Browsercache gelöscht wird. Problemumgehung: Versuchen Sie, sich bei der Konsole abzumelden, den Browsercache zu löschen, den Browser neu zu starten und sich dann wieder bei der Konsole anzumelden.
Anwendungsnamen werden in Kleinbuchstaben angezeigt, wenn Endbenutzer mithilfe von Workspace ONE Access darauf zugreifen. (1967245)
Wenn Ihre Horizon Cloud-Umgebung in Workspace ONE Access integriert ist, greifen Ihre Endbenutzer mit Workspace ONE Access auf die ihnen zugewiesenen Desktops und Anwendungen zu. Aufgrund dieses bekannten Problems werden die Anwendungsnamen mit Kleinbuchstaben dargestellt, unabhängig von der tatsächlichen Schreibweise der Anwendungsnamen. Diese Einschränkung liegt an der Art, wie Workspace ONE Access Start-IDs von Horizon Cloud mithilfe von älteren Horizon Cloud-REST-APIs erstellt. Problemumgehung: Keine.
Die Prozentsätze der Arbeitsspeicherauslastung, die in Berichten für den Desktop-Zustand angezeigt und für Desktop-Zustandswarnungen verwendet werden, basieren auf dem Prozentsatz des genutzten zugesicherten Arbeitsspeichers und nicht nur des genutzten physischen Arbeitsspeichers. (2015772)
Der zugesicherte Arbeitsspeicher für eine Desktop-VM wird aus der Summe von physischem Arbeitsspeicher und Größe der Auslagerungsdatei berechnet. Der von diesem Gesamtwert (physischer Arbeitsspeicher plus Größe der Auslagerungsdatei) ermittelte Prozentsatz wird für die Berechnung des Prozentsatzes der Arbeitsspeicherauslastung in einem Desktop verwendet. Sowohl die Desktop-Zustandswarnungen und als auch der Bericht zur Arbeitsspeicherauslastung in den Desktop-Zustandsberichten verwenden diesen Prozentsatz zur Berechnung. Wenn Sie sich aber bei einer Desktop-VM anmelden und den Windows-Task-Manager im Windows-Betriebssystem des Desktops zur Anzeige der Arbeitsspeicherauslastung öffnen, basiert im Gegensatz dazu der darin angezeigte Prozentsatz ausschließlich auf dem physischen Arbeitsspeicher. Deshalb ist der im Windows-Task-Manager angezeigte Prozentsatz der Arbeitsspeicherauslastung nicht mit dem entsprechenden Wert in den Desktop-Zustandsberichten oder in der Desktop-Zustandswarnung identisch. Problemumgehung: Beachten Sie diesen Unterschied, wenn Sie den Prozentsatz der Arbeitsspeicherauslastung im Windows-Task-Manager des Desktops und den Prozentsatz der Arbeitsspeicherauslastung im Desktop-Zustandsbericht und in den Desktop-Zustandswarnungen in der Konsole für den jeweiligen Desktop vergleichen.
Wenn die CPU-Auslastung einer Desktop-VM fast 100 % beträgt, wird keine Desktop-Warnung ausgelöst. (1446496)
Wenn die CPU-Auslastung einer Desktop-VM durch eine Anwendung oder eine Aktion in der VM 100 % erreicht, kann der Desktop-Agent nicht mehr so viele Datenproben wie normalerweise an Horizon Cloud senden, da die CPU zu stark ausgelastet ist. Dies hat Einfluss auf die Berechnung, aufgrund der die Desktop-Warnung ausgelöst wird. Problemumgehung: Keine.

Bekannte Probleme in Zusammenhang mit Endbenutzern, Horizon Agent und Horizon Client

Die hier aufgeführten bekannten Probleme beziehen sich auf in Microsoft Azure bereitgestellte Pods.

Das Starten eines dedizierten Desktops von einem Horizon-Client mit der Option „Zuletzt geöffnet“ (oder einer gleichwertigen Option, basierend auf dem Client-Typ) startet den dedizierten Desktop möglicherweise nicht korrekt (SR23422432704, HCS-39121).
Verschiedene Horizon-Clients bieten Mechanismen, mit denen sich der Client einen zuvor gestarteten Desktop oder eine Remote-Anwendung merkt, und der Endbenutzer kann diese zuvor geöffneten Desktops oder veröffentlichten Anwendungen starten, ohne die vollständige Liste der Desktops und Anwendungen aufrufen zu müssen, zu denen er berechtigt ist.

Im Horizon Client für iOS und Horizon Client für Android beispielsweise bieten die Bildschirme mit der Bezeichnung Zuletzt gestartet Zugriff auf solche zuvor gestarteten Desktops und Remote-Apps. Wie in der Dokumentation Horizon Client für Mac beschrieben, bietet der Horizon Client für Mac zwei Möglichkeiten zum Öffnen der letzten Desktops und Remote-Anwendungen: über die Client-Option File > Open Recent und, wenn der Client zum Dock hinzugefügt wurde, über das Symbol im Dock. Wie in der Dokumentation Horizon Client für Windows beschrieben, verfügt der Horizon Client für Windows über eine GPO-Einstellung für die so genannte Sprunglistenintegration, die in der Regel standardmäßig aktiviert ist und es den Benutzern ermöglicht, über das Horizon Client-Symbol in der Windows-Taskleiste eine Verbindung zu aktuellen Desktops und veröffentlichten Anwendungen herzustellen.

Im Falle eines dedizierten Desktops, der von Horizon Cloud on Microsoft Azure bereitgestellt wird, speichert der Horizon Client nach dem ersten Start des Desktops möglicherweise nicht die korrekte Identität des Desktops als kürzlich erfolgten Start.

Aufgrund dieses Problems wird der Desktop möglicherweise nicht gestartet, wenn der Endbenutzer anschließend einen der oben beschriebenen Zuletzt gestartet-Mechanismus des Clients verwendet, um diesen Desktop erneut zu öffnen.

Dieses Problem kann auch auftreten, wenn Workspace ONE Access mit der Horizon Cloud on Microsoft Azure-Bereitstellung verwendet wird und der Horizon Client den Benutzer zu Workspace ONE umleitet, um den Start des dedizierten Desktops zu orchestrieren. Wenn der Endbenutzer den Desktop zuvor direkt vom Workspace ONE-Portal aus gestartet hat und dann versucht, einen der Zuletzt gestartet-Mechanismen des Clients zum Starten des Desktops zu verwenden, wird der Desktop aufgrund dieses Problems möglicherweise nicht gestartet, wenn der Client zur Orchestrierung des Starts zu Workspace ONE umgeleitet wird.

Problemumgehung: Um dieses Problem zu vermeiden, starten Sie den Desktop immer, indem Sie ihn entweder direkt aus der vollständigen Desktop-Liste im Client auswählen oder, wenn die Umgebung so konfiguriert ist, dass alle Starts über das Workspace ONE-Portal erfolgen müssen, den Start durch Auswahl des Desktops im Workspace ONE-Portal initiieren. Vermeiden Sie die Verwendung des Zuletzt gestartet-Mechanismus eines Clients (vermeiden Sie die Verwendung von Datei > Zuletzt geöffnete Dateien oder die Zuletzt geöffnet-Liste oder einen der Zuletzt geöffnet-Mechanismen, die von den Clients angeboten werden).
Hinweis: Wenn die Workspace ONE-Umleitung für die Horizon Cloud on Microsoft Azure-Bereitstellung aktiviert ist, ein Endbenutzer einen Zuletzt geöffnet-Mechanismus verwendet und der Desktop nicht gestartet werden kann, wird ein Workspace ONE-Audit-Ereignis geschrieben, um den fehlgeschlagenen Start anzuzeigen.
Bei einer VM mit Microsoft Windows 10 Enterprise Multi-Session 2004 oder höher treten Probleme in Zusammenhang mit der DPI-Synchronisierung und -Anzeigeskalierung auf (2587685, DPM-6352)
Durch den Fehler bei der Abfrage der aktuellen DPI in VMs, bei denen Microsoft Windows 10 Enterprise Multi-Session 2004 oder höher implementiert ist, verhalten sich diese Funktionen bei diesen VMs nicht so, wie dies in der Horizon Client-Dokumentation beschrieben ist. Die DPI-Synchronisierung und -Anzeigeskalierung funktionieren nicht beim erneuten Verbinden von PCoIP-Sitzungen. Die DPI-Skalierung funktioniert nicht beim erneuten Verbinden von Blast-Sitzungen. Problemumgehung: Melden Sie sich von der Sitzung ab und dann wieder an.
Bei einer VM mit dem Enterprise-Betriebssystem Microsoft Windows 10 1903 oder höher treten Probleme in Zusammenhang mit der DPI-Synchronisierung und -Anzeigeskalierung auf (2589129)
Durch den Fehler bei der Abfrage der aktuellen DPI in VMs, bei denen das Enterprise-Betriebssystem Microsoft Windows 10 1903 oder höher implementiert ist, verhalten sich die Funktionen beim erneuten Verbinden einer PCoIP- oder Blast-Sitzung nicht so, wie dies in der Horizon Client-Dokumentation beschrieben ist. Problemumgehung: Melden Sie sich von der Sitzung ab und dann wieder an.
Manchmal erscheint beim Start eines VDI-Desktops mit VMware HTML Access eine Fehlermeldung über die Trennung der Verbindung, und anschließend ist der Start erfolgreich. (2243471)
Virtuelle VDI-Desktop-Maschinen verfügen über ein Standard-Verbindungszeitlimit für Sitzungen, und wenn dieses Limit erreicht ist, wird die Verbindung getrennt. Wenn beim Starten eines Desktops die HTML Access-Sitzung des Endbenutzers zum Zeitpunkt des Erreichens des Standard-Verbindungszeitlimits für Sitzungen des Desktops abgelaufen ist, löst der Desktop diesen Fehler zunächst aus und fährt dann mit dem Starten des Desktops fort. Problemumgehung: Keine.
Wenn für eine VDI-Desktopzuweisung Festplattenverschlüsselung ausgewählt ist und sie über ein VM-Modell mit einem oder zwei Kernen verfügt und gleichzeitig die zugrunde liegende Desktop-VM ausgeschaltet ist, kann über die automatische Horizon Client-Option zum erneuten Versuch unter Umständen keine Verbindung hergestellt werden. (2167432)
Wird eine VDI-Desktop-VM aufgrund der Energieverwaltungseinstellung der VDI-Desktop-Zuweisung ausgeschaltet, muss die VM eingeschaltet werden und betriebsbereit sein, bevor Endbenutzer eine Verbindung zu diesem Desktop herstellen können. Wenn der Client eines Endbenutzers versucht, eine Verbindung mit der virtuellen Maschine einer VDI-Desktop-Zuweisung herzustellen und die virtuelle Maschine ausgeschaltet ist, beginnt das System, diese virtuelle Maschine einzuschalten. Bei nicht verschlüsselten virtuellen Maschinen gilt Folgendes: Die virtuelle Maschine ist in der Regel in weniger als 10 Minuten bereit, eine Clientverbindung zu akzeptieren. Doch bei einer verschlüsselten virtuellen Maschine mit einem oder zwei Kernen dauert es in der Regel mehr als 10 Minuten, bis diese dazu bereit ist, eine Verbindung zu akzeptieren. Die Obergrenze bei der Horizon Client-Option für Erneute Client-Versuche liegt bei 12 Minuten. Aufgrund dieser Obergrenze für die Option Erneute Client-Versuche gilt Folgendes: Haben Endbenutzer den Client so konfiguriert, dass automatisch versucht wird, erneut eine Verbindung herzustellen, während die zugrunde liegende virtuelle Maschine des Desktops eingeschaltet wird und hochfährt, wird dieser automatische Versuch nach 12 Minuten ohne Verbindungsherstellung unterbrochen. Da eine verschlüsselte virtuelle Maschine in der Regel mehr als 12 Minuten braucht, um eine Clientverbindung zu akzeptieren, stellt der Endbenutzer möglicherweise fest, dass die automatischen erneuten Verbindungsversuche von Horizon Client fehlschlagen und keine Verbindung zu einer verschlüsselten Desktop-VM hergestellt werden kann. Problemumgehung: Wenn Sie die Festplattenverschlüsselung für eine VDI-Desktopzuweisung verwenden möchten, wählen Sie ein VM-Modell mit mehr als zwei Kernen aus. Doch wenn Ihre VDI-Desktop-Zuweisung über Festplattenverschlüsselung und ein VM-Modell mit einem oder zwei Kernen verfügt, informieren Sie Ihre Endbenutzer, dass bei einer Verwendung der Option für erneute Client-Versuche bei diesen verschlüsselten Desktop-VMs Probleme auftreten können.
In einigen Fällen ist es nicht möglich, einen virtuellen Desktop aus einer dedizierten VDI-Desktop-Zuweisung über den Schnellzugriffs-Link auf der Horizon Client-Seite „Zuletzt gestartet“ zu starten. (1813881, HD-3686, DPM-1140)
In den iOS- und Android-Versionen der Horizon Clients gibt es eine Seite „Zuletzt gestartet“, auf der Links zu vor Kurzem gestarteten Desktops angezeigt werden. Startet ein Benutzer einen dedizierten virtuellen Pool-Desktop zum ersten Mal, wird der Start normal ausgeführt, und der Client erzeugt ein Startsymbol auf der Seite „Zuletzt gestartet“. Trennt der Benutzer die Verbindung zum Desktop und versucht später, ihn über die Seite „Zuletzt gestartet“ erneut zu starten, kann der Desktop jedoch nicht gestartet werden, da das Startsymbol eine gekürzte Version des Desktop-Namens verwendet. Problemumgehung: Starten Sie den Desktop über die Client-Hauptseite, nicht über die Seite „Zuletzt gestartet“.
Pods mit der Manifestversion 1976.0 und Farm-VMs, die auf Agent-Ebene 19.4 ausgeführt werden: Benutzer werden nach einer Stunde von ihren Desktops oder Remoteanwendungssitzungen getrennt, wenn sie HTML Access (Blast) und PCoIP-Protokolle verwenden. (2519400)
Dieses Problem tritt wegen eines Problems in Microsoft-Terminaldiensten in Microsoft Windows 10-Enterprise-Multisession-Systemen auf. Wenn für sitzungsbasierte Desktops und Remoteanwendungen, die über RDSH-Farmen bereitgestellt werden, die auf dem Microsoft Windows 10-Enterprise-Multisession-Betriebssystem basieren, ein Endbenutzer nach Ablauf einer Stunde die Verbindung mit einer vorhandenen Desktop- oder Remotenanwendungssitzung mit dem Protokoll HTML Access (Blast) oder PCoIP wiederherstellt, dann wird die Sitzung des Benutzers zwangsweise getrennt. Es tritt kein Datenverlust auf. Auch wenn der Benutzer die Verbindung wiederherstellen kann und sich die Sitzung im gleichen Zustand wie vor der Trennung befindet, wiederholt sich dieses Verhalten und die wiederhergestellte Sitzung wird nach einer Stunde erneut zwangsweise getrennt.

Dieses Problem wird mithilfe von Horizon Agents Installer (HAI) 20.1 oder höher behoben. Wenn Ihr Pod der Version 1976.0 auf das Manifest 1976.1 oder höher aktualisiert wurde, installiert der Assistent zum Importieren von virtuellen Maschinen aus Marketplace automatisch die Agent-Software mit diesem Fix. Wenn sich Ihr Pod noch auf der Ebene des Manifests 1976.0 befindet, wird beim Ausführen des Assistenten weiterhin die Agent-Software mit dem Problem installiert. Wenn Sie die virtuelle Maschine jedoch versiegeln, wird auf der Seite „Images“ der blaue Punkt angezeigt. Dieser gibt an, dass Sie mit der Funktion „Aktualisieren des Agents“ den Agent auf die Ebene mit dem Fix aktualisieren können.

Pods mit Manifestversionen vor 2298: Wenn Sie im Client zwischen den Protokollen wechseln und dafür die Option „Verbinden“ nutzen, statt „Abmelden“ und „Neu verbinden“, reagiert der Client möglicherweise nicht mehr. (2528014)
Dieses Problem wurde in Pods behoben, die auf die Manifestversion 2298 oder höher aktualisiert wurden. Dieses Problem tritt auf, wenn im Client nach dem Herstellen einer Sitzung mit einer RDSH-Farm mit einem Protokoll zu einem anderen Protokoll gewechselt wird. Wenn Sie den Desktop oder die Anwendung mit einem Protokoll starten, dann die Sitzung trennen, über das Client-Menü zu einem anderen Protokoll wechseln und denselben Desktop oder dieselbe Anwendung starten, zeigt der Client ein Dialogfeld mit dem Hinweis an, dass dieser Desktop auf dem Server geöffnet ist, aber ein anderes Protokoll ausführt. Zudem haben Sie in dem Dialogfeld die Möglichkeit, eine Verbindung herzustellen oder sich abzumelden und erneut zu verbinden. Wenn Sie die Schaltfläche „Verbinden“ auswählen, wird das Dialogfeld ein zweites Mal angezeigt. Wenn Sie die Option zur erneuten Verbindungsherstellung auswählen, reagiert der Client nicht mehr.
Wenn Sie die Funktion „Agent aktualisieren“ verwenden, um Images mit einer Agent-Version vor 18.2.2 zu aktualisieren, schlägt der Aktualisierungsvorgang möglicherweise fehl (2200962).
Dieses Problem tritt möglicherweise bei Images auf, die Sie auf Knoten mit einer Manifestversion vor 965 erstellt haben. Manchmal verfügt das Image über RunOnce-Registrierungswerte, die den Abschluss des Agent-Aktualisierungsvorgangs blockieren. Problemumgehung: Führen Sie die Agent-Aktualisierung erneut aus und fügen Sie dabei auf der Registerkarte „Befehlszeile“ des Assistenten für die Agent-Aktualisierung das folgende Befehlszeilenargument hinzu: VDM_SUPPRESS_RUNONCE_CHECK=1