Vous être sûrement nombreux à avoir vécu, ou à vivre encore ? Le fameux « not registred » de vos machines sur vos DDC, ou alors des machines qui passent automatiquement en « maintenance mode ».

Il peut y avoir plusieurs causes à effet de cet état :

  • La machine est éteinte ? logique une machine éteinte ne peut pas être en mode « registred » puisque l’agent ne communique pas.
  • Le service, ou l’exe du VDA est endommagé, ou bloqué par un tiers (Antivirus par exemple)
  • Des problèmes de DNS sur vos contrôleurs, ou de vos serveurs/machines clientes ?
  • Le Firewall qui bloque ? un mauvais enregistrement de vos ddc ?
  • Etc…

Il existe de multiples causes de ce statut, c’est pour cela qu’il est parfois un peu chaotique de s’y retrouver dans le troubleshooting des VDA.

Tout d’abord, je vais brièvement vous expliquer comment fonctionne un enregistrement, c’est relativement simple.

Le DDC va contacter, envoyer une requête (un heartbeat) toutes les 20 minutes aux machines de la ferme, si pour « x » raison il ne parvenait pas à contacter une ou des machines, il réessayera 3 fois avant de placer la machine en maintenance mode.

Cela a pour but d’éviter les nombreuses communications inutiles, et ainsi optimiser au maximum les flux des infrastructures. En cas de négligence de ce service sur de grosses infrastructures hébergées par VMware par exemple, vous pourriez saturer le service SDK par exemple, et si votre SDK est saturé, c’est l’ensemble de vos infrastructures XenApp 7.5 et XenDesktop qui seraient dégradées.

Ce mécanisme a un nom, vous l’abordez dans les formations Citrix officielles, le Power Save.

A ce sujet, Immajg Consult, la société qui m’emploie donne des cours officiels via notamment, Patrice Jacques-gustave, CCI et auteur de ce superbe blog, et c’est sûrement le meilleur CCI que je connaisse … m’enfin soyons objectifs J

Nous pouvons modifier le comportement des remontées d’informations entre le DDC et les VDA en modifiant une clé de registre :

–        « DesktopServer\MaxFailedRegistrationsAllowed » sur 0xFFFFFFFF

Cette valeur « 0xFFFFFFFF » augmente considérablement le nombre d’échecs « tolérés » par le DDC avant de placer la machine en « maintenance mode ».

En gros, c’est une rustine qui empêchera vos machines de passer en mode maintenance si vous avez des petites instabilités dans vos infrastructures mais ne doit en aucun cas solutionner le problème de fond.

Je vais vous expliquer, ci-dessous ma méthodologie afin de déterminer ce qui pourrait être la cause de ce dysfonctionnement.

En pré- requis avant de vous lancer dans un troubleshooting avancé, vérifiez les éléments de « base » comme la présence des clés dans la base de registre, le firewal, les ports, un ping, etc …

–        Activez les logs sur vos machines (VDA)

  • BrokerAgent.exe.config pour XenApp 7.5 et XenDesktop 7.x
  • WorkstationAgent.exe.config pour XenDesktop 5.x

 –        Activez les logs sur vos contrôleurs (DDC)

 –        Faites un XDping et analysez les dernières lignes où il indique que les machines ne parviennent pas à communiquer avec nos DDC.

SD_0004_photo_1

Une fois les traces en place, faites des tests avec les machines qui vous posent des problèmes (Reboot, ouverture de session etc…).

–        Analyse d’une trace de VDA :

[  11] 23/07/14 16:53:57.7660 : Workstation Agent:Failed to find controller DDC1 in AD, skipping…

[  11] 23/07/14 16:53:57.7660 : Workstation Agent:Attempting to validate controller hostname1by looking up (&(objectCategory=computer)(cn=hostname1)) filter in AD

[  11] 23/07/14 16:53:57.7660 : Workstation Agent:Obtained controller SID: S-1-5-21-1547161642-1482476501-839522115-397924

[  11] 23/07/14 16:53:57.7660 : Workstation Agent:AD object found

[  11] 23/07/14 16:53:57.7660 : Workstation Agent:No endpoint pattern found, using defaults

[  11] 23/07/14 16:53:57.7660 : Workstation Agent:Adding controller to list: hostname1.lab.local, hostname1, http:// hostname1.lab.local:80/Citrix/CdsController/IRegistrar

[  11] 23/07/14 16:53:57.7660 : Workstation Agent:Attempting to validate controller DDC2 by looking up (&(objectCategory=computer)(cn=DDC2)) filter in AD

[  11] 23/07/14 16:53:57.7660 : Workstation Agent:Attempting to validate controller DDC2 by looking up (&(objectCategory=computer)(dNSHostName=DDC2*)) filter in AD

[  11] 23/07/14 16:53:59.1701 : Workstation Agent:Failed to find controller DDC2 in AD, skipping..

On constate 3 points importants sur la trace, que l’agent ne parvient pas à s’enregistrer sur les deux contrôleurs DDC1 et DDC2 « [  11] 23/07/14 16:53:59.1701 : Workstation Agent:Failed to find controller DDC2 in AD, skipping..” Mais … il contacte le service « IRegistrar en FDDN » …

Avec cette première trame d’informations, nous allons pouvoir aller vérifier la configuration de nos agents et des services qui oscillent autour.

  • Vérification de la base de registre (Ok ci-dessous, les machines sont en FQDN)

SD_0004_photo_2

  • Vérification de nos DNS, les deux entrées existent, ce sont des alias DNS :

SD_0004_photo_3

  • Vérification des enregistrements AD

SetSPN –l hostname

Jusqu’à présent tous les éléments sont corrects d’après l’analyse des logs, il faut maintenant synthétiser le résultat de nos analyses :

–        Les logs des VDA montrent que :

Les VDA essayent de s’enregistrer via des objets présents dans l’AD. Fonction appelée Active Directory-Based Controller Discovery.

http://support.citrix.com/proddocs/topic/xendesktop-rho/cds-about-broker-discovery-rho.html

Il est possible de paramétrer l’enregistrement basé sur les contrôleurs (DDC) et non sur une recherche active directory, la procédure est décrite dans le lien ci-dessus.

Les objets enregistrés sont : DDC1 (alias) pour l’objet AD hostname1, DDC2 pour l’objet AD hostname2.

DDC1 et DDC2 étant des alias, ces objets sont donc non présents dans l’AD.

–        La conclusion :

Le log nous indiquait « [  11] 23/07/14 16:53:57.7660 : Workstation Agent:Adding controller to list: hostname1.lab.local, hostname1, http:// hostname1.lab.local:80/Citrix/CdsController/IRegistrar”. Cela signifie qu’il parvient à s’enregistrer sur le DDC « hostname1 » mais qu’il fait des tentatives d’enregistrement sur des objets AD inexistants (DDC1 et DDC2) qui sont donc des alias.

Cela a pour cause à effet d’avoir de temps à autres des machines en statut « unregistred » et d’alourdir le processus de communication entre le VDA et le DDC suite à une méthode « default » non optimisée, c’est pourquoi dans cet exemple nous pouvons suggérer le fait :

  • De retirer les alias DNS
  • De modifier le comportement d’enregistrement sur VDA avec le script « Set-ADControllerDiscovery.ps1 »

Après modification du comportement d’enregistrement des VDA, relancez des traces pour voir si cela fonctionne correctement.

N’hésitez pas à partager ou demander un petit coup de pouce je ne manquerai pas d’y répondre.

A bientôt

Steeve DELMOTTE.

Tweeter : @rSx78

Laisser un commentaire