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

April 1, 2026
Beitrag von: 
C C

Einführung

Hinweis:

In einer lokalen Umgebung registrieren sich VDAs bei einem Delivery Controller. In einer Citrix Cloud-Dienstumgebung registrieren sich VDAs bei einem Cloud Connector. In einer Hybridumgebung registrieren sich einige VDAs bei einem Delivery Controller, während andere sich bei einem Cloud Connector registrieren.

Bevor ein VDA verwendet werden kann, muss er sich bei einem oder mehreren Controllern oder Cloud Connectors am Standort registrieren (Kommunikation herstellen). Der VDA findet einen Controller oder Connector, indem er eine Liste namens ListofDDCs überprüft. Die ListOfDDCs auf einem VDA enthält DNS-Einträge, die diesen VDA auf Controller oder Cloud Connectors am Standort verweisen. Zum Lastenausgleich verteilt der VDA Verbindungen automatisch auf alle Controller oder Cloud Connectors in der Liste.

Warum ist die VDA-Registrierung so wichtig?

  • Aus Sicherheitssicht ist die Registrierung ein sensibler Vorgang. Sie stellen eine Verbindung zwischen dem Controller oder Cloud Connector und dem VDA her. Bei einem so sensiblen Vorgang ist das erwartete Verhalten, die Verbindung abzulehnen, wenn nicht alles in einwandfreiem Zustand ist. Sie stellen effektiv zwei separate Kommunikationskanäle her: VDA zum Controller oder Cloud Connector und Controller oder Cloud Connector zum VDA. Die Verbindung verwendet Kerberos, daher sind Probleme mit der Zeitsynchronisation und der Domänenmitgliedschaft unversöhnlich. Kerberos verwendet Service Principal Names (SPNs), sodass Sie keine lastverteilte IP\Hostname verwenden können.
  • Wenn ein VDA keine genauen und aktuellen Controller- oder Cloud Connector-Informationen hat, während Sie Controller (oder Cloud Connectors) hinzufügen und entfernen, kann der VDA Sitzungsstarts ablehnen, die von einem nicht gelisteten Controller oder Cloud Connector vermittelt werden. Ungültige Einträge können den Start der virtuellen Desktop-Systemsoftware verzögern. Ein VDA akzeptiert keine Verbindung von einem unbekannten und nicht vertrauenswürdigen Controller oder Cloud Connector.

Zusätzlich zur ListofDDCs gibt die ListOfSIDs (Security IDs) an, welche Maschinen in der ListofDDCs vertrauenswürdig sind. Die ListOfSIDs kann verwendet werden, um die Last auf Active Directory zu verringern oder mögliche Sicherheitsbedrohungen durch einen kompromittierten DNS-Server zu vermeiden. Weitere Informationen finden Sie unter ListOfSIDs.

Wenn eine ListofDDCs mehr als einen Controller oder Cloud Connector angibt, versucht der VDA, sich in zufälliger Reihenfolge mit ihnen zu verbinden. In einer lokalen Bereitstellung kann die ListofDDCs auch Controller-Gruppen enthalten. Der VDA versucht, sich mit jedem Controller in einer Gruppe zu verbinden, bevor er zu anderen Einträgen in der ListofDDCs übergeht.

Citrix Virtual Apps and Desktops™ testet während der VDA-Installation automatisch die Konnektivität zu konfigurierten Controllern oder Cloud Connectors. Fehler werden angezeigt, wenn ein Controller oder Cloud Connector nicht erreicht werden kann. Wenn Sie eine Warnung ignorieren, dass ein Controller oder Cloud Connector nicht kontaktiert werden kann (oder wenn Sie während der VDA-Installation keine Controller- oder Cloud Connector-Adressen angeben), werden Sie durch Meldungen daran erinnert.

Methoden zur Konfiguration von Controller- oder Cloud Connector-Adressen

Der Administrator wählt die Konfigurationsmethode, die verwendet werden soll, wenn sich der VDA zum ersten Mal registriert (die Erstregistrierung). Während der Erstregistrierung wird ein persistenter Cache auf dem VDA erstellt. Bei nachfolgenden Registrierungen ruft der VDA die Liste der Controller oder Cloud Connectors aus diesem lokalen Cache ab, es sei denn, es wird eine Konfigurationsänderung erkannt.

