Scripts Archive

17

Supervision de silo serveurs

Comme vous le savez chez nous la supervision (et le monitoring) XenApp c’est une religion, c’est pourquoi au détour d’une discussion avec notre collègue Corvette_Man (à qui nous devons l’idée originale de ce billet)  l’idée d’une supervision global des silos (serveurs) d’une ferme XenApp nous est venue.

Le but de cette démarche est double, premièrement permettre à la Citrix team d’avoir une vision des silos avec leur taux d’utilisation et deuxièmement offrir aux équipes applicatives une vue de leurs silos respectifs avec le taux d’utilisation.

Nous avons donc mis en place un script PowerShell permettant d’afficher une page html au sein de laquelle sont regroupés tous les silos de serveurs (ayant au moins un serveur). La disponibilité de ces silos est exprimée en pourcentage au travers d’un graphique (le pourcentage est issu du total de la charge des serveurs du silo) , un clic sur un silo déclenche l’ouverture d’une page html regroupant la totalité des serveurs membres du silo avec leur charge respective.

Le script tourne au travers d’une boucle s’exécutant toutes les 5 mn (à adapté selon vos besoin, de notre côté le script tourne via une tache planifiée), Les graphiques sont issus de justGage.com (justGage est basé sur la librairie  Raphaël).

L’avantage de justGage est qu’il est personnalisable, rapide et facile à mettre en place. Le graphique change de couleur en fonction de la valeur entrée dans le graphique, vert en dessous de 34 %, jaune de 34 % jusqu’à 66 % et rouge à partir de 67 %.

 

XenApp_LoadMonitor1La vue globale d’une ferme XenApp 6.5
Le chiffre à côté du pourcentage de chaque silo correspond aux nombre de serveurs membre du silo

 

XenApp_LoadMonitor2La vue d’un silo avec la charge de chaque serveur

 

Les pages générées sont compatibles avec Chrome, Firefox et IE (9).

 

Download_2XenApp_LoadMonitor.rar

8

XenApp_Usr : mise à jour 1.3

Dans cette mise à jour, nous avons corrigé quelques bugs mineurs et rajouté les fonctionnalités ci-dessous :

  • Une section « Gpo Applied » qui affiche toutes les Gpos appliquées (avec les Gpos bloquées) sur l’utilisateur et le serveur hébergeant la session (avec un compteur total du nombre de Gpos appliquées)
  • Possibilité d’exporter la Gpo sélectionnée au format HTML (il faut comme pré-requis que le  Module GroupPolicy soit installé sur même le serveur que XenApp_Usr)
  • Possibilité d’exporter toutes informations de la session courante dans un fichier texte

 

XenApp_usr1_3
Nos collègues ont bien apprécié la partie Gpos applied 😉

Pour télécharger XenaApp_Usr c’est par ici

2

Mise à jour de XenApp_Check (XenApp 6.x) : 2.6

XenApp_Check pour XA 6 passe en 2.6, dans cette mise à jour nous avons modifié le check du nombre de serveur(s) publié(s) au sein d’une application afin que ce dernier prenne en compte les Groupes de tâches (Worker Groups).

Toutes les applications n’ayant qu’un seul serveur de publié en direct ou via les Worker Groups seront regroupées dans la section (section « Server in Application(s)).

 

XenAppcheck_26Plus d’excuse pour les publications via les Worker Groups .

Le billet concernant XenApp_Check est ici .

XenApp_CheckXA6 2.6 (XenApp 6.x)

XenApp_CheckXA6.rar

36

XenApp_Usr

————————————————————————————————————
MAJ : 23/03/2015
V1.4

  • Rajout du refresh des sessions lors d’un logoff
  • La progressBar change de couleur en fonction de la charge du serveur hébergeant la session (vert de 0 à 5999, orange de 6000 à 8499 et rouge à partir de 8500)
  • Le champ username accepte la validation via la touche Entrée (Enter)
  • Refresh des process lorsqu’un process est tué via le bouton Stop
  • Correction de divers bug mineurs

————————————————————————————————————

MAJ : 22/12/2014
V1.3

  • Correction de bugs mineurs
  • Ajout de la section « Gpo Applied »
  • Possibilité d’exporter la Gpo sélectionnée au format HTML (il faut comme pré-requis que le  Module GroupPolicy soit installé sur même le serveur que XenApp_Usr)
  • Possibilité d’exporter toutes informations de la session courante dans un fichier texte

————————————————————————————————————

C’est quoi XenApp_Usr  ? 🙂

C’est un script PowerShell que nous avons mis en place et qui permet via une GUI de retrouver la ou les session(s) d’un utilisateur au sein d’une ferme XenApp.

