XenApp – Page 7

Vérifier la version UPM des serveurs membres d’une ferme XenApp

Toujours dans l’idée d’avoir des serveurs XenApp les plus ISO possible, cette fois-ci nous nous sommes penchés sur la/les version(s)s d’UPM (Universal Profil Manager) installée(s) au sein de nos différentes fermes XenApp.

Hé oui à la base UPM c’était SepagoProfile (écrit en C++ et multithreadé s’il vous plait 😉 ), Citrix ayant racheté SepagoProfile à SEPAGO en Mai 2008)

Le script disponible dans ce billet permet donc de vérifier la version UPM (via WMI, il faut donc que le port TCP 135 soit ouvert sur les serveurs) installée sur tous les serveurs membres d’une ferme XenApp.
Afin de vérifier la version UPM installée sur chaque serveur, le script va rechercher dans toutes les subkeys de “SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\” si l’une des valeurs “DisplayName” contient la chaîne de caractère “Citrix Profile Management” si c’est la cas, le script va lire la valeur “DisplayVersion” afin de déterminer la version UPM installée et vérifier si cette dernière correspond ou pas à la version recherchée et validée dans votre environnement, dans notre cas la 5.0.0.111 (Variable $UPMVer en ligne 17 du script).

On n’est pas si mal sur cette ferme, juste un serveur sans UPM et un avec une ancienne version, reste à faire un check de la DMZ 😉 .

