Der Zweck dieser Checkliste besteht darin, Sie über die erforderlichen Elemente für eine Horizon Cloud on Microsoft Azure-Bereitstellung zu informieren. Wenn Sie diese Checkliste befolgen, können Sie den Pod-Bereitsteller erfolgreich ausführen und die Tag-1-Aufgaben abschließen.
Checklisten-Zielgruppe
Diese Checkliste gilt in erster Linie für Horizon Cloud-Kundenkonten, über die vor dem Datum der Dienstfreigabe am 20. Oktober 2022 noch nie eine Horizon Cloud on Microsoft Azure-Bereitstellung in der Mandantenumgebung stattgefunden hat. Solche Mandanten werden oft als saubere (clean-slate) Umgebungen oder Umgebungen auf der grünen Wiese (greenfield) bezeichnet.
Der hier beschriebene Satz gilt in erster Linie für Produktionsbereitstellungen. Test- und die meisten Proof-of-Concept-Bereitstellungen können in der Regel mit einer Teilmenge durchgeführt werden, wie in einer vereinfachten Proof-of-Concept-Bereitstellung dargestellt.
Einige der unten aufgeführten Abschnitte müssen vor der Ausführung des Assistenten für die Bereitstellung eines neuen Pods eingerichtet werden.
Einige Elemente können verschoben werden, bis die Bereitstellung abgeschlossen ist und ausgeführt wird.
Einige Elemente sind als optional aufgeführt, da sie sich auf die Optionen beziehen, die Sie für Ihre Horizon Cloud on Microsoft Azure-Bereitstellung treffen.
Beispielsweise können Sie den Assistenten für neue Pods ausführen, ohne eine Unified Access Gateway-Konfiguration auszuwählen, und die Gateway-Konfiguration später hinzufügen. In diesem Fall brauchen Sie die Unified Access Gateway-Anforderungen erst zu einem späteren Zeitpunkt erfüllen.
| Erfüllen Sie diese, bevor Sie den Assistenten für neue Pods ausführen. | Kann nach der Bereitstellung des Pods erledigt werden |
|---|---|
|
|
Einige wichtige Überlegungen
Wenn Sie eine Test- oder Proof-of-Concept-Bereitstellung von Horizon Cloud on Microsoft Azure durchführen, sind Sie möglicherweise der Besitzer des Microsoft Azure-Abonnements, das Sie für die Bereitstellung verwenden werden – oder Sie führen das Proof-of-Concept im Auftrag einer Organisation durch, der das Abonnement gehört.
Der Besitzer des Abonnements muss sicherstellen, dass keine der Microsoft Azure-Richtlinien, die im Abonnement des Pods in Kraft sind, die Erstellung der Pod-Komponenten blockieren, verweigern oder einschränken.
Der Grund dafür ist, dass der Pod-Bereitsteller während des Pod-Bereitstellungsvorgangs API-Aufrufe verwendet, um Ressourcen innerhalb des Abonnements zu erstellen, das im Assistenten für neue Pods angegeben ist. Wenn in diesem Abonnement Microsoft Azure-Richtlinien in Kraft sind, die die Erstellung der Pod-Komponenten blockieren, verweigern oder einschränken würden, ist die Bereitstellung nicht erfolgreich und erfordert eine Support-Anfrage an den VMware-Support.
Ein Beispiel: Der Pod-Bereitsteller verlangt, dass keine der Microsoft Azure-Richtlinien, die im Abonnement des Pods in Kraft sind, die Erstellung von Komponenten auf dem Azure-Speicherkonto blockieren, verweigern oder einschränken.
Bevor Sie den Assistenten für neue Pods ausführen, vergewissern Sie sich beim Besitzer des Abonnements, dass die Definitionen der integrierten Microsoft Azure-Richtlinien die Erstellung der Pod-Komponenten nicht blockieren, verweigern oder einschränken.
Anforderungen an die Horizon Cloud-Steuerungsebene
| ☐ | VMware Customer Connect-Konto, das von VMware für die Anmeldung bei der Horizon Cloud-Steuerungsebene konfiguriert wurde. Eine Übersicht über die Beziehung dieses Kontos zu Ihrem Horizon Cloud-Mandantenkonto finden Sie auf der Seite Horizon Service-Bereitstellungen und Onboarding von Pods. |
Anforderungen für Microsoft Azure-Abonnements
| ☐ | Gültiges Microsoft Azure-Abonnement in einer unterstützten Microsoft Azure-Umgebung (Azure Commercial, Azure China und Azure Government). Wenn Sie das externe Unified Access Gateway in einem eigenen VNet mit einem eigenen Abonnement bereitstellen, müssen Sie ein zusätzliches gültiges Microsoft Azure-Abonnement in derselben Microsoft Azure-Umgebung erwerben.
Hinweis:
Horizon Cloud unterstützt die Mehrheit der Microsoft Azure-Regionen. Eine Auflistung der derzeit nicht unterstützten Microsoft Azure-Regionen finden Sie im
VMware Knowledgebase-Artikel „Microsoft Azure-Regionen mit Horizon Cloud Service für Microsoft Azure (77121)“.
|
| ☐ | Gültige Microsoft Azure-Administrationsrechte in diesem Microsoft Azure-Abonnement, damit Sie das Microsoft Azure-Portal verwenden und die Schritte zur Vorbereitung der Pod-Bereitstellung durchführen können. |
| ☐ | Horizon Cloud-App-Registrierung und geheimer Clientschlüssel, der im Abonnement des Pods erstellt wurde. Siehe Erstellen einer Horizon Cloud-App-Registrierung im Abonnement des Pods. Wenn Sie oder Ihre Organisation die Funktion zur Bereitstellung der externen Gateway-Konfiguration in einem vom Pod-Abonnement getrennten Abonnement verwenden, benötigt dieses Gateway-Abonnement ebenfalls eine Horizon Cloud-App-Registrierung und einen geheimen Clientschlüssel. |
| ☐ | Durch das Erstellen der Horizon Cloud-App-Registrierung in einem Abonnement wird automatisch ein Dienstprinzipal gemäß dem standardmäßigen Microsoft Azure-Verhalten erstellt. Weisen Sie diesem Dienstprinzipal eine Rolle zu, die es Horizon Cloud ermöglicht, API-Aufrufe im Abonnement des Pods durchzuführen. Normalerweise wird die Rolle Alternativ kann die Rolle eine benutzerdefinierte Rolle sein, die auf der Abonnementebene des Pods zugewiesen wird. Wenn Sie die Konfiguration des externen Gateways in einer vorhandenen Ressourcengruppe in einem separaten Abonnement bereitstellen, können Sie entweder eine benutzerdefinierte Rolle oder die Rolle Wenn Sie oder Ihre Organisation für die Horizon Cloud-App-Registrierung eine benutzerdefinierte Rolle verwenden möchten, lesen Sie die folgende Seite, auf der die Aktionen beschrieben werden, die diese benutzerdefinierte Rolle aufweisen muss – Wenn Ihre Organisation die Verwendung einer benutzerdefinierten Rolle bevorzugt.
Hinweis: Die Rolle muss dem Dienstprinzipal der
Horizon Cloud-App-Registrierung direkt zugewiesen werden. Die Verwendung einer gruppenbasierten Zuweisung einer Rolle zu diesem Dienstprinzipal wird nicht unterstützt.
|
| ☐ | Erforderliche Ressourcenanbieter sind in jedem Microsoft Azure-Abonnement registriert. Weitere Informationen finden Sie unter Registrieren von Ressourcenanbietern. |
| ☐ | Abonnement-ID, Verzeichnis-ID, Anwendungs-ID und Schlüssel für das Abonnement, das Sie im Bereitstellungsassistenten angeben. |
| ☐ | Das Abonnement muss die Verwendung des Azure StorageV2-Kontotyps zulassen. Stellen Sie sicher, dass die Microsoft Azure-Richtlinien des Abonnements die Erstellung von Inhalten, die den Kontotyp Azure StorageV2 erfordern, nicht einschränken oder ablehnen. |
| ☐ | Das Abonnement muss die Erstellung von Ressourcengruppen ohne Tags zulassen, es sei denn, Sie geben benutzerdefinierte Ressourcen-Tags im Pod-Bereitstellungsassistenten an. Bei der Pod-Bereitstellung werden Ressourcengruppen im Abonnement des Pods ohne Tags erstellt, es sei denn, Sie geben benutzerdefinierte Ressourcen-Tags im Assistenten an. Wenn Sie nicht planen, die Funktion für benutzerdefinierte Ressourcen-Tags des Bereitstellungsassistenten zu verwenden, müssen Sie sicherstellen, dass Ihre Microsoft Azure-Richtlinien das Erstellen der nicht markierten Ressourcengruppen des Pods im Zielabonnement ermöglichen. Wenn Sie im Assistenten keine benutzerdefinierten Ressourcen-Tags angeben und Ihr Microsoft Azure-Abonnement bestimmte Ressourcen-Tag-Anforderungen aufweist, schlägt die Pod-Bereitstellung fehl, wenn Sie versuchen, einen Pod in diesem Abonnement bereitzustellen. Die Pod-Bereitstellung kann bei Pod-Aktualisierungen oder beim Hinzufügen einer Gateway-Konfiguration zu einem Pod fehlschlagen. Die Namen der vom Bereitsteller erstellten Ressourcengruppen finden Sie unter Ressourcengruppen, die vom Pod-Bereitsteller erstellt werden. |
| ☐ | Optional. Wenn Ihre Organisation vorschreibt, dass Sie eine bestimmte, vorab erstellte und von der Organisation benannte Ressourcengruppe für das externe Unified Access Gateway in einem vom Pod-Abonnement getrennten VNet und Abonnement verwenden müssen, würden Sie die Funktion verwenden, um das externe Unified Access Gateway in Ihrer eigenen benannten Ressourcengruppe bereitzustellen. Wenn Sie diese Funktion nicht verwenden, erstellt der Pod-Bereitsteller automatisch eine Ressourcengruppe mit seiner eigenen Namenskonvention. Um diese Funktion zu verwenden, müssen Sie diese Ressourcengruppe in dem Abonnement erstellen, bevor Sie den Pod-Bereitsteller ausführen. Sie müssen außerdem sicherstellen, dass die erforderlichen Berechtigungen für den Pod-Bereitsteller vorhanden sind, damit er die Unified Access Gateway-Konfiguration in dieser Ressourcengruppe bereitstellen, die Konfiguration verwalten und die Unified Access Gateway-Software im standardmäßigen Pod-Aktualisierungsvorgang aktualisieren kann. Weitere Informationen zu den erforderlichen Berechtigungen für die benutzerdefinierte Rolle finden Sie unter Wenn Ihre Organisation die Verwendung einer benutzerdefinierten Rolle bevorzugt. |
Anforderungen an Microsoft Azure-Kapazität
Wenn sich die folgende Tabelle auf die Microsoft Azure-Kapazität bezieht, ist keine manuelle Installation erforderlich. Solange die angegebenen Kapazitäten im Abonnement verfügbar sind, instanziiert der Pod-Bereitsteller automatisch die beschriebenen VMs.
Für Kapazitäten, die VM-Familien betreffen, verwendet das Microsoft Azure-Portal auch den Begriff Kontingent.
| ☐ | Microsoft Azure-Kapazität für die Kern-Horizon Cloud-Pod-Artefakte, die in diesem Abonnement bereitgestellt werden sollen. (Diese Liste schließt die Kapazitäten aus, die für die optionalen Unified Access Gateway-Konfigurationen und für Ihre erwarteten Desktop- und App-Arbeitslasten erforderlich sind.)
|
| ☐ | Optional. Kapazität, die bei der Angabe der Verwendung von Unified Access Gateway für den Pod erforderlich ist.
Hinweis: Das
A4_v2-VM-Modell reicht nur für Proof-of-Concept (PoCs), Pilotversuche oder kleinere Umgebungen aus, in denen Sie wissen, dass Sie 1.000 aktive Sitzungen auf dem Pod nicht überschreiten werden.
Falls die Region Ihres Abonnements die Größen von |
Netzwerkanforderungen
| ☐ | Virtuelles Microsoft Azure-Netzwerk (VNet), das in der gewünschten Microsoft Azure-Region mit dem anwendbaren Adressbereich zur Abdeckung der erforderlichen Subnetze erstellt wurde. Siehe Konfigurieren des erforderlichen virtuellen Netzwerks in Microsoft Azure. Wenn Sie das externe Unified Access Gateway in einem eigenen, vom VNet des Pods getrennten VNet bereitstellen, müssen Sie dieses VNet des Unified Access Gateway in derselben Microsoft Azure-Region erstellen wie das VNet des Pods mit anwendbarem Adressbereich, um erforderliche Subnetze abzudecken, und die beiden VNets als Peers verbinden. |
| ☐ | 3 sich nicht überschneidende Adressbereiche im CIDR-Format im VNet des Pods, reserviert für Subnetze.
Tipp: Nach der Bereitstellung des Pods können Sie den Pod bearbeiten, um Mandantensubnetze zur Verwendung mit den VMs in Ihren Farmen und Desktop-Zuweisungen hinzuzufügen. Die zusätzlichen Mandanten-Subnetze können sich in demselben VNet befinden, in dem der Pod bereitgestellt ist, oder in einem Peer-VNet. Weitere Informationen finden Sie unter
Übersicht über die Verwendung mehrerer Mandantensubnetze.
|
| ☐ | Bei der Bereitstellung des externen Unified Access Gateway in einem eigenen, vom VNet des Pods getrennten VNet 3 sich nicht überschneidende Adressbereiche im CIDR-Format im VNet des Unified Access Gateway, reserviert für Subnetze.
|
| ☐ | NTP-Server verfügbar und über den Horizon Cloud-Pod und Unified Access Gateway-Instanzen zugänglich. |
| ☐ | Konfigurieren Sie den DNS-Server des VNet (virtuellen Netzwerks) und verweisen Sie auf einen gültigen DNS-Server, der sowohl interne Computernamen als auch externe Namen auflösen kann. |
| ☐ | Ausgehender Internetzugriff aus den VNets, die Sie für die Pod- und Gateway-Bereitstellung verwenden, muss bestimmte DNS-Namen unter Verwendung bestimmter Ports und Protokolle auflösen und erreichen können. Dies ist für die Bereitstellung und den laufenden Betrieb erforderlich. Eine Liste der DNS-Namen und -Ports finden Sie unter DNS-Anforderungen und Anforderungen für Ports und Protokolle. |
| ☐ | Optional. Proxy-Serverinformationen bei Bedarf für ausgehenden Internetzugriff auf dem VNet, das während der Bereitstellung und des laufenden Betriebs der Horizon Cloud-Umgebung verwendet wird. |
| ☐ | Optional. Microsoft Azure VPN/Express Route konfiguriert, wenn Sie ein Netzwerk zwischen dem VNet und Ihrem lokalen Unternehmensnetzwerk herstellen möchten. |
Port- und Protokollanforderungen
| ☐ | Für das Onboarding von Pods und den laufenden Betrieb Ihrer Horizon Cloud-Umgebung sind bestimmte Ports und Protokolle erforderlich. Weitere Informationen finden Sie unter Ports und Protokolle. |
Unified Access Gateway-Anforderungen
Sie können den Assistenten für neue Pods ausführen, ohne eine Unified Access Gateway-Konfiguration auszuwählen, und die Gateway-Konfiguration später hinzufügen. In diesem Fall brauchen Sie die Unified Access Gateway-Anforderungen erst zu einem späteren Zeitpunkt erfüllen. Definitionsgemäß ermöglicht ein externes Unified Access Gateway Clients in externen Netzwerken den Start der virtuellen Desktops und Apps, während ein internes Unified Access Gateway Clients in internen Netzwerken vertrauenswürdige HTML Access (Blast)-Verbindungen ermöglicht. Um Endbenutzerverbindungen aus dem Internet zu unterstützen und die jeweiligen virtuellen Desktops und Anwendungen zu starten, muss für den Pod ein externes Unified Access Gateway konfiguriert sein.
Wenn Sie die Unified Access Gateway-Optionen im Assistenten für neue Pods auswählen, verlangt der Assistent die folgenden Elemente.
| ☐ | FQDN für die Unified Access Gateway-Konfiguration. |
| ☐ | Zertifikat oder Zertifikate für das Unified Access Gateway im PEM-Format, das dem FQDN entspricht.
Hinweis: Wenn das Zertifikat oder die Zertifikate, die Sie für diesen Zweck bereitstellen, CRLs (Zertifikatsperrlisten) oder OCSP (Online Certificate Status Protocol)-Einstellungen verwenden, die sich auf bestimmte DNS-Namen beziehen, müssen Sie sicherstellen, dass der ausgehende Internetzugriff aus dem VNet diese DNS-Server auflösen und erreichen kann. Während der Konfiguration Ihres bereitgestellten Zertifikats in der
Unified Access Gateway-Gateway-Konfiguration greift die
Unified Access Gateway-Software auf diese DNS-Namen zu, um den Sperrstatus des Zertifikats zu überprüfen. Wenn diese DNS-Namen nicht erreichbar sind, schlägt die Bereitstellung des Pods während der Phase
Verbindung fehl. Diese Namen sind in hohem Maße von der Zertifizierungsstelle abhängig, die Sie zum Abrufen der Zertifikate verwendet haben. Sie unterliegen daher nicht der Kontrolle von VMware.
|
| ☐ | Optional, außer wenn Sie möchten, dass Ihre Endbenutzer die Zwei-Faktor-Authentifizierung verwenden. In diesem Fall muss der Unified Access Gateway für die Zwei-Faktor-Authentifizierung mit einem der Authentifizierungssystemtypen konfiguriert werden, die für die Verwendung mit Horizon Cloud on Microsoft Azure-Bereitstellungen unterstützt werden. Die Konfiguration sollte Folgendes umfassen:
Hinweis: Nachdem der Pod bereitgestellt wurde und Sie die Zwei-Faktor-Authentifizierung in den
Universal Broker-Einstellungen konfiguriert haben, sind einige zusätzliche Konfigurationsschritte erforderlich, wenn Sie möchten, dass auch Ihre internen Endbenutzer die Zwei-Faktor-Authentifizierung überspringen. Wenn ein Pod über eine interne
Unified Access Gateway-Konfiguration verfügt, leitet diese Konfiguration die Verbindungsanforderungen an virtuelle Desktops und Apps für solche internen Endbenutzer weiter. Wenn
Universal Broker den Schritt für die Zwei-Faktor-Authentifizierung für Ihre internen Endbenutzer überspringen soll, geben Sie nach der Bereitstellung des Pods und der Konfiguration von
Universal Broker die Bereiche der Egress-NAT-Adressen ein, die Ihrem internen Endbenutzerdatenverkehr entsprechen. Mit diesen Bereichen kann
Universal Broker Datenverkehr des Clients von den internen Endbenutzern identifizieren, die sich von den externen Endbenutzern unterscheiden, um die Zwei-Faktor-Authentifizierung zu überspringen. Weitere Informationen finden Sie im Dokumentationsthema
Definieren von internen Netzwerkbereichen für Universal Broker
|
Pod-Bereitstellungsworkflow
Die vorstehenden Elemente sind diejenigen, die vor dem Start des Pod-Bereitstellungsassistenten benötigt werden. Nachdem Sie sichergestellt haben, dass Sie über die vorstehenden Elemente verfügen, führen Sie die unter Horizon Cloud on Microsoft Azure – Bereitstellung des ersten Pods – Allgemeiner Workflow beschriebenen Pod-Bereitstellungsschritte bis Schritt 4 aus, um Ihren Pod bereitzustellen.
Nachdem der Pod erfolgreich bereitgestellt wurde, stellen Sie sicher, dass die im folgenden Abschnitt beschriebenen Elemente vorhanden sind, damit Sie die übrigen wichtigen Schritte dieses allgemeinen Workflows abschließen können.
Active Directory-Anforderungen
Der Workflow für die Active Directory-Registrierung der Konsole schreibt die folgenden Elemente vor. Umfassende Informationen zu diesem Workflow finden Sie unter Durchführen der ersten Active Directory-Domänenregistrierung in der Horizon Cloud-Umgebung.
| ☐ | Eine der folgenden unterstützten Active Directory-Konfigurationen:
|
| ☐ | Unterstützte Domänenfunktionsebenen von Active Directory Domain Services (AD DS):
|
| ☐ | Alle mit der Cloud verbundenen Pods im selben Horizon Cloud-Kundenkonto müssen zum Zeitpunkt der Bereitstellung dieser Pods für denselben Satz von Active Directory-Domänen sichtbar sein. Diese Anforderung gilt nicht nur für zusätzliche Pods, die Sie nach dem ersten Pod in Microsoft Azure bereitstellen, sondern auch für die Horizon-Pods, die über Horizon Cloud Connector und per Cloud mit dem gleichen Kundenkonto verbunden sind. |
| ☐ |
Referenz: Dienstkonten, die Horizon Cloud für seine Vorgänge benötigt. |
| ☐ |
Referenz: Dienstkonten, die Horizon Cloud für seine Vorgänge benötigt. |
| ☐ |
Weitere Informationen finden Sie unter Dienstkonten, die Horizon Cloud für seine Vorgänge benötigt. Wenn Sie in Microsoft Active Directory eine neue OE erstellen, legt das System möglicherweise automatisch das Attribut |
| ☐ |
Weitere Informationen finden Sie unter Dienstkonten, die Horizon Cloud für seine Vorgänge benötigt. Wenn Sie in Microsoft Active Directory eine neue OE erstellen, legt das System möglicherweise automatisch das Attribut |
| ☐ | Active Directory-Gruppen
Horizon Cloud unterstützt die Verwendung von Active Directory-Sicherheitsgruppen sowohl für Administratoranmeldungen als auch für Endbenutzerberechtigungen. Verschachtelte Gruppen werden unterstützt. Die Gruppenmitgliedschaft wird durch die Abfrage des berechneten Attributs tokenGroups bewertet, d. h. Horizon Cloud hat keine Einschränkungen hinsichtlich der Verschachtelungstiefe, sondern unterstützt die in Ihrem Active Directory festgelegten Einstellungen. Auf die Frage, ob es zusätzliche Überlegungen oder Einschränkungen im Zusammenhang mit Active Directory-Gruppen und der Kombination von Horizon Cloud plus Universal Broker plus Workspace ONE Access Cloud gibt, lautet die Antwort: Nein, keine. Wenn in Ihrer Mandantenumgebung Horizon Cloud-Pods in Microsoft Azure mit Manifesten vor 1600.0 ausgeführt werden, müssen sich das Domänenbeitrittskonto sowie alle zusätzlichen Domänenbeitrittskonten ebenfalls in der Gruppe „Horizon Cloud-Administratoren“ oder in einer Active Directory-Gruppe befinden, der die Rolle Superadministrator in Horizon Cloud erteilt wurde. |
| ☐ | Active Directory-Organisationseinheit (OU) bzw. -einheiten (OUs) für virtuelle Desktops und RDS-sitzungsbasierte Desktops oder veröffentlichte Anwendungen oder beides. Wenn Sie in Microsoft Active Directory eine neue OE erstellen, legt das System möglicherweise automatisch das Attribut |
Wenn Sie eine für LDAPS konfigurierte Active Directory verwenden möchten, müssen Sie die Aktivierung der von LDAPS unterstützten Funktionen mit Ihrem Horizon Cloud-Mandanten anfordern. Weitere Informationen finden Sie unter Verwenden von für LDAPS konfigurierten Active Directory-Umgebungen.
Universal Broker-Konfiguration
Stellen Sie bei der Konfiguration des Universal Brokers sicher, dass Sie die Punkte aus der folgenden Tabelle erfüllen, die auf die von Ihnen gewünschten Optionen zutreffen. Ausführliche Informationen finden Sie unter Konfigurieren von Universal Broker.
| ☐ | Ausgehender Internetzugriff der VNets, die Sie für den Pod verwenden, muss bestimmte DNS-Namen auflösen und über bestimmte Ports und Protokolle erreichen können. Dies ist für die Universal Broker-Konfiguration und den laufenden Betrieb erforderlich. Eine Liste der DNS-Namen und Ports finden Sie unter Horizon Cloud on Microsoft Azure-Bereitstellungen – Anforderungen an die Auflösung von Hostnamen, DNS-Namen und Horizon Cloud-Pod – Anforderungen an Ports und Protokolle. |
| ☐ | Abhängig von den Typen der Endbenutzerverbindungen, die Sie bereitstellen möchten, gilt Folgendes:
|
| ☐ | Optional. Wenn Universal Broker die Zwei-Faktor-Authentifizierung erzwingen soll, müssen Pods über ein externes Unified Access Gateway verfügen, die für die Zwei-Faktor-Authentifizierung mit einem der Authentifizierungssystemtypen konfiguriert ist, die für die Verwendung mit Horizon Cloud on Microsoft Azure-Bereitstellungen unterstützt werden. Universal Broker übergibt die Authentifizierungsanforderung an das Unified Access Gateway, das mit dem Authentifizierungsserver kommuniziert, und leitet die Antwort dann zurück an Universal Broker. Für diese externe Unified Access Gateway-Konfiguration sind die folgenden Elemente erforderlich:
|
| ☐ | Optional: Ein benutzerdefinierter FQDN, den Ihre Endbenutzer für den Zugriff auf den Universal Broker-Dienst und das auf diesem FQDN basierende Zertifikat verwenden. Wenn Sie den von VMware bereitgestellten Brokering-FQDN verwenden möchten, ist kein benutzerdefinierter FQDN erforderlich. |
Anforderungen an den DNS-Datensatz
Nachdem der Pod in der Microsoft Azure-Cloud bereitgestellt wurde und abhängig von Ihrer Geschäftssituation und den Funktionen, die Sie nutzen möchten, ist es wichtig, Datensätze in Ihrem DNS-Server einzurichten, die vollqualifizierte Domänennamen (FQDNs) den IP-Adressen des Pods zuordnen. Hintergrundinformationen zur DNS-Datensatzzuordnung finden Sie auf der Microsoft Cloud Services-Dokumentationsseite Konfigurieren eines benutzerdefinierten Domänennamens für einen Azure-Clouddienst.
- Wenn Sie den Universal Broker des Mandanten mit einem benutzerdefinierten FQDN konfigurieren
-
☐ Erstellen Sie einen öffentlichen DNS-Datensatz, der Ihren benutzerdefinierten FQDN dem von VMware bereitgestellten Brokering-FQDN in Ihrer Universal Broker-Konfiguration zuweist. Siehe Konfigurieren von Universal Broker. - Wenn der Pod über ein externes Unified Access Gateway verfügt
-
☐ Erstellen Sie einen öffentlichen DNS-Datensatz für den externen Endbenutzerzugriff, der dem FQDN in der Konfiguration des externen Gateways entspricht. Dieser DNS-Datensatz verweist diesen FQDN auf den externen Microsoft Azure-Lastausgleichsdienst in der externen Unified Access Gateway-Konfiguration des Pods. Hintergrundinformationen zur DNS-Datensatzzuordnung finden Sie auf der Microsoft-Dokumentationsseite Konfigurieren eines benutzerdefinierten Domänennamens für einen Azure-Clouddienst.
- Wenn der Pod über ein internes Unified Access Gateway verfügt
-
☐ Erstellen Sie einen internen DNS-Datensatz für den internen Endbenutzerzugriff, der dem FQDN in der internen Gateway-Konfiguration entspricht. Dieser DNS-Datensatz übergibt diesen FQDN an den internen Microsoft Azure-Lastausgleichsdienst in der internen Unified Access Gateway-Konfiguration des Pods.
Golden Images, Desktops und Farmen für Horizon Cloud
Ihr Microsoft Azure-Abonnement muss die folgenden Anforderungen erfüllen, die von den Typen der Golden Images, VDI-Desktops und RDS-Farmen abhängig sind, die Sie über den bereitgestellten Pod bereitstellen möchten.
Beachten Sie auch die folgende Supportmatrix für die Verwendung der Microsoft Azure VM-Modelle Generation 1 VM, Generation 2 VM, in Bezug auf die Gastbetriebssysteme Windows 10 und Windows 11.
| Azure-VM-Modell | Windows 10 | Windows 11 |
|---|---|---|
| Generation 1 VM | Unterstützt | Nicht unterstützt |
| Generation 2 VM | Nicht unterstützt | Unterstützt |
| ☐ | Basis für das Golden Image – mindestens eine der unterstützten Konfigurationen für Microsoft Azure-VMs.
Wenn Sie den Assistenten zum automatisierten Importieren von VMs der Konsole aus dem Download-Center verwenden, um eine Basis-VM zu erstellen, verwendet das System automatisch eine der oben genannten VM-Größen. Die Standardauswahl des Systems basiert auf seinen internen Einstellungen und dem jeweiligen Betriebssystem (OS). Das System verwendet die angegebenen Modelle sowohl für Einzel- als auch für Multi-Pod-Images. |
| ☐ | Modellauswahl für die Desktop-VMs in VDI-Desktop-Zuweisungen – eine beliebige der Konfigurationen für Microsoft Azure-VMs, die in der Microsoft Azure-Region verfügbar sind (mit Ausnahme der Konfigurationen, die nicht mit Horizon Cloud-Desktopvorgängen kompatibel sind). Für Produktionsumgebungen empfehlen VMware-Skalierungstests die Verwendung von Modellen mit mindestens 2 CPUs. |
| ☐ | Modellauswahl für die RDSH-VMs in Farmen – eine der Konfigurationen für Microsoft Azure-VMs, die in der Microsoft Azure-Region verfügbar sind (mit Ausnahme der Konfigurationen, die nicht mit Horizon Cloud-RDS-Farmvorgängen kompatibel sind). Diese Anforderung gilt auch für eine VM, auf der Microsoft Windows 10 Enterprise für Mehrfachsitzungen oder Windows 11 Enterprise für Mehrfachsitzungen ausgeführt wird, wenn diese VM mit Horizon Cloud verwendet wird. Gemäß Beschreibung in den Häufig gestellten Fragen zu Microsoft Windows Enterprise für Mehrfachsitzungen in der Microsoft Azure Virtual Desktop-Dokumentation ist Microsoft Windows Enterprise für Mehrfachsitzungen ein Remotedesktop-Sitzungshost(RDSH)-Typ, der mehrere gleichzeitige interaktive Sitzungen zulässt, die zuvor nur von Microsoft Windows Server Betriebssystemen bereitgestellt werden konnten. Die für RDS-Server geltenden Horizon Cloud-Workflows gelten auch für Microsoft Windows Enterprise für Mehrfachsitzungen. Für Produktionsumgebungen empfehlen VMware-Skalierungstests die Verwendung von Modellen mit mindestens 2 CPUs. |
Anforderungen an den Image Management Service (IMS)
Ab der Version vom Juli 2021 stehen die Horizon Image-Verwaltungsdienst-Funktionen für diese Pods zur Verfügung, wenn auf allen Ihren Horizon Cloud-Pods Manifest 2632 oder höher ausgeführt wird und Universal Broker für Ihren Mandanten aktiviert ist. Für die Verwendung der vom -Dienst bereitgestellten Multi-Pod-Image-Funktionen gelten zusätzliche Anforderungen. Ausführliche Informationen zu den Systemanforderungen für die Verwendung dieser Funktionen finden Sie im Microsoft Azure-Abschnitt Horizon Image Management Service-Systemanforderungen. Eine Übersicht über die zusätzlichen Anforderungen an das Pod-Abonnement, die Horizon Cloud-App-Registrierung dieses Abonnements und seinen Dienstprinzipal bei der Verwendung von Multi-Pod-Images finden Sie in der folgenden Tabelle.
| ☐ | Die Abonnements, die von den Pods verwendet werden, die an Multi-Pod-Images teilnehmen, müssen sich innerhalb eines einzelnen AAD-Mandanten (Microsoft Azure Active Directory) befinden. |
| ☐ | Der Dienstprinzipal der Horizon Cloud-App-Registrierung, der von den Pods verwendet wird, die an Multi-Pod-Images beteiligt sind, muss eine der folgenden Anforderungen erfüllen:
Da sich die Pods wahrscheinlich in unterschiedlichen Abonnements befinden, ermöglicht die Anforderung des Lesezugriffs das Abonnement jedes teilnehmenden Pods, die Abonnements der anderen teilnehmenden Pods zu sehen. Diese Sichtlinie ist erforderlich, damit der Dienst die Funktionen der gemeinsam genutzten Azure-Image-Galerie zum Erstellen der Multi-Pod-Images verwenden kann. |
| ☐ | Alle benutzerdefinierten Rollen, die von den Dienstprinzipalen der teilnehmenden Pods verwendet werden, müssen die folgenden Berechtigungen in Bezug auf die Verwendung der Azure-freigegebene Image-Galerie enthalten.
|
Lizenzierung für die Microsoft Windows-Betriebssysteme
Diese Elemente beziehen sich auf die Microsoft Windows-Betriebssysteme in Ihren importierten VMs, auf Golden Images, auf RDSH-fähige Farm-VMs und auf virtuelle Desktop-VMs. Eine Liste der von Horizon Cloud unterstützten Microsoft Windows-Betriebssysteme finden Sie im VMware Knowledgebase-Artikel 78170 und VMware Knowledgebase-Artikel 70965.
Horizon Cloud stellt keine Lizenz für das Gastbetriebssystem bereit, die für die Verwendung von Microsoft Windows-Betriebssystemen erforderlich ist, die Sie im Zuge der Verwendung der Horizon Cloud-Workflows nutzen. Sie, der Kunde, sind dafür verantwortlich, über gültige und geeignete Microsoft-Lizenzen zu verfügen, die Sie zu Folgendem berechtigen: Erstellen von, Ausführen von Workflows für und Betreiben von Windows-basierten Desktop-VMs und RDSH-VMs, die Sie für Ihre Horizon Cloud-Mandantenumgebung auswählen. Die erforderliche Lizenzierung hängt von der beabsichtigten Verwendung ab.
| ☐ | Lizenzierung für einen oder mehrere der folgenden Typen: Microsoft Windows 7 Enterprise, Microsoft Windows 10, Microsoft Windows 11 (Einzelsitzung, VDI-Client-Typen) |
| ☐ | Lizenzierung für Microsoft Windows 10 Enterprise für Mehrfachsitzungen oder Microsoft Windows 11 Enterprise für Mehrfachsitzungen |
| ☐ | Lizenzierung für einen oder mehrere der folgenden Typen: Microsoft Windows Server 2012 R2, Microsoft Server 2016, Microsoft Server 2019 |
| ☐ | Lizenzierungsserver für Microsoft Windows RDS – für Hochverfügbarkeit werden redundante Lizenzierungsserver empfohlen |
| ☐ | Microsoft RDS-Benutzer oder -Geräte-CALs oder beides |
Anforderungen für die Horizon-Infrastrukturüberwachung
Wenn Ihr Horizon Cloud-Mandant für die Verwendung von Horizon-Infrastrukturüberwachung aktiviert ist, können Sie die Horizon Universal Console nutzen, um diese Funktion auf Ihren Pods zu aktivieren. Wenn Sie diese Funktion auf einem Pod aktivieren, erstellt das System automatisch eine virtuelle Appliance in demselben Microsoft Azure-Abonnement, in dem dieser Pod vorhanden ist, und konfiguriert diese Appliance für die Erfassung der Infrastrukturdaten. Diese Überwachungsfunktion können Sie erst nach dem Onboarding Ihres Mandanten in VMware Cloud Services aktivieren. Weitere Informationen finden Sie unter Onboarding Ihres Horizon Cloud-Mandanten in VMware Cloud Services und Horizon-Infrastrukturüberwachung und Pods in Ihrer Horizon Cloud-Umgebung.
| ☐ | Führen Sie das Onboarding Ihres Mandanten in VMware Cloud Services durch. |
| ☐ | Das Microsoft Azure-Abonnement aller Pods, auf denen Sie die Horizon-Infrastrukturüberwachung-Funktion aktivieren möchten, muss diese zusätzlichen Anforderungen erfüllen.
|
Referenzarchitektur
Verwenden Sie die nachfolgenden Architekturdiagramme als Referenz.
