Script Archive

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

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)

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

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

Ctx_App_SrvCountLes applications avec un seul serveur apparaissent en rouge 😉 

 

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

Ctx_App_SrvCount1

0

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

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

     

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

 

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

 

AppDisable02On 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

 

Download_2
App_DisableDelete.ps1

0

Créer une alerte sur les GPO Citrix modifiées.


Dans les infras où la délégation est « forte » (dans le cas présent les GPOs),  il est important (pour ne pas dire obligatoire) de mettre en place des alertes permettant d’informer les administrateurs qu’une ou plusieurs GPOs ont été modifiée(s).  L’un des avantages de ce type d’alerte est de permettre à l’ensemble des admins  d’avoir le même niveau de connaissance sur les  modifications apportées aux GPO.

dontTouchEn amont on pourrait aussi mettre ça, histoire que tout le monde ait le même niveau de connaissance 🙂

En PowerShell la cmdlet GET-GPO avec son attribut ModificationTime associé à un filtre sur le DisplayName (Ctx dans notre cas) permet de filtré facilement les GPOs  venant d’être modifiées,  le résultat étant envoyé par mail en html.

GPOs_Modified
Le script remonte toute les GPOs dont le DisplayName contient la chaîne « Ctx » et qui ont été modifier durant les trois dernières heures.
A l’ancienne en tache planifiée ça fera l’affaire 😉  .

 

Download_2Check_Gpo_Modified.ps1

0

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.

SearchEventXenAppFarm1

SearchEventXenAppFarm

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

  

Download_2Search_Event_XenApp.ps1

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

0

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

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

  

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

 

 

MoveFolder3

 MoveFolder4Une fois les dossiers déplacés

 

 

Download_2Ctx_MoveSrvFolders.ps1

 

8

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

Xml_schema

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

panneau signalétique rue Marettes

 

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.

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

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

 

 

Download_2Check_Xml.ps1

0

Script : Supprimer/Restaurer les applications publiées d’un serveur

Pour diverses raisons vous pouvez avoir besoin de supprimer toutes les applications publiées d’un serveur (voir notre billet sur ce sujet), cependant vous ne souhaitez peut-être pas laisser ce serveur « ad vitam æternam » sans ses applications publiées.

Nous avons donc modifié le script de notre précédent billet afin de sauvegarder au préalable toutes les applications du serveur (avant la suppression), ainsi que la possibilité d’ajouter les applications précédemment supprimées du serveur.

Les applications sont sauvegardées dans un répertoire backup (le choix du backup vs juste le nom des applis dans un fichier texte tient juste dans le « au cas ou »)

Reste plus qu’à 🙂

 

Apps_DepublishRepublish.ps1