Produktdokumentation
Citrix Virtual Apps and Desktops
Service Current Release 2402 LTSR 2311 2308 2305 2303 2212 2209 2206 2203 LTSR 1912 LTSR
PDF anzeigen

VDA-Registrierung

September 13, 2024
Beitrag von: 
C C

Einführung

Hinweis:

In einer On-Premises–Umgebung registrieren sich VDAs bei einem Delivery Controller. In einer Citrix Cloud-Umgebung registrieren sich VDAs bei einem Cloud Connector. In einer Hybridumgebung registrieren sich einige VDAs bei einem Delivery Controller und andere bei einem Cloud Connector.

VDAs können erst verwendet werden, wenn sie bei mindestens einem Controller oder einem Cloud Connector der Site registriert wurden (Herstellen der Kommunikation). Zur Suche eines Controllers bzw. Connectors überprüft der VDA die Liste ListofDDCs. Die Liste ListOfDDCs auf einem VDA enthält DNS-Einträge, die den VDA an die Controller bzw. Cloud Connectors der Site verweisen. Um einen Lastausgleich zu erzielen, verteilt der VDA die Verbindungen automatisch über alle Controller bzw. Cloud Connectors in der Liste.

Warum ist die VDA-Registrierung so wichtig?

  • Die Registrierung ist sicherheitsrelevant. Es wird eine Verbindung zwischen Controller bzw. Cloud Connector und VDA hergestellt. Bei einem solchen Vorgang wird eine Abweisung erwartet, wenn bei der Anforderungen nicht alles einwandfrei ist. Es werden zwei separate Kommunikationskanäle eingerichtet: VDA an Controller bzw. Cloud Connector und Controller bzw. Cloud Connector an VDA. Bei der Verbindung wird Kerberos verwendet. Daher darf es keine Probleme bei der Zeitsynchronisation und Domänenmitgliedschaft geben. Kerberos verwendet Dienstprinzipalnamen (SPN), d. h. Sie können keine per Lastausgleich gewählten IP-\Hostnamen verwenden.
  • Wenn Sie Controller bzw. Cloud Connectors zur Site hinzufügen und entfernen und ein VDA keine präzisen und aktuellen Controller-/Connectorinformationen hat, kann er Sitzungsstarts ablehnen, die von einem nicht aufgelisteten Controller bzw. Cloud Connector vermittelt werden. Ungültige Einträge in der Liste können den Start der Systemsoftware des virtuellen Desktops verzögern. VDAs akzeptieren keine Verbindung von einem unbekannten, nicht vertrauenswürdigen Controller bzw. Cloud Connector.

Zusätzlich zur Liste ListofDDCs enthält die Liste ListOfSIDs (Sicherheits-IDs) die Maschinen auf der Liste ListofDDCs, denen vertraut wird. Die Liste ListofSIDs kann verwendet werden, um die Last auf Active Directory zu verringern oder um Sicherheitsbedrohungen durch einen nicht sicheren DNS-Server zu vermeiden. Weitere Informationen finden Sie unter ListOfSIDs.

Wenn in ListofDDCs mehrere Controller bzw. Cloud Connectors angegeben sind, erfolgt die Verbindung mit ihnen durch den VDA in einer zufälligen Reihenfolge. Die Liste ListofDDCs kann auch Controller-/Connectorgruppen enthalten. Der VDA versucht, eine Verbindung mit jedem Controller in einer Gruppe herzustellen, bevor er weitere Einträge in der Liste ListofDDCs versucht.

In Citrix Virtual Apps and Desktops wird bei der VDA-Installation automatisch die Verbindung mit konfigurierten Controllern bzw. Cloud Connectors überprüft. Wenn ein Controller bzw. Cloud Connector nicht erreicht werden kann, wird ein Fehler angezeigt. Wenn Sie eine Warnung über einen nicht erreichbaren Controller bzw. Cloud Connector ignorieren (oder wenn Sie während der VDA-Installation keine Controller-/Cloud Connector-Adressen angeben), werden Sie durch Meldungen erinnert.

Methoden zum Konfigurieren von Controller-/Cloud Connector-Adressen

