ctxblog – Page 14

Mise à jour de XenApp_Check : 2.5

MAJ :19/09/2014

La version XA5 passe en 2.5

Déjà plus d’un an depuis la dernière mise à jour de XenApp_Check (436 jours exactement), on ne vous fera pas le coup du “comme le temps passe vite” mais pas loin 😉 .

Dans cette mise à jour nous avons ajouté une section “UPM version” qui permet de vérifier si les agents UPM sont UpToDate (par rapport à la version que vous avez validée ) au sein de vos fermes et une section “Section statut” affichant les sections désactivées”.

La version UPM de référence dans XenApp_Check est la “5.0.0.111” (modifiable via la variable $UPMVer)
Nous avons aussi corrigé divers bugs mineurs et amélioré le temps d’exécution du script (réduction d’environ 15 % du temps d’exécution) en changeant le check WMI (on passe par un socket.TcpClient sur le port 135).

Seule la version XA6 passe en version 2.5, la version XA5 sera très prochainement mise à jour.

Désormais les fichiers XenApp_CheckXA6.ps1 et le fichier Ctx_FunctionXa6.ps1 sont regroupés au sein d’un fichier rar.

Comme d’habitude vos remarques et suggestions sont les bienvenues.

Merci pour les DL 😉

Le billet sur XenApp_Check

Recreation du compte de service Ctx_SmaUser

Ce billet juste pour mettre à dispo CtxSma20.exe (vu qu’on a lutté pour le retrouver 😉 ). En effet récemment nous avons dû recréer dans l’urgence le compte de service Ctx_SmaUser (sur un serveur membre d’une bonne vielle PS 4.0 R03 Fr) et bien sûr aucun moyen de mettre la main sur CtxSma20.exe (si vous avez un link up on le rajoutera dans ce billet), du coup direction la CTX106393 qui est la seconde solution pour récréer le Ctx_SmaUser (à la mano), son seul inconvénient est d’être un poil plus long ;).

A la question, “mais vous n’aviez pas sur vous un SSD rempli des tools indispensables” ? He bien non… pas ce jour là 🙂

Download_2
CtxSma20.exe

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

XenDekstop : Modifier le host pour les desktops membres d’un catalogue

Si vous souhaitez changer le host des desktops membre d’un catalogue (lors d’une migration de vCenter par exemple) il faut passer par la case PowerShell vu qu’en GUI (Desktop Studio) ce n’est pas possible (tout du moins simplement).

On se demande encore pourquoi via Desktop Studio ce n’est pas possible simplement (ou alors on a raté quelque chose)

Avant d’exécuter le script il vous faut renseigner le nom du futur Host (ligne 12) et le nom du catalogue à migrer (ligne 13) dans le script.

Un fichier de log est disponible dans le répertoire courant
Au passage dans le screenshot on a laissé l’ancien nom du script 😉

Le script XD_MigrateHost.ps1 a été testé sur un DDC en XenDekstop 5.6 US

XD_MigrateHost.ps1