Scripts – Page 3

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

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

Identifier les applications avec un seul serveur

Un petit script pour identifier rapidement les applications publiées ayant un seul serveur.

$OriginalColor=$Host.UI.RawUI.ForegroundColor;get-xaapplicationReport *|Sort DisplayName|Format-Table -Property DisplayName,@{label="Serveur";Expression={If($_.ServerNames.count -le 1) {$Host.ui.rawui.ForegroundColor="Red";$_.ServerNames.count}Else{ $Host.ui.rawui.foregroundcolor="Yellow";$_.ServerNames.count}}};$Host.UI.RawUI.ForegroundColor=$OriginalColor

Les applications avec un seul serveur apparaissent en rouge 😉

Pour rappel dans XenAppCheck vous avez aussi la liste des applications avec un seul serveur.

Rechercher une application dans plusieurs fermes XenApp

Si vous souhaitez connaitre la/les fermes publiant une application (par exemple word, excel ou bien une application comprenant une chaîne de caractère “TEST” 😉 ) le script contenu dans ce billet devrait vous intéresser.

Les pré-requis sont que les serveurs entrés dans la variable $Serveurs aient le PowerShell SDK d’installer (XenApp 5, XenApp 6x) et que le port TCP 2513 soit ouvert entre le serveur exécutant le script et le(s) serveurs ayant le sdk installé (bien sur on ne peut attaquer une ferme XenApp 6x à partir d’un serveur XenApp 5 et vice-versa 😉 .

Modifier la variable $Serveurs (ligne trois du script) la liste des serveurs (un par ferme XenApp) permettant de se connecter avec les différentes fermes XenApp.

23 Applications publiées réparties sur trois fermes XenApp 6.5 ayant dans leur browsername la chaîne de caractère “TEST” 😉

SearchAppFarms.ps1

Supprimer les applications désactivées

Depuis quelques temps les rapports issus de nos XenApp_Check remontaient un nombre croissant d’applications désactivées sur nos fermes XenApp 5 et 6x (Recette, Qualification et Production).

52 applications désactivées sur une ferme XenApp 5 R07

Vu que ces applications restaient désactivées dans le temps (plus de 30 jours) nous avons mis en place un script PowerShell permettant de supprimer toutes (sauf les applications ayant dans le champs description la chaîne de caractère #NOT_DELETE#) les applications désactivées d’une ferme.

Les actions du script :

Sauvegarde dans le répertoire courant des applications désactivées
Suppression des applications désactivées (hors application ayant dans le champs description la chaîne de caractère #NOT_DELETE#)
Suppression des sauvegardes supérieur à 180 jours (dans le répertoire courant)

54 applications (soit deux de plus en l’espace d’une journée) en moins dans une de nos fermes XenApp 5 R07

Le Get-XaApplication prenait 5,40 secondes pour 580 applis dans la ferme

On tombe à 4,64 secondes une fois les 54 applications supprimés 😉

Pour restaurer une application lancez la ligne de commande ci-dessous :

import-Clixml "\\YourPath\Backup\App.xml"|New-XAApplication

App_DisableDelete.ps1

Check des services XenApp 6.5

Suite à une campagne de patchs MS, un nombre important de serveurs XenApp (60 sur 700) avait des services XenApp (et non XenApp comme le spooler par exemple) non démarrés (RadeSvc, CtxSmartCardSvc, cpsvc) sur une de nos fermes XenApp 6.5 R01 Us.

Vu que les services démarraient sans problème manuellement sur plusieurs serveurs et ne tombaient pas une fois démarré (et qu’il fallait rendre le service ASAP), nous sommes passés par la case PowserShell afin de checker l’état des services XenApp (les principaux) et de démarrer les services qui ne l’étaient pas (on a bien sûr gardé quelques serveurs sous le coude histoire de comprendre ce qui a bien pu se passer).

Deux serveurs sur deux dans notre lab ont des services arrêtés (que fait le pilotage 🙂 ).

En relançant le script on constate que les services ont bien été démarrés.

CheckServiceXenApp.ps1