Nutzen Sie die folgenden Informationen und die verlinkten Artikel, wenn Sie sich während des Onboardings Ihrer Pods und im Alltagseinsatz auf die Verwendung von First-Gen-Horizon Cloud oder First-Gen-Horizon-Steuerungsebenendiensten vorbereiten.

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.

Voraussetzungen für die Einrichtung, Software-Downloads, Persistenz von Benutzereinstellungen, Produktdokumentation und weitere hilfreiche Ressourcen

Voraussetzungen für die Einrichtung
Überprüfen Sie bei Microsoft Azure-Bereitstellungen vor dem Bereitstellen die Setup-Voraussetzungen.

Für das Onboarding Ihrer Horizon-Pods für Cloud-Plane-Dienste, einschließlich des Lizenzdiensts, lesen Sie die Beschreibungen des Typs der Bereitstellungsarchitektur, die Ihr Pod verwendet, und die Onboarding-Anleitung. Weitere Informationen finden Sie an folgenden Stellen:

Software-Downloads
Überprüfen Sie die Software-Downloads von VMware Customer Connect, die Sie eventuell für Ihre Umgebung benötigen. Auch wenn diese Downloads für den Start Ihrer Bereitstellung möglicherweise nicht zwingend erforderlich sind, sollten Sie sie je nach Anwendungsszenario vor der Bereitstellung überprüfen. Weitere Informationen finden Sie auf der VMware Horizon Cloud Service-Download-Seite; suchen Sie das neueste Datum der Dienstveröffentlichung und navigieren Sie zum Download-Link. Auf dieser Seite finden Sie die Zeile „Horizon Cloud Connector“, in der Sie auf Zu den Downloads klicken können, um die neueste Version des Installationsprogramms für den Horizon Cloud Connector und das VMware Universal Broker-Plug-in zu erhalten. Eine Tabelle mit der Version des VMware Universal Broker-Plug-In-Installationsprogramms mit dem jeweiligen Horizon-Verbindungsserver finden Sie in der Tabelle im Thema Horizon Pods – Installieren des Universal Broker-Plug-Ins auf dem Verbindungsserver.
Persistenz von Benutzereinstellungen
Für alle Microsoft Azure-Bereitstellungen können Sie die Persistenz von Benutzerprofilen mithilfe von VMware Dynamic Environment Manager™ mit Ordnerumleitung sicherstellen. Sie können die Dynamic Environment Manager-Software, die für die Verwendung mit dieser Version unterstützt wird, von der Download-Seite für VMware Horizon Cloud Service herunterladen und zum Download-Link für diese spezielle Version navigieren.
Produktdokumentation und weitere hilfreiche Ressourcen

Um auf die gesamte Produktdokumentation für alle Bereitstellungsmodelle zuzugreifen, rufen Sie die Zielseite für die VMware Horizon Cloud Service-Dokumentation auf.

Auf der Community-Website finden Sie hilfreiche Tipps und Sie können dort beliebige Fragen stellen. Im Abschnitt „Ressourcen“ der Horizon Cloud-Produktseite finden Sie auch technische Dokumente zu diesem Thema.

Wissenswertes zum Tag 0