Der Administrator wählt die gewünschte Konfigurationsmethode bei der ersten Registrierung des VDAs. Bei dieser Erstregistrierung wird ein persistenter Cache auf dem VDA erstellt. Bei anschließenden Registrierungen ruft der VDA die Liste der Controller bzw. Cloud Connectors aus diesem lokalen Cache ab, es sei denn, es wird eine Konfigurationsänderung erkannt.

Die einfachste Methode des Abrufs dieser Liste bei späteren Registrierungen ist die Verwendung des Features zur automatischen Aktualisierung. Die automatische Aktualisierung ist standardmäßig aktiviert. Weitere Informationen finden Sie unter Automatische Aktualisierung.

Es gibt verschiedene Methoden zum Konfigurieren von Controller-/Cloud Connector-Adressen auf einem VDA.

  • Über Richtlinien (LGPO oder GPO)
  • Über die Registrierung (Gruppenrichtlinieneinstellungen (GPP), manuell während der VDA-Installation)
  • Über Active Directory (Legacy-OU-Discovery)
  • Über MCS (personality.ini)

Sie geben die anfängliche Registrierungsmethode an, wenn Sie einen VDA installieren. (Wenn Sie die automatische Aktualisierung deaktivieren, wird die bei der VDA-Installation gewählte Methode auch für nachfolgende Registrierungen verwendet.)

Die nachfolgende Abbildung zeigt die Seite Delivery Controller des VDA-Installationsassistenten.

Delivery Controller-Seite im VDA-Installationsassistenten

Konfiguration über Richtlinien (LGPO, GPO)

Citrix empfiehlt die Verwendung des Gruppenrichtlinienobjekts für die VDA-Erstregistrierung. Es hat die höchste Priorität. Die automatische Aktualisierung hat zwar eigentlich die höchste Priorität, sie wird jedoch erst nach der Erstregistrierung verwendet. Die richtlinienbasierte Registrierung bietet den Vorteil der Zentralisierung der Konfiguration über die Gruppenrichtlinie.

Zum Angeben dieser Methode führen Sie die folgenden Schritte aus:

  • Wählen Sie auf der Seite Delivery Controller des VDA-Installationsassistenten Später (erweitert). Aufgrund der hohen Bedeutung der VDA-Registrierung werden Sie von dem Assistenten mehrmals an das Angeben von Controlleradressen erinnert, obwohl Sie sie während der VDA-Installation nicht angeben. (Die VDA-Registrierung ist wirklich wichtig.)
  • Aktivieren oder deaktivieren Sie die richtlinienbasierte VDA-Registrierung durch die Citrix Richtlinie über die Einstellung Virtual Delivery Agent Settings > Controllers. (Wenn Sicherheit höchste Priorität hat, verwenden Sie die Einstellung Virtual Delivery Agent Settings > Controller SIDs.)

Diese Einstellung wird unter HKLM\Software\Policies\Citrix\VirtualDesktopAgent (ListOfDDCs) gespeichert.

Registrierungsbasiert

Zum Angeben dieser Methode führen Sie einen der folgenden Schritte aus:

  • Wählen Sie auf der Seite Delivery Controller des VDA-Installationsassistenten Manuell. Geben Sie dann den FQDN eines installierten Controllers ein und klicken Sie auf Hinzufügen. Wenn Sie weitere Controller installiert haben, fügen Sie deren Adressen hinzu.
  • Bei einer VDA-Installation über die Befehlszeile verwenden Sie die Option “/controller” und geben Sie die FQDNs der installierten Controller bzw. Cloud Connectors an.

Diese Informationen werden im Registrierungswert ListOfDDCs unter dem Registrierungsschlüssel HKLM\Software\Citrix\VirtualDesktopAgent oder HKLM\Software\Wow6432Node\Citrix\VirtualDesktopAgent gespeichert.

Sie können diesen Registrierungsschlüssel auch manuell oder über Gruppenrichtlinieneinstellungen (GPP) konfigurieren. Diese Methode ist eventuell der richtlinienbasierten vorzuziehen, z. B. wenn Sie eine bedingungsbasierte Verarbeitung verschiedener Controller bzw. Cloud Connectors wünschen, etwa “‘XDC-001’ für Computernamen verwenden, die mit ‘XDW-001-‘ beginnen”.

