Damit Sie während Ihrer gesamten Reise mit First-Gen-Horizon Cloud den bestmöglichen Erfolg haben, beachten Sie die folgenden bekannten Einschränkungen.

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.

Alle Bereitstellungstypen

  • Jeder Pod, der Ihrem Horizon Cloud-Mandanten zugeordnet ist und mit Horizon Cloud verbunden ist, muss Zugriff auf denselben Satz von Active Directory-Domänen haben. Wenn die Pod-Flotte Ihres Mandanten eine Kombination aus Pod-Typen aufweist, z. B. Horizon 8- und Horizon Cloud-Typen, ist zusätzlich zu dieser Zugriffsberechtigung eine unidirektionale oder bidirektionale Vertrauensstellung zwischen allen Domänen erforderlich, die bei demselben Horizon Cloud-Mandanten registriert sind.
    Hinweis: Zugriff in diesem Kontext bedeutet, dass ein bestimmter Pod über Netzwerkzugriff auf jede Domäne verfügen muss, damit er diese Domäne für Statusprüfungen erreichen kann.
  • Das System ruft die Daten für die Berichte zu Nutzung, Parallelität, Sitzungsverlauf und Top-Anwendungen einmal täglich zu einer bestimmten UTC-Zeit ab. Die Daten für die Berichte zu Nutzung und Parallelität werden um 2:00 Uhr UTC abgerufen, die Daten für den Bericht zum Sitzungsverlauf um 2:10 Uhr UTC und die Daten für den Bericht zu den Top-Anwendungen um 2:30 Uhr UTC. Folglich enthalten die in der Verwaltungskonsole angezeigten Informationen möglicherweise nicht die Daten, die zwischen dem letzten Abruf und dem Zeitpunkt, zu dem Sie die Berichte in der Konsole anzeigen, erfasst wurden. Beispiel: Da die Logik Benutzer und Spitzenparallelität im Bericht zur Parallelität anhand der Daten berechnet, die für den Tag erfasst wurden, für den die Daten abgerufen werden, werden die Daten für die Benutzeraktivität vom 23. April um 2:00 Uhr UTC am 24. April (dem folgenden Tag) berechnet. Wenn dieser Zeitpunkt überschritten ist und das System die erfassten Daten abruft, werden die Daten vom 23. April im Bericht angezeigt. Wenn einer Ihrer Endbenutzer eine Sitzung am 23. April nach 2:00 Uhr UTC startet, werden die Daten für die Sitzung dieses Benutzers erst am 24. April nach 2:00 Uhr UTC im Bericht angezeigt.

Bereitstellungen – Horizon Cloud-Pods in Microsoft Azure

