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 ü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 Zeitsynchronisierung und der Domänenmitgliedschaft unversöhnlich. Kerberos verwendet Service Principal Names (SPNs), daher können Sie keine Lastenausgleichs-IP\Hostnamen 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 Desktop-Systemsoftware verzögern. Ein VDA akzeptiert keine Verbindung von einem unbekannten und nicht vertrauenswürdigen Controller oder Cloud Connector.
Zusätzlich zu den 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 ein 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-Ermittlung)
- 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 erledigen (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 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 (zum Beispiel, 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 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)
Hinweis: Wenn Sie auch die richtlinienbasierte VDA-Registrierung über die Citrix-Richtlinie aktivieren, überschreibt dies 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 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 RegistrierungseintragFarmGuidauf jedem VDA, sodass er auf die richtige OU verweist. Diese Einstellung kann über Gruppenrichtlinien konfiguriert werden.
Weitere Informationen finden Sie unter Active Directory OU-basierte Erkennung.
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 Datei Personality.ini ein. Die automatische Aktualisierung hält die Liste auf dem neuesten Stand.
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 Registrierungsmethode der Gruppenrichtlinie 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). Richten Sie VDAs auf Controller oder Cloud Connectors aus, 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, durch ein Leerzeichen oder Komma getrennt, um Registrierungsprobleme zu vermeiden, falls ein Controller nicht verfügbar ist. 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 Informationen zur Maschinenrichtlinie, wodurch sichergestellt wird, dass die Richtlinieneinstellungen über Neustarts hinweg beibehalten werden.
Die automatische Aktualisierung wird unterstützt, wenn MCS oder Citrix Provisioning™ zum Bereitstellen von Maschinen verwendet wird, mit Ausnahme des serverseitigen Caches von Citrix Provisioning. Der serverseitige Cache ist kein gängiges Szenario, da kein persistenter Speicher für den Cache der automatischen Aktualisierung vorhanden ist.
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 automatische Aktualisierung in einer Satellitenzone zuerst automatisch alle lokalen Controller. 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 Last des Active Directory 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. Einzelheiten finden Sie unter ListOfSIDs.
Ausnahme von der Auto-Update-Priorität
Obwohl Auto-Update normalerweise die höchste Priorität aller VDA-Registrierungsmethoden hat und Einstellungen für andere Methoden überschreibt, gibt es eine Ausnahme. Die NonAutoListOfDDCs-Elemente im Cache geben die anfängliche VDA-Konfigurationsmethode an. Auto-Update überwacht diese Informationen. Wenn sich die anfängliche Registrierungsmethode ändert, überspringt der Registrierungsprozess das Auto-Update 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 (zum Beispiel 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 betrachtet, 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. 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 die Registrierung bei Bedarf automatisch zwischen ihnen. Mit Auto-Update 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) dem Dienst (Controller) seine Identität nachweisen muss. Der Controller oder Cloud Connector muss jedoch dem VDA seine Identität 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-Adresse 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) von 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 und die andere Gruppe für ein Failover verwendet wird, falls alle Controller/Cloud Connectors ausfallen. Denken Sie daran, dass Controller oder Cloud Connectors zufällig aus der Liste ausgewählt werden, sodass die Gruppierung dazu beitragen kann, eine bevorzugte Nutzung zu erzwingen.
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. Bei vier Controllern (zwei primäre und zwei Sicherungs-Controller) könnte eine Gruppierung beispielsweise 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 Citrix 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 kann; 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 notwendig, 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/2203-ltsr/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. 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 einen Controller während der anfänglichen Suche nicht finden kann.
HKEY_LOCAL_MACHINE\Software\Citrix\VirtualDesktopAgent
- Name:
DisableDdcWildcardNameLookup - Typ:
DWORD - Wert:
0(Standard) oder ein beliebiger Wert ungleich Null
Wenn auf 0 festgelegt, wird die Fallback-Suche aktiviert. Wenn die anfängliche Suche nach dem Controller fehlschlägt, wird die Fallback-Top-Down-Suche gestartet. Dies ist das Standardverhalten. Wenn jedoch ein beliebiger Wert ungleich Null festgelegt wird, wird die Fallback-Suche deaktiviert. Wenn die anfängliche Suche nach dem Controller fehlschlägt, beendet der Broker-Agent die Suche.
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 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 ein Administrator beheben kann. Studio bietet Informationen zur Fehlerbehebung im Assistenten zur Katalogerstellung und nachdem Sie eine Bereitstellungsgruppe erstellt haben.
-
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 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ö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 (und später, wenn sich die Funktionsebene nicht ändert) eingeführten Funktionen 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 sollten, es aber nicht sind. Mit anderen Worten, es kann eine oder mehrere Maschinen geben, die eingeschaltet und nicht im Wartungsmodus sind, aber derzeit nicht bei einem Controller registriert sind. Beim Anzeigen einer Maschine, 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. Details finden Sie unter Informationen zu Integritätsprüfungen.