Aktualisieren Sie den Registrierungsschlüssel ListOfDDCs, der die vollqualifizierten Domänennamen aller Controller bzw. Cloud Connectors in der Site enthält. (Dieser Schlüssel entspricht der Active Directory-Site-Organisationseinheit.)

HKEY_LOCAL_MACHINE\Software\Citrix\VirtualDesktopAgent\ListOfDDCs (REG_SZ)

Wenn die Registrierungsstruktur HKEY_LOCAL_MACHINE\Software\Citrix\VirtualDesktopAgent sowohl den Registrierungsschlüssel ListOfDDCs als auch FarmGUID enthält, wird ListOfDDCs für die Controller- oder Cloud Connector-Discovery verwendet. FarmGUID ist vorhanden, wenn die Organisationseinheit der Site bei der Installation des VDAs angegeben wurde. (Dies kann für Legacy-Bereitstellungen verwendet werden.)

Aktualisieren Sie optional den Registrierungsschlüssel ListOfSIDs (weitere Informationen unter ListOfSIDs):

HKEY_LOCAL_MACHINE\Software\Citrix\VirtualDesktopAgent\ListOfSIDs (REG_SZ)

Nicht vergessen: Wenn Sie außerdem die richtlinienbasierte VDA-Registrierung über die Citrix Richtlinie aktivieren, hat dies Vorrang vor den bei der VDA-Installation angegebenen Konfigurationseinstellungen, da es eine höhere Methodenpriorität hat.

Konfiguration über Active Directory-Organisationseinheit

Diese Methode wird hauptsächlich zum Zweck der Abwärtskompatibilität unterstützt und wird nicht empfohlen. Wenn Sie sie noch immer verwenden, empfiehlt Citrix den Wechsel zu einer anderen Methode.

Zum Angeben dieser Methode führen Sie die folgenden Schritte aus:

  • Wählen Sie auf der Seite Delivery Controller des VDA-Installationsassistenten Standorte aus Active Directory auswählen.
  • Verwenden Sie das Skript Set-ADControllerDiscovery.ps1 (steht auf jedem Controller zur Verfügung). Konfigurieren Sie außerdem den Registrierungseintrag FarmGuid auf jedem VDA mit der korrekten Organisationseinheit. Diese Einstellung kann mit der Gruppenrichtlinie konfiguriert werden.

Konfiguration über MCS

Wenn Sie MCS zur Bereitstellung von VMs verwenden, richtet MCS die Liste der Controller oder Cloud Connectors ein. Dieses Feature wirkt mit der automatischen Aktualisierung zusammen. MCS fügt bei der Katalogerstellung die Controller-/Connectorliste bei der ersten Bereitstellung in die Datei Personality.ini ein. Die automatische Aktualisierung bewirkt, dass die Liste immer aktuell bleibt.

Wählen Sie hierfür auf der Seite Delivery Controller des VDA-Installationsassistenten Automatische Erstellung durch Maschinenerstellungsdienste.

Empfehlungen

Bewährte Methoden:

  • Verwenden Sie die Gruppenrichtlinie für die Erstregistrierung.
  • Verwenden Sie die automatische Aktualisierung (standardmäßig aktiviert), um die Controllerliste auf dem neuesten Stand zu halten.
  • Verwenden Sie in einer Multizonenbereitstellung die Gruppenrichtlinie für die anfängliche Konfiguration (mit mindestens zwei Controllern bzw. Cloud Connectors). Verweisen Sie die VDAs auf lokale Controller bzw. Cloud Connectors in ihrer Zone. Verwenden Sie die automatische Aktualisierung um die Einrichtung auf dem letzten Stand zu halten. Durch die automatische Aktualisierung wird die Liste ListofDDCs für VDAs in Satellitenzonen automatisch optimiert.

  • Listen Sie mehrere Controller durch Leerzeichen getrennt im Registrierungsschlüssel ListOfDDCs auf, um Registrierungsprobleme bei Ausfall eines Controllers zu vermeiden. Beispiel:

     DDC7x.xd.local DDC7xHA.xd.local

 32-bit: HKEY_LOCAL_MACHINE \Software\Citrix\VirtualDesktopAgent\ListOfDDCs

 HKEY_LOCAL_MACHINE \Software\Citrix\VirtualDesktopAgent\ListOfDDCs (REG_SZ)
 <!--NeedCopy-->
  • Stellen Sie sicher, dass alle unter ListofDDCs aufgelisteten Einträge auf einen gültigen vollqualifizierten Domänennamen verweisen, um Verzögerungen bei der Registrierung zu vermeiden.