Der einfachste Weg, diese Liste bei nachfolgenden Registrierungen abzurufen, ist die Verwendung der Auto-Update-Funktion. Auto-Update ist standardmäßig aktiviert. Weitere Informationen finden Sie unter Auto-Update.

Es gibt verschiedene Methoden zur Konfiguration von Controller- oder Cloud Connector-Adressen auf einem VDA.

  • Richtlinienbasiert (LGPO oder GPO)
  • Registrierungsbasiert (manuell, Gruppenrichtlinieneinstellungen (GPP), während der VDA-Installation angegeben)
  • Active Directory OU-basiert (Legacy-OU-Erkennung)
  • MCS-basiert (personality.ini)

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

Die folgende Grafik zeigt die Seite Delivery Controller des VDA-Installationsassistenten.

Seite „Delivery Controller“ im VDA-Installationsassistenten

Richtlinienbasiert (LGPO\GPO)

Citrix® empfiehlt die Verwendung von GPO für die anfängliche VDA-Registrierung. Dies hat die höchste Priorität. (Obwohl Auto-Update als höchste Priorität aufgeführt ist, wird Auto-Update nur nach der Erstregistrierung verwendet.) Die richtlinienbasierte Registrierung bietet die zentralisierenden Vorteile der Verwendung von Gruppenrichtlinien für die Konfiguration.

Um diese Methode anzugeben, führen Sie beide der folgenden Schritte aus:

  • Wählen Sie auf der Seite Delivery Controller im VDA-Installationsassistenten die Option Später ausführen (erweitert). Der Assistent erinnert Sie mehrmals daran, Controller-Adressen anzugeben, auch wenn Sie diese während der VDA-Installation nicht angeben. (Die VDA-Registrierung ist so wichtig.)
  • Aktivieren oder deaktivieren Sie die richtlinienbasierte VDA-Registrierung über die Citrix-Richtlinie mit der Einstellung Virtual Delivery Agent Settings > Controllers. (Wenn Sicherheit Ihre oberste Priorität ist, verwenden Sie die Einstellung Virtual Delivery Agent Settings > Controller SIDs.)

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

Registrierungsbasiert

Um diese Methode anzugeben, führen Sie einen der folgenden Schritte aus:

  • Auf der Seite Delivery Controller im VDA-Installationsassistenten wählen Sie Manuell durchführen. 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.
  • Für eine VDA-Installation über die Befehlszeile verwenden Sie die Option /controllers und geben die FQDNs der installierten Controller oder 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 konfigurieren oder Gruppenrichtlinieneinstellungen (GPP) verwenden. Diese Methode könnte der richtlinienbasierten Methode vorzuziehen sein (z. B. wenn Sie eine bedingte Verarbeitung verschiedener Controller oder Cloud Connectors wünschen, wie: Verwenden Sie XDC-001 für Computernamen, die mit XDW-001- beginnen).

Aktualisieren Sie den Registrierungsschlüssel ListOfDDCs, der die FQDNs aller Controller oder Cloud Connectors in der Site auflistet. (Dieser Schlüssel entspricht der Active Directory-Site-OU.)

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

Wenn der Registrierungspfad HKEY_LOCAL_MACHINE\Software\Citrix\VirtualDesktopAgent sowohl die Schlüssel ListOfDDCs als auch FarmGUID enthält, wird ListOfDDCs für die Controller- oder Cloud Connector-Ermittlung verwendet. Der FarmGUID ist vorhanden, wenn während der VDA-Installation eine Site-OU angegeben wurde. (Dies könnte in älteren Bereitstellungen verwendet werden.)

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

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

Beachten Sie: Wenn Sie auch eine richtlinienbasierte VDA-Registrierung über eine Citrix-Richtlinie aktivieren, überschreibt diese die Einstellungen, die Sie während der VDA-Installation angeben, da sie eine Methode mit höherer Priorität ist.

Active Directory OU-basiert (Legacy)

Diese Methode wird hauptsächlich aus Gründen der Abwärtskompatibilität unterstützt und wird nicht empfohlen. Wenn Sie sie noch verwenden, empfiehlt Citrix, zu einer anderen Methode zu wechseln.