Ein Horizon Cloud-Pod ist der Typ, der auf der Horizon Cloud-Pod-Manager-Technologie basiert.

  • Aufgrund von Einschränkungen bei der Art und Weise, wie Microsoft Azure VNets gleichzeitige Vorgänge zum Erstellen und Löschen von Subnetzen handhaben, kann die parallele Ausführung von Pod-bezogenen Vorgängen, die eine gleichzeitige Änderung desselben VNets erfordern, dazu führen, dass diese Vorgänge nicht abgeschlossen werden können. Um dieses Problem zu umgehen, vermeiden Sie es, Pod-Bereitstellungen, Pod-Löschungen oder Pod-Bearbeitungen auszuführen, die Subnetze gleichzeitig betreffen, wenn diese Pods dasselbe VNet verwenden. Hier einige Beispiele für parallele Pod-bezogene Vorgänge, die eine VNet-Änderung beinhalten, bei denen es zu gleichzeitigen Subnetz-Aktionen im VNet kommen kann, die zu Fehlern bei der Ausführung der Vorgänge führen können:
    • Wenn Sie Ihre Subnetze nicht frühzeitig erstellen und den Pod-Bereitsteller die Subnetze unter Verwendung von CIDRs erstellen lassen, während Sie gleichzeitig eine Erstellung von zwei Pods im selben VNet einleiten. Die Subnetze werden dem VNet für beide Pod-Erstellungen gleichzeitig hinzugefügt.
    • Wenn ein Pod gerade bereitgestellt wird und Sie die Löschung eines anderen Pods im selben VNet einleiten. Die Subnetze für den gerade bereitgestellten Pod werden dem VNet zur gleichen Zeit hinzugefügt, wie die Subnetze des anderen Pods aus demselben VNet gelöscht werden.
    • Wenn Sie einen Pod bearbeiten, um eine externe Gateway-Konfiguration im VNet des Pods unter Verwendung von CIDR-Blöcken hinzuzufügen, während ein anderer Pod gelöscht wird. Die Subnetze für die Gateway-Konfiguration werden dem VNet zur gleichen Zeit hinzugefügt, wie die Subnetze des anderen Pods aus dem VNet gelöscht werden.
  • Zurzeit wir eine Erweiterung der Größe der Subnetze nach der Bereitstellung des Pods nicht unterstützt. Bevor Sie einen Pod bereitstellen, müssen Sie sicherstellen, dass die Adressbereiche für die Subnetze, die Sie im Bereitstellungsassistenten angeben, groß genug sind, um Ihre erwartete Nutzung zu unterstützen.
    Hinweis: Zur Umgehung dieser Einschränkung ermöglicht eine neue Funktion, die für Pods der Manifestversion 2298.0 und höher verfügbar ist, das Hinzufügen von Mandanten-Subnetzen, die nach der Bereitstellung des Pods für Farm- und VDI-Desktop-Zuweisungen verwendet werden können. Diese Funktion bietet Flexibilität beim Hinzufügen von Mandanten-Subnetzen, die sich im gleichen VNet des Pods oder in einem Peer-VNet befinden und die von Ihren Farm- und Desktop-VMs nach der Bereitstellung des Pods verwendet werden können. Weitere Informationen finden Sie im Administratorhandbuch.
  • Mehrere Pods können nicht denselben vollqualifizierten Domänennamen gemeinsam nutzen, der in ihren Unified Access Gateway Konfigurationen festgelegt ist. Jeder Pod, der mit Unified Access Gateway-Instanzen konfiguriert ist, benötigt einen eigenen eindeutigen vollqualifizierten Domänennamen (FQDN). Der FQDN darf keine Unterstriche enthalten.
    Hinweis: Ab der Cloud Plane-Aktualisierung vom 15. Dezember 2020 wird das Vorhandensein verschiedener FQDNs für die Konfigurationen für externe Gateways und interne Gateways des Pods unterstützt. Bis zum 15. Dezember 2020 wurde für einen Pod mit dem Manifest 2298 und höher der gleiche FQDN vom System erzwungen. Jetzt können Sie entscheiden, ob die Gateways des Pods unterschiedliche FQDNs oder denselben FQDN verwenden sollen. Wenn Sie den gleichen FQDN für beide Gateways verwenden möchten, konfigurieren Sie nach der Pod-Bereitstellung ein aufgeteiltes DNS (Split Domain Name System), um die Gateway-Adresse entweder zum externen Gateway oder zum internen Gateway aufzulösen, je nach dem Ursprungsnetzwerk der DNS-Abfrage des Endbenutzer-Clients. Dann kann der FQDN im Endbenutzer-Client zur Weiterleitung an das externe Gateway verwendet werden, wenn sich der Client im Internet befindet, und zur Weiterleitung an das interne Gateway, wenn sich der Client in Ihrem internen Netzwerk befindet.
  • Die Bearbeitung oder Aktualisierung der Proxy-Einstellungen auf einem Pod nach der Bereitstellung des Pods in Microsoft Azure wird derzeit nicht unterstützt. Auch das Hinzufügen einer Proxy-Konfiguration zu einem bereitgestellten Pod, der ohne Proxy-Einstellungen bereitgestellt wurde, wird derzeit nicht unterstützt.
  • Die NSX Cloud-Funktionen in dieser Version werden für Microsoft Windows Server 2019 nicht unterstützt.
  • Wenn Sie einen Horizon Cloud-Pod in Microsoft Azure bereitstellen und True SSO bereits für zuvor bereitgestellte Pods konfiguriert haben, wird der neue Pod vom System nicht automatisch mit den Registrierungsservern gekoppelt. Sie müssen die Schritte manuell wiederholen, um das Koppelungspaket zu exportieren und in die Registrierungsserver zu importieren. Informationen zu den entsprechenden Schritten finden Sie im Thema Konfigurieren von True SSO für die Verwendung mit Ihrer Horizon Cloud-Umgebung und in den zugehörigen Unterthemen.
  • In Workflows, die zur Erstellung von VMs führen (z. B. zur Erstellung von Farmen, Images und Zuweisungen), werden Sie daran gehindert, einen Namen für das zu erstellende Element einzugeben, der mehr als die vom System unterstützte Anzahl von Zeichen umfasst. Die Anzahl der unterstützten Zeichen für einen Elementnamen hängt vom Workflow ab.
  • In einer Microsoft Azure-Umgebung mit mehreren Pods können Sie Namen, die Sie bereits in einem Pod verwendet haben, nicht wiederverwenden, wenn Sie Elemente in einem anderen Pod erstellen. Der Grund für diese Einschränkung ist, dass Pods in einer Umgebung mit mehreren Pods dieselbe Active Directory-Domäne und dasselbe VNet nutzen. Wenn in solchen Umgebungen mit mehreren Pods Namen gemeinsam genutzt werden, kann es zu unerwartetem Verhalten kommen. Diese Einschränkung gilt für Namen von Images, Farmen und VDI-Desktop-Zuweisungen. Stellen Sie sicher, dass für Ihre Images, Farmen und VDI-Desktop-Zuweisungen eindeutige Namen verwendet werden.
  • Beachten Sie diese Regeln, wenn Sie in der Verwaltungskonsole Zeichen eingeben:
    • Verwenden Sie nur standardmäßige ASCII-Zeichen für Benutzernamen und Kennwörter sowie für das Kennwort zum Herunterladen der DaaS-SSL-Bootstrap-Datei. Bei Verwendung nicht standardmäßiger ASCII-Zeichen für diese Objekte können unerwartete Ereignisse auftreten.
    • Bei der Eingabe von Namen für importierte Images, Farmen, Zuweisungen und andere Objekte zum Erstellen einer virtuellen Maschine in Microsoft Azure sind maximal zwölf Zeichen pro Name zulässig.
    • Verwenden Sie in Benutzerkennwörtern kein Komma.
    • Bei der Verwendung des Assistenten zum Importieren von VMs zum Erstellen einer Basisimage-VM aus Microsoft Azure Marketplace müssen Sie Folgendes beachten:
      • Geben Sie einen Benutzernamen und ein Kennwort ein, die den Anforderungen von Microsoft Azure für VM-Admin-Benutzernamen und ‑Kennwörter entsprechen. Einzelheiten dazu finden Sie auf der Seite Häufig gestellte Fragen zu Microsoft Azure.
      • Geben Sie keinen Namen für das Image ein, der mit einem Bindestrich (-) endet.
      • Verwenden Sie für den Image-Namen keinen Unterstrich (_).

