Script

Script : Supprimer les applications d’un utilisateur ou d’un groupe

Dans Citrix Virtual and Desktops supprimer un utilisateur ou un groupe de toutes ses applications ou bureaux publiés peut vite s’averer fastidieux.

Le fameux Testdf1 qui nous suit depuis tant d’années 🙂

Comme on est sympa on ne va pas vous laisser supprimer à la mano tous ces utilisateurs/groupes. Le script Powershell “Xa7x_Unpublished” va juste vous demander de rentrer le nom de l’utilisateur ou groupe que vous souhaitez supprimer (ou visualiser) des applications et bureau publiés.

Lancez le script
Entrez le nom de l’utilisateur ou groupe
Entrer 1 si vous souhaitez supprimer l’utisateur/groupe ou 2 si vous souhaitez uniquement visualiser le resultat
Un fichier de log ( Xa7x_Unpublished.log) est disponible dans le répertoire d’exécution du script.

XenApp : création d’applications en masse

Ca nous est tous arrivé un jour de se retrouver devant LA fameuse demande de création d’applications en masse (dans notre cas plus 300 applications one shoot).

En plein match de la coupe du monde, 300 applis à créer, avec 300 tickets différents bien sûr 🙂

Le script powershell joint à ce billet permet la création des applications “en masse”, avec les utilisateurs/groupes et l’icone associée au binaire de publication (sauf si votre chemin applicatif est un bacth, script etc..). Là où c’est pratique c’est que le script repose sur un fichier de configuration (format csv) dans lesquel vos productions applicatives vont rentrer toutes les informations nécessaires à la création des applications (sinon c’est à vous de le faire 😉 ).

En argument lors du lancement vous pouvez indiquez un Delivery Controller (exemple : Xa7x_CreateApps.ps1 MonDeliveryController), en l’absence d’argument le script considère que le serveur local est un Delivery Controller.

XA7x_CreateApps.zip

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

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.

XenApp_Usr.rar

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

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)

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

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.

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

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.

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

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

Check_Gpo_Modified.ps1

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.

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

Search_Event_XenApp.ps1

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

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

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

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

Une fois les dossiers déplacés

Ctx_MoveSrvFolders.ps1