Um diese Methode anzugeben, führen Sie die folgenden beiden Schritte aus:

  • Wählen Sie auf der Seite Delivery Controller im VDA-Installationsassistenten die Option Speicherorte aus Active Directory auswählen.
  • Verwenden Sie das Skript Set-ADControllerDiscovery.ps1 (auf jedem Controller verfügbar). Konfigurieren Sie außerdem den Registrierungseintrag FarmGuid auf jedem VDA so, dass er auf die richtige OU verweist. Diese Einstellung kann über Gruppenrichtlinien konfiguriert werden.

MCS-basiert

Wenn Sie MCS zum Bereitstellen von VMs verwenden, richtet MCS die Liste der Controller oder Cloud Connectors ein. Diese Funktion arbeitet mit der automatischen Aktualisierung. Beim Erstellen des Katalogs injiziert MCS die Liste der Controller oder Cloud Connectors während der Erstbereitstellung in die Datei Personality.ini. Die automatische Aktualisierung hält die Liste aktuell.

Um diese Methode anzugeben, wählen Sie auf der Seite Delivery Controller im VDA-Installationsassistenten die Option Machine Creation Services™ ausführen lassen.

Überprüfung und Empfehlungen

Als Best Practice gilt:

  • Verwenden Sie die Gruppenrichtlinien-Registrierungsmethode für die Erstregistrierung.
  • Verwenden Sie die automatische Aktualisierung (standardmäßig aktiviert), um Ihre Controller-Liste auf dem neuesten Stand zu halten.
  • Verwenden Sie in einer Multi-Zonen-Bereitstellung Gruppenrichtlinien für die Erstkonfiguration (mit mindestens zwei Controllern oder Cloud Connectors). Verweisen Sie VDAs auf Controller oder Cloud Connectors, die sich lokal in ihrer Zone befinden. Verwenden Sie die automatische Aktualisierung, um sie auf dem neuesten Stand zu halten. Die automatische Aktualisierung optimiert die ListofDDCs für VDAs in Satellitenzonen automatisch.

  • Listen Sie mehr als einen Controller im Registrierungsschlüssel ListOfDDCs auf, getrennt durch ein Leerzeichen, um Registrierungsprobleme zu vermeiden, falls ein Controller nicht verfügbar ist. Zum 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 aufgeführten Werte einem gültigen vollqualifizierten Domänennamen zugeordnet sind, um Verzögerungen bei der Startregistrierung zu vermeiden.

Automatische Aktualisierung

Die automatische Aktualisierung (eingeführt in XenApp und XenDesktop 7.6) ist standardmäßig aktiviert. Sie ist die effizienteste Methode, um Ihre VDA-Registrierungen auf dem neuesten Stand zu halten. Obwohl sie nicht für die Erstregistrierung verwendet wird, lädt die Software für die automatische Aktualisierung die ListofDDCs herunter und speichert sie in einem persistenten Cache auf dem VDA, wenn die Erstregistrierung erfolgt. Dieser Prozess wird für jeden VDA durchgeführt. Der Cache enthält auch Maschinenrichtlinieninformationen, die sicherstellen, dass die Richtlinieneinstellungen über Neustarts hinweg beibehalten werden.

Die automatische Aktualisierung wird bei der Bereitstellung von Maschinen mit MCS oder Citrix Provisioning™ unterstützt, mit Ausnahme des serverseitigen Caches von Citrix Provisioning. Der serverseitige Cache ist kein häufiges Szenario, da es keinen persistenten Speicher für den Auto-Update-Cache gibt.

Um diese Methode anzugeben:

  • Aktivieren oder deaktivieren Sie das Auto-Update ü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:

  • Jedes Mal, wenn sich ein VDA neu registriert (z. B. nach einem Neustart des Computers), wird der Cache aktualisiert. Jeder Controller oder Cloud Connector überprüft außerdem alle 90 Minuten die Sitedatenbank. Wenn seit der letzten Überprüfung ein Controller oder Cloud Connector hinzugefügt oder entfernt wurde oder eine Richtlinienänderung aufgetreten ist, die die VDA-Registrierung betrifft, sendet der Controller oder Cloud Connector eine aktualisierte Liste an seine registrierten VDAs, und der Cache wird aktualisiert. Der VDA akzeptiert Verbindungen von allen Controllern oder Cloud Connectors in seiner zuletzt zwischengespeicherten Liste.
  • Wenn ein VDA eine Liste erhält, die den Controller oder Cloud Connector, bei dem er registriert ist, nicht enthält (d. h. dieser Controller oder Cloud Connector wurde vom Site entfernt), registriert sich der VDA neu und wählt aus den Controllern oder Cloud Connectors in der ListofDDCs aus.

