XenApp – Page 9

Rechercher un EventId au sein d’une ferme XenApp

Il arrive lors de troubleshooting que l’on souhaite connaître la présence (ou pas) d’un EventId au sein des divers silo d’une ferme XenApp (ce qui permettra par la suite d’appliquer le correctif sur les silos impactés et au passage de faire une petite comm 😉 ).

Dans le cas présent il s’agissait de connaitre la liste des silos (avec leurs serveurs) rencontrant l’EventId 6005 (nous ferons très prochainement un billet sur cet EventId) afin de pouvoir appliquer la GPO corrigeant le problème sur les serveurs concernés.

On utilise la cmdlet Get-EventLog afin de retrouver l’EventID recherché (avec un filtre -Newest 500, suffisant pour constater ou pas la présence de l’EventId durant les derniers jours).

Au préalable modifier la valeur “6005” (et/ou changer le type de journal dans lequel vous allez effectuer votre recherche) par celui recherché en ligne 8 du script.

La liste des silo Impactés est affichée dans la colonne FolderPath

Search_Event_XenApp.ps1

Cela exclue pas l’utilisation d’un bon vieux Syslog ou un Graylog2 😉

Script : Retrouver la ferme d’un serveur XenApp

Si vous souhaitez retrouver (ou un de vos collègues 😉 ) la ferme d’un serveur XenApp dans un environnement “riche” (plusieurs fermes de Prod avec leur Qualif et Recette associés), vous pouvez passer par :

Un AppCenter qui agrège toutes les fermes
Une nomenclature explicite
Votre outil d’inventaire
A l’ancienne (RDP sur le serveur ou accès en remote à la registry du serveur ou au fichier mf20.dsn etc… etc..)
Un script PowerShell

Concernant le script, nous utilisons la cmdlet GET-ADComputer pour checker si le serveur est bien dans l’AD (et récupérer son DN), puis on récupère en WMI la valeur registre “Neighborhood” afin de remonter le nom de la ferme d’appartenance du serveur .

Le serveur existe bien dans l’AD mais n’est dans aucune ferme XenApp

Le serveur existe bien dans l’AD mais ne répond pas à l’ICMP

Le serveur n’existe pas dans l’AD

Le serveur existe bien dans l’AD et on retrouve sa ferme XenApp

SearchXenAppFarm.ps1

Retour “qfarm /load” vide

Nous allons dans ce billet vous expliquer comment un serveur “pas entièrement supprimé d’une ferme XenApp” peut engendrer un effet de bord inattendu (mais logique).

Il y a quelques temps nous avons rencontré un problème de retour avec la commande qfarm /load, en effet un qfarm /load ne retournait aucun serveur (un qfarm retournait bien la liste des serveurs de la ferme en question).
Le premier réflexe fut de tester la cmdlet Get-XAServerLoad, qui elle nous retournait l’erreur “Get-XaServerLoad : Exception has been thrown by the target of an invocation“.

Du coup direction CDFControl afin de faire une trace durant l’exécution d’un qfarm /load.

Intéressant cette Uid 😉 .

En googlelant l’erreur IMA_BUF_BinBuffer nous sommes tombés sur la CTX138294 , on passe donc par un Queryds /table:LMS_ServerLoadTable >ErrorGet-XaServerLoad.txt et en cherchant dans le fichier de sortie nous avons retrouvé notre serveur.

En se connectant sur le serveur en question nous avons constaté que le service IMA était encore démarré, (alors que le serveur était censé être sorti de la ferme) une fois le service arrêté et désactivé (juste au cas ou), la command qfarm /load retournais bien la liste des serveurs membre avec leurs charges respectives.

Script : inventaire de serveurs non XenApp

Au détour d’un troubleshooting nous sommes tombés sur des serveurs “non XenApp” alors que ces derniers se trouvaient dans des Ou réservés aux serveurs XenApp.

Comme nous n’aimons pas les serveurs qui ne servent à rien, nous avons mis en place un PowerShell qui va se charger d’inventorier tous les serveurs “non XenApp”.

Le fonctionnement du script est on ne peut plus simple, on vérifie si le service IMA existe (s’il n’existe pas on considère que XenApp n’est pas installé) sur les serveurs, on prend aussi en compte les serveurs qui ne répondent pas à l’envoi de paquets ICMP (via la cmdlet Test-Connection) ainsi que ceux pour lesquels nous n’avons pas les droits nécessaires pour obtenir l’existence du service IMA.

Avant de lancer le script rentrer le DN de l’OU que vous souhaitez vérifier en ligne 3 du script.