Automatische Updates

Die automatische Aktualisierung wurde in XenApp und XenDesktop 7.6 eingeführt und ist standardmäßig aktiviert. Sie stellt die effizienteste Methode dar, um VDA-Registrierungen auf dem neuesten Stand zu halten. Bei der Erstregistrierung eines VDAs erfolgt zwar keine automatische Aktualisierung, die zugehörige Software lädt jedoch die Liste ListofDDCs herunter und speichert sie in einem persistenten Cache auf dem VDA. Dieser Schritt wird für jeden VDA durchgeführt. Im Cache werden auch Maschinenrichtlinieninformationen gespeichert, sodass Richtlinieneinstellungen bei Neustarts beibehalten werden.

Die automatische Aktualisierung wird unterstützt, wenn das Provisioning über MCS oder Citrix Provisioning erfolgt, außer bei Verwendung eines Citrix Provisioning-Servercache. Ein serverseitiger Cache ist jedoch kein übliches Verfahren, da es keinen persistenten Cache zur Speicherung automatischer Aktualisierungen gibt.

Gehen Sie zum Angeben dieser Methode folgendermaßen vor:

  • Aktivieren oder deaktivieren Sie die automatische Aktualisierung über eine Citrix Richtlinie, die die Einstellung Virtual Delivery Agent Settings > Enable auto update of Controllers enthält. Diese Einstellung ist standardmäßig aktiviert.

Funktionsweise:

  • Bei jeder erneuten Registrierung eines VDAs (z. B. nach einem Neustart der Maschine) wird der Cache aktualisiert. Außerdem überprüft jeder Controller bzw. Cloud Connector alle 90 Minuten die Sitedatenbank. Wenn seit der letzten Überprüfung ein Controller bzw. Cloud Connector hinzugefügt oder entfernt wurde oder bei einer Änderung der Richtlinie, die sich auf die VDA-Registrierung auswirkt, sendet der Controller bzw. Cloud Connector eine aktualisierte Liste an die bei ihm registrierten VDAS und der Cache wird aktualisiert. Der VDA nimmt alle Verbindungen von allen Controllern bzw. Cloud Connectors in der aktuellen Liste im Cache an.
  • Geht eine Liste ein, die den Controller bzw. Cloud Connector, bei dem der VDA registriert ist, nicht enthält (d. h. der Controller/Cloud Connector wurde aus der Site entfernt), nimmt der VDA eine neue Registrierung bei einem der Controller bzw. Cloud Connectors aus der Liste ListofDDCs vor.

Beispiel:

  • Die Bereitstellung hat die drei Controller A, B und C. Ein VDA wird bei Controller B registriert (dies wurde bei der Installation des VDAs festgelegt).
  • Anschließend werden der Site zwei Controller (D und E) hinzugefügt. Innerhalb von 90 Minuten erhalten die VDAs aktualisierte Listen und akzeptieren Verbindungen von den Controllern A, B, C, D und E. Die Lastverteilung auf alle Controller erfolgt erst nach einem Neustart der VDAs.
  • Controller B wird später in eine andere Site verschoben. Innerhalb von 90 Minuten erhalten die VDAs der ursprünglichen Site aktualisierte Listen, da seit der letzten Überprüfung eine Controlleränderung stattfand. Der ursprünglich bei (dem nun nicht mehr vorhandenen) Controller B registrierte VDA wird bei einem der anderen Controller der Liste (A, C, D oder E) registriert.

In einer Bereitstellung mit mehreren Zonen speichert die automatische Aktualisierung in einer Satellitenzone automatisch zuerst alle lokalen Controller. Alle Controller in der primären Zone werden in einer Backupgruppe gespeichert. Wenn keine lokalen Controller in der Satellitenzone zur Verfügung stehen, wird eine Registrierung bei einem Controller in der primären Zone versucht.