Vor Ausführen eines Bereitstellungstyps
  • Wenn Ihre Horizon Cloud-Umgebung nicht in Ihre Workspace ONE-Umgebung integriert ist, erfolgt die Anmeldeauthentifizierung in der cloudbasierten Konsole über die Authentifizierung der Kontoanmeldedaten bei der VMware Cloud services-Plattform. Wenn dieser Dienst die erforderlichen Authentifizierungsanforderungen nicht abschließen kann, schlägt die Anmeldung bei der Konsole fehl. Wenn beim Anmelden beim ersten Anmeldebildschirm in der Konsole Probleme auftreten, überprüfen Sie die Seite VMware Workspace ONE-Status unter https://status.workspace.com, um den neuesten Systemstatus anzuzeigen. Auf dieser Seite können Sie sich auch für den Empfang von Updates registrieren.
  • Wenn Sie einen Pod mithilfe des Pod-Bereitstellungsassistenten der Konsole bereitstellen und einen Horizon-Pod über Horizon Cloud Connector verbinden, müssen bestimmte DNS-Namen erreichbar und bestimmte Ports und Protokolle zulässig sein. Informationen zu den Konnektivitätsanforderungen finden Sie unter First-Gen-Mandanten – Anforderungen an DNS, Ports und Protokolle bei Verwendung von Horizon Cloud Connector und einem Horizon-Pod, First-Gen-Mandanten – Horizon Cloud on Microsoft Azure-Bereitstellungen – Anforderungen an die Auflösung von Hostnamen, DNS-Namen und First-Gen-Mandanten – Horizon Cloud-Pod – Anforderungen an Ports und Protokolle.
  • Für alle mit der Horizon Cloud-Steuerungsebene gekoppelten Pods, die demselben Kundenkonto zugewiesen sind, muss eine Sichtverbindung mit den Active Directory-Domänen bestehen, die mit diesen Pods verbunden sind. Neben der Sichtverbindung ist auch eine unidirektionale oder bidirektionale Vertrauensstellung erforderlich. Wenn Sie z. B. drei Pods haben, von denen ein Pod in Microsoft Azure, ein Pod lokal und ein Pod in VMware Cloud on AWS vorhanden ist, benötigt jeder dieser Pods eine Sichtverbindung sowie eine unidirektionale oder bidirektionale Vertrauensstellung für denselben Satz an Active Directory-Domänen.