Et voila huit serveurs (physiques) à récupérer 🙂

Check_XenApp_Computer.ps1

Problème d’affichage qfarm /load

Sur plusieurs fermes XenApp 6.5 R01 US Sp1, on nous a remonté un problème d’affichage lors de l’exécution d’un qfarm /load (ou query farm /load pour les anciens 😉 ).

En effet la sortie quelque peu décalé 🙂

Après quelques googles infructueux et afin de pallier rapidement ce problème d’affichage (un troubleshoting en bon et du forme viendra rapidement) nous sommes passés par un PowerShell faisant appel à la cmdlet Get-XaServerLoad.

Nous avons ajouté en argument la possibilité de rentrer une charge afin de n’afficher que les serveurs ayant une charge égale ou supérieure à la charge rentrée (si aucun argument n’est rentré la totalité des serveurs sera affichée) ainsi qu’un compteur totalisant le nombre de serveurs issus du qfarm /load.

Dans notre cas nous avons mis le script QfarmPS.ps1 dans %ProgramFiles(x86)%\Citrix\system32 afin que ce dernier puisse être lancé directement via une console PowerShell.

Un screenshot avec et sans argument

QfarmPS.ps1

Problème pour forcer l’adresse Ip dans un launch.ica

Toujours dans la série post-it (rentrée des classes oblige), récemment nous avons rencontré un problème pour forcer l’adresse IP serveur dans un launch.ica via une WebInterface 5.4 (2003 sp1 us).
Dans pareil cas on se tourne rapidement vers le webinterface.conf du site afin de modifier l’addressResolutionType pour forcer le type de résolution (dns-port, dns, ipv4-port, ipv4).

Dans notre cas le WebInterface.conf était configuré pour présenter des adresses dns (configuration par défaut)

Pour le coup normal que les launch.ica présentent des adresses dns, cependant une fois le webinterface.conf modifié (addressResolutionType=ipv4-port) afin de présenter des adresses Ip nos launch.ica présentaient toujours des adresses dns.

Après un moumoutage (french expression very famous 🙂 ) de 20 mn, direction les propriétés de la ferme (XenApp 5 R07, 2003 sp1 us) dans la partie XenApp-General la coche XML Service DNS address Resolution était coché .

Sous XenApp5

Sous XenApp 6.5 (dans stratégie ordinateur-Paramètre du serveur)

Une fois l’XML service DNS adress resolution décoché nous obtenons bien une adresse en Ip dans le launch.ica

Script : déplacer un ou plusieur dossier serveur avec ses objets

Comme vous le savez, il n’est pas possible dans l’AppCenter de déplacer un dossier (ou plusieurs dossiers) contenant des objets vers un autre dossier, la seule façon de le faire est de passer par la case scripting 🙂 .

Dans notre exemple , nous souhaitons déplacer tous les dossiers (ces derniers n’ont pas de sous-dossiers) contenus dans le dossier Silo1 à la racine du dossier Serveurs.

Nous avons donc mis en place un script PowerShell permettant ce type de déplacement.

Avant d’exécuter le script il vous faudra au préalable modifier les lignes 4 et 5 afin d’indiquer le chemin des dossiers à déplacer ($FolderSearch) et leurs destination ($FolderDest).

Une fois les dossiers déplacés

Ctx_MoveSrvFolders.ps1

Problème mappage de clavier Mac sur un mstsc publiée

Ce billet tient plus du post-it que du billet (on vous prévient 😉 ).

