CurrPorts :
logiciel de surveillance réseau (voir notre billet sur CurrPort)
Process Monitor :
Outil de surveillance système (fichiers, registre et process le tout en temps réel)
SpaceMonger :
Affiche graphiquement le taux d’occupation d’un disque (sans installation)
ThreadMaster :
Permet de gérer la consommation CPU par application
WireShark :
Analyseur de protocole réseau (Unix et Windows)
CurrPorts :
logiciel de surveillance réseau (voir notre billet sur CurrPort)
Process Monitor :
Outil de surveillance système (fichiers, registre et process le tout en temps réel)
RamMap :
Outil permettant de visualiser graphiquement l’état de la ram (utilisation, process, assignation, cache etc…)
SpaceMonger :
Affiche graphiquement le taux d’occupation d’un disque (sans installation)
ThreadMaster :
Permet de gérer la consommation CPU par application
WireShark :
Analyseur de protocole réseau (Unix et Windows)
XenApp_Check :
Script powershell permettant de vérifier l’état de santé d’une ferme XenApp
Xperf (Windows Performance Toolkit) :
Outils microsoft permettant prendre une trace système (le tout graphiquement).
[cleanarchivesreloaded]
[si-contact-form form=’1′]
Et voilà après presque deux ans sous Dotclear, CTXBLOG passe sous WordPress.
La migration ne fut pas exempte de bugs (loin de là 🙂 ).
Bugs encore présents :
Nous travaillons actuellement sur ces bugs afin que la migration soit totalement finie
Ceci est un exemple de page WordPress. Vous pouvez la modifier pour mettre ici des informations vous concernant ou concernant votre site afin que vos lecteurs en sachent un peu plus sur vous. Vous pouvez créer autant de pages ou sous-pages que vous voulez, et gérer l’intégralité de votre contenu dans WordPress.
Lors d’une désinstallation d’une PS 4.0 nous avons rencontré l’erreur :
“Erreur 25602. Impossible d’obtenir la longueur de la propriété CustomActionData dans la fonction ParseCADProperty.”
ID 1005 – Souce : MSInstaller
Le serveur sur lequel cette erreur a été rencontrée est un serveur en Windows 2003 enterprise sp2 Fr avec PS 4.0 R06.
Plutôt que de partir dans un troubleshooting compliqué, connectez-vous en admin et en console sur le serveur puis désinstaller la version XenApp, ça pourrait vous éviter un long pèlerinage 🙂 .
Un post sur Citrix.com traite cette erreur (bien que le post soit à la base pour une PS 4.5, dans notre cas il était aussi valable en PS 4.0).
Nous avons rencontré (toujours avec Menhir Two 😉 ) un effet de bord de la cmdlet “GET-XAServerConfiguration” (en CTP V3 non up to date)
En effet lors de l’appel de la cmdlet, nous obtenions l’erreur suivante : “Failed to read all bytes in a wint value“.
L’effet de bord lui était surprenant (surtout pour un GET 😉 ) :
Et voila plus de serveur de licence au sein de la ferme XenApp 🙁 (cependant si vos serveurs n’ont pas l’héritage d’activé pour la partie serveur de licence, l’effet de bord n’aura aucun impact) .
L’effet de bord est connu (notamment sur ce post sur le forum Citrix Us).
La solution est de mettre à jour les Cmdlet (au préalable il vous faut désinstaller le CTP (Command Technology Preview), puis installer la dernière version CTP (dans notre cas celle du 13/01/11)
Une fois les Cmdlets à jour la commande GET-XAServerConfiguration fonctionne nickel et sans aucun effet de bord.
—
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 :
Partie Zone Details :
Classement alphabétique par nom de zone.
Partie Load Evaluator(s) Details :
Classement par priorité des stratégies
Partie Policy(s) details :
Classement par priorité des stratégies.
Partie Administrator(s) détails :
Classement par ordre alphabétique des comptes administrateurs.
Partie Application(s) Details :
Classement par ordre alphabétique des dossiers applications.
Partie Server(s) Details :
Classement par ordre alphabétique des dossiers servers.
Fonctionnement du 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
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 :
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 🙂 ).