Die Cachedatei enthält wie im folgenden Beispiel dargestellt Hostnamen und eine Liste von Sicherheits-IDs (ListofSIDs). Der VDA fragt keine SIDs ab, wodurch die Active Directory-Last reduziert wird.

Beispiel einer Registrierungscachedatei eines VDAs

Sie können die Cachedatei mit einem WMI-Aufruf abrufen. Allerdings ist sie an einem Speicherort gespeichert, auf den nur das SYSTEM-Konto Lesezugriff hat.

Wichtig:

Diese Angaben dienen lediglich der Information. ÄNDERN SIE DIESE DATEI NICHT. Änderungen an dieser Datei oder an dem Ordner führen zu einer nicht unterstützten Konfiguration.

Get-WmiObject -Namespace "Root\Citrix\DesktopInformation" -Class "Citrix_VirtualDesktopInfo" -Property "PersistentDataLocation"

Wenn Sie die Liste ListofSIDs aus Sicherheitsgründen (d. h. nicht zur Senkung der Active Directory-Last) manuell konfigurieren müssen, können Sie die automatische Aktualisierung nicht verwenden. Weitere Informationen finden Sie unten unter ListOfSIDs.

Ausnahme zur Priorität der automatischen Aktualisierung

Die automatische Aktualisierung besitzt zwar in der Regel die höchste Priorität unter allen VDA-Registrierungsmethoden und setzt die Einstellungen anderer Methoden außer Kraft, es gibt jedoch eine Ausnahme. Die NonAutoListOfDDCs-Elemente im Cache geben die anfängliche VDA-Konfigurationsmethode an. Die automatische Aktualisierung überwacht diese Informationen. Wenn sich die anfängliche Registrierungsmethode ändert, wird bei der Registrierung die automatische Aktualisierung übersprungen und die Methode mit der nächsthöchsten Priorität verwendet. Dieser Prozess kann hilfreich sein, wenn Sie einen VDA in eine andere Site verschieben (Beispiel bei einer Notfallwiederherstellung).

Überlegungen zur Konfiguration

Hier wird eine gebräuchliche VDA-Registrierungskonfiguration vorgestellt.

Das folgende Video zeigt die Schritte zur VDA-Registrierung.

Berücksichtigen Sie beim Konfigurieren von Elementen, die sich auf die VDA-Registrierung auswirken können, die nachfolgenden Punkte.

Controller- bzw. Cloud Connector-Adressen

Unabhängig davon, welche Methode Sie zum Angeben von Controllern bzw. Cloud Connectors verwenden, empfiehlt Citrix eine FQDN-Adresse. Eine IP-Adresse gilt nicht als vertrauenswürdige Konfiguration, da sie leichter als ein DNS-Datensatz angegriffen werden kann. Wenn Sie die Liste ListofSIDs manuell erstellen, können Sie eine IP-Adresse in einer ListofDDCs-Liste verwenden. Es wird dennoch empfohlen, FQDNs zu verwenden.

Lastausgleich

Wie bereits erwähnt, verteilt ein VDA die Verbindungen automatisch über alle Controller bzw. Cloud Connectors in der Liste ListofDDCs. Failover und Lastausgleich sind Teil des für die Vermittlung verwendeten Protokolls CBP (Citrix Brokering Protocol). Wenn Sie mehrere Controller bzw. Cloud Connectors in Ihrer Konfiguration angeben, erfolgt bei Bedarf bei der Registrierung automatisch ein Failover zwischen diesen. Bei der automatischen Aktualisierung erfolgt automatisch ein Failover für alle VDAS.

Aus Sicherheitsgründen können Sie keinen Netzwerk-Load Balancer wie etwa Citrix ADC verwenden. Bei der VDA-Registrierung wird die gegenseitige Authentifizierung über Kerberos verwendet, bei der der Client (VDA) dem Dienst (Controller) seine Identität beweisen muss. Doch auch der Controller bzw. Cloud Connector muss dem VDA seine Identität beweisen. Das bedeutet, dass VDA und Controller/Cloud Connector Server und Client zugleich sind. Wie bereits am Anfang dieses Artikels erwähnt, gibt es zwei Kommunikationskanäle: VDA zum Controller/Cloud Connector und Controller/Cloud Connector zum VDA.

