Scripts – Page 4

Comparer les OUs enfants de deux OUs parents

Logiquement dans toute production XenApp (ou autre) on a une production ISO à la qualification, cependant il peut arriver au fil du temps que la réalité soit un peu différente 🙂 .

Afin de mettre en évidence les silos applicatifs n’ayant pas de Qualif (ou pas de Prod) nous avons mis en place un PowerShell qui compare les OUs de Prod et de Qualif de nos différentes fermes XenApp.

En général la qualif XenApp est sur une Ad de Qualif et la Prod XenApp sur une Ad de Prod, mais (car il y a toujours un mais dans certaines missions) dans le cas présent la qualif et la prod sont sur l’AD de prod 🙂 .

En ligne 1 il faut adapter le contenu de la variable $Vers en fonction de votre nomenclature.
Les OUs parents sont à renseigner en ligne 13 et 16 du script (vous pouvez aussi supprimer la variable $Vers et le Foreach en ligne 3 et31 si vous ne souhaitez checker qu’une seule version XenApp)

Sur notre lab on est presque ISO 🙂

Compare_Ou_ProdQualif.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 : Retrouver la ferme d’un serveur XenApp

Si vous souhaitez retrouver (ou un de vos collègues 😉 ) la ferme d’un serveur XenApp dans un environnement “riche” (plusieurs fermes de Prod avec leur Qualif et Recette associés), vous pouvez passer par :

Un AppCenter qui agrège toutes les fermes
Une nomenclature explicite
Votre outil d’inventaire
A l’ancienne (RDP sur le serveur ou accès en remote à la registry du serveur ou au fichier mf20.dsn etc… etc..)
Un script PowerShell

Concernant le script, nous utilisons la cmdlet GET-ADComputer pour checker si le serveur est bien dans l’AD (et récupérer son DN), puis on récupère en WMI la valeur registre “Neighborhood” afin de remonter le nom de la ferme d’appartenance du serveur .

Le serveur existe bien dans l’AD mais n’est dans aucune ferme XenApp

Le serveur existe bien dans l’AD mais ne répond pas à l’ICMP

Le serveur n’existe pas dans l’AD

Le serveur existe bien dans l’AD et on retrouve sa ferme XenApp

SearchXenAppFarm.ps1

Script : inventaire de serveurs non XenApp

Au détour d’un troubleshooting nous sommes tombés sur des serveurs “non XenApp” alors que ces derniers se trouvaient dans des Ou réservés aux serveurs XenApp.

Comme nous n’aimons pas les serveurs qui ne servent à rien, nous avons mis en place un PowerShell qui va se charger d’inventorier tous les serveurs “non XenApp”.

Le fonctionnement du script est on ne peut plus simple, on vérifie si le service IMA existe (s’il n’existe pas on considère que XenApp n’est pas installé) sur les serveurs, on prend aussi en compte les serveurs qui ne répondent pas à l’envoi de paquets ICMP (via la cmdlet Test-Connection) ainsi que ceux pour lesquels nous n’avons pas les droits nécessaires pour obtenir l’existence du service IMA.

Avant de lancer le script rentrer le DN de l’OU que vous souhaitez vérifier en ligne 3 du script.

Et voila huit serveurs (physiques) à récupérer 🙂

Check_XenApp_Computer.ps1

Problème d’affichage qfarm /load

Sur plusieurs fermes XenApp 6.5 R01 US Sp1, on nous a remonté un problème d’affichage lors de l’exécution d’un qfarm /load (ou query farm /load pour les anciens 😉 ).

En effet la sortie quelque peu décalé 🙂

Après quelques googles infructueux et afin de pallier rapidement ce problème d’affichage (un troubleshoting en bon et du forme viendra rapidement) nous sommes passés par un PowerShell faisant appel à la cmdlet Get-XaServerLoad.

Nous avons ajouté en argument la possibilité de rentrer une charge afin de n’afficher que les serveurs ayant une charge égale ou supérieure à la charge rentrée (si aucun argument n’est rentré la totalité des serveurs sera affichée) ainsi qu’un compteur totalisant le nombre de serveurs issus du qfarm /load.

Dans notre cas nous avons mis le script QfarmPS.ps1 dans %ProgramFiles(x86)%\Citrix\system32 afin que ce dernier puisse être lancé directement via une console PowerShell.

Un screenshot avec et sans argument

QfarmPS.ps1

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

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

Mise à jour de XenApp_Check : 2.3

Ajout de la section Server(s) Load, cette section regroupe les serveurs dont la charge est supérieure à 9998.

Vous pouvez désactiver cette section via le script XenApp_Check.ps1 en mettant à FALSE la variable $Check_Ctx_SrvLoad.

Les serveurs dont le calculateur de charge correspond à celui configuré dans la variable $LoadEval_Check(calculateur de charge de maintenance configuré via le script XenApp_Check.ps1) sont exclus de cette section.

Le billet sur XenApp_Check

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