Updates von Horizon Cloud-Pods in Microsoft Azure

  • Während der Aktualisierung eines Pods auf den aktuellen Softwarestand werden Endbenutzer mit Sitzungen, die mit dem Knoten, der gerade aktualisiert wird, verbunden sind, von den aktiven Sitzungen getrennt. Dabei gehen keine Daten verloren, außer wenn in den Einstellungen der RDSH-Farm oder VDI-Desktop-Zuweisung, die die Sitzungen bereitstellt, für Getrennte Sitzungen abmelden die Option Sofort festgelegt ist. Für solche Farmen und VDI-Desktop-Zuweisungen werden die getrennten Sitzungen außerdem sofort abgemeldet. In diesem Fall geht die aktuelle Arbeit der Benutzer verloren. Wenn die Aktualisierung abgeschlossen ist, können sich diese Benutzer erneut verbinden. Der Pod-Aktualisierungsvorgang dauert in der Regel weniger als eine halbe Stunde. Einige Pod-Aktualisierungen können jedoch länger ausfallen.
  • Wenn Pods in Manifesten vor dem Manifest Oktober 2020 Version 2474 ausgeführt werden, dann auf 2474 oder höher aktualisiert werden und Sie das Microsoft Azure-Portal zum manuellen Hinzufügen von Tags zu Ressourcen oder Ressourcengruppen verwendet haben, die von Horizon Cloud in Ihrem Abonnement erstellt wurden (z. B. Erstellung benutzerdefinierter Tags in den Ressourcengruppen der Farm oder der VDI-Desktop-Zuweisungen), werden die benutzerdefinierten Tags, die Sie direkt mithilfe des Microsoft Azure-Portals hinzugefügt haben, bei der Pod-Aktualisierung nicht beibehalten. Diese benutzerdefinierten Tags werden entfernt. Im Anschluss an die Pod-Aktualisierung müssen Sie die Horizon Universal Console-Funktionen zum Bearbeiten der Farmen und VDI-Desktop-Zuweisungen verwenden, damit das System diese Tags auf die Ressourcengruppen für diese Farmen und VDI-Desktop-Zuweisungen anwenden kann. Die Verwendung der Funktion Azure Resource-Tags der Konsole gilt als unterstützte Methode zum Hinzufügen von Ressourcen-Tags zu den vom Pod erstellten Ressourcengruppen für Farmen und VDI-Desktop-Zuweisungen. Lesen Sie in jedem der folgenden Dokumentationsthemen die Beschreibungen der Felder vom Typ Azure Resource-Tags. Dieselben Felder werden beim Bearbeiten einer Farm oder VDI-Desktop-Zuweisung verwendet.

