Author: CtxBlog

XenApp_InfoFarm : Script de remontée d’informations XenApp

—
MAJ : 27/01/2011
Ajout de la colonne “Calculateur de charge” dans la section “Server(s)”.
Modification de la méthode (qui reste encore à améliorer côté code) du changement de couleur des évènements type “FALSE”.
—

18/01/2011

Si comme nous, vous avez besoin de remonter les informations principales de vos fermes XenApp sans passer par EdgesSight, le script powershell Xenapp_InfoFarm vous permettra facilement de le faire (dans notre cas avec une tâche planifiée pour une mise à jour quotidienne).

Côté présentation nous nous sommes inspirés (très fortement même) du script vcheck (merci à Alan et Hypervisor.fr) de la communauté Vmware.

Côté fonctionnel vous avez juste besoin de powershell et des cmdlets XenApp (CTP) 😉 .

XenApp_InforFarm est composé de deux fichiers (joint à ce billet), le script powershell  “XenApp_InforFarm.ps1” et le fichier de fonctions “Ctx_Functions.ps1”

XenApp_InforFarm  permet de remonter les informations suivantes :

Partie Generals Details :

  • Nom de la ferme
  • Type de Datastore
  • Serveur Datastore
  • Serveur de licence et le port
  • Nombre de serveurs dans la ferme
  • Nombre d’applications dans la ferme
  • Nombre de zones
  • Nombre de calculateurs de charges
  • Nombre de stratégies
  • Nombre d’administrateur

Partie Zone Details :
Classement alphabétique par nom de zone.

  • Nom de la zone
  • DataCollector

Partie Load Evaluator(s) Details :
Classement par priorité des stratégies

  • Nom du calculateur de charge
  • Description


Partie Policy(s) details :
Classement par priorité des stratégies.

  • Nom de la stratégie
  • Description
  • Priorité
  • Statut (en rouge les stratégies désactivées)

Partie Administrator(s) détails :
Classement par ordre alphabétique des comptes administrateurs.

  • Compte Administrateur
  • Type de permission
  • Statut


Partie Application(s) Details :
Classement par ordre alphabétique des dossiers applications.

  • Nom de l’application
  • Description
  • Dossier
  • Statut (en rouge les applications désactivées)


Partie Server(s) Details :
Classement par ordre alphabétique des dossiers servers.

  • Nom du serveur
  • IP
  • Dossier
  • Zone
  • Logon activé
  • Type d’édition XenApp
  • Date d’installation XenApp


Fonctionnement du script :

  • Renommer les fichiers en .ps1
  • Copié les fichiers dans le répertoire de votre choix et modifier le fichier XenApp_InfoFarm.ps1 à la ligne6, et indiquer le chemin du fichier Ctx_Functions.ps1.
  • Exécuté le script XenApp_InfoFarm.ps1
  • Consulter le fichier “XenApp_InfoFarm-Nom de votre ferme.html” créé par le script

XenApp_infoFarm a été testé sur une ferme en XenApp 5 (2003 Sp2 Fr) en R06.

Vos remarques et suggestions sont les bienvenus 🙂 .

Télécharger :
XenApp-InfoFarm
Ctx_Functions

Post to Twitter

Erreur : Le Serveur n’a pas réussi à allouer de la mémoire paginée du pool système car celui-ci est vide.

Sur des serveurs (2003 Fr Sp2) membre de ferme XenApp 5 R06 ou XenApp 4.5 R01, nous avons rencontré des erreurs de type  “Le Serveur n’a pas réussi à allouer de la mémoire paginée du pool système car celui-ci est vide” (Source : Srv – Id : 2020).

 
Les conséquences de cette erreur sur les serveurs en question étaient :

  • Impossibilité d’ouvrir une mmc
  • Task manager indisponible
  • Accès impossible aux propriétés system
  • Erreurs RPC
  • Freez de l’OS
     

En googlelant nous sommes tombés (avec Menhir Two) sur la KB27560 (voir aussi la KB923360) qui explique que ce problème peut se produire avec les versions  7.00, 7.01, 7.02, 7.03 ou 8.0 de Norton Antivirus installées sur des DC en Windows 2000 Server (dans notre cas nous étions en 8.1.0.821 avec un moteur d’analyse en 4.2.0.7 et pas sur des DC).

La résolution s’est faite en désinstallant la version 8.1.0.821 de Norton anti-virus et en passant à la version SEP11 (il ne reste plus qu’a scripter tout ça 🙂 ).

Post to Twitter

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)

Post to Twitter

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 😉

Post to Twitter

Convertir un fichier batch en .exe

Lors d’une mise à jour applicative, nous avons eu besoin de compiler un script batch en .exe.

Certains utilitaires le font très bien (Bat to Exe Converter par exemple) , cependant suite à un tweet de nos collègues d’Hypervisor.fr, nous avons voulu tester Iexpress.

L’avantage de Iexpress est qu’il est natif à Windows, l’utilisation est simple et permet de convertir un fichier .bat en .exe rapidement.

Allez dans le menu démarrer-Exécuter, puis tapez la commande “Iexpress”.

Bien que Bat to Exe Converter soit plus complet, Iexpress permet de faire l’essentiel le tout en natif 😉 .

Post to Twitter

Best Practices pour les administrateurs XenApp

Citrix vient de mettre en ligne (15/12/2010) la CTX127574 “Best Practices for XenApp Administrators”.

La CTX127574 comprend les 10 Best Pratcices minimum à mettre en place lors de l’installation d’une ferme XenApp.

  1. Mettre en place une sauvegarde régulière du DataStore (CTX677542)
  2. Mettre en place une ferme XenApp de qualification
  3. Se maintenir informer des mises à jour et correctifs pouvant s’appliquer à votre environnement (CTX120842 et CTX127228)
  4. Mettre en place une gestion du changement (Faire une recherche “Journalisation de la configuration” sur Citrix Edocs)
  5. Mise en place d’une (ou plusieurs) stratégie d’impression (CTX111967, CTX126093 et CTX119815)
  6. Se familiariser avec les outils de débogage (CTX122827 et CTX126294)
  7. Se familiariser avec les dump mémoire (KB254649, CTX105888 et CTX466627)
  8. Comprendre les notions de Zone(s) et Zone Data Collector (faire une recherche “Zones” sur Citrix Edocs et lire la CTX126335)
  9. Monitorer la ferme XenApp (faire une recherche “Health Monitoring and Recovery” sur Citrix Edocs et lire la CTX107935)
  10. S’assurer que les utilisateurs se connectent à la ferme XenApp avec un client correctement configuré et à jour ( (faire une recherche “Receiver and Plug-in” sur  Citrix Edocs)

Post to Twitter

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.

Post to Twitter