Beispiel:

  • Eine Bereitstellung umfasst drei Controller: A, B und C. Ein VDA registriert sich bei Controller B (der während der VDA-Installation angegeben wurde).
  • Später werden zwei Controller (D und E) zum Site hinzugefügt. Innerhalb von 90 Minuten erhalten die VDAs aktualisierte Listen und akzeptieren dann Verbindungen von den Controllern A, B, C, D und E. (Die Last wird erst nach dem Neustart der VDAs gleichmäßig auf alle Controller verteilt.)
  • Noch später wird Controller B auf einen anderen Site verschoben. Innerhalb von 90 Minuten erhalten die VDAs im ursprünglichen Site aktualisierte Listen, da seit der letzten Überprüfung eine Controller-Änderung stattgefunden hat. Der VDA, der ursprünglich bei Controller B registriert war (der nicht mehr auf der Liste steht), registriert sich neu und wählt aus den Controllern in der aktuellen Liste (A, C, D und E) aus.

In einer Multi-Zonen-Bereitstellung speichert das Auto-Update in einer Satellitenzone automatisch zuerst alle lokalen Controller im Cache. Alle Controller in der primären Zone werden in einer Sicherungsgruppe zwischengespeichert. Wenn keine lokalen Controller in der Satellitenzone verfügbar sind, wird die Registrierung bei Controllern in der primären Zone versucht.

Wie im folgenden Beispiel gezeigt, enthält die Cache-Datei Hostnamen und eine Liste von Sicherheits-IDs (ListofSIDs). Der VDA fragt keine SIDs ab und reduziert somit die Active Directory-Last.

Beispiel einer VDA-Registrierungs-Cache-Datei

Sie können die Cache-Datei mit einem WMI-Aufruf abrufen. Sie wird jedoch an einem Speicherort gespeichert, der nur vom SYSTEM-Konto gelesen werden kann.

Wichtig:

Diese Informationen dienen nur zu Informationszwecken. DIESE DATEI NICHT ÄNDERN. Jede Änderung an dieser Datei oder diesem Ordner führt zu einer nicht unterstützten Konfiguration.

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

Wenn Sie die ListofSIDs aus Sicherheitsgründen (im Gegensatz zur Reduzierung der Active Directory-Last) manuell konfigurieren müssen, können Sie die Auto-Update-Funktion nicht verwenden. Einzelheiten finden Sie unter ListOfSIDs.

Ausnahme von der Auto-Update-Priorität

Obwohl das Auto-Update in der Regel die höchste Priorität aller VDA-Registrierungsmethoden hat und die Einstellungen für andere Methoden überschreibt, gibt es eine Ausnahme. Die NonAutoListOfDDCs-Elemente im Cache geben die anfängliche VDA-Konfigurationsmethode an. Das Auto-Update überwacht diese Informationen. Wenn sich die anfängliche Registrierungsmethode ändert, überspringt der Registrierungsprozess das Auto-Update und verwendet die nächsthöchste konfigurierte Prioritätsmethode. Dieser Prozess kann hilfreich sein, wenn Sie einen VDA auf einen anderen Site verschieben (z. B. während der Notfallwiederherstellung).

Konfigurationsüberlegungen

Eine gängige VDA-Registrierungskonfiguration anzeigen.

VDA-Registrierungsschritte anzeigen.

Berücksichtigen Sie Folgendes, wenn Sie Elemente konfigurieren, die die VDA-Registrierung beeinflussen können.

Controller- oder Cloud Connector-Adressen