Un fois la ou les sessions retrouvée(s), il suffit de sélectionner une session afin que les informations ci-dessous s’affichent dans la GUI :

  • Nom et version de la ferme XenApp
  • Application publiée
  • Serveur sur lequel la session est connectée
  • Etat de la session
  • Version du client ICA
  • Type de client
  • Nom du client
  •  IP du client
  • Date et heure de la connexion
  • Imprimantes de la session
  • Processus  lancés dans la session
  • Afficher la bande passante de la session ICA
  • Afficher la latence de la session ICA

A cela nous avons ajouté la possibilité d’effectuer les actions ci-dessous :

  • Fermer la session
  • Lancer un remote assistance sur la session
  • Stopper un process de la session

 

XenApp_UsrV1 Ok la GUI fait un peu année 90 🙂

 

XenApp_Usr a été validé sur des fermes XenApp 6.5 R01, R03 et R04 (us et fr), la consommation mémoire est d’environ 60 Mo ( 🙁 faudra qu’on regarde pour diminuer ça).

Vos remarques et suggestions sont les bienvenues (au passage nous avons volontairement éviter les Splash Screen et Progress Bar).

Pour l’instant (et vu que le code n’est pas encore présentable) on ne livre que le ps1 compilé en binaire, la version ps1 arrive asap .

Au passage la GUI a été réalisée avec Powershell Studio de Sapien.

 

Download_2XenApp_Usr.rar

 

———————————————————
MAJ : 24/11/2014
V1.1
Correction de bugs mineurs
Ajout de la charge serveur (Load server)
———————————————————

8

Publication du Remote Assistance

Comme vous le savez, en XenApp 6.5 le shadowing sur des sessions multi-écran cause problème (voir CTX125693), l’utilisation de MSRA (Microsoft Remote Assistance) permet de palier cette problématique (la seule contrainte est de connaitre à l’avance le nom du serveur hébergeant la session que l’on souhaite observer, ce qui est peu pratique à l’usage).

Au départ on souhaitait mettre en place une GUI permettant de faire du MSRA sans avoir à chercher où se trouve la session de l’utilisateur, en googlelant nous sommes tombés sur l’excellent script de nos collègues de DEPTIVE qui avait déjà (depuis 2012) mis en place un PowerShell  permettant de rechercher un session ICA/RDP (le tout via une GUI) au sein d’une ferme et de lancer sur cette session un MSRA.

Nous avons juste rajouté/modifié les éléments ci-dessous afin qu’ils correspondent un peu plus à notre besoin :

  • Teste si le snapin Citrix est bien chargé
  • Si le champ username est vide le script n’affiche plus toutes les sessions ica/rdp ouvertes dans la ferme mais une erreur indiquant qu’il faut renseigner le champ username
  • Le bouton Connect est désactivé tant qu’une session n’est pas trouvée dans la ferme XenApp en cours
  • Ajout de la colonne application publiée (afin de bien cibler la session de l’utilisateur)
  • Ajout d’un compteur comptabilisant le nombre de sessions trouvées pour un utilisateur
  • Ajout du nom de la ferme en cours

 

MSRA_Script

 

MSRA_Script1Sur des grandes ferme avec what mille CCU on evite l’affichage de toutes les sessions de la ferme si on clique sur le bouton Search et que le champ username est vide

 

MSRA_Script2Rien de transcandant dans nos modifications mais c’est pratique 🙂

 

 

Si vous publiez le script sur un serveur avant l’agent EdgeSight installé alors n’oubliez pas d’exclure le process « msra.exe » dans l’agent EdgeSight  (voir CTX131271).

 

EdgeSightExcluRsaSi vous souhaitez le reg pour l’importation c’est juste en dessous

 

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\rskcore]

« UviProcessList »= »rotatelogs.exe;msra.exe »

 

Pour plus d’information sur le Remote Assistance (et pour l’activer) c’est par ici.

Au passage pour ajouter le Remote Assistance sur un serveur en PowerShell :

import-module servermanager;get-windowsfeature "Remote-Assistance"|?{$_.installed -eq $False}|%{Add-WindowsFeature "Remote-Assistance"} 

 

Quelques liens  sur la configuration de Remote Assistance  :

 

 

Download_2RemoteAssistance.ps1

4

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).

 

XenApp_Check_2_5

 

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.

 

XenApp_Check_GraphMerci pour les DL 😉


Le billet sur XenApp_Check

2

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.

 

SepagoHé 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).

 

UPM_CheckOn 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 🙂 .

 

Download_2CheckVer_UPM.ps1

 

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

8

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).

 

Edg_du_Pauvre011Et 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

 

Edg_du_Pauvre012Un tableau dynamique plus loin 😉

Download_2UsrApp.ps1


—————–

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

0

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_WIVu 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 5XenApp 6x)sur vos XML Broker.

 

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

 

Download_2

0

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 .

XMI_Check1Bon 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).

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

Download_2WmiCheckNameSpace.ps1