Scripts – Page 6

Cacher des applications dans une Web Interface

Récemment nous souhaitions cacher des applications publiées d’un site Web Interface sur un pool de Web Interface 5.4 (us) dédiées, sans modifier le fichier WebInterface.conf (voir la CTX122133 qui au passage nous avait déjà rendu service 🙂 ).

L’idée était de le faire via le champ description des applications (comme la CTX123969 mais qui ne fonctionne qu’avec les sites XenApp Services) et de modifier le champs description d’une ou plusieurs applications publiées via un script powershell (tout en gardant l’ancienne description).

Nous somme tombés sur un post de Miguel Contreras sur le Citrix blog qui justement met en ligne un code à insérer dans le fichier global.asax.cs et qui correspond exactement à notre recherche.

Une fois le fichier global.asax.cs modifié il ne reste plus qu’à rajouter au début du champs description des applications un “@” (dans notre cas nous avions remplacé le @ par la chaîne =HIDE=).

Par contre ne pas perdre de vu que si vous cachez toutes les applications d’un dossier Web Interface, le dossier sera quand même visible dans la Web Interface 😉 .

global.asax.cs

App_Change_Description.ps1

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 : recherche de version agent Edgesight

Récemment nous avons eu besoin d’extraire des listes de serveurs au sein de fermes XA6.5, n’ayant pas la version de l’agent EdgeSight de référence ainsi que les serveurs n’ayant pas d’agent EdgeSight installé.

Nous avons donc écrit un script powershell permettant de remonter ces informations dans un fichier htm.

Au préalable il faut renseigner la version de l’agent EdgeSight validé dans votre production ligne 11 du script.

Dans notre cas une 5.4.0.5107 que notre collègue Net2Sys affectionne 😉

11 serveurs n’ont pas d’agent et un n’est pas à jour.
C’est paradoxal mais on évite de passer par EdgeSight pour la version des agents 🙂

Forcer la Publication d’Internet Explorer en full screen

Si vous souhaitez forcer la publication d’Internet Explorer (dans notre cas sous XenApp 6.5) en seamless, la CTX132434 explique comment le faire via le vbs ci-dessous :

Set WshShell = WScript.CreateObject("WScript.Shell")
WshShell.Run "iexplore.exe", 3, false

Dans notre cas nous souhaitons publier plusieurs url applicatives tout en évitant la multiplication du script ci-dessus. Nous avons donc modifié le script afin que nous puissions mettre en argument une url.

Set WshShell = WScript.CreateObject("WScript.Shell")
If wscript.Arguments.length = 0 Then
WshShell.Run "iexplore.exe", 3, false
Else
WshShell.Run "iexplore.exe" & Space(1) & wscript.arguments(0), 3, false
End if

Rajoutez l’url en fin de ligne de commande

Installation silencieuse du SDK powershell XenApp 6.5

Sur un de nos serveurs d’infra XenApp 6.5 nous avons eu besoin d’installer le Citrix.GroupPolicy.Commands (afin de pouvoir importer/exporter des policies, voir la CTX128625 pour de plus amples informations) avec en pré-requis le SDK Powershell XenApp 6.5 (au passage si vous chercher un SDK pour XenApp : SDK XenApp ).

Nous avons écrit un script permettant d’installer en unattended le SDK powershell XenApp 6.5 et le Citrix.GroupPolicy.Commands.

Au préalable télécharger le SDK Powershell XenApp 6.5 puis extraire son contenu (via 7-Zip par exemple), puis télécharger le Citrix.GroupPolicy.Commands et le copier dans le dossier setup du SDK.

Renseignez la variable $msiPath (mettre le chemin menant au dossier setup du SDK), puis exécuter le script sur le serveur en question.

$msiPath = "\\PATH_SDK\Setup\"
 $msi = @(($msipath+"Citrix.Common.Commands.Install_x64.msi"), ($msipath+"Citrix.XenApp.Commands.Client.Install_x64.msi"), ($msipath+"Citrix.XenApp.Server.Sdk_x64.msi"), ($msipath+"CitrixGroupPolicyManagement_x64.msi"))

foreach($_ in $msi)
 {Start-Process -FilePath msiexec -ArgumentList /i, $_, /qb- -Wait
 Write-Host "$msi"
 }

import-module ($MsiPath+"Citrix.GroupPolicy.Commands")

Il est aussi possible de passer par un invoke-command à la place du Start-Process pour une installation en remote, le /qb- c’est juste qu’on aime bien voir les progressbar lors des installations 🙂 .

Script : Désactivation SpeedScreen via les MFCOM

Dans une de nos fermes de prod (XenApp 5 R06 sur Windows 2003 Sp2 Fr), nous avons eu besoin de désactiver l’accélération de navigation HDX 3D (SpeedScreen) sur un silo applicatif.

Nous avons réalisé un script wsf (ça faisait longtemps qu’on n’avait pas mis les mains dans les MFCOM 🙂 ) afin de pouvoir désactiver dans un premier temps l’héritage des paramètres de la batterie (puisque dans notre cas le SpeedScreen était paramétré au niveau de la batterie), puis de désactiver l’accélération de navigation HDX 3D (le script filtre les serveurs en fonction du hostname, voir ligne 67 du script).

