Script – Page 2

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

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

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.

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

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

Check_Xml.ps1

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

Script : Application d’un calculateur de charge en fonction du type de serveur

Récemment dans plusieurs fermes XenApp 6.5 R01 nous avons eu besoin d’appliquer un calculateur de charge (Load Evaluator) sur tous les serveurs dont le calculateur de charge est “Défaut” (et on en avait un max 🙂 ) .

Au passage nous en profitons pour appliquer un calculateur de charge en fonction du type de serveur (Virtuel ou physique).

Dans notre cas les calculateurs de charges sont paramétrés via des Groupes de taches (Worker Groups), un pour les serveurs virtuels et un pour les serveurs physiques.

Comme d’hab ça passe par un script Powershell.

Pré-requis :
– Deux calculateurs de charge configurés en fonction du type de serveur (Virtuel ou Physique)
– Deux stratégies ordinateur, chacune pointant sur un des calculateurs de charge.
– Deux groupes de taches permettant le filtrage des stratégies

Xa6_AttribLE.ps1

Xa5_AttribLE.ps1
Pour XenApp 5 (le script reste le même sans les parties Worker Groups et GPupdate)

Afficher la liste des applications publiées pour un utilisateur en Powershell

——————
15/05/2013
——————
Le script utilise désormais le Token-Groups (merci Pierre pour l’info 😉 ) pour la recherche de groupes d’un utilisateur.
L’avantage du Token-Groups est que nous n’avons plus besoin d’utiliser des recherches récursives, l’attribut (qui est un attribut calculé) contient la liste de tous les SID des groupes (ainsi que les groupes imbriqués) ce qui améliore grandement les temps de recherche :).
Le script affiche la liste des applications publiées pour un utilisateur (un fichier texte contenant la liste des applications publiée pour un utilisateur est également disponible dans le répertoire racine du script).

search_apps_users.ps1

——————
27/03/2013
——————

Récemment on nous a demandé de sortir la liste de toutes les applications publiées pour un utilisateur (dans une ferme en XenApp 6.5 R01).

Donc direction PowerShell 🙂

Nous avons mis en place un script permettant d’afficher la liste de toutes les applications publiées d’un utilisateur dans une ferme (que l’application soit publiée en direct ou via un groupe, concernant le groupe la recherche dans le groupe est récurisve).

Concernant la recherche récursive cette dernière se fait en DotNet (.Net 3.5 sp1 requis dans notre cas).

Au départ nous étions partis avec la cmdlet Get-ADGroupMember mais nous avons vite rencontré la limitation du MaxGroupOrMemberEntries (à 5000, bien que cette valeur soit modifiable via le fichier Microsoft.ActiveDirectory.WebServices.exe.config sur les DC). Il est aussi possible de faire la recherche en ADSI ou via les cmdlet Quest (mais on avait pas envie 🙂 ).

Avant d’exécuter le script modifier en ligne 19 la valeur de la variable $DC par un de vos DC (un DC prévu pour l’exécution de script par exemple).

Une fois le script passé, nous avons constaté en prod (bien qu’on s’en doutait au vu des nombreuses imbrications de groupes) que certaines applications étaient publiées plusieurs fois pour un même utilisateur.

Merci à VmDude pour le trick du bind sur un DC spécifique en DotNet .

On constate que certaines applications sont publiées directement sur le compte du user au passage

DisplayAllAppsForSpecificUser.ps1

Afficher les applications dont le BrowserName est différent du DisplayName

Si vous souhaitez afficher la liste des applications dont le BrowersName n’est pas identique au DisplayName, exécutez la ligne de commande PowerShell ci-dessous (gare aux surprises 🙂 ).

Ho la belle bleu 🙂

get-xaapplication|%{if($_.DisplayName -ne $_.BrowserName){write-host $_.DisplayName "-" $_.BrowserName;$count++}};write-host "Count:" $Count

Erreur : The Citrix System Monitoring Agent cannot contact the Citrix End User Experience Monitor….

Le contexte : Plusieurs fermes (4.5 R06/5 R06 en 32/64 bits et XA6.0/6.5 R01 le tout en us), au sein de ces fermes des serveurs rencontraient l’erreur :

Event Source: Citrix System Monitoring Agent
Event ID: 109
Description: The Citrix System Monitoring Agent cannot contact the Citrix End User Experience Monitor. EUEM data will not be collected. Contact Citrix Support.

La cause vient du fait que les serveurs n’ont pas d’accès à internet alors que le service “Citrix End User Experiencing Monitoring” tente de se connecter à crl.microsoft.com afin de valider un certificat.

La CTX120846 permet de contourner ce problème en créant un fichier “SemsService.exe.config”sur chaque serveurs rencontrant le problème dans “c:\Program Files\ Citrix\ EUEM\Service\”.

Le contenu du fichier “SemsService.exe.config” :

<? xml version = “1.0” encoding = “utf-8”>
<configuration> <runtime>
<generatePublisherEvidence enabled=”false” />
</ runtime>
</ configuration>

Il existe aussi la solution GPO qui consiste à désactiver la mise à jour automatique des certificats racines 🙂 .

Mais car il y a un mais dans notre cas 😉 , l’activation de ce setting n’est pas possible dans l’immédiat, donc direction un script powershell qui va copier le fichier SemsService.exe.config sur l’ensemble des serveurs d’une ferme.

Le script EdgeSightCopySemsService_exe_config.ps1 check l’Os archicture de chaque serveur et test si le répertoire c:\Program Files\ Citrix\ EUEM\Service\ (ou c:\Program Files (x86)\ Citrix\ EUEM\Service\) existe, puis vérifie que le fichier “SemsService.exe.config” n’est pas déjà présent, s’il n’est pas présent il le copie sur le serveur.

