Powershell Archive

0

SDK Modification du scope d’exécution

Il y a quelques jours nos scripts de prod (d’une de nos fermes XenApp 6.5 R04)  renvoyaient les informations d’une ferme de qualification, en regardant de plus près nous avons constaté que le scope d’exécution du SDK avait été changé sur un de nos serveurs d’administration.

Un Get-XADefaultComputerName confirma que le scope n’était pas le bon, afin de rétablir le scope sur la ferme d’appartenance du serveur il faut passer par un Set-XADefaultComputerName -ComputerName “VotreServeur”.

Ce billet juste pour souligner qu’un changement de scope ne concerne pas que la session dans laquelle il est lancé mais le serveur en lui-même, l’information étant présente dans la valeur “DefaultComputerName” situé dans [HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\XenAppCommands].

Si vous souhaitez ne pas changer de scope, les cmdlets du SDK permettant de faire du remote avec l’utilisation de l’argument -computername.

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

2

XenApp_Usr : mise à jour 1.4

XenApp_Check passe en 1.4, la liste des ajouts et corrections sont ci-dessous :

  • 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

XenApp_UsrV14

 

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

2

XenApp_Gpupdate

———————–
MAJ : 28/06/2015
Version : 1.1
———————–

  • Ajout de la possibilité d’afficher la liste complète des serveurs membres de la ferme (via le bouton “Servers”)
  • Ajout de la possibilité de rechercher un serveur spécifique (via la coche “Search server”)
  • Retour du statut de la commande Gpupdate /force (indique si le process a bien été lancé sur le serveur et si ce dernier est bien fermé.), avec la durée d’exécution (duration) par serveur
  • Correction de bugs mineurs

XenApp_GpUpdate_V1.1

 


Tout est dans le titre 🙂 , via XenApp_Gpupdate vous avez désormais la possibilité de faire (en remote) des “gpupdate /force” sur des serveurs membres d’un silo applicatif au sein d’une ferme XenApp 6.5.

XenApp_Gpupdate (comme XenApp_Usr) est un script Powershell réalisé pour la partie GUI avec Powershell Studio de Sapien.

Le “gpupdate /force” est fait via un “Invoke-WmiMethod” (il faut donc que le port TCP 135 soit ouvert entre le serveur exécutant XenApp_Gpupdate et les serveurs XenApp des divers silos de la ferme courante, avant de lancer le GpUpdate un socket tcp est envoyé afin de vérifier que le port 135 est bien ouvert sur le ou les serveurs du silo choisis.

Le fonctionnement de XenApp_Gpupdate est simple, il suffit d’afficher la liste des silos (dossiers serveurs) ou la liste des applications via les boutons Applications ou Servers Silo (il est aussi possible de faire une recherche sur un silo ou une application), puis de sélectionner le silo (ou l’application) souhaité. Une fois le dossier ou l’application sélectionné(e) la liste des serveurs s’affichera sur la partie droite (lors de la première sélection un temps d’attente est à prévoir), une fois la liste des serveurs affichés vous pouvez lancer un gpupdate /force sur un ou plusieurs serveurs.

 

XenApp_GpUpdateC’est une V1 n’hésitez pas à nous faire part de vos retours (suggestions, critiques etc… )

 

Nous travaillons actuellement sur le retour des “gpupdate /force” afin de déterminer si ces derniers ont bien été réalisés sur le ou les serveurs sélectionnés.

 

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

Erreur HTTP : Error 503 sur Web Interface

Suite à une mise à jour sur nos Web Interface (5.4 us /2008 R2 us) de prod (suppression de sites XenApp Web) nous avons rencontré sur deux Web Interface une erreur HTTP 503 (Service Unavailable).


Http503_1

 

Vu que seuls les sites XenApp Web étaient impactés (IIS était ok, la création d’un site et son accès répondait bien), nous avons regardé du coté de IIS, et en cliquant sur l’application Pools (bien sur nous ne sommes pas tombés directement dessus 😉 ), nous avons constaté que “CitrixWebInterface5.4.0AppPool” était arrêté.

 

Http503_2C’est sûr que ça risquait de marcher la

 

Une fois l’application pool “CitrixWebInterface5.4.0AppPool” démarrée, l’erreur HTTP 503  n’apparaissait plus.

Afin de checker les sites XenApp Web de nos différentes Web Interface, nous avons mis en place un script PowerShell permettant de vérifier si les différentes url répondent bien.  Dans un second temps  en parcourant l’outil de supervision (Zabbix) de notre client actuel,  nous avons remarqué que le check d’URL est possible via un scénario web qui lui même va checker les différentes url de nos sites Web Interface (avec un trigger afin de générer une alerte dans Zabbix).

 

Zabbix_WebuiDans notre cas nous avons créé le scénario web dans un template que nous appliquons à nos Web Interface

 

Zabbix01
Une fois l’étape du scénario créée le check d’url est réalisé

 

Zabbix_Webui_XenApp_triggerLe trigger que nous avons associé à notre scénario Web, si le dernier check est différent de 0 (check ok) alors une alerte avec un statut haut remontera dans Zabbix

 

Http503_3
Le résultat de la supervision Web dans Zabbix

 

Concernant le script Powershell, il faut au préalable :

  1. Modifier en ligne 2 du script les Web Interface à checker
  2. Modifier l’url à checker en ligne 7 du script

 

WebiCheckPour la partie PowerShell, si vous avez pas d’outil de surpervision ou autres solution alors à l’ancienne une tache planifiée (en dernier recours)

 

Download_2
Check_Url_Webi.ps1

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