Si vous rencontrez un problème de mappage de clavier (un “à” la place d’un “@” par exemple) avec votre mac (dans notre cas avec un receiver 11.8.0 (241823) en lançant un mstsc publié (sur un serveur 2003), alors direction la CTX110281 .

Une fois le clavier paramétré sur “Sur cet ordinateur” (On this computer) le mappage fonctionne sans problème.

Une solution est de créer un fichier .rdp et mettre à 0 le keyboardhook (keyboardhook:i:0, ce qui va forcer le Keyboard sur “On this computer”), puis de publier le mstsc avec le fichier rdp précédemment paramétré.

Script : Check XML Broker

Comme vous le savez le rôle XML Broker est important au sein d’une ferme XenApp, et à ce titre un check de ce dernier est très fortement recommandé (si vous souhaitez en savoir plus sur les interactions entres une Web-Interface et un XML Broker alors direction la CX122877).

Un schéma simplifié d’une architecture XenApp (issus de support.citrix.com)

Il existe nativement des solutions permettant de checker les XML Brokers (Netscaler et F5 par exemple), mais si comme nous dans votre infra le matériel acheté et “censé” faire ce check ne le fait pas et que l’affaire tourne en rond, alors il vous reste la solution scripting (afin de laisser le temps au fameux matériel de pouvoir répondre au besoin 🙂 ).

Avant de scripter il faut déjà comprendre ce qu’il faut envoyer à l’XML Broker et ce qu’il doit nous répondre, ce type d’infos se trouve dans le pdf “Health Checking Citrix Services with Advanced Monitors from the NetScaler Application Switch ” (dont nous vous recommandons la lecture), en page 12 nous trouvons la requete HTTP à envoyer à l’xml broker ainsi que la réponse si tout est ok

La requête Http (au format xml), avec comme application publiée “Notepad_Netscaler” pour le check :

<?xml version=”1.0″ encoding=”UTF-8″?>
<!DOCTYPE NFuseProtocol SYSTEM “NFuse.dtd”>
<NFuseProtocol version=”4.1″>
<RequestAddress>
<Flags>no-load-bias</Flags> ###
<Name>
<AppName>Notepad_Netscaler</AppName>
</Name>
</RequestAddress>
</NFuseProtocol>

La réponse de l’XML Broker si tout est ok :

<?xml version=”1.0″ encoding=”UTF-8″ ?>
<!DOCTYPE NFuseProtocol SYSTEM “NFuse.dtd”>
<NFuseProtocol version=”4.1″>
<ResponseAddress>
<ServerAddress addresstype=”dot”>5.214.10.251</ServerAddress>
<ServerType>win32</ServerType>
<ConnectionType>tcp</ConnectionType>
<ClientType>ica30</ClientType>
<TicketTag>IMAHostId:13093</TicketTag>
<FarmLoadHint>0</FarmLoadHint>
</ResponseAddress>
</NFuseProtocol>

Comme indiqué en page 13 du pdf, ce qui nous intéresse dans la réponse de l’XML Broker est la partie <TicketTag>, donc si tout va bien on obtient un TicketTag, inversement si la requête échoue nous n’avons pas de TicketTag dans la réponse.

Exemple de réponse sans TicketTag (pour le test nous avions désactiver l’application Notepad_Netscaler)

Afin que le check passe bien il faut s’assurer que (toujours page 12 du pdf) :

L’IMA est bien fonctionnel sur l’XML Broker checker
La LHC de l’XML Broker est valide
L’IMA est fonctionnel sur le ZDC
La base de donnée dynamique du ZDC est valide
Avoir un serveur XenApp disponible pour l’application publiée (dans notre cas “notepad”)
Le service XML de l’XML Broker fonctionne correctement

Concernant le script nous nous sommes inspirés des scripts trouvés sur http://stackoverflow.com (Powershell API Post Variable to Ducksboard et powershell http post REST API basic authentication).

Au passage nous avons rajouté un envoi de mail en cas d’échec sur un XML Broker (à terme nous enverrons une trape snmp).

Dans notre production nous avons mis en place le script Check_Xml.ps1 en tache planifiée (toutes les 5 mn 7/24).

Si vous recevez ce type de mail…. rien ne va plus (mais au moins vous êtes au courant 😉 )

Check_Xml.ps1

Charge serveur bloqué sur 10000

Aujourd’hui nous sommes tombés (avec notre collègue Corvette man) sur un problème de charge à 10000 sur un serveur XenApp 6.5 (Sp1 R01 US), au passage le serveur n’avait aucun calculateur de type maintenance.

Le calculateur de charge affecté sur ce serveur prenait en compte la CPU/Mémoire et le nombre de session, aucun de ces 3 critères (ni-même l’indice de charge) ne permettait de définir une charge à 10000.

En regardant de plus près nous avons remarqué qu’il manquait des compteurs dans le perfmon du serveur (‘erreur : Unable to add these counters).

En googlelant nous sommes tombés sur la KB2554336 qui corrige ce type de problème.

Nous avons effectué les actions suivantes (vu qu’aucun compteurs n’étaient désactivés) :

Allez dans le menu Démarrer-Executé et lancer la commande c:\windows\system32\lodctr /R

Allez dans le menu Démarrer-Executé et lancer la commande c:\windows\sysWOW64\lodctr /R

Allez dans le menu Démarrer-Executé et lancer la commande WINMGMT.EXE /RESYNCPERF

Redemarrer le service Windows Management Instrumentation service

Redémarrer le service ImaService

Une fois ces étapes réalisées, les compteurs perfmon manquants étaient disponibles et notre serveur a retrouvé sa charge réel.