Une fois les infos trouvées sur la bible des MFCOM, la lecture est lourde mais à chaque fois payante 🙂 .

Avant le script

Après le script

SpeedScreen_Disable.wsf

MAJ TestPort : Script permettant de tester les ports Tcp

Il ya quelque temps nous avions mis en ligne test_port qui permettait de tester les port Tcp Xenapp afin de vérifier les ouvertures réseau sur l’ICA par exemple.

Après un peu plus de deux ans, nous avons mis à jour test_port 🙂 .

Outre la correction des divers bug et la simplification du code, il est possible désormais de tester les ports sur plusieurs serveurs.

Cliquez sur le bouton “Ouvrir le fichier serveur cible” (le fichier est crée automatiquement)
Renseignez les Ip des serveurs à tester et enregistrez le fichier
Cliquez sur le bouton “Lancer le test“

Test_Port V1.3

MAJ : 03/04/2012
Test_Port V1.3
Correction bug : lors clic sur le bouton Ouvrir le fichier serveur Cible le fichier servers.txt ne gardait pas les informations enregistrées.

XenApp_Check compatible XenApp 6

XenApp_Check est désormais comptatible XenApp 6 🙂 et disponible ici .

Le code est fonctionnel mais pas encore optimisé .
Le fonctionnement reste identique à XenApp_check pour XA5, à la différence qu’il faut configurer le mode policy via les lignes 58 et 64 du script XenApp_CheckXA6.ps1

RecreateLHC sur plusieurs serveurs

MAJ : 04/03/2012
Version 1.1
Ajout de la compatibilité 64 bits

—————————————

Dans ce billet un petit script qui permet de faire des RecreateLhc sur plusieurs serveurs avec un fichier de log, permettant de vérifier chaque étape du RecreateLhc sur chaque server.

Utilisation du script Ctx_RecreateLHC.vbs :

Créer dans le répertoire ou est situé Ctx_RecreateLHC.vbs un fichier nommé “servers.txt” et rentrer le nom des serveurs où sera recrée la LHC.
Double cliquer sur Ctx_RecreateLHC.vbs
Un fichier de log au format html sera créé dans le répertoire d’exécution de Ctx_RecreateLHC.vbs

Le détails des actions du script est contenu dans le fichier log (arrêt service IMA et de ses dépendences, vérification de la taille de la base LHC, dsmaint recreatelhc, vérification de la taille de la base LHC (après RecreateLhc), démarrage des dépendances du service IMA et du service IMA)

Le script fonctionne sur des fermes XenApp 5/6 sous windows 2003/2008 (32/64 bits) (~~prochaine étape XenApp 6/6.5~~ 🙂 ).

La CTX759510 préconise elle de son côté, de faire un recreatelhc sur tous les serveurs membre d’une ferme après un DSCHECK /clean (de notre côté nous procédons par vague de serveurs)

If you must clean the farm data store, using the DSCHECK utility, you should then rebuild the LHC on each of the servers in your farm, once the data store has been cleaned.

Ctx_RecreateLHC.vbs

Erreur 3961 : la mémoire du collecteur de donnée est insuffisante……

Récemment sur une de nos fermes de prod (XenApp 5 R06) nous avons rencontré une erreur peu commune sur un Zone Data Collector :

Source IMAService – ID : 3961
La mémoire du collecteur de données est insuffisante et les données du magasin dynamiques sont peut-être obsolètes. Veuillez désigner un nouveau collecteur de données et vérifiez que le nouveau collecteur de données dispose d’assez de mémoire.

Ce qui a eu pour effet que le ZDC ne remplissait plus son rôle (impossible d’obtenir la charge des serveurs par exemple) dans sa zone. Le résultat était que plus aucune application de la zone impactée n’était disponible (en bref plus de prod sur cette zone).

Dans pareil cas, soit vous forcez une nouvelle élection de ZDC (en baissant le privilège de l’actuel ZDC par exemple), soit vous redémarrez le service IMA du ZDC (tout en veillant au préalable qu’aucun process ne consomme de façon excessive de la mémoire). Le problème de ces solutions est qu’elles sont manuelles 🙁 .

Nous avons écrit un script powershell (search_Event_3961.ps1), qui va checker les events 3961 (le script est mis dans une tâche planifiée s’éxécutant toute les 5 mn sur le ZDC )

Les actions du script :

Check les events system (ID 3961) sur les quatre dernières minutes sur le ZDC
Si un event 3961 est trouvé alors le script va changer la priorité du ZDC actuel en “NotPrefered” ce qui aura pour effet de forcer une élection de ZDC sur le ZDC de backup.
Envoi d’un mail afin d’informer qu’un event 3961 a été détecté sur le ZDC et qu’une élection a été réalisée (le mail précise l’ancien et le nouveau ZDC)
Création d’un fichier de log html

L’avantage du script en tâche planifiée (ou via un syslog) est que cela vous permet de rétablir votre production rapidement sans aucune action, et vous permet de pouvoir lancer un troubleshooting sur votre ZDC (de notre côté nous n’avons pas eu la chance de pouvoir troubleshooter le ZDC du fait de l’urgence, le ZDC a eu son service IMA redémarré).