Rentrer en ligne 6 dans le script le share où se trouve le fichier SemsService.exe.config dans votre infra.

EdgeSightCopySemsService_exe_config.ps1

En attendant de passer ça en GPO faute de mieux ça fera l’affaire 🙂 .

Pour en savoir un peu plus sur l’EUEM c’est par ici.

Script : lister les serveurs d’un calculateur de charge

Quoi de plus utile qu’un calculateur de charge de “maintenance” permettant d’isoler un ou plusieurs serveurs de leurs applications publiées ceci afin de pouvoir effectuer des mises à jour (ou autres) sans supprimer ces mêmes serveurs de leurs applications publiées.

Une fois ces serveurs en “maintenance”, les administrateurs peuvent avoir besoin de savoir quels sont les serveurs concernés par cette maintenance (dans notre cas plusieurs fermes administrées par plusieurs administrateurs)

Le script powershell (merci à CloudyDude pour le tips du formatage) ci-dessous va lister les serveurs appartenant au calculateur de charge “maintenance”, puis enverra un mail aux administrateurs avec la liste de ces serveurs (l’idéal étant de mettre ce script en tâche planifiée)

$farm = Get-XAFarm
$LoadEval = “MAINTENANCE”
$XA_Load = get-xaserver -LoadevaluatorName $LoadEval | Select ServerName | sort ServerName| out-string

$emailFrom = “CTX-” +$farm +”@domain.fr”
$emailTo = “email@domain.fr“
$subject = “Farm : ” +$farm + ” – Server(s) in Load Evaluator ” +$LoadEval
$body = $XA_Load
$smtpServer = “VotreSmtp”
$smtp = new-object Net.Mail.SmtpClient($smtpServer)
$smtp.Send($emailFrom, $emailTo, $subject, $body)

Script inventaire d’installation d’un Rollup Pack

———————–
MAJ : 27/12/2010
———————–
Modification du script.
Dans le fichier de log, les serveurs avec et sans le rollup pack sont désormais séparés en deux listes distinctes (les hots sont classés par ordre alphabétique)

—————
12/01/2010
—————
Si vous êtes en train de passer un Rollup Pack sur une ferme PS 4.0 (dans notre cas), et que vous souhaitez connaître l’avancement de l’installation du Rollup Pack sur votre ferme.

Le script Farm_RollupV1.wsf vous permet de lister tous les serveurs membre d’une ferme, et vous indique si le Rollup Pack est installé ou pas sur chaque serveur.

Dans le script vous modifiez la variable MyRollup ligne 70, afin de précisez le Rollup Pack que vous souhaitez inventorier.

Une fois le script exécuté, un fichier nommé XenApp_NomDeVotreFerme-MyRollup.txt est créer à la racine du C: (vous pouvez modifier le nom et l’emplacement aux lignes 74 et 77).

Liste des serveurs avec Rollup Pack installé (dans l’exemple le Rollup Pack 6 pour une PS 4.0)

Si le Rollup Pack n’est pas installé (dans l’exemple un Rollup Pack 05 pour une PS 4.0)

A la fin du fichier vous avez trois totaux :

Total des serveurs avec le Rollup Pack installé

Total des serveurs sans le Rollup Pack

Total des serveurs membre de la ferme

Soyez indulgent avec le code 😉

Script : Vérification des services XenApp après le passage d’un Rollup Pack

Suite au passage du R06 (pour XenApp 5 2003), nous avions besoin de connaître l’état des services XenApp après l’installation du R06 (l’installation du R06 et de ses pré-requis est faite via Installation Manager)

Nous avons mis en place un script (Testing_Services.vbs, renommez le fichier Testing_Services.txt joint dans ce billet en Testing_Services.vbs) afin de pouvoir faire un état des services XenApp après le passage du R06.

Actions du script Testing_Services.vbs :

Vérification de l’état des principaux services XenApp
Vérifiez que l’ouverture de session est bien activée
Suppression du fichier dotnetfx35_SP1.exe (présent dans le (c:\windows\temp\dotnetfx35_SP1.exe des serveurs), la partie java étant installée que sur les serveurs publiant la CMC, le script n’en tient pas compte)
Création d’un fichier de log “Log_Testing_Services.txt“

Fonctionnement du script :

Créez un fichier serveurs.txt (chaque ligne de ce fichier contient le Hotsname d’un serveur déjà patché en R06)
Copiez dans le même emplacement le script Testing_Services.vbs
Exécutez le script Testing_Services.vbs
Double cliquez sur le fichier Log_Testing_Services.txt

Le script Testing_Services.vbs peut aussi est utilisé lors de passage autre que le R06 😉 .

Voir aussi le billet “Script inventaire d’installation d’un Rollup Pack” afin de connaitre la liste des serveurs patchés dans une version Rollupack.

Script : Liste des serveurs XenApp avec leur Uptime respectif

Afin de pouvoir visualisez la liste des serveurs XenApp d’une ferme avec leur uptime respectif, nous avons réalisé un script (Farm-Info_serverUptime.wsf est joint en annexe à ce billet) qui affiche dans un tableau le nom des Hosts avec leur Uptime.

Dans notre exemple l’alerte de l’Uptime est fixée à 15 jours, vous pouvez modifier l’alerte de l’utpime à la ligne 127 du script.

Une fois le script exécuté vous obtenez un fichier html “farmUptime_Votreferme.html” à la racine de votre C:.