Tag: Powershell

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

Post to Twitter

XenApp_Check : Health check for XenApp farm

MAJ :03/12/2014
Version : 2.6 (XA6x)

Add check WorkerGroup in “Server in Application(s)” section

XenAppcheck_26

MAJ :02/07/2013
Version : 2.3 (XA5/XA6x)

Adding “Server(s) Load” section, this section contains all servers with higher load at 9998.
To disable this section modify $Check_Ctx_SrvLoad.  variable to FALSE in XenApp_CheckXAx.ps1 file.
All server with Load Evaluator “Maintenance” (set by $LoadEval_Check variable) is excluded on this section

 

 

 

MAJ : 29/04/2013
Version : 2.2 (XA5/XA6x)
Adding “Citrix HotFix missing” section, this section is enable by default. To disable this section modify $Check_Ctx_HotFix.  variable to FALSE in XenApp_CheckXAx.ps1 file.

If you want to change the HotFix Citrix version ( in the XenApp_CheckXAx.ps1 file):
– For  XenApp6.0/6.5 modify  $Ctx_HotFixXA60 variable  (for XenApp 6.0)  or $Ctx_HotFixXA65 variable (for XenApp 6.5)
– For XenApp 5 modify  $Ctx_HotFixXA5_32 variable (for 32bits) and/or $Ctx_HotFixXA5_64 variable (for 64 bits)

Next step, install the hotfix validated by you

If the message  LHC error or CtxHotFix not Installed appears in the Citrix HotFix column, the HotFix is not installed or the LHC is corrupt

MAJ :29/04/20133
Version : 2.0 (XA5/XA6x)
Adding “EdgeSight Agent” section, this section is disable by default. To enable this section modify $Check_EdgeSightAgentVer variable to TRUE in XenApp_CheckXAx.ps1 file.

MAJ : 22/12/2012
Version : 2.0 (XA5/XA6x)
Add “Split-Path -Parent $MyInvocation.MyCommand.Path” for Check directory script run
Modify path function file “. \\your share\XenApp_Check\Ctx_Functions.ps1” by “. $Path’Ctx_FunctionsXA6.ps1′ ”
Add create backup folder if not exist on $Path
Add check WMI error on Foreach ($Servers in $Servers) for reduce time execution XenApp_Check if WMI fail

MAJ : 25/11/2012
Add Domain in General Détail section
Add Licence server TS/RDS in General Détail section
Adding “Server(s) type” section (physical, vm, xen or hyperV
This update is just for XenApp_Check XA6x, Xa5 version will soon be updated


MAJ : 05/09/2012
Adding “Cmdlet Execution Time” section, this section is disable by default. To enable this section modify $Check_CmdletExecution Time variable to TRUE in XenApp_CheckXAx.ps1 file.

Adding “Uptime Servers” section, by default the uptime value is ≥ 30. Its possible to change this value in the function Uptime (Ctx_FunctionsXA6.ps1 file), modify “30” value by your value.

Table bug fix

MAJ : 03/08/2012
Compatibility on XenApp 6.5 farm  ok.
Adding Farm version in XenApp_CheckXA6 (testing on XA 6.5)

MAJ : 19/03/2012
XenApp_CheckXA6 ver 1.0
Adding a XenApp 6 version.
The code is functional but is not optimized yet ;) .
Operation remains identical to XenApp_check for XA5,  with the difference which should be configured the policy mode via rows 58 and 64 of the XenApp_CheckXA6.ps1 script.

MAJ : 21/10/2011
Version 1.2
 Adding possibility not show some checks in the report:

Adding variable $AppNameExclude for exclude Application Name.

MAJ : 07/06/2011
Version 1.1
Adding counter for each section

MAJ : 13/05/2011
Version 1.02
Adding variable $AppFolderExclude and $ServFolderExclude for exclude Application folder and Server folder

MAJ : 07/05/2011
Version 1.01
Adding “Server(s) Off line” section

In order to know the XenApp farm, we implemented a powershell script (XenApp_Check.ps1) , this will provide information to get a precise idea of the current state.

XenApp_Check generated an HTML file, and send a report by mail (htlm), to be able to be informed  wherever you are.

XenApp_Check (same as XenApp_InfoFarm) is inspired from the graph part of vcheck from the Vmware community.

XenApp_Check will bring a serie of information to give  a summary fo the XenApp farm , along with a serie of check outputs (detailed below in this post), this provides an instant status of the XenApp farm (very convenient in the morning, when the ‘admins’ arrive for instance, or if you have to work on an XenApp farm that you have never monitored previously 🙂 ).

XenApp_Check was tested on windows 2003 server Fr sp2 and Xen App5 fr with R01,R03 and R06, XenApp_CheckXA6 ​​has been tested on servers 2008 R2 sp1 and XenApp 6 R01 Farms.