Eine Komponente dieses Prozesses ist der Dienstprinzipalname (SPN), der als Eigenschaft in einem Active Directory-Computerobjekt gespeichert ist. Wenn der VDA sich mit einem Controller bzw. Cloud Connector verbindet, muss er angeben, mit wem er kommunizieren möchte. Diese Adresse ist ein SPN. Wenn Sie IP-Adressen und Lastausgleich verwenden, wird bei der gegenseitigen Kerberos-Authentifizierung richtig erkannt, dass die IP-Adresse nicht zu dem erwarteten Controller bzw. Cloud Connector gehört.

Weitere Informationen:

Automatische Aktualisierung ersetzt CNAME

Die automatische Aktualisierung ersetzt die CNAME-Funktion (DNS-Alias) von XenApp- und XenDesktop-Versionen vor 7.x. Die CNAME-Funktion ist ab XenApp- und XenDesktop-Version 7 deaktiviert. Verwenden Sie statt CNAME die automatische Aktualisierung. (Wenn Sie CNAME verwenden müssen, lesen Sie CTX137960. Damit die DNS-Aliasfunktion einwandfrei funktioniert, verwenden Sie CNAME und automatische Aktualisierung nicht gleichzeitig.)

Controller-/Cloud Connector-Gruppen

In bestimmten Szenarien können Sie Controller bzw. Cloud Connectors in Gruppen zusammenfassen, von denen eine bevorzugt wird und die andere bei Ausfall aller Controller/Connectors für ein Failover verwendet wird. Controller bzw. Cloud Connectors werden zufällig aus der Liste ausgewählt, eine Gruppierung kann daher zur Durchsetzung einer bevorzugten Verwendung helfen.

Die Gruppen sind für die Verwendung innerhalb einer Site (nicht mehrerer Sites) vorgesehen.

Verwenden Sie Klammern, um Controller-/Connectorgruppen anzugeben. Beispiel für vier Controller (zwei primäre und zwei als Backup):

(XDC-001.cdz.lan XDC-002.cdz.lan) (XDC-003.cdz.lan XDC-004.cdz.lan)

In diesem Beispiel werden die Controller der ersten Gruppe (001, 002) zuerst verarbeitet. Wenn beide ausfallen, werden die Controller der zweiten Gruppe (003 und 004) verarbeitet.

Bei XenDesktop ab Version 7.0 müssen Sie zur Verwendung des Features Registrierungsgruppen einen zusätzlichen Schritt ausführen. Sie müssen die Richtlinie Automatische Aktualisierung von Controllern in Studio auf Nicht zulassen festlegen.

ListOfSIDs

ListofDDCs ist die Liste der Controller, die ein VDA zur Registrierung ansprechen kann. Ein VDA muss außerdem wissen, welche Controller vertrauenswürdig sind. VDAs vertrauen nicht automatisch den Controllern in der Liste ListofDDCs. Die Liste der Sicherheits-IDs (ListofSIDs) enthält die vertrauenswürdigen Controller. VDAs versuchen eine Registrierung nur mit vertrauenswürdigen Controllern.

In den meisten Umgebungen wird die Liste ListofSIDs automatisch aus der Liste ListofDDCs generiert. Sie können die Liste ListofSIDs mit einer CDF-Ablaufverfolgung lesen.

