XenApp and XenDesktop

VDA-Registrierung

Einführung

VDAs können erst verwendet werden, wenn sie bei mindestens einem Controller oder einem Cloud Connector der Site registriert wurden (Herstellen der Kommunikation). (In on-premises XenApp und XenDesktop-Bereitstellungen werden VDAs bei einem Controller registriert. In XenApp und XenDesktop Service-Bereitstellungen werden VDAs bei Cloud Connectors registriert.) Der VDA findet den Controller bzw. Connector anhand der Liste “ListofDDCs”. Die Liste “ListOfDDCs” auf einem VDA enthält DNS-Einträge, die den VDA an die Controller bzw. Cloud Connectors der Site verweisen. Um einen Lastausgleich zu erzielen, verteilt der VDA die Verbindungen automatisch über alle Controller bzw. Cloud Connectors in der Liste.

Warum ist die VDA-Registrierung so wichtig?

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

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

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

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

Methoden zum Konfigurieren von Controller-/Cloud Connector-Adressen

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

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

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

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

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

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

VDA – Controller installieren

Konfiguration über Richtlinien (LGPO, GPO)

Citrix empfiehlt die Verwendung des Gruppenrichtlinienobjekts für die VDA-Erstregistrierung. Es hat die höchste Priorität. (Obwohl die automatische Aktualisierung vorher mit höchster Priorität aufgelistet wurde, wird automatische Aktualisierung nur nach der Erstregistrierung verwendet.) Die richtlinienbasierte Registrierung bietet den Vorteil der Zentralisierung der Konfiguration über die Gruppenrichtlinie.

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

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

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

Konfiguration über die Registrierung

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

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

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

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

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

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

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

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

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

Nicht vergessen:

Wenn Sie außerdem die richtlinienbasierte VDA-Registrierung über die Citrix Richtlinie aktivieren, hat diese Konfiguration Vorrang vor den bei der VDA-Installation angebenen Konfigurationseinstellungen, da sie eine höhere Methodenpriorität hat.

Konfiguration über Active Directory-Organisationseinheit

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

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

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

Informationen finden Sie unter Auf Organisationseinheiten von Active Directory basierende Controller-Discovery.

Konfiguration über MCS

Wenn Sie virtuelle Maschinen mit MCS bereitstellen, können Sie MCS zur Einrichtung der Liste der Controller bzw. Cloud Connectors konfigurieren. Dieses Feature ist kompatibel mit der automatischen Aktualisierung: MCS fügt die Controller-/Connectorliste bei der ersten Bereitstellung (beim Erstellen des Maschinenkatalogs) in die Datei Personality.ini ein. Die automatische Aktualisierung sorgt dafür, dass die Liste immer aktuell bleibt.

Diese Methode wird für große Umgebungen nicht empfohlen. Sie eignet sich in folgenden Fällen:

  • Die Umgebung ist klein.
  • Es werden keine VDAs zwischen Sites verschoben.
  • Sie stellen virtuelle Maschinen ausschließlich mit MCS bereit.
  • Sie möchten die Gruppenrichtlinie nicht verwenden.

Gehen Sie zum Angeben dieser Methode folgendermaßen vor:

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

Empfehlungen

Bewährte Methoden:

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

Automatische Updates

Die automatische Aktualisierung wurde in XenApp und XenDesktop 7.6 eingeführt und ist standardmäßig aktiviert. Sie stellt die effizienteste Methode dar, um VDA-Registrierungen auf dem neuesten Stand zu halten. Bei der Erstregistrierung eines VDAs erfolgt zwar keine automatische Aktualisierung, die zugehörige Software lädt jedoch die Liste “ListOfDDCs” herunter und speichert sie in einem persistenten Cache auf dem VDA. Dies geschieht bei jedem VDA. (In dem Cache werden auch Maschinenrichtlinieninformationen gespeichert, sodass Richtlinieneinstellungen bei Neustarts beibehalten werden.)

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

Gehen Sie zum Angeben dieser Methode folgendermaßen vor:

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

Funktionsweise:

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

Beispiel:

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

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

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

VDA-Registrierungscachedatei

Sie können die Cachedatei mit einem WMI-Aufruf abrufen. Allerdings ist sie an einem Speicherort gespeichert, auf den nur das SYSTEM-Konto Lesezugriff hat. Diese Angaben dienen lediglich der Information. ÄNDERN SIE DIESE DATEI NICHT. Änderungen an dieser Datei oder an dem Ordner führen zu einer nicht unterstützten Konfiguration.

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

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

Ausnahme zur Priorität der automatischen Aktualisierung

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

Überlegungen zur Konfiguration

Controller- bzw. Cloud Connector-Adressen

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

Lastausgleich

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

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

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

Weitere Informationen:

Automatische Aktualisierung ersetzt CNAME

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

Controller-/Cloud Connector-Gruppen

Es ist günstig, Controller oder Cloud Connectors in Gruppen zu verarbeiten. Bei Gruppen wird eine Gruppe bevorzugt und die andere Gruppe für ein Failover verwendet, wenn alle Controller/Cloud Connectors ausfallen. Controller bzw. Cloud Connectors werden zufällig aus der Liste ausgewählt, eine Gruppierung kann daher zur Durchsetzung einer bevorzugten Verwendung helfen.

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

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

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

ListOfSIDs

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

In den meisten Umgebungen wird die Liste “ListOfSIDs” automatisch aus der Liste “ListOfDDCs” generiert. Sie können die Liste “ListOfSIDs” mit einer CDF-Ablaufverfolgung lesen.

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

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

Ändern Sie also die Liste “ListOfSIDs” nicht ohne spezifischen Grund.

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

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

VDA-Registrierung

Controllersuche während der VDA-Registrierung

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

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

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

HKEY_LOCAL_MACHINE\Software\Policies\Citrix\VirtualDesktopAgent

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

Bei Auswahl von 1 ist die Fallbacksuche deaktiviert. Wenn die erste Suche nach dem Controller fehlschlägt, sucht der Broker-Agent nicht weiter. Dies ist die Standardeinstellung. Bei Auswahl von 0 ist die Fallbacksuche aktiviert. Wenn die erste Suche nach dem Controller fehlschlägt, wird die Top-Down-Fallbacksuche gestartet.

Problembehandlung bei der VDA-Registrierung

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

Identifizieren von Problemen während der Maschinenkatalogerstellung:

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

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

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

Identifizieren von Problemen nach der Erstellung von Bereitstellungsgruppen:

Nach dem Erstellen einer Bereitstellungsgruppe werden in Studio Informationen zu Maschinen angezeigt, die der Gruppe zugeordnet sind. Im Detailbereich für eine Bereitstellungsgruppe wird die Anzahl der Maschinen angezeigt, die registriert sein müssten, es jedoch nicht sind. Es kann also Maschinen geben, die eingeschaltet und nicht im Wartungsmodus sind, jedoch nicht bei einem Controller registriert sind. Beim Anzeigen einer Maschine, die eigentlich registriert sein müsste, enthält die Registerkarte Problembehandlung im Detailbereich Informationen zu möglichen Ursachen und empfohlene Korrekturmaßnahmen.

Weitere Informationen finden Sie unter Erstellen von Maschinenkatalogen im Abschnitt VDA-Versionen und Funktionsebenen.

Weitere Informationen zur Fehlerbehebung bei der VDA-Registrierung finden Sie unter CTX136668.

Sie können auch den Citrix Health Assistant zur Problembehandlung bei der VDA-Registrierung und Sitzungsstarts verwenden. Weitere Informationen finden Sie unter CTX207624.