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.

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

Le script en mode affichage

Le script en mode suppression


Post to Twitter

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

 

 

 

 

Post to Twitter

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

Post to Twitter

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)

Post to Twitter

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

Post to Twitter

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

Post to Twitter

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

Post to Twitter

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

Post to Twitter

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 😉

Post to Twitter

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

 

Post to Twitter