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

Dieses Dokumentationsthema enthält die bekannten Probleme für Horizon Cloud Connector. Doch obwohl Sie Horizon Cloud Connector zum Verbinden von Horizon Pods mit Horizon Cloud verwenden, sind die bekannten Probleme für die Software, die innerhalb dieser Horizon-Pods ausgeführt werden, an anderer Stelle verfügbar. Die bekannten Probleme für die Softwareversionen von Horizon-Pods sind in den Versionshinweisen für das Horizon-Softwareprodukt selbst dargelegt. Die Dokumente der Horizon-Softwareversion 7.x sind über die VMware Horizon 7-Dokumentationsseite verknüpft. Die Dokumente für Horizon-Softwareversion 2006 sind auf dieser VMware Horizon-Dokumentationsseite verknüpft (manchmal zusätzlich zu Horizon 2006 auch als Horizon 8 bezeichnet).

Informationen zu bekannten Problemen mit dem Imageverwaltungsdienst (IMS) finden Sie auf der Seite „Bekannte Probleme“ unter Verwaltung 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 Cloud Connector

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 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.

Bekannte Problem im Zusammenhang mit Images, Farmen und Zuweisungen

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

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 VMware KB 2079196, 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 im Image zu deaktivieren und dann die Farm zu erstellen.
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.

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.

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 2-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.

Der Inhalt im Fenster Hilfe > Info der Verwaltungskonsole ist nicht korrekt.
Wenn Sie in der Konsole auf Hilfe > Info klicken, sind die Informationen im Fenster nicht korrekt. Aufgrund dieses Problems ist der Text hartcodiert, sodass anstelle von stichhaltigen und relevanten Informationen über die Mandantenumgebung oder über die Cloud-Steuerungsebenenumgebung, in der Sie arbeiten, immer Version 2.2 angezeigt wird. Problemumgehung: Keine.
Auch wenn ein Pod mit dem Manifest 2298.0 oder höher mindestens eine Gateway-Konfiguration für unterstützte Vorgänge aufweisen muss, hindert Sie die Verwaltungskonsole nicht daran, die einzige Gateway-Konfiguration vom Pod zu löschen und diesen nicht unterstützten Zustand beizubehalten.
Die Verwaltungskonsole bietet einen Workflow, in dem Sie die vorhandene Gateway-Konfiguration eines Pods löschen können, um das Gateway mit einer neuen Bereitstellungskonfiguration erneut bereitzustellen. Dieser Workflow wird bereitgestellt, da die Konsole zurzeit keine Möglichkeit bietet, den Workflow „Pod bearbeiten“ zu verwenden, um die Bereitstellungskonfiguration des Gateways zu aktualisieren, obwohl der Workflow „Pod bearbeiten“ verwendet werden kann, um die Softwarekonfiguration des Gateways zu einem beliebigen Zeitpunkt zu aktualisieren.

Nun muss ein Pod mit dem Manifest 2298 oder höher über mindestens eine Gateway-Konfiguration verfügen, um unterstützte Vorgänge aufzuweisen. Wenn Sie die einzige Gateway-Konfiguration eines solchen Pods löschen, um die Bereitstellungskonfiguration des Gateways zu aktualisieren, zeigt die Konsole eine Warnmeldung an, wie im vorherigen Absatz beschrieben. Die Konsole verhindert jedoch nicht das Löschen des einzigen bereitgestellten Pod-Gateways, weil sie den Anwendungsfall wie im vorherigen Absatz beschrieben bereitstellt. Es wird erwartet, dass Sie die Gateway-Konfiguration kurz danach mit neuen Auswahlmöglichkeiten für die Gateway-Bereitstellung erneut bereitstellen, die in der gelöschten Konfiguration nicht vorhanden waren. Das Problem besteht darin, dass die Konsole derzeit das Löschen der einzigen Gateway-Konfiguration von einem Pod zulässt, auf dem mindestens ein Gateway für unterstützte Vorgänge erforderlich ist. Gleichzeitig ist im Anschluss für die Konsole jedoch keine erneute Bereitstellung eines neuen Gateways auf dem Pod erforderlich. Wenn Sie den Pod ohne Gateway-Konfiguration beibehalten, weist dieser Pod eine nicht unterstützte Konfiguration auf.

Problemumgehung: Damit die Konfiguration unterstützt wird, müssen Sie sicherstellen, dass jeder Pod mit dem Manifest 2298.0 oder höher über mindestens eine Gateway-Konfiguration verfügt. Eine der folgenden Konfigurationen muss auf dem Pod bereitgestellt werden:

  • Ein externes Gateway
  • Ein internes Gateway
  • Sowohl externe als auch interne Gateways

Wenn Sie die einzige Gateway-Konfiguration von einem Pod mit dem Manifest 2298.0 oder höher löschen, um eine Gateway-Einstellung zu ändern, die nur durch Löschen und erneutes Bereitstellen des Gateways geändert werden kann, müssen Sie ein neues Gateway auf dem Pod erneut bereitstellen, damit die Konfiguration weiterhin unterstützt wird. Das VMware Horizon-Serviceteam arbeitet momentan an Verbesserungen, bei denen die Konsole keinen Workflow mehr benötigt, um ein bereitgestelltes Gateway für den Anwendungsfall zum Ändern der Gateway-Bereitstellungskonfiguration zu löschen. Zu diesem Zeitpunkt besteht keine Möglichkeit, die einzige Gateway-Konfiguration mithilfe der Konsole vom Pod zu löschen.

Wenn Sie in der Benutzerkarte für eine VDI-Desktop-Sitzung auf einem Pod in Microsoft Azure auf Zurücksetzen klicken, wird eine Fehlermeldung angezeigt, obwohl die VM erfolgreich zurückgesetzt wurde. (2567272)
Aufgrund dieses Problems wird in der Verwaltungskonsole eine Fehlermeldung angezeigt, obwohl der Rücksetzungsvorgang erfolgreich eingeleitet wurde und die VM anschließend zurückgesetzt wird. In der Meldung wird angegeben, dass das System Ihre Anforderung nicht abschließen konnte, obwohl die VM tatsächlich zurückgesetzt wird. Dieses Problem tritt möglicherweise bei einer Desktopsitzung mit einer flexiblen VDI Desktop-Zuweisung auf. Problemumgehung: Keine. Der Rücksetzungsvorgang wird erfolgreich eingeleitet, und die VM wird anschließend zurückgesetzt. Schließen Sie die angezeigte Fehlermeldung.
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.

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