Unabhängig davon, welche Methode Sie zur Angabe von Controllern oder Cloud Connectors verwenden, empfiehlt Citrix die Verwendung einer FQDN-Adresse. Eine IP-Adresse wird nicht als vertrauenswürdige Konfiguration betrachtet, da es einfacher ist, eine IP-Adresse zu kompromittieren als einen DNS-Eintrag. Wenn Sie die ListofSIDs manuell füllen, können Sie eine IP-Adresse in einer ListofDDCs verwenden. FQDN wird jedoch weiterhin empfohlen.

Lastenausgleich

Wie bereits erwähnt, verteilt der VDA Verbindungen automatisch auf alle Controller oder Cloud Connectors in der ListofDDCs. Failover- und Lastenausgleichsfunktionen sind in das Citrix Brokering Protocol (CBP) integriert. Wenn Sie mehrere Controller oder Cloud Connectors in Ihrer Konfiguration angeben, erfolgt bei Bedarf ein automatisches Failover der Registrierung zwischen diesen. Mit der Auto-Update-Funktion erfolgt das automatische Failover für alle VDAs automatisch.

Aus Sicherheitsgründen können Sie keinen Netzwerklastenausgleich, wie z. B. Citrix ADC, verwenden. Die VDA-Registrierung verwendet die gegenseitige Kerberos-Authentifizierung, bei der der Client (VDA) seine Identität gegenüber dem Dienst (Controller) nachweisen muss. Der Controller oder Cloud Connector muss jedoch seine Identität gegenüber dem VDA nachweisen. Dies bedeutet, dass der VDA und der Controller oder Cloud Connector gleichzeitig als Server und Client fungieren. Wie zu Beginn dieses Artikels erwähnt, gibt es zwei Kommunikationskanäle: VDA zu Controller/Cloud Connector und Controller/Cloud Connector zu VDA.

Eine Komponente in diesem Prozess wird als Service Principal Name (SPN) bezeichnet, der als Eigenschaft in einem Active Directory-Computerobjekt gespeichert ist. Wenn Ihr VDA eine Verbindung zu einem Controller oder Cloud Connector herstellt, muss er angeben, mit wem er kommunizieren möchte. Diese Adresse ist ein SPN. Wenn Sie eine Lastenausgleichs-IP verwenden, erkennt die gegenseitige Kerberos-Authentifizierung korrekt, dass die IP nicht zum erwarteten Controller oder Cloud Connector gehört.

Weitere Informationen finden Sie unter:

Auto-Update ersetzt CNAME

Die Auto-Update-Funktion ersetzt die CNAME-Funktion (DNS-Alias) aus XenApp- und XenDesktop-Versionen vor 7.x. Die CNAME-Funktionalität ist ab XenApp und XenDesktop 7 deaktiviert. Verwenden Sie Auto-Update anstelle von CNAME. (Wenn Sie CNAME verwenden müssen, siehe CTX137960. Damit das DNS-Aliasing konsistent funktioniert, verwenden Sie Auto-Update und CNAME nicht gleichzeitig.)

Controller-/Cloud Connector-Gruppen

In bestimmten Szenarien möchten Sie Controller oder Cloud Connectors möglicherweise in Gruppen verarbeiten, wobei eine Gruppe bevorzugt wird und die andere Gruppe für ein Failover verwendet wird, falls alle Controller/Cloud Connectors ausfallen. Beachten Sie, dass Controller oder Cloud Connectors zufällig aus der Liste ausgewählt werden, sodass die Gruppierung dazu beitragen kann, eine bevorzugte Nutzung durchzusetzen.

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

Verwenden Sie Klammern, um Gruppen von Controllern/Cloud Connectors anzugeben. Zum Beispiel könnte bei vier Controllern (zwei primäre und zwei Sicherungs-Controller) eine Gruppierung wie folgt aussehen:

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

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

Für XenDesktop 7.0 oder höher müssen Sie einen zusätzlichen Schritt ausführen, um die Funktion Registrierungsgruppen zu verwenden. Sie müssen die Richtlinie Automatische Aktualisierung des Controllers aktivieren in Studio verbieten.

ListOfSIDs

Die Liste der Controller, die ein VDA zur Registrierung kontaktieren kann, ist die ListofDDCs. Ein VDA muss auch wissen, welchen Controllern er vertrauen soll, da VDAs den Controllern in der ListofDDCs nicht automatisch vertrauen. Die ListofSIDs (Sicherheits-IDs) identifizieren die vertrauenswürdigen Controller. VDAs versuchen, sich nur bei vertrauenswürdigen Controllern zu registrieren.