Importierte VMs, Golden Images, Farmen oder VDI-Desktop-Zuweisungen in Horizon Cloud-Pods in Microsoft Azure

  • Obwohl die Konsole Sie nicht daran hindert, Images aus anderen Quellen als dem Azure Marketplace in den Workflows der Konsole zu verwenden, wird die Verwendung solcher Images nicht unterstützt. Damit sie für die Verwendung in Horizon Cloud on Microsoft Azure unterstützt werden, müssen alle importierten Basisimages aus Windows-basierten VMs erstellt werden, die aus dem Azure Marketplace stammen. Selbst wenn Sie ein Image aus anderen Quellen innerhalb der Workflows der Konsole verwenden können, werden solche Images nicht unterstützt.

    Darüber hinaus muss ein Windows 11-Image direkt aus dem Azure Marketplace bezogen werden und kann anschließend nicht verarbeitet werden. Der Import von Windows 11-VMs aus anderen Quellen, wie z. B. Shared Image Gallery (SIG), von Azure verwaltete Images, Azure-VM-Snapshots usw., wird derzeit nicht unterstützt.

  • Azure-VMs der Generation 2 werden derzeit nur für die Verwendung mit Windows 11-Betriebssystemen für Einzelsitzungen und Windows 11 Enterprise-Betriebssystemen für Mehrfachsitzungen unterstützt.
  • Derzeit werden die Azure GPU-fähigen NVv4-VMs, die die AMD Radeon Instinct-Grafiktreiber verwenden, nur dann unterstützt, wenn sie mithilfe der benutzerdefinierten Importmethode importiert werden. Die benutzerdefinierte Importmethode wird in dieser Dokumentation auch als manueller Import bezeichnet. Der automatisierte Assistent zum Importieren virtueller Maschinen aus Marketplace stellt diese Funktion derzeit nicht zur Verfügung.

    Darüber hinaus unterstützt der Dienst derzeit nicht die Verwendung von Windows 11 mit diesen NVv4-VMs und den AMD Radeon Instinct-Grafiktreibern. Diese Verwendung wurde nicht qualifiziert.

  • Die Unterstützung des Diensts für Windows 11 weist einige bekannte Überlegungen, Einschränkungen und Probleme auf. Weitere Informationen finden Sie unter Unterstützung für Windows 11-Gastbetriebssysteme – Überlegungen, bekannte Einschränkungen und bekannte Probleme.
  • Die Verwendung von True SSO mit Sitzungsdesktops, Remoteanwendungen oder VDI-Desktops, die auf Images mit Windows 10 Version 2004, Windows 10 Version 20H2, Windows Server Version 2004 oder Windows Server Version 20H2 basieren, erfordert die Installation eines Microsoft-Patches für diese Betriebssysteme. Der Patch behebt ein Microsoft-Problem, das die Authentifizierung von True SSO mit diesen Betriebssystemen blockiert. Weitere Informationen finden Sie im VMware-Knowledgebase-Artikel 79644, der sich auf Microsoft Update KB4598291 bezieht.
  • Die Festplattenverschlüsselungsfunktion für Farmen und VDI-Desktop-Zuweisungen wird derzeit nicht für Pods in Microsoft Azure Government-Clouds unterstützt.
  • Aktuell wird die Verwendung der folgenden Horizon Agent-Funktionen nicht unterstützt: VMware Logon Monitor-Dienst. Der VMware Logon Monitor-Dienst ist standardmäßig in allen mit dem Horizon Agents Installer durchgeführten Installationen deaktiviert.
  • Die USB-Umleitungsfunktion wird nicht unterstützt, wenn Sie den VMware Horizon Client für Android zum Zugriff auf virtuelle Desktops und Remoteanwendungen verwenden, die von Ihrer Horizon Cloud-Umgebung bereitgestellt werden.
  • Für GPU-fähige Golden Images, die auf Server-Betriebssystemen basieren, werden die Microsoft Windows Server-Versionen 2016 und 2019 empfohlen, damit die Anzahl Endbenutzersitzungen nicht begrenzt werden muss. Aufgrund einer NVIDIA-Treibereinschränkung unter Windows Server 2012 R2 liegt die maximale Anzahl an Sitzungen für jeden RDS-Desktop-Server bei 20.
  • Wenn Sie ein Image mit Microsoft Windows 10 1709 (RS3) haben und es auf Windows 10 1803 (RS4) oder Windows 10 1809 (RS5) aktualisieren möchten, aktualisieren Sie zuerst Windows 10 1709 auf die neueste Horizon Agent-Version 19.4, bevor Sie mit dem Upgrade des Windows-Betriebssystems beginnen.
  • Wenn Sie den automatisierten Assistenten zum Importieren von virtuellen Maschinen aus Marketplace verwenden, um ein Image mit einem Windows Server 2012-Betriebssystem zu erstellen, ist die Desktopdarstellung für das resultierende Image standardmäßig nicht aktiviert. Wenn Sie möchten, dass die Desktopdarstellung für das resultierende Image aktiviert ist, müssen Sie die Desktopdarstellung im resultierenden Image manuell aktivieren.
  • Wenn Sie die Konvertierung eines Desktops in ein Image einleiten, aber vor Beendigung der Aufgabe abbrechen, schlägt ein zweiter Versuch, den Desktop in ein Image zu konvertieren, möglicherweise fehl. Um dieses Problem zu vermeiden, sollten Sie den Desktop ausschalten und wieder einschalten, bevor Sie versuchen, ihn ein zweites Mal in ein Image zu konvertieren.
  • Bei einer URL-Umleitungsanpassung wird die Groß- und Kleinschreibung von URL-Mustern berücksichtigt, wenn sie vom Horizon Client abgefangen werden. Beispielsweise wird keine URL-Umleitung für URL-Muster wie *GOOGLE.com und *Google.com ausgeführt, obwohl z. B. das Muster *google.com umgeleitet wird. Für Endbenutzer wird keine Umleitung ausgeführt, wenn das angegebene Muster nicht der tatsächlichen in den Ziel-Dateisystemen verwendeten Groß- und Kleinschreibung entspricht.