Im Allgemeinen besteht keine Notwendigkeit einer manuellen Änderung der Liste ListofSIDs. Es müssen allerdings einige Ausnahmen berücksichtigt werden. Die ersten beiden Ausnahmen sind nicht mehr relevant, da neuere Technologien zur Verfügung stehen.

  • Getrennte Rollen für Controller: Vor der Einführung von Zonen in XenApp und XenDesktop 7.7 wurde die Liste ListofSIDs manuell konfiguriert, wenn nur eine Teilgruppe von Controllern für die Registrierung verwendet wurde. Wenn beispielsweise XDC-001 und XDC-002 als XML-Broker verwendet wurden und XDC-003 und XDC-004 für die VDA-Registrierung, wurden alle Controller in der Liste ListofSIDs sowie die Controller XDC-003 und XDC-004 in der Liste ListofDDCs angegeben. Dies ist keine typische oder empfohlene Konfiguration. Verwenden Sie sie nicht in neueren Umgebungen. Verwenden Sie stattdessen Zonen.
  • Reduzierung der Active Directory-Last: Vor Einführung der automatischen Aktualisierung in XenApp und XenDesktop 7.6 wurde die Liste ListofSIDs zur Reduzierung der Last auf Domänencontrollern verwendet. Durch die Auffüllung der Liste ListofSIDs vorab kann die Auflösung von DNS-Namen in SIDs ausgelassen werden. Durch die automatische Aktualisierung entfällt jedoch die Notwendigkeit für diesen Arbeitsschritt, da der persistente Cache SIDs enthält. Citrix empfiehlt, die automatische Aktualisierung aktiviert zu lassen.
  • Sicherheit: In manchen hochsicheren Umgebungen wurden die SIDs vertrauenswürdiger Controller manuell konfiguriert, um mögliche Sicherheitsbedrohungen durch beeinträchtigte DNS-Server zu vermeiden. Hierfür müssen Sie jedoch auch die automatische Aktualisierung deaktivieren. Andernfalls wird die Konfiguration aus dem persistenten Cache verwendet.

Ändern Sie also die Liste ListofSIDs nicht ohne spezifischen Grund.

Wenn Sie die Liste ListofSIDs ändern müssen, erstellen Sie unter HKLM\Software\Citrix\VirtualDesktopAgent einen Registrierungsschlüssel mit dem Namen ListOfSIDs (REG_SZ). Der Wert ist eine vertrauenswürdige SID, bzw. eine Liste mehrerer, durch Leerzeichen getrennter SIDs.

Im folgenden Beispiel werden ein Controller für die VDA-Registrierung (ListofDDCs) und zwei für die Vermittlung (ListOfSIDs) verwendet.

Beispiel für den Einsatz verschiedener Controller für Registrierung und Vermittlung

Controllersuche während der VDA-Registrierung

Wenn ein VDA versucht, sich zu registrieren, führt der Broker-Agent zunächst eine DNS-Suche in der lokalen Domäne durch, um sicherzustellen, dass der angegebene Controller erreicht werden kann.

Wenn der Controller dabei nicht gefunden wird, kann der Broker-Agent eine Top-Down-Fallbacksuche in AD starten. Diese Abfrage durchsucht alle Domänen und wird mehrfach wiederholt. Wenn die Controlleradresse ungültig ist (z. B. weil der Administrator bei der Installation des VDA einen falschen FQDN eingegeben hat), kann die Abfrage zu einem verteilten Denial-of-Service (DDoS) auf dem Domänencontroller führen.

Der folgende Registrierungsschlüssel legt fest, ob der Broker-Agent die Top-Down-Fallbacksuche verwendet, wenn er bei der ersten Suche keinen Controller findet.

HKEY_LOCAL_MACHINE\Software\Citrix\VirtualDesktopAgent

  • Name:DisableDdcWildcardNameLookup
  • Typ: DWORD
  • Wert: 1 (Standard) oder 0

Wenn der Wert 1 oder kein Wert festgelegt ist, wird die Fallback-Suche aktiviert. Wenn die erste Suche nach dem Controller fehlschlägt, wird die Top-Down-Fallbacksuche gestartet. Dies ist das Standardverhalten. Wenn diese Option auf 0 gesetzt ist, ist die Fallback-Suche jedoch deaktiviert. Wenn die erste Suche nach dem Controller fehlschlägt, sucht der Broker-Agent nicht weiter.

LDAP-Bindungssequenzdurchlauf während der VDA-Registrierung mit einem schreibgeschützten Domänencontroller

Wenn ein VDA sich bei einem schreibgeschützten Domänencontroller (RODC) registriert, muss der Broker Agent die LDAP-Bindungen auswählen, die ignoriert werden sollen. Um diese Auswahl zu treffen, benötigt der Broker Agent einen geeigneten Registrierungsschlüssel.

Wenn kein Registrierungsschlüssel bereitgestellt wird oder wenn das Feld für den Registrierungsschlüssel leer ist, dauert die VDA-Registrierung beim RODC länger, da zunächst die ursprüngliche LDAP-Bindungssequenz durchlaufen wird.