In den meisten Umgebungen wird die ListofSIDs automatisch aus der ListofDDCs generiert. Sie können einen CDF-Trace verwenden, um die ListofSIDs zu lesen.

Im Allgemeinen ist es nicht erforderlich, die ListofSIDs manuell zu ändern. Es gibt mehrere Ausnahmen. Die ersten beiden Ausnahmen sind nicht mehr gültig, da neuere Technologien verfügbar sind.

  • Getrennte Rollen für Controller: Bevor Zonen in XenApp und XenDesktop 7.7 eingeführt wurden, wurde die ListofSIDs manuell konfiguriert, wenn nur eine Untergruppe von Controllern für die Registrierung verwendet wurde. Wenn Sie beispielsweise XDC-001 und XDC-002 als XML-Broker und XDC-003 und XDC-004 für die VDA-Registrierung verwendet haben, haben Sie alle Controller in der ListofSIDs und XDC-003 und XDC-004 in der 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: Bevor die Auto-Update-Funktion in XenApp und XenDesktop 7.6 eingeführt wurde, wurde die ListofSIDs verwendet, um die Last auf Domänencontrollern zu reduzieren. Durch das Vorabfüllen der ListofSIDs kann die Auflösung von DNS-Namen zu SIDs übersprungen werden. Die Auto-Update-Funktion macht diese Arbeit jedoch überflüssig, da dieser persistente Cache SIDs enthält. Citrix empfiehlt, die Auto-Update-Funktion aktiviert zu lassen.
  • Sicherheit: In einigen hochsicheren Umgebungen wurden die SIDs vertrauenswürdiger Controller manuell konfiguriert, um mögliche Sicherheitsbedrohungen durch einen kompromittierten DNS-Server zu vermeiden. Wenn Sie dies tun, müssen Sie jedoch auch die Auto-Update-Funktion deaktivieren. Andernfalls wird die Konfiguration aus einem persistenten Cache verwendet.

Wenn Sie also keinen bestimmten Grund haben, ändern Sie die ListofSIDs nicht.

Wenn Sie die ListofSIDs ändern müssen, erstellen Sie einen Registrierungsschlüssel namens ListOfSIDs (REG_SZ) unter HKLM\Software\Citrix\VirtualDesktopAgent. Der Wert ist eine Liste vertrauenswürdiger SIDs, die durch Leerzeichen getrennt sind, wenn Sie mehr als eine haben.

Im folgenden Beispiel wird ein Controller für die VDA-Registrierung (ListofDDCs) verwendet, aber zwei Controller werden für das Brokering (List OfSIDs) verwendet.

Beispiel für verschiedene Controller, die für Registrierung und Brokering verwendet werden

Controller-Suche während der VDA-Registrierung

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

Wenn diese anfängliche Abfrage den Controller nicht findet, kann der Broker Agent eine Top-Down-Fallback-Abfrage in AD starten. Diese Abfrage durchsucht alle Domänen und wird häufig wiederholt. Wenn die Controller-Adresse ungültig ist (z. B. wenn der Administrator bei der Installation des VDA einen falschen FQDN eingegeben hat), kann die Aktivität dieser Abfrage potenziell zu einem Distributed Denial of Service (DDoS)-Zustand auf dem Domänencontroller führen.

Der folgende Registrierungsschlüssel steuert, ob der Broker Agent die Top-Down-Fallback-Abfrage verwendet, wenn er bei der anfänglichen Suche keinen Controller finden kann.

HKEY_LOCAL_MACHINE\Software\Citrix\VirtualDesktopAgent

  • Name: DisableDdcWildcardNameLookup
  • Typ: DWORD
  • Wert: 0 (Standard) oder ein beliebiger Wert ungleich Null

Wenn auf 0 gesetzt, ist die Fallback-Suche aktiviert. Schlägt die anfängliche Suche nach dem Controller fehl, wird die Top-Down-Fallback-Suche gestartet. Dies ist das Standardverhalten. Wenn jedoch ein beliebiger Wert ungleich Null festgelegt wird, ist die Fallback-Suche deaktiviert. Schlägt die anfängliche Suche nach dem Controller fehl, stellt der Broker Agent die Suche ein.

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