Bien sur on va rajouter le check de la version UPM dans XenAppCheck (ça fait un bail qu’on ne l’a pas mis à jour d’ailleurs 🙂 .

CheckVer_UPM.ps1

Vous avez aussi la possibilité de lancer le script en mode verbose en rajouter l’argument -Verbose ( CheckVer_UPM.ps1 -Verbose)

Le EdgeSight du pauvre

———————–
MAJ 05/04/2016
———————–
Ajout du “ClientVersion” afin d’obtenir la version du receiver de chaque utilisateur

———————-

Suite à des BSOD provoqués par nos agents EdgeSight, nous avons dû en urgence désinstaller les clients EdgeSight d’un silo d’une ferme XenApp 6.5 R03 us (les dumps sont en cours d’analyse et pour l’instant le coupable est rskcore.sys).

Nous avons certes rétabli le service, mais nous avons perdu des informations utiles comme “qui lance les applications publiées” (informations disponibles en mode avancé) 🙁 .

Du coup nous avons mis en place un script PowerShell qui récupère les applications publiées lancées au sein de notre ferme, puis écrit tout ça dans un fichier à plat (on va rapidement passer ça dans une base sql).

Et voila ce que ça donne sous excel (on vous l’avais dit c’est le EdgeSight du pauvre 🙂 mais ça rend le service

Comment fonctionne le script ? Tout d’abord nous ne souhaitions pas installer d’agent sur chaque serveur membre de la ferme ou passer par un login script (bien que GETPUBAPP de chez Ctrl-Alt-Del aurait parfaitement fait l’affaire), une solution est donc d’interroger le ZDC via un serveur d’administration par exemple (et là on entend certains crier HOULA).

Le script en lui-même est on ne peut plus simple, en gros on fait un “Get-Xasession|?{$_.LogOnTime -gt $Date3}” ($Date3 étant égal à l’heure du jour moins une minute) toutes les minutes et on ne récupère que les sessions ouvertes la dernière minute.

Concernant la mise en place du script, plusieurs solutions sont possibles comme une tache planifiée, un service ou bien un login script computer. Nous avons opté pour un service afin que ce dernier puisse se relancer en cas de d’arrêt du script.

Pour la création du service on passe par un bon vieux SC (au préalable nous avions compiler notre script via PowerGui, le binaire sera lancé via SRVAny avec un compte admin de la ferme XenApp ) :

SC CREATE “ServiceName” binPath= “YourPath” DisplayName= “DisplayName” start= auto

Un tableau dynamique plus loin 😉

UsrApp.ps1

—————–
06/08/2014
—————–
Le script crée désormais un fichier de log par mois (NomDeLaFerme_Année-Mois_UsrApp.txt)

Vérifier l’ouverture du port IMA

Récemment du jour au lendemain certains de nos utilisateurs rencontraient le message d’erreur ci-dessous en cliquant sur une application publiée via une Web Interface (dans notre cas une 5.4 Us).

” Une erreur s’est produite lors de l’établissement de la connexion requise”.

Error_Xml_WI Vu que seul un silo était impacté, le premier réflexe a été de vérifier si le port IMA était bien ouvert entre nos XML Broker et les serveurs du silo concerné, et effectivement le 2512 n’était plus ouvert 😉

Afin de palier ce type de situation, nous avons mis en place un PowerShell qui va checker que le port 2512 (port par défaut, cependant le script va vérifier le port IMA au cas ou 😉 ) est ouvert (avec un timeout de 1000 milliseconds, au delà on considère que le port IMA n’est pas ouvert), avec un tableau récapitulatif des serveurs non joignables sur le port IMA.

Au préalable il vous faudra installer le SDK Powershell (XenApp 5, XenApp 6x)sur vos XML Broker.

Une petite visite chez nos collègues du réseau ? 🙂

Vérifier les classes WMI des serveurs membres d’une ferme XenApp

Généralement lorsque vous rencontrez une erreur WMI vous avez un ou plusieurs événements dans les journaux Windows, et bien ça c’est quand tout va bien 🙂 .

Dans le cas présent nous avions une application “Premium” 7/24 (en gros si elle tombe vous avez les cinq continents au tel avec des mots diplomatiques) qui refusait de se lancer sur deux serveurs sur dix. Le listener ICA était ok sur les deux serveurs (publication/connexion sur un notepad ok), en regardant le launcher de la fameuse appli, on se rend compte que le batch, lance un vbs qui lui lance son petit frère qui lui-même appelle sa tante…bref à un moment il y a une requête WMI qui échoue et pas de log applicative .

Bon ok c’est exagéré 🙂

En lançant la requête localement sur un des serveurs incriminés on s’est aperçu que la couche WMI était corrompu (pour la réparer voir notre billet “Erreur WMI : Espace de noms non valide…..“.

Afin d’anticiper ce type de problème nous avons mis en place un PowerShell qui va checker si les namespace “root\default” et “root\citrix” répondent bien sur tous les serveurs membres d’une ferme XenApp.

Au passage avant le test de Namspace on teste si le port TCP 135 est bien ouvert (sur un timeout de 1000 millisecondes) histoire de ne pas se prendre des timeouts de fou dans sur les serveurs situé dans des DMZ ou autre).

On va aussi en profiter pour intégrer ce check WMI dans XenAppCheck 😉

WmiCheckNameSpace.ps1

Retrouver le mot de passe d’un compte de service IMA

Si vous n’avez pas de coffre fort numérique (un bon Keepass et vous n’aurez plus d’excuse) et que vous avez perdu le mot de passe du compte de service IMA , et bien tout n’est pas perdu 😉 .

En googlelant nous sommes tombés sur le billet de Remko Weijnen “Decoding Citrix IMA Datastore Password“, du coup on teste direct le binaire (CtxImaPass.exe).

Bon ok on savait le hash perfectible mais à ce point

Pour info le compte de service IMA et le mot de passe associé se trouve dans les valeurs ci-dessous :

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\IMA\Datastore\L$ImaDBUsername
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\IMA\Datastore\L$ImaDBPassword

Forcer une barre de tâche (Pinned Bar) en GPP

Au sein d’un bureau publié sous XenApp 6.5 R03 on nous a demandé de forcer une barre de tâche custom (Word, Excel, PowerPoint et Outlook), plusieurs solutions sont possibles comme un script ou une bonne GPP 😉 (et oui nativement en 2008 R2 on ne peut pas le faire).

La barre de tache souhaitée

Chez notre client actuel le sujet du logon script étant sensible nous sommes donc passés par une GPP.

Les étapes sont très simples :

Au sein d’une session, customisez votre barre de tâche (l’idéal est de le faire au sein de votre session et sur un serveur pouvant exécuter un gpmc.msc)
Recopiez les raccourcis de la barre de tâche (%APPDATA%\Microsoft\Internet Explorer\Quick Launch\User Pinned\TaskBar) dans un share accessible à tous les utilisateurs (en lecture)
Créez une GPO (Ex : CTX_XA65_Forced_PinnedBar)
Modifiez la GPO précédemment créée, Configuration utilisateur-Préférence-Paramètre Windows-Registre, clique droit sur Registre, Nouveau élément de registre, dans le champ “Chemin d’accès de la clé”, allez dans HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Taskband” puis choisissez Favorites.

Toujours dans la GPO allez dans Configuration utilisateur-Préférence-Paramètre Windows-Fichier puis ajoutez les fichiers précédemment copiés dans votre share.

En l’état nous avons une Barre de tâche avec nos nouvelles icônes et les icônes par défaut (Gestionnaire de Serveur et PowerShell)

Pour supprimer les icônes par défaut nous avons choisi de passer par les permissions NTFS (ok c’est la version dure on vous l’accorde) afin de retirer les droits aux utilisateurs (on ne laisse que les administrateurs), Dans la GPO allez dans Configuration ordinateur-Stratégie-Paramètre Windows-Paramètres de sécurité-Système de fichier, puis ajoutez les trois entrées ci-dessus.

%AllUsersProfile%\Microsoft\Windows\Start Menu\Programs\Accessories\Windows PowerShell\Windows PowerShell.lnk
%AllUsersProfile%\Microsoft\Windows\Start Menu\Programs\Administrative Tools\Server Manager.lnk
%AllUsersProfile%\Microsoft\Windows\Start Menu\Programs\Administrative Tools\Windows PowerShell Modules.lnk

Au passage on vous donne la GPO (il vous faudra juste changer le path des icônes de la barre de tâche) 😉

Force_Pinned_Bar

Visualiser la bande passante d’une session ICA

Il arrive qu’on nous demande quelle est la taille de la bande passante de telle ou telle session ICA, le plus simple, en l’absence d’outils de type EdgeSight, est de passer par Perfmon (compteur ICA-Session : Bande passante de session – sortie et Bande passante de session – entrée), cependant le “problème” avec Perfmon est qu’il faut à chaque fois préciser le serveur et la session que vous souhaitez visualiser, c’est pourquoi on a mis en place un script PowerShell permettant de visualiser rapidement la consommation de bande passante d’une session ICA.

On peut aussi afficher toutes les sessions par contre à lire 🙂

Lors de l’exécution du script il vous sera demandé de rentrer le nom du serveur, le SessionId (la liste vous sera proposée une fois le nom du serveur rentré) et la durée d’analyse (un sample étant égal à 2 secondes).

Bon ok une visualisation sur 20 secondes c’est léger 😉

Un export en csv est disponible dans le répertoire courant histoire de faire un beau graph 😉

Le script a été testé sur des fermes XenApp 6.5 Us et Fr (le pré-requis est la présence du PowerShell SDK XenApp 6.5 sur le serveur exécutant le script)

ICA_Bandwith.ps1

Lenteur d’ouverture de session

Il y a quelques semaines nous avons traité un problème de lenteur d’ouverture de session (SBSL : Slow Boot Slow Logon) sur des fermes XenApp 6.0 (Us) et XenApp 6.5 R03 (Us), les temps d’ouverture des applications publiées prenaient en moyenne 45 secondes au lieu des 25/30 habituels (bien que ce temps soit déjà un peu au dessus d’une bonne ouverture de session) .

un utilisateur patient ou résigné ? les deux ?

Dans un premier temps il convient de vérifier que les serveurs XenApp ont bien les hotfix conseillés par Citrix via la CTX129229 (regarder aussi la CTX133873 qui traite des problèmes de lenteur d’ouverture de session avec des RODC) ainsi que les KB suivantes KB973772, KB977346, KB2409711 et KB977346.

Schéma des étapes précédent le lancement d’une application publiée via une Web Interface

Dans un second temps nous allons prendre une trace d’ouverture de session causant problème avec Xperf 4.1.6512 (on aurait pu prendre la 6.3.9600 au passage 😉 ).

Pour plus d’info sur Xperf c’est juste en dessous :

Pour lancer une trace Xperf (nous passons l’installation d’Xperf qui est une suite de Next Next Next) nous avons lancé la ligne de commande ci-dessous :

xperf -on base+latency+dispatcher+NetworkTrace+Registry+FileIO -stackWalk CSwitch+ReadyThread+ThreadCreate+Profile -BufferSize 128 -start UserTrace -on “Microsoft-Windows-Shell-Core+Microsoft-Windows-Wininit+Microsoft-Windows-Folder Redirection+Microsoft-Windows-User Profiles Service+Microsoft-Windows-GroupPolicy+Microsoft-Windows-Winlogon+Microsoft-Windows-Security-Kerberos+Microsoft-Windows-User Profiles General+e5ba83f6-07d0-46b1-8bc7-7e669a1d31dc+63b530f8-29c9-4880-a5b4-b8179096e7b8+2f07e2ee-15db-40f1-90ef-9d7ba282188a” -BufferSize 1024 -MinBuffers 64 -MaxBuffers 128 -MaxFile 1024

Une fois la trace lancée, il vous faut lancer une application publiée sur un serveur (de préférence avec aucun utilisateur dessus). Dès l’application publiée lancée, vous pouvez arrêter la trace.

Pour arrêter la trace Xperf :

xperf -stop -stop UserTrace -d merged.etl

Les problèmes de lenteur d’ouverture de session peuvent avoir plusieurs origines comme (liste non exhaustive) :

GPOs
Login Script
Mappage de périphérique(s)
Profil (taille, type de profil)
Redirection de dossiers
Problème WMI et SMB
Application publiées (temps d’ouverture de l’application)

Le problème devrait se situer dans une de ces étapes 😉

A partir du serveur où a été installé Xperf, allez dans le menu démarrer-Programs-Microsoft Windows Performance Toolkit puis lancer Performance Analyzer

Ouvrez la trace précédemment réalisée

La trace une fois ouverte

Dans la section Winlogon, on s’aperçoit que la partie GPCLIENT prend plus de 8 secondes (une première piste)

Maintenant on va dans la section Process afin de faire un export des process et de trouver le PID de notre logon script
Clique droit puis Export full Table

Une fois le login script trouvé on relève son PID

Afin d’afficher la durée de notre logon script dans la section Winlogon il faut faire un clique droit Overlay graph-CPU Sampling by Process et on clique sur le PID du logon script.

La lecture de la trace fait apparaître deux problèmes, l’application des GPO qui prend 8 secondes avec un logon script qui en prend presque 13, ce qui est pénalisant dans notre cas puisque le Run logon scripts synchronously est activé (Exécuter les scripts d’ouverture de session simultanément) ce qui force l’exécution du logon script avant le lancement de l’application publiée.

Avec nos 8 secondes nous sommes au dessus des 7 secondes maximum 🙂
Voir le billet Optimizing Group Policy Performance

Nous avons donc deux axes d’amélioration qu’il va falloir traiter rapidement, un GPLCIENT trop long et un logon script qui prend son temps.

quelques liens traitant des problèmes de type SBSL :

Erreur IMAService EventId 4007

Lors d’une migration entre deux fermes XenApp 6.5 R03 Fr, un de nos serveurs n’arrivait plus à démarrer son service IMA.

Dans le journal system nous avons retrouvé l’erreur ci-dessous :

Log Name: System
Source: IMAService
Event ID: 4007
Description:
Le service Citrix Independent Management Architecture (IMA) se ferme. Le fichier DSN n’a pas pu être mis à jour avec les informations récupérées depuis la stratégie de groupe. Erreur : 80000001h Fichier DSN : mf20.dsn Entrée DSN : DATABASE Paramètre de stratégie : VotreFerme Confirmez que le service réseau possède des permissions en écriture dans le fichier DSN.

Le problème venait de la valeur “DataSourceName” situé dans “HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\IMA”, cette dernière étant vide ça ne risquait pas de fonctionner.