Information part :

  • Farm name
  • Datastore type
  • Datastore server
  • Licence server name and port
  • Number of servers
  • Number of applications
  • Number of zones
  • Number of load evaluator
  • Number of administrators

Check part :

  • Dschek
  • Disable policy
  • Test presence of the event 4033 on the members servers of the XenApp farm (in order to be able to visualise the elections of the ZDC
  • Test the principals servers XenApp (the service spooler as well) on the members servers of the farm XenApp
  • Test the disk space remaining on the servers member of the XenApp farm ( if the space disk is below 1.7 Go, we consider it as an alert to escalate)
  • Test if the open session on the members of the server is not disable
  • Test if the member servers of the farm XenApp belong to a specific Load evaluator ( in our case the Load evaluator is named “maintenance” and allow to exit a server from our production via  the scheduled task).
  • Test if one application has at least two servers to be pusblished
  • Test if one application is disable


Prerequire XenApp_Check :

  • Powershell V2
  • Citrix XenApp Command CTP3
  • Modify the row 24 in the file XenApp_Check.ps1  in order to indicate the place where the file Ctx_Functions.ps1 is located
  • Modify the rows 27,29 et 31 in the file XenApp_Check.ps1 for the part email send  Configure « # Set the SMTP Server address”  in XenApp_Check.ps1  file to send email
  • Modify the rows 41 et 43 in the file  XenApp_Check.ps1 to precise where the html and their back up will be save/archive.

The execution of XenApp_Check on a farm of  304 servers, 484 applications, 6 zones, 10 Load Evaluators and 10 Policies takes around 45 mn 30 mn.

Any suggestions and feedback will be welcome 😉 .

XenApp_Check (XenApp 5)

XenApp_CheckXA5.rar

 

 

XenApp_CheckXA6 (XenApp 6.x)

XenApp_CheckXA6.rar

Post to Twitter

XenApp_Check

MAJ :03/12/2014
Version : 2.6 (XA6x)

Le check du nombre de serveur(s) publié(s) au sein d’une application comprend désormais les Worker Groups (section “Server in Application(s)”)

XenAppcheck_26

 

Afin de connaitre l’état de nos fermes XenApp, nous avons mis en place un script powershell (XenApp_Check.ps1) afin que ce dernier nous remonte un ensemble d’informations permettant de se faire une idée précise de l’état de nos fermes XenApp.

XenApp_Check va générer un fichier .htm et procéder à un envoi de mail du rapport (format .html) afin que vous puissiez être informé où que vous soyez.

XenApp_Check (tout comme XenApp_InfoFarm) est très fortement inspiré pour la partie graphique du script vcheck de la communauté Vmware.

XenApp_Check va remonter une série d’informations permettant d’avoir une synthèse de la ferme XenApp accompagnée du résultat d’une série de checks (détaillés plus bas dans ce billet) permettant d’avoir un instantané de l’état de la ferme XenApp (très pratique le matin quand les admins arrivent par exemple, ou si vous devez intervenir sur une ferme XenApp que vous n’avez jamais administré 🙂 ).

XenApp_Check a été testé sur des serveurs Windows 2003 Fr sp2 et des fermes XenApp 5 fr en R01,R03 et R06, XenApp_CheckXA6 a été testé sur des serveurs 2008 R2 sp1 et des fermes en XenApp 6 R01.

Partie information :

  • Nom de la ferme
  • Type de datastore
  • Serveur licence XenApp et son port
  • Nombre d’application(s) de la ferme
  • Nombre de serveur(s) de la ferme
  • Nombre de stratégie(s) de la ferme
  • Nombre de calculateur(s) de charge de la ferme
  • Nombre d’administrateur(s)

Continue reading “XenApp_Check”

Post to Twitter

PowerShell et .Net 4.0

Si vous souhaitez installer un .Net Framework 4.0 sur un serveur sur lequel vous utilisez PowerShell avec des appels en .Net (dans notre cas System.ServiceProcess.ServiceController sur un serveur en 2003 sp2 Fr) alors il vous faudra rajouter la clé de registre OnlyUseLatestCLR (qui permet d’utiliser la dernier version .Net) sur votre serveur.

Une fois la clé OnlyUseLatestCLR rajoutée, lancer votre console PowerShell et tester un script faisant appel à du .Net ou lancer la commande “ [Environment]::Version.ToString() ” , puis vérifier que le résultat est bien 4.0.30319.1.

Pour rajouter la clé OnlyUseLatestCLR copié le texte ci-dessous dans un fichier .reg puis double cliquer sur votre fichier .reg (pas besoin de rebooter le serveur)




32 Bits


Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework]
"OnlyUseLatestCLR"=dword:00000001



  


64 Bits

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework]
"OnlyUseLatestCLR"=dword:00000001



  Attention, cette modification affecte toutes les applications utilisant

le .Net sur votre serveur.

Post to Twitter

GET-XAServerConfiguration = effet de bord

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.

Post to Twitter

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

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