Bereitstellungen – Horizon-Pods

Ein Horizon-Pod ist der Pod-Typ, der auf der Software Horizon Connection Server basiert. Hintergrundinformationen zu den verschiedenen Bereitstellungsarchitekturen, die für Horizon-Pods verwendet werden, finden Sie unter First-Gen-Mandanten – Bereitstellungsarchitekturen für Horizon-Pods mit First-Gen-Horizon Cloud. Detaillierte Informationen zu den verschiedenen Cloud-Plane-Diensten finden Sie im Administratorhandbuch.

Die folgenden Einschränkungen gelten für die aktuelle Version und werden für jede Horizon Cloud Service-Version aktualisiert.

  • Die automatisierte Aktualisierungsfunktion von Horizon Cloud Connector wird nur für lokal bereitgestellte Horizon-Pods unterstützt. Um eine Horizon Cloud Connector-Instanz zu aktualisieren, die mit einem in einer Cloud-Umgebung bereitgestellten Horizon-Pod gekoppelt ist, befolgen Sie die Anweisungen unter Manuelles Aktualisieren der virtuellen Horizon Cloud Connector-Appliance.
  • Der Horizon Image-Verwaltungsdienst (IMS) wird derzeit nur für eine Teilmenge der Horizon-Bereitstellungsmodelle unterstützt, die in der Horizon-Referenzarchitektur von VMware Tech Zone beschrieben sind. Informationen zu den aktuell von IMS unterstützten Bereitstellungsmodellen finden Sie in IMS-Systemanforderungen. Sobald weitere Modelle der Horizon-Referenzarchitektur für die IMS-Unterstützung qualifiziert sind, werden die neu unterstützten Modelle in die Liste aufgenommen.

