VDA-Registrierung
Einführung
Bevor ein VDA verwendet werden kann, muss er sich bei einem oder mehreren Controllern oder Cloud Connectors am Standort registrieren (Kommunikation herstellen). (In einer lokalen XenApp- und XenDesktop®-Bereitstellung registrieren sich VDAs bei Controllern. In einer XenApp- und XenDesktop Service-Bereitstellung registrieren sich VDAs bei Cloud Connectors.) 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 zu Controller oder Cloud Connector und Controller oder Cloud Connector zu VDA. Die Verbindung verwendet Kerberos, daher sind Probleme mit der Zeitsynchronisierung und der Domänenmitgliedschaft unversöhnlich. Kerberos verwendet Dienstprinzipalnamen (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 wurden. 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 gibt die ListOfSIDs (Sicherheits-IDs) an, welche Maschinen in den ListOfDDCs vertrauenswürdig sind. Die ListOfSIDs können 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 können 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 den ListOfDDCs übergeht.
XenApp® und XenDesktop testen 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 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. (Dies wird als Erstregistrierung bezeichnet.) 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, 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 auch 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 zuvor als höchste Priorität aufgeführt wurde, wird die automatische Aktualisierung nur 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 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. (Weil die VDA-Registrierung so wichtig ist!)
- Aktivieren oder deaktivieren Sie die richtlinienbasierte VDA-Registrierung über eine 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 ausfü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.
- 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 normalerweise 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 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)
Hinweis:
Wenn Sie die richtlinienbasierte VDA-Registrierung auch über die Citrix-Richtlinie aktivieren, überschreibt diese Konfiguration die Einstellungen, die Sie während der VDA-Installation angeben, da es sich um eine Methode mit höherer Priorität handelt.
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 Registrierungseintrag FarmGuid auf jedem VDA so, dass er auf die richtige OU verweist. Diese Einstellung kann mithilfe von Gruppenrichtlinien konfiguriert werden.
Weitere Informationen finden Sie unter Active Directory OU-basierte Erkennung.
MCS-basiert
Wenn Sie planen, nur MCS zur Bereitstellung von VMs zu verwenden, können Sie MCS anweisen, die Liste der Controller oder Cloud Connectors einzurichten. Diese Funktion ist mit der automatischen Aktualisierung kompatibel: MCS fügt die Liste der Controller oder Cloud Connectors während der Erstbereitstellung (beim Erstellen des Maschinenkatalogs) in die Datei Personality.ini ein. Die automatische Aktualisierung hält die Liste auf dem neuesten Stand.
Diese Methode wird für den Einsatz in großen Umgebungen nicht empfohlen. Sie können diese Methode verwenden, wenn Sie:
- Eine kleine Umgebung haben
- VDAs nicht zwischen Sites verschieben
- Nur MCS zur Bereitstellung von VMs verwenden
- Keine Gruppenrichtlinie verwenden möchten
So geben Sie diese Methode an:
- Wählen Sie auf der Seite Delivery Controller im VDA-Installationsassistenten die Option Machine Creation Services™ ausführen lassen.
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). 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 die ListOfDDCs für VDAs in Satellitenzonen automatisch.
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 die automatische Aktualisierung 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. Dies geschieht für jeden VDA. (Der Cache enthält auch Informationen zur Maschinenrichtlinie, wodurch sichergestellt wird, dass die Richtlinieneinstellungen über Neustarts hinweg beibehalten werden.)
Die automatische Aktualisierung wird bei der Bereitstellung von Maschinen mit MCS oder PVS unterstützt, mit Ausnahme des PVS-serverseitigen Caches (was kein häufiges Szenario ist, 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 Maschinenneustart), 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 aus der Site entfernt), registriert sich der VDA neu und wählt dabei 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 nach dem Neustart der VDAs gleichmäßig auf alle Controller verteilt.)
- 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 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 dabei aus den Controllern in der aktuellen Liste (A, C, D und E).
In einer Multi-Zonen-Bereitstellung speichert die automatische Aktualisierung 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 Last auf 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. 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 manuell konfigurieren müssen (im Gegensatz zur Reduzierung der Active Directory-Last), können Sie die Auto-Update-Funktion nicht verwenden. Weitere Informationen 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 Methode mit der nächsthöheren konfigurierten Priorität. Dies kann hilfreich sein, wenn Sie einen VDA an einen anderen Standort verschieben (z. B. während der Notfallwiederherstellung).
Überlegungen zur Konfiguration
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 füllen, können Sie eine IP-Adresse in einer 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. Mit dem 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 Kerberos-gegenseitige 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 zum Controller oder Cloud Connector und Controller oder Cloud Connector zum 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:
- Einführung in Kerberos: https://blogs.technet.microsoft.com/askds/2008/03/06/kerberos-for-the-busy-admin/
- Gegenseitige Authentifizierung mit Kerberos: https://docs.microsoft.com/de-de/windows/win32/ad/mutual-authentication-using-kerberos?redirectedfrom=MSDN
Auto-Update ersetzt CNAME
Die Auto-Update-Funktion ersetzt die CNAME (DNS-Alias)-Funktion 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
Sie möchten Controller oder Cloud Connectors möglicherweise in Gruppen verarbeiten. Bei Gruppen wird eine Gruppe bevorzugt und die andere Gruppe für ein Failover verwendet, 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 durchzusetzen.
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.
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) identifiziert die vertrauenswürdigen Controller. VDAs versuchen nur, sich 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 jedoch mehrere Ausnahmen. Die ersten beiden Ausnahmen sind nicht mehr gültig, da neuere Technologien verfügbar sind.
- Separate 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 verwendeten, gaben Sie alle Controller in der ListOfSIDs und XDC-003 und XDC-004 in der ListOfDDCs an. Dies ist keine typische oder empfohlene Konfiguration und wird in neueren Umgebungen nicht verwendet. 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 konnte 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 jedoch tun, müssen Sie auch die Auto-Update-Funktion deaktivieren. Andernfalls wird die Konfiguration aus dem persistenten Cache verwendet.
Ändern Sie die ListOfSIDs also nicht, es sei denn, Sie haben einen bestimmten Grund dafür.
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 (ListOfSIDs) verwendet.
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 Abfrage 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\Policies\Citrix\VirtualDesktopAgent
- Name:
DisableDdcWildcardNameLookup - Typ:
DWORD - Wert:
1(Standard) oder0
Wenn auf 1 gesetzt, ist die Fallback-Suche deaktiviert. Schlägt die anfängliche Suche nach dem Controller fehl, stellt der Broker Agent die Suche ein. Dies ist die Standardeinstellung.
Wenn auf 0 gesetzt, ist die Fallback-Suche aktiviert. Schlägt die anfängliche Suche nach dem Controller fehl, wird die Fallback-Top-Down-Suche gestartet.
Beheben von Problemen bei der VDA-Registrierung
Wie bereits erwähnt, muss ein VDA bei einem Delivery Controller 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 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 (mit der Schaltfläche Entfernen) oder die Maschine hinzufügen. Wenn eine Meldung beispielsweise darauf hinweist, dass keine Informationen über eine Maschine abgerufen wurden (vielleicht weil sie sich nie bei einem Delivery Controller registriert hatte), können Sie die Maschine trotzdem hinzufügen.
Die Funktionsebene eines Katalogs steuert, welche Produktfunktionen für Maschinen in diesem 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äter, wenn sich die Funktionsebene nicht ändert) für Maschinen im Katalog verfügbar. Maschinen in diesem Katalog mit einer älteren 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 verknüpften 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. Wenn Sie eine Maschine anzeigen, die „nicht registriert ist, aber registriert sein sollte“, überprüfen Sie die Registerkarte Problembehandlung im Detailbereich auf mögliche Ursachen und empfohlene Korrekturmaßnahmen.
Weitere Informationen zu Funktionsebenen finden Sie im Abschnitt VDA-Versionen und Funktionsebenen unter Maschinenkataloge erstellen.
Weitere Informationen zur Problembehandlung bei der VDA-Registrierung finden Sie unter CTX136668.
Sie können auch den Citrix Health Assistant verwenden, um Probleme bei der VDA-Registrierung und dem Sitzungsstart zu beheben. Weitere Informationen finden Sie unter CTX207624.
In diesem Artikel
- Einführung
- Methoden zur Konfiguration von Controller- oder Cloud Connector-Adressen
- Richtlinienbasiert (LGPO\GPO)
- Registrierungsbasiert
- Active Directory OU-basiert (veraltet)
- MCS-basiert
- Empfehlungen
- Automatische Aktualisierung
- Überlegungen zur Konfiguration
- ListOfSIDs
- Controller-Suche während der VDA-Registrierung
- Beheben von Problemen bei der VDA-Registrierung