VDA-Registrierung
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 prü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. Für einen so sensiblen Vorgang ist das erwartete Verhalten, die Verbindung abzulehnen, wenn nicht alles perfekt ist. Sie stellen effektiv zwei separate Kommunikationskanäle her: VDA zu Controller oder Cloud Connector und Controller oder Cloud Connector zu VDA. Die Verbindung verwendet Kerberos, daher sind Probleme mit der Zeitsynchronisation und der Domänenmitgliedschaft unversöhnlich. Kerberos verwendet Service Principal Names (SPNs), daher können Sie keine lastverteilte IP\Hostname verwenden.
- 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 Desktopsystemsoftware verzögern. Ein VDA akzeptiert keine Verbindung von einem unbekannten und nicht vertrauenswürdigen Controller oder Cloud Connector.
Zusätzlich zur ListofDDCs geben die ListOfSIDs (Sicherheits-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 die Konnektivität zu konfigurierten Controllern oder Cloud Connectors während der VDA-Installation automatisch. 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 zum Konfigurieren 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 zum Konfigurieren 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 Abbildung zeigt die Seite Delivery Controller des 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 die automatische Aktualisierung als höchste Priorität aufgeführt ist, wird die automatische Aktualisierung erst nach der anfänglichen Registrierung verwendet.) Die richtlinienbasierte Registrierung bietet die zentralisierenden Vorteile der Verwendung von Gruppenrichtlinien für die Konfiguration.
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 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 höchste Priorität ist, verwenden Sie die EinstellungVirtual 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:
- Wählen Sie auf der Seite Delivery Controller im VDA-Installationsassistenten die Option Manuell eingeben. 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.
- Verwenden Sie für eine VDA-Installation über die Befehlszeile die Option /controllers und geben Sie 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 ist möglicherweise der richtlinienbasierten Methode vorzuziehen (z. B. wenn Sie eine bedingte Verarbeitung verschiedener Controller oder Cloud Connectors wünschen, wie z. B.: 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 Registrierungsspeicherort 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. FarmGUID ist vorhanden, wenn während der VDA-Installation eine Site-OU angegeben wurde. (Dies kann 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)
Denken Sie daran: Wenn Sie auch die richtlinienbasierte VDA-Registrierung über die Citrix-Richtlinie aktivieren, überschreibt diese die Einstellungen, die Sie während der VDA-Installation angeben, da dies eine Methode mit höherer Priorität ist.
Active Directory OU-basiert (veraltet)
Diese Methode wird hauptsächlich zur 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 RegistrierungseintragFarmGuidauf jedem VDA so, dass er auf die richtige OU verweist. Diese Einstellung kann mithilfe von 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 fügt MCS die Liste der Controller oder Cloud Connectors während der Erstbereitstellung in die Personality.ini-Datei ein. 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™ soll dies tun.
Überprüfung und Empfehlungen
Als Best Practice gilt:
- Verwenden Sie die Registrierungsmethode über Gruppenrichtlinien 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 automatisch die
ListofDDCsfür VDAs in Satellitenzonen. -
Listen Sie mehr als einen Controller im Registrierungsschlüssel
ListOfDDCsauf, getrennt durch ein Leerzeichen oder ein Komma, 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
ListofDDCsaufgefü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 Vorgang 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 gängiges Szenario, da es keinen persistenten Speicher für den Cache der automatischen Aktualisierung gibt.
So geben Sie diese Methode an:
- Aktivieren oder deaktivieren Sie die automatische Aktualisierung über eine Citrix-Richtlinie, die die Einstellung
Virtual Delivery Agent Settings > Enable auto update of Controllersenthält. Diese Einstellung ist standardmäßig aktiviert.
Funktionsweise:
- Jedes Mal, wenn sich ein VDA neu registriert (z. B. nach einem Neustart der Maschine), wird der Cache aktualisiert. Jeder Controller oder Cloud Connector überprüft die Sitedatenbank außerdem alle 90 Minuten. 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 aus der Site entfernt), registriert sich der VDA neu und wählt aus den Controllern oder Cloud Connectors in der
ListofDDCs.
Beispiel:
- Eine Bereitstellung hat 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) zur 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 dann gleichmäßig auf alle Controller verteilt, wenn die VDAs neu gestartet werden.)
- Noch später wird Controller B in eine andere Site verschoben. Innerhalb von 90 Minuten erhalten die VDAs in der ursprünglichen Site aktualisierte Listen, da sich seit der letzten Überprüfung ein Controller geändert 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).
In einer Multi-Zonen-Bereitstellung speichert die Auto-Update-Funktion in einer Satellitenzone automatisch zuerst alle lokalen Controller zwischen. 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, was die Active Directory-Last reduziert.
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. ÄNDERN SIE DIESE DATEI NICHT. Jegliche Änderungen an dieser Datei oder diesem Ordner führen 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. Weitere Informationen finden Sie unter ListOfSIDs.
Ausnahme von der Auto-Update-Priorität
Obwohl die automatische Aktualisierung (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. Die automatische Aktualisierung überwacht diese Informationen. Wenn sich die anfängliche Registrierungsmethode ändert, überspringt der Registrierungsprozess die automatische Aktualisierung und verwendet die Methode mit der nächsthöheren konfigurierten Priorität. Dieser Prozess kann hilfreich sein, wenn Sie einen VDA an einen anderen Standort verschieben (z. B. während der Notfallwiederherstellung).
Überlegungen zur Konfiguration
Zeigen Sie eine gängige VDA-Registrierungskonfiguration an.
Zeigen Sie die VDA-Registrierungsschritte an.
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 angesehen, da es einfacher ist, eine IP-Adresse zu kompromittieren als einen DNS-Eintrag. Wenn Sie die ListofSIDs manuell ausfüllen, können Sie eine IP-Adresse in einem ListofDDCs verwenden. Es wird jedoch weiterhin FQDN 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 ihnen. Bei der automatischen Aktualisierung erfolgt ein automatisches Failover für alle VDAs.
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 nicht gleichzeitig Auto-Update und CNAME.)
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 Sicherungen) 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 ist ein zusätzlicher Schritt erforderlich, um die Funktion Registrierungsgruppen zu verwenden. Sie müssen die Richtlinie Automatische Controller-Aktualisierung 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; VDAs vertrauen den Controllern in der ListofDDCs nicht automatisch. 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
ListofSIDsmanuell 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 verwendeten, gaben Sie alle Controller in derListofSIDsund XDC-003 und XDC-004 in derListofDDCsan. 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
ListofSIDsverwendet, um die Last auf Domänencontrollern zu reduzieren. Durch das Vorabfüllen derListofSIDskann die Auflösung von DNS-Namen in 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 jedoch tun, müssen Sie auch die Auto-Update-Funktion deaktivieren. Andernfalls wird die Konfiguration aus dem 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 für das Brokering (List OfSIDs).
Beispiel für verschiedene Controller, die für Registrierung und Brokering verwendet werden(/de-de/citrix-virtual-apps-desktops/2311/media/vda-registration-listofsids.png)
Controller-Suche während der VDA-Registrierung
Wenn ein VDA versucht, sich zu registrieren, führt der Broker-Agent zuerst eine DNS-Abfrage in der lokalen Domäne durch, um sicherzustellen, dass der angegebene Controller erreichbar ist.
Wenn diese anfängliche Suche den Controller nicht findet, kann der Broker-Agent eine Fallback-Top-Down-Abfrage in AD starten. Diese Abfrage durchsucht alle Domänen und wiederholt sich häufig. 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 Fallback-Top-Down-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 eingestellt, ist die Fallback-Suche aktiviert. Schlägt die anfängliche Suche nach dem Controller fehl, wird die Fallback-Top-Down-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 unter Verwendung eines schreibgeschützten Domänencontrollers
Wenn ein VDA sich bei einem schreibgeschützten Domänencontroller (RODC) registriert, muss der Broker-Agent auswählen, welche Light Directory Access Protocol (LDAP)-Bindung(en) ignoriert werden sollen. Um diese Auswahl zu treffen, benötigt der Broker-Agent einen geeigneten Registrierungsschlüssel.
Wenn kein Registrierungsschlüssel angegeben wird oder das Feld für den Registrierungsschlüssel leer ist, dauert die VDA-Registrierung beim RODC länger, da sie die ursprüngliche LDAP-Bindungssequenz durchlaufen 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 bei 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 alle Werte, die er nicht als gültig erkennt.
Beheben von Problemen bei der VDA-Registrierung
Wie bereits erwähnt, muss ein VDA bei einem Delivery Controller oder Cloud Connector registriert sein, um beim Starten von vermittelten 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 nachdem Sie eine Bereitstellungsgruppe erstellt haben.
-
Probleme bei der Erstellung von Maschinenkatalogen identifizieren: Im Assistenten zur Katalogerstellung zeigt die Liste der Computerkontonamen nach dem Hinzufügen vorhandener Maschinen an, ob jede Maschine für die Aufnahme in den 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 beispielsweise eine Meldung darauf hinweist, dass keine Informationen über eine Maschine abgerufen wurden (vielleicht weil sie nie registriert wurde), könnten Sie sich trotzdem dafür entscheiden, die Maschine hinzuzufügen.
Die funktionale Ebene 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 funktionalen Ebene macht alle in dieser Version eingeführten Funktionen (und spätere, wenn sich die funktionale Ebene 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.
-
Probleme nach dem Erstellen von Bereitstellungsgruppen identifizieren: Nachdem Sie eine Bereitstellungsgruppe erstellt haben, zeigt Studio Details zu den mit dieser Gruppe verbundenen Maschinen an.
Der Detailbereich einer Bereitstellungsgruppe zeigt die Anzahl der Maschinen an, die registriert sein sollten, es aber nicht sind. Mit anderen Worten, es gibt möglicherweise eine oder mehrere Maschinen, die eingeschaltet und nicht im Wartungsmodus sind, aber derzeit nicht bei einem Controller registriert sind. Wenn Sie eine Maschine anzeigen, die „nicht registriert, aber registriert sein sollte“, überprüfen Sie die Registerkarte Problembehandlung im Detailbereich auf mögliche Ursachen und empfohlene Korrekturmaßnahmen.
Weitere Informationen zur Problembehandlung bei der VDA-Registrierung
-
Weitere Informationen zu Funktionsebenen finden Sie unter VDA-Versionen und Funktionsebenen.
-
Weitere Informationen zur Problembehandlung bei der VDA-Registrierung finden Sie unter CTX136668.
-
Sie können auch Citrix Scout-Integritätsprüfungen verwenden, um Probleme bei der VDA-Registrierung und dem Sitzungsstart zu beheben. Einzelheiten finden Sie unter Informationen zu Integritätsprüfungen.
In diesem Artikel
- Einführung
- Methoden zum Konfigurieren von Controller- oder Cloud Connector-Adressen
- Automatische Aktualisierung
- Überlegungen zur Konfiguration
- ListOfSIDs
- Controller-Suche während der VDA-Registrierung
- LDAP-Bindungssequenzierung während der VDA-Registrierung unter Verwendung eines schreibgeschützten Domänencontrollers
- Beheben von Problemen bei der VDA-Registrierung