Scripts Archive

4

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

0

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.

Tags: ,
5

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

 

0

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

 

0

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

15

Script (XenApp_Check) : Etat de santé ferme XenApp

MAJ : 19/03/2012
XenApp_CheckXA6 ver 1.0
Ajout d’une version compatible XenApp 6.
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

 

MAJ : 21/10/2011
Version 1.2
Ajout de la possibilité de ne pas afficher dans la rapport certains checks :

Ajout de la possibilité d’exclure des applications (via la variable $AppNameExclude).

 

MAJ : 07/06/2011
Version 1.1
Ajouts des compteurs sur chaque Sections

MAJ : 13/05/2011
Version 1.02
Ajout de la possibilité d’exclure des dossiers (folderPath) serveur et application (exemple : QUALIF) via les variables $AppFolderExclude and $ServFolderExclude

MAJ : 07/05/2011
Version 1.01
Ajout de la section « Server(s) Off Line »

——

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)



Read the rest of this entry »

6

Envoi par mail d’un rapport DsCheck

Le script ci-dessous va vous permettre de recevoir par mail le résultat d’une commande DSCHECK au sein de votre ferme.

Il ne reste plus qu’à mettre le script dans une tâche planifiée ;) .

#DsCheck report V1
$farm = Get-XAFarmConfiguration
$DsCheckReport =  &'C:\Program Files\Citrix\System32\dscheck.exe'

Foreach ($line in $DsCheckReport)
{
if($line -eq "") {} else {$DscheckLine += $line+"`n"}
}

$BodyReport += $DscheckLine
#Send mail "Report DsCheck"
$emailFrom = "DsCheckReport@yourDomain.fr"
$emailTo = "Your Adresse Email"
$subject = "DsCheck Report : "+$Farm
$body = $BodyReport
$smtpServer = "Your SMTP Server"
$smtp = new-object Net.Mail.SmtpClient($smtpServer)
$smtp.Send($emailFrom, $emailTo, $subject, $body)


Le rapport reçu par mail

Tags:
0

Activer/Désactiver l’ouverture de session TS par le registre

Si vous devez activer/désactiver l’ouverture de session Terminal Server sur un serveur distant et que vous ne souhaitez pas passer par TSLOGINS (ou autres), une solution est de le faire via le registre (modification de la valeur WinStationsDisable) .

La valeur WinStationsDisable se trouve dans :
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon]
« WinStationsDisabled »= »0″
0 = Logon On
1 = Logon Off

Connectez vous au registre du serveur distant (faite un regedit puis allez dans le menu « Fichier » et choisissez   »Connexion au Registre réseau ») et modifiez la valeur WinStationsDisable.

Si la modification via le registre ne vous tente pas trop, vous pouvez le faire en powershell :

$Hostname = "Your Server"
$Registry = [Microsoft.Win32.RegistryKey]::OpenRemoteBaseKey('LocalMachine', $Hostname)
$WinStationsDisabled = $Registry.OpenSubKey("SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Winlogon",$true)
$WinStationsDisabled.SetValue('WinStationsDisabled','0','String')
Write-Host $Hostname " WinStationsDisabled " $WinStationsDisabled.GetValue('WinStationsDisabled')

2

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

0

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)