Wenn sich ein VDA bei einem schreibgeschützten Domänencontroller (RODC) registriert, muss der Broker Agent auswählen, welche LDAP-Bindung(en) (Light Directory Access Protocol) ignoriert werden sollen. Für diese Auswahl benötigt der Broker Agent einen geeigneten Registrierungsschlüssel.

Wenn kein Registrierungsschlüssel angegeben oder das Feld für den Registrierungsschlüssel leer ist, dauert die VDA-Registrierung beim RODC länger, da die ursprüngliche LDAP-Bindungssequenz durchlaufen werden muss.

Um die LDAP-Bindungssequenz zu ändern, wurde der Registrierungsschlüssel ListofIgnoredBindings zu HKEY_LOCAL_MACHINE\Software\Policies\Citrix\VirtualDesktopAgent hinzugefügt. Die Verwendung von ListofIgnoredBindings ermöglicht es Ihnen, die LDAP-Bindungssequenz nach Bedarf zu ändern und dadurch die VDA-Registrierung bei einem RODC zu 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 er nicht als gültig erkennt.

Beheben von VDA-Registrierungsproblemen

Wie bereits erwähnt, muss ein VDA bei einem Delivery Controller oder Cloud Connector registriert sein, um bei der Initiierung vermittelter Sitzungen berücksichtigt zu werden. Nicht registrierte VDAs können zu einer Unterauslastung ansonsten verfügbarer Ressourcen führen. Es gibt verschiedene Gründe, warum ein VDA möglicherweise nicht registriert ist, von denen viele von einem Administrator behoben werden können. Studio bietet Informationen zur Fehlerbehebung im Assistenten zur Katalogerstellung und nach dem Erstellen einer Bereitstellungsgruppe.

  • Identifizieren von Problemen während der Maschinenkatalogerstellung: Im Assistenten zur Katalogerstellung zeigt die Liste der Computerkontonamen nach dem Hinzufügen vorhandener Maschinen an, ob jede Maschine für das Hinzufügen zum Katalog geeignet ist. Fahren Sie mit der Maus über das Symbol neben jeder Maschine, um eine informative Meldung zu dieser Maschine anzuzeigen.

    Wenn die Meldung eine problematische Maschine identifiziert, können Sie diese Maschine entweder entfernen (mithilfe der Schaltfläche Entfernen) oder die Maschine hinzufügen. Wenn eine Meldung beispielsweise darauf hinweist, dass keine Informationen über eine Maschine abgerufen wurden (möglicherweise weil sie sich nie registriert hatte), können Sie die Maschine trotzdem hinzufügen.

    Die Funktionsebene eines Katalogs steuert, welche Produktfunktionen für Maschinen im Katalog verfügbar sind. Die Verwendung von Funktionen, die in neuen Produktversionen eingeführt wurden, erfordert möglicherweise einen neuen VDA. Das Festlegen einer Funktionsebene macht alle in dieser Version eingeführten Funktionen (und spätere, wenn sich die Funktionsebene nicht ändert) für Maschinen im Katalog verfügbar. Maschinen in diesem Katalog mit einer früheren VDA-Version können sich jedoch nicht registrieren.

  • Identifizieren von Problemen nach dem Erstellen von Bereitstellungsgruppen: Nachdem Sie eine Bereitstellungsgruppe erstellt haben, zeigt Studio Details zu den mit dieser Gruppe verbundenen Maschinen an.

    Der Detailbereich für eine Bereitstellungsgruppe zeigt die Anzahl der Maschinen an, die registriert sein müssen, aber nicht registriert sind. Mit anderen Worten, es kann eine oder mehrere Maschinen geben, die eingeschaltet und nicht im Wartemodus sind, aber derzeit nicht bei einem Controller registriert sind. Wenn Sie eine „nicht registrierte, aber erforderliche“ Maschine anzeigen, überprüfen Sie die Registerkarte Problembehandlung im Detailbereich auf mögliche Ursachen und empfohlene Korrekturmaßnahmen.

Weitere Informationen zur Problembehandlung bei der VDA-Registrierung

VDA-Registrierung
April 1, 2026
Beitrag von: 
C C
April 1, 2026
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.