Vor dem Ausführen von Microsoft Azure-Bereitstellungen
  • Abonnements und Anzahl Pods: Legen Sie die Anzahl der für ein einzelnes Microsoft Azure-Abonnement bereitgestellten Pods sorgfältig fest, vor allem dann, wenn jeder Pod in einem großen Umfang ausgeführt werden soll. Auch wenn in einem einzelnen Microsoft Azure-Abonnement in einer Region oder über mehrere Regionen verteilt mehrere Pods bereitgestellt werden können, gelten für Microsoft Azure bestimmte Grenzwerte für ein einzelnes Abonnement. Aufgrund dieser Microsoft Azure-Grenzwerte erhöht eine große Anzahl von Pods in einem einzelnen Abonnement die Wahrscheinlichkeit, dass diese Grenzwerte erreicht werden. Zur Erreichung dieser Grenzwerte tragen eine Vielzahl von Variablen und Kombinationen dieser Variablen bei, wie z. B. die Anzahl der Pods, die Anzahl der Farmen und Zuweisungen in einem Pod, die Anzahl der Server in einem Pod, die Anzahl der Desktops in jeder Zuweisung, usw. Wenn Pods in einem großen Umfang ausgeführt werden sollen, ist möglicherweise die Verwendung mehrerer Abonnements unter einem Microsoft Azure-Konto sinnvoll. Microsoft Azure-Kunden können und bevorzugen häufig diese Vorgehensweise, da sie für die fortlaufende Verwaltung der Abonnements einige Vorteile bietet. Dabei wird pro Abonnement ein einziger Pod bereitgestellt und die Abonnements werden in einem einzelnen „primären Konto“ zusammengefasst. Dies reduziert die Wahrscheinlichkeit, dass die Microsoft Azure-Grenzwerte für ein einzelnes Abonnement erreicht werden.
  • Ausgehender Internetzugriff ist im virtuellen Microsoft Azure-Netzwerk (VNet) erforderlich, das von den Pod-Manager-VMs der Bereitstellung verwendet wird. Proxy-basierte Authentifizierung wird für eine Horizon Cloud on Microsoft Azure-Bereitstellung unterstützt. Sie müssen Ihre Proxy-Details im Pod-Bereitstellungsassistenten angeben. Für die Bereitstellung von Pods müssen bestimmte DNS-Namen erreichbar und bestimmte Ports und Protokolle zulässig sein. Informationen zu den Konnektivitätsanforderungen finden Sie unter First-Gen-Mandanten – Horizon Cloud on Microsoft Azure-Bereitstellungen – Anforderungen an die Auflösung von Hostnamen, DNS-Namen.
  • Subnetzdimensionierung: Momentan wir eine Erweiterung der Größe der Subnetze nach der Bereitstellung des Pods nicht unterstützt. Deshalb sollten Sie für Produktionsumgebungen Subnetz-Größen verwenden, die die folgenden Anforderungen erfüllen können:
    • Management-Subnetz: Wenn Sie einen Pod bereitstellen, ist für das Management-Subnetz des Pods seit März 2019 mindestens CIDR /27 erforderlich, nachdem für frühere Versionen eine Untergrenze von CIDR /28 galt. Diese Änderung wurde vorgenommen, um die Probleme zu reduzieren, die aufgrund fehlender verfügbarer IP-Adressen im Subnetz bei der Aktualisierung von Pods auftreten können. CIDR /27 ermöglicht 32 IP-Adressen.
    • VM-Subnetz – primär: Verwenden Sie CIDR in einem Bereich, der groß genug ist, um die VMs für Ihre erwarteten VDI-Desktops, RDS-Images und alle VMs in den RDS-Farmen des Pods zu unterstützen. Die Pod-Manager-VMs und die Unified Access Gateway-VMs benötigen ebenfalls einige IP-Adressen aus diesem Subnetz (insgesamt 12 Adressen, um die Blue-Green-Aktualisierung eines HA-fähigen Pods mit beiden Arten von Gateways zu ermöglichen). Im Allgemeinen ist der Bereich von /24 bis /21 für typische Anwendungsfälle ausreichend. Hinweis: Manchmal wird dieses VM-Subnetz auch als Desktop-Subnetz oder Mandanten-Subnetz bezeichnet.
    • Ab der Dienstversion vom Juli 2020 und dem Pod-Manifest 2298.0 ermöglicht eine neue Funktion die Verwendung zusätzlicher Mandanten-Subnetze für Ihre VDI-Desktops und RDS-Farm-VMs. Diese zusätzlichen Subnetze können sich im selben VNet wie der Pod oder in Peer-VNets befinden. Für einen Pod mit Manifest 2298.0 oder höher können Sie die Konfiguration bearbeiten, um diese zusätzlichen Subnetze einzubeziehen. Dann können Sie die zusätzlichen Mandanten-Subnetze in den Definitionen Ihrer Farmen und VDI-Desktop-Zuweisungen angeben, sodass diese statt des primären VM-Subnetzes verwendet werden. Die Verwendung dieser sekundären Subnetze für Ihre Farm-VMs und VDI-Desktop-VMs vereinfacht die Verwaltung, da Sie angeben können, welche Farmen und VDI-Desktop-Zuweisungen sich in welchem Mandanten-Subnetz und -VNet befinden.
  • Damit die Funktion das externe Gateway in seinem eigenen VNet bereitstellen kann, müssen die VNets verbunden werden. Daher müssen Sie die Subnetze vor der Ausführung des Bereitstellungsassistenten manuell erstellen. Für das VNet des externen Gateways müssen dessen Verwaltungs-Subnetz und Back-End-Subnetz jeweils den gleichen CIDR /27-Mindestwert aufweisen.