Um die LDAP-Bindungssequenz zu ändern, wurde unter HKEY_LOCAL_MACHINE\Software\Policies\Citrix\VirtualDesktopAgent der Registrierungsschlüssel ListofIgnoredBindings hinzugefügt. Mithilfe von ListofIgnoredBindings können Sie die LDAP-Bindungssequenz nach Bedarf ändern und dadurch die VDA-Registrierung bei einem RODC beschleunigen.

  • Name:ListofIgnoredBindings
  • Typ: REG_SZ
  • Werte: DefaultPath, DomainPath, PDCPath

Der Wert ist eine Liste von Bindungspfadoptionen, die jeweils durch ein Komma getrennt sind. Der Registrierungsschlüssel ignoriert Werte, die nicht als gültig erkannt werden.

Problembehandlung bei der VDA-Registrierung

Wie bereits erwähnt, muss ein VDA bei einem Delivery Controller oder Cloud Connector registriert sein, damit er beim Start gebrokerter Sitzungen in die Auswahl kommt. Nicht registrierte VDAs können eine mangelnde Auslastung verfügbarer Ressourcen zur Folge haben. Es gibt eine Reihe von Gründen, warum ein VDA nicht registriert sein könnte. Viele können vom Administrator behandelt werden. Studio bietet Informationen zur Problembehandlung im Assistenten zum Erstellen von Maschinenkatalogen und nach dem Erstellen einer Bereitstellungsgruppe.

  • Identifizieren von Problemen während der Maschinenkatalogerstellung: Im Assistenten zum Erstellen von Maschinenkatalogen wird nach dem Hinzufügen vorhandener Maschinen in der Liste der Computerkontonamen angezeigt, ob die einzelnen Maschinen zum Hinzufügen zu dem Katalog geeignet sind. Zeigen Sie auf das Symbol neben jeder Maschine, um Informationen dazu einzublenden.

    Wenn die Nachricht eine problematische Maschine identifiziert, können Sie diese Maschine entweder entfernen (über die Schaltfläche Entfernen) oder die Maschine hinzufügen. Wird beispielsweise gemeldet, dass die Maschineninformationen nicht abgerufen wurde (z. B. weil die Maschine nie registriert wurde), können Sie die Maschine auf Wunsch dennoch hinzufügen.

    Die Funktionsebene eines Katalogs steuert, welche Produktfeatures den Maschinen in dem Katalog zur Verfügung stehen. Um Features zu verwenden, die in neueren Produktversionen eingeführt wurden, ist u. U. ein neuer VDA erforderlich. Das Festlegen einer Funktionsebene stellt den Maschinen in dem Katalog alle mit der entsprechenden Version (und höheren Versionen, wenn die Funktionsebene nicht geändert wird) eingeführten Features zur Verfügung. In dem Katalog enthaltene Maschinen mit einer älteren VDA-Version können dann allerdings nicht registriert werden.

  • Identifizieren von Problemen nach der Erstellung von Bereitstellungsgruppen: Nach dem Erstellen einer Bereitstellungsgruppe werden in Studio Informationen zu Maschinen angezeigt, die der Gruppe zugeordnet sind.

    Im Detailbereich für eine Bereitstellungsgruppe wird die Anzahl der Maschinen angezeigt, die registriert sein müssten, es jedoch nicht sind. Es kann also Maschinen geben, die eingeschaltet und nicht im Wartungsmodus sind, jedoch nicht bei einem Controller registriert sind. Beim Anzeigen einer Maschine, die nicht registriert ist, es aber sein muss, enthält die Registerkarte Problembehandlung im Detailbereich Informationen zu möglichen Ursachen und empfohlenen Korrekturmaßnahmen.

Weitere Informationen zur Fehlerbehebung bei der VDA-Registrierung

VDA-Registrierung
September 13, 2024
Beitrag von: 
C C
September 13, 2024
Beitrag von: 
C C

In diesem Artikel

Feedback zur Site | Your privacy choices footer linkIhre Datenschutzauswahl | Datenschutz und rechtliche Bestimmungen | Cookie-Einstellungen | Einstellungen für die Zustimmung | docs.cloud.com
© 1999- Cloud Software Group, Inc. All rights reserved.