Workspace ONE Hub Services und Universal Broker – Integration

  • Diese Funktion ist ausschließlich für VMware Workspace ONE® Access™ Cloud verfügbar. Sie wird nicht unterstützt, wenn VMware Workspace ONE Access lokal bereitgestellt ist.
  • Mit dieser Integration können Endbenutzer über den Hub-Katalog auf ihre Horizon Cloud-Desktops und -Anwendungen zugreifen. Stellen Sie sicher, dass Sie die erforderlichen Einstellungen für VMware Workspace ONE® Intelligent Hub konfigurieren, die unter Workspace ONE Access – Konfigurieren von Intelligent Hub für die Integration mit Horizon Cloud beschrieben werden.
  • In dieser Version unterstützt diese Integration den Endbenutzerzugriff über die folgenden Clients: browserbasierter Hub-Katalog, Workspace ONE Intelligent Hub für Windows und Workspace ONE Intelligent Hub für macOS. Die für diese Unterstützung erforderliche Mindestversion der Windows- und macOS-Desktop-Apps ist 21.05.
  • Kennwort-Caching ist in neuen Workspace ONE Access-Mandanten standardmäßig nicht aktiviert. Wenn True SSO in Ihrer Horizon-Umgebung nicht aktiviert ist, können Sie das Kennwort-Caching aktivieren, um die Kennwörter der Benutzer zwischenzuspeichern, sodass diese ihre Kennwörter nicht erneut eingeben müssen, wenn sie Horizon Cloud-Desktops und -Anwendungen starten. Weitere Informationen finden Sie unter Konfigurieren des Kennwort-Cachings für virtuelle Apps (nur Workspace ONE Access Cloud).
  • In Workspace ONE Access festgelegte Zugriffsrichtlinien gelten nicht für Anwendungen und Desktops aus einer Horizon Cloud-Umgebung, für die Universal Broker aktiviert ist.
  • Das gleichzeitige Starten mehrerer Endbenutzersitzungen in mehreren Clients auf demselben physischen Client-Endpoint wird nicht unterstützt. Mit anderen Worten: Endbenutzer können nicht mehr als eine Sitzung pro physischem Client-Endpoint für mehr als einen zugewiesenen virtuellen Desktop oder eine Remote-App starten, unabhängig davon, ob es sich um eine dedizierte oder eine flexible VDI-Desktop-Zuweisung handelt. So kann das System z. B. folgende Endbenutzererfahrung nicht bieten: Verwendung eines physischen Client-Systems, das an zwei Monitore nebeneinander angeschlossen ist, und gleichzeitige Ausführung von zwei separaten virtuellen Desktop-Sitzungen über dasselbe Client-System, wobei ein Desktop auf einem Monitor und der andere Desktop auf dem anderen Monitor angezeigt wird. Diese Einschränkung bedeutet, dass das System wie vorgesehen funktioniert.

Horizon Universal Console – Zugehörige Schwachstellen und Einschränkungen

  • Die Konsole ruft nicht die aktuell gültigen Namen Ihrer Active Directory-Benutzer und Gruppen ab , die bereits in den Details einer Zuweisung angegeben sind. Wenn Sie den Namen eines Benutzers oder einer Gruppe in Ihrem Active Directory ändern, zeigt die Konsole in den Zuweisungsdetails weiterhin den früheren Namen des Benutzers oder der Gruppe an, der beim anfänglichen Hinzufügen des Benutzers oder der Gruppe zur Zuweisung verwendet wurde. Bei der Bearbeitung einer Zuweisung und der Suche nach einem Benutzer oder einer Gruppe im Suchfeld werden die aktuellen effektiven Namen der Benutzer oder Gruppen in der Konsole angezeigt . Selbst nach dem Speichern der aktualisierten Zuweisung wird jedoch weiterhin der alte anfängliche Name in den Details der Zuweisung angezeigt. Diese Einschränkung hat keine funktionalen Auswirkungen.
  • Die webbasierte Verwaltungskonsole wird im Apple Safari-Browser nicht unterstützt. Einige Funktionen der Benutzeroberfläche funktionieren möglicherweise nicht ordnungsgemäß. In einem Mac OS-Betriebssystem können Sie anstelle von Apple Safari die Browser Chrome oder Firefox verwenden.
  • Ihre authentifizierte (angemeldete) Sitzung in der Konsole läuft ab, sobald die in der Konsole auf der Seite „Allgemeine Einstellungen“ konfigurierte Zeit erreicht ist. Die Standardeinstellung beträgt 30 Minuten. Wenn Sie über mindestens einen mit der Cloud verbundenen Pod verfügen, können Sie die Standardeinstellung auf einen Wert zwischen 30 Minuten und 180 Minuten ändern. In den meisten Fällen werden Sie bei Ablauf der konfigurierten Zeit automatisch vom System explizit abgemeldet und es wird eine Meldung mit dem Hinweis angezeigt, dass Sie sich erneut anmelden müssen. Manchmal beendet das System jedoch Ihre authentifizierte Sitzung und meldet Sie nicht explizit ab. In diesem Fall werden bei der Durchführung bestimmter Aufgaben in der Konsole möglicherweise Fehlermeldungen angezeigt, die den aktuellen Status nicht korrekt wiedergeben. Beispielsweise kann angegeben werden, dass der Assistent zur Knotenbereitstellung Ihre Abonnementeinträge nicht validieren kann, Werte in Dropdown-Menüs werden nicht angezeigt, oder auf der Farmseite weist eine Meldung darauf hin, dass kein Knoten zum Erstellen einer Farm verfügbar ist, sowie die Fehlermeldung „Es wurden keine service_sessions des Typs identity_node bereitgestellt“. Wenn ein solches Verhalten auftritt und Sie die Konsole bereits 30 Minuten oder länger verwenden, melden Sie sich manuell ab und wieder an.