Vor dem Verbinden von Pods mit Horizon Cloud Connector
  • Neue Bereitstellungen sollten die neueste Version von Horizon Cloud Connector herunterladen und verwenden, die unter VMware Customer Connect verfügbar ist und mit der Horizon Connection Server-Softwareversion des Pods kompatibel ist. Die Verwendung der neuesten Version stellt sicher, dass Sie die neuesten Fixes und Verbesserungen nutzen können. Die Kompatibilitätsmatrix zwischen Horizon Cloud Connector und Horizon Connection Server finden Sie unter VMware-Produkt-Interoperabilitätsmatrix. Überprüfen Sie die Interoperabilität zwischen den beiden Lösungsnamen VMware Horizon Cloud Connector und VMware Horizon.
  • Ein ausgehender Internetzugriff ist erforderlich, damit Horizon Cloud Connector mit der Cloud-Ebene des Diensts kommunizieren kann, insbesondere um die Lizenzierungsdetails zu erhalten. Bestimmte DNS-Namen müssen erreichbar und bestimmte Ports und Protokolle zulässig sein. Informationen zu den Konnektivitätsanforderungen finden Sie unter First-Gen-Mandanten – Anforderungen an DNS, Ports und Protokolle bei Verwendung von Horizon Cloud Connector und einem Horizon-Pod.
  • Bevor Sie einen zweiten Horizon-Pod mit Horizon Cloud verbinden, sollten Sie sich bei der Horizon Cloud-Verwaltungskonsole anmelden und den Active Directory-Domänenregistrierungsprozess abschließen, nachdem Sie Ihren ersten Horizon-Pod über den Onboardingprozess von Horizon Cloud Connector verbunden haben. Wenn Sie mehrere Horizon-Pods mit Horizon Cloud koppeln, bevor Sie diese Active Directory-Domänenregistrierung abschließen, können unerwartete Ergebnisse auftreten, wenn Sie sich schlussendlich bei der Konsole anmelden, um den Domänenregistrierungsprozess zu starten.
  • Aufgrund eines bekannten Problems kann es bei Verwendung einer lokalen Active Directory-Domäne zur Wartung eines Pods in VMware Cloud on AWS zu langsamen Zugriffszeiten kommen. Grund hierfür ist eine Netzwerklatenz oder Netzwerküberlastung zwischen der lokalen Active Directory-Domäne und dem Pod in VMware Cloud on AWS, die dazu führt, dass es bei Aufrufen der Domäne zu Zeitüberschreitungen kommt. Zu den typischen Symptomen dieser Latenz zählt u. a., dass die Anmeldung über den Active Directory-Anmeldebildschirm nicht abgeschlossen werden kann, bevor es zu einer Zeitüberschreitung kommt. Wenn solche Symptome auftreten, kann die Konfiguration eines beschreibbaren Domänencontrollers in jedem Software-Defined Data Center (SDDC) in der Cloud hilfreich sein.

Informationen zu einigen betrieblichen E-Mails des Diensts

Ab der Dienstversion von April 2021 enthalten einige der betrieblichen E-Mails des Systems standardmäßig für jeden Kundendatensatz, der mit einem designierten VMware-Kundenkontomitarbeiter verknüpft ist, die E-Mail-Adressen der angegebenen VMware-Kundenkontomitarbeiter im BCC-Feld. Die Einbeziehung der VMware-Kundenkontomitarbeiter in das BCC-Feld der E-Mails dient dazu, ein besseres Onboarding und bessere Geschäftskontinuität sicherzustellen.

Die betrieblichen E-Mails, die VMware-Kundenkontomitarbeiter im BCC-Feld enthalten, sind:

  • Bei der anfänglichen Erstellung Ihres Kundendatensatzes für den Dienst werden ein Kundenname und eine E-Mail-Adresse als Besitzer im neu erstellten Kundendatensatz angegeben. Eine Begrüßungs-E-Mail wird an die E-Mail-Adresse gesendet, die mit diesem Besitzer-Kundennamen verknüpft ist.
  • Wenn Aktualisierungen im Zusammenhang mit diesem Besitzer – zum Beispiel eine aktualisierte E-Mail-Adresse – erfolgen, wird eine Benachrichtigungs-E-Mail gesendet.
  • Wenn es zu Aktualisierungen im Zusammenhang mit den Horizon-Lizenzen des Kundendatensatzes kommt, wird eine Benachrichtigungs-E-Mail gesendet.