Ajout de la section Server(s) Load, cette section regroupe les serveurs dont la charge est supérieure à 9998.
Vous pouvez désactiver cette section via le script XenApp_Check.ps1 en mettant à FALSE la variable $Check_Ctx_SrvLoad.
Les serveurs dont le calculateur de charge correspond à celui configuré dans la variable $LoadEval_Check(calculateur de charge de maintenance configuré via le script XenApp_Check.ps1) sont exclus de cette section.
On vous prévient là on est plus dans le bloc note que dans le billet, mais ça évitera une prochaine fois de chercher (et moumouter) pendant trente minutes avant de comprendre pourquoi il manquait le menu “Se connecter au serveur” dans un AppCenter.
Vérifier que sur votre serveur il y a bien un Online Plug-in d’installé (une fois ce dernier installé ça va mieux 🙂 )
Pour diverses raisons vous pouvez avoir besoin de supprimer toutes les applications publiées d’un serveur (voir notre billet sur ce sujet), cependant vous ne souhaitez peut-être pas laisser ce serveur “ad vitam æternam” sans ses applications publiées.
Nous avons donc modifié le script de notre précédent billet afin de sauvegarder au préalable toutes les applications du serveur (avant la suppression), ainsi que la possibilité d’ajouter les applications précédemment supprimées du serveur.
Les applications sont sauvegardées dans un répertoire backup (le choix du backup vs juste le nom des applis dans un fichier texte tient juste dans le “au cas ou”)
Reste plus qu’à 🙂
Apps_DepublishRepublish.ps1
Récemment dans plusieurs fermes XenApp 6.5 R01 nous avons eu besoin d’appliquer un calculateur de charge (Load Evaluator) sur tous les serveurs dont le calculateur de charge est “Défaut” (et on en avait un max 🙂 ) .
Au passage nous en profitons pour appliquer un calculateur de charge en fonction du type de serveur (Virtuel ou physique).
Dans notre cas les calculateurs de charges sont paramétrés via des Groupes de taches (Worker Groups), un pour les serveurs virtuels et un pour les serveurs physiques.
Comme d’hab ça passe par un script Powershell.
Pré-requis :
– Deux calculateurs de charge configurés en fonction du type de serveur (Virtuel ou Physique)
– Deux stratégies ordinateur, chacune pointant sur un des calculateurs de charge.
– Deux groupes de taches permettant le filtrage des stratégies
Xa6_AttribLE.ps1
Xa5_AttribLE.ps1
Pour XenApp 5 (le script reste le même sans les parties Worker Groups et GPupdate)
——————
15/05/2013
——————
Le script utilise désormais le Token-Groups (merci Pierre pour l’info 😉 ) pour la recherche de groupes d’un utilisateur.
L’avantage du Token-Groups est que nous n’avons plus besoin d’utiliser des recherches récursives, l’attribut (qui est un attribut calculé) contient la liste de tous les SID des groupes (ainsi que les groupes imbriqués) ce qui améliore grandement les temps de recherche :).
Le script affiche la liste des applications publiées pour un utilisateur (un fichier texte contenant la liste des applications publiée pour un utilisateur est également disponible dans le répertoire racine du script).
search_apps_users.ps1
——————
27/03/2013
——————
Récemment on nous a demandé de sortir la liste de toutes les applications publiées pour un utilisateur (dans une ferme en XenApp 6.5 R01).
Donc direction PowerShell 🙂
Nous avons mis en place un script permettant d’afficher la liste de toutes les applications publiées d’un utilisateur dans une ferme (que l’application soit publiée en direct ou via un groupe, concernant le groupe la recherche dans le groupe est récurisve).
Concernant la recherche récursive cette dernière se fait en DotNet (.Net 3.5 sp1 requis dans notre cas).
Au départ nous étions partis avec la cmdlet Get-ADGroupMember mais nous avons vite rencontré la limitation du MaxGroupOrMemberEntries (à 5000, bien que cette valeur soit modifiable via le fichier Microsoft.ActiveDirectory.WebServices.exe.config sur les DC). Il est aussi possible de faire la recherche en ADSI ou via les cmdlet Quest (mais on avait pas envie 🙂 ).
Avant d’exécuter le script modifier en ligne 19 la valeur de la variable $DC par un de vos DC (un DC prévu pour l’exécution de script par exemple).
Une fois le script passé, nous avons constaté en prod (bien qu’on s’en doutait au vu des nombreuses imbrications de groupes) que certaines applications étaient publiées plusieurs fois pour un même utilisateur.
Merci à VmDude pour le trick du bind sur un DC spécifique en DotNet .
On constate que certaines applications sont publiées directement sur le compte du user au passage
DisplayAllAppsForSpecificUser.ps1
Ajout de la section Citrix HotFix missing, permettant de vérifier la présence d’un HotFix Citrix sur chaque serveur membre de la ferme XenApp (XA5/6x).
Par défaut cette section est activée, vous pouvez la désactiver via le fichier XenApp_Check.ps1 en mettant à FALSE la variable $Check_Ctx_HotFix.
Si vous souhaitez changer version du HotFix Citrix recherché (la modification se fait dans le fichier XenApp_CheckXAx.ps1) :
– Pour XenApp6.0/6.5 changer la valeur de la variable $Ctx_HotFixXA60 (pour XenApp 6.0) ou $Ctx_HotFixXA65 (pour XenApp 6.5).
– Pour XenApp 5 changer les valeur de la variable $Ctx_HotFixXA5_32 (pour les OS 32bits) et/ou $Ctx_HotFixXA5_64 (pour les OS 64 bits).
Reste plus qu’à leur installer le HotFix validé par vos soins
Si le message LHC error or CtxHotFix not Installed apparait dans la colonne Citrix HotFix, soit le HotFix n’est pas installé soit la LHC est corrompu
Si vous rencontrez des problèmes pour sortir un serveur d’une ferme XenApp 6.5, il existe un moyen simple et rapide de forcer sa suppression (le trick a été trouvé sur le forum Citrix, merci à Christoph Sinabell 😉 ).
Allez sur le serveur récalcitrant, et modifiez la valeur “Joined” (dans HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\IMA\Status) à 0 (par defaut la valeur est à 1)
Il ne reste plus qu’à lancer un “C:\Program Files (x86)\Citrix\XenApp\ServerConfig\XenAppConfigConsole.exe /ExecutionMode:Leave” et le serveur est supprimé de votre ferme (testé sur un serveur XA65 US sp R01 😉 ).
Sur un serveur XenApp 6.5 R01 US nous avions un problème d’application de Calculateur de charge (via les policy Citrix de l’Appcenter), en regardant dans les logs du serveur nous avons constaté la présence de l’event ID 1091.
Log Name: System
Source: Microsoft-Windows-GroupPolicy
Event ID: 1091
Level: Warning
Description:
Windows could not record the Resultant Set of Policy (RSoP) information for the Group Policy extension <Citrix Group Policy>. Group Policy settings successfully applied to the computer or user; however, management tools may not report accurately.
Un rsop sur le serveur en question
La CTX130116 traite ce type de problème, en effet dans notre cas les fichiers Rsop.gpf et Rollback.gpf avaient bien une taille de 0 Ko.
Une fois les fichiers Rsop.gpf et Rollback.gpf (ainsi que les répertoires contenus dans %PROGRAMDATA%\Citrix\GroupPolicy) supprimés (associé à un gpupdate /force) l’application des policy Citrix s’est faite sans problème.
Afin de vérifier que nous n’avons pas d’autres serveurs rencontrant le même problème d’application de policy Citrix, nous avons mis en place un script PowerShell listant les serveurs XenApp ayant des fichiers Rsop.gpf et Rollback.gpf avec une taille de 0 Ko.
Lui il est bon pour un delete de fichier Rsop.gpf et Rollback.gpf 🙂
CheckGpfFileCtxPolicy.ps1
Dans ce billet et juste pour le fun, un script PowerShell permettant de “grapher” les CCU d’une application publiée.
On vous l’a dit cacti on aime 😉
Tester sur une Ferme en XA 6.5 R01 Us, via une tâche planifiée et à la mano.
Bien que le résultat soit old school, c’est propre et ne nécessite aucune installation (hormis le Chart Controls for Microsoft .NET Framework 3.5 🙂 .
Pré-requis :
XenApp_Chart.ps1
La partie graphique du script est fortement inspirée du billet “Tutorial: PowerShell and Microsoft Chart Controls (or How To Spice Up Your Reports)” de ByteCookie.
