XenApp – Page 6

XenApp_Gpupdate

———————–
MAJ : 28/06/2015
Version : 1.1
———————–

Ajout de la possibilité d’afficher la liste complète des serveurs membres de la ferme (via le bouton “Servers”)
Ajout de la possibilité de rechercher un serveur spécifique (via la coche “Search server”)
Retour du statut de la commande Gpupdate /force (indique si le process a bien été lancé sur le serveur et si ce dernier est bien fermé.), avec la durée d’exécution (duration) par serveur
Correction de bugs mineurs

Tout est dans le titre 🙂 , via XenApp_Gpupdate vous avez désormais la possibilité de faire (en remote) des “gpupdate /force” sur des serveurs membres d’un silo applicatif au sein d’une ferme XenApp 6.5.

XenApp_Gpupdate (comme XenApp_Usr) est un script Powershell réalisé pour la partie GUI avec Powershell Studio de Sapien.

Le “gpupdate /force” est fait via un “Invoke-WmiMethod” (il faut donc que le port TCP 135 soit ouvert entre le serveur exécutant XenApp_Gpupdate et les serveurs XenApp des divers silos de la ferme courante, avant de lancer le GpUpdate un socket tcp est envoyé afin de vérifier que le port 135 est bien ouvert sur le ou les serveurs du silo choisis.

Le fonctionnement de XenApp_Gpupdate est simple, il suffit d’afficher la liste des silos (dossiers serveurs) ou la liste des applications via les boutons Applications ou Servers Silo (il est aussi possible de faire une recherche sur un silo ou une application), puis de sélectionner le silo (ou l’application) souhaité. Une fois le dossier ou l’application sélectionné(e) la liste des serveurs s’affichera sur la partie droite (lors de la première sélection un temps d’attente est à prévoir), une fois la liste des serveurs affichés vous pouvez lancer un gpupdate /force sur un ou plusieurs serveurs.

C’est une V1 n’hésitez pas à nous faire part de vos retours (suggestions, critiques etc… )

Nous travaillons actuellement sur le retour des “gpupdate /force” afin de déterminer si ces derniers ont bien été réalisés sur le ou les serveurs sélectionnés.

XenApp_Gpupdate.rar

Template Zabbix XenApp 6.5

Cela faisait quelque temps que nous souhaitions mettre en place un template Zabbix dédié XenApp 6.5 (pas de monitoring de type ZDC/XML broker ou Webi, ça fera l’objet d’un prochain billet 😉 ), au passage ce template a été réalisé sous Zabbix 2.4.

Afin que ce template XenApp 6.5 puisse être le plus compatible tout langage, nous avons utilisé les “ID” des compteurs perfmon (ce que permet facilement Zabbix, concernant les compteurs perfmon propre à XenApp ils ne sont pas concernés car nous avons constaté qu’entre un 2008 Fr et un 2008 Us les “ID” ne correspondaient pas, mais comme on est sympa on vous a mis dans le champ description des items XenApp la version perfmon US).

Le template comprend 30 items (certains items sont liés afin de permettre des valeurs calculées), 21 trigers, un screen avec cinq graphiques (afin de pouvoir rapidement lors d’une recherche sur un host de pouvoir visualiser graphiquement.

Bien sur ces items correspondent à un monitoring et une supervision globale (si vous avez d’autres items à rajouter n’hésitez pas à les partager)

Le template comprend cinq graphiques et un screen (le screen reprenant les cinq graphiques afin de permettre un affichage rapide des graphiques).

Cpu load
Disk usage
Load server
Memory usage
Total Session (moins les deux connections des listeners RDP/ICA)

Ok notre labs est par hyper sollicité 🙂

zbx_template_XenApp_65.xml

La page des templates Zabbix de zabbix.org est ici (elle comprend notamment un template XenApp regroupant les parties Web Interface, ZDC etc..).
La page des templates officiels de zabbix.com est ici.

Problème d’incrementation de Session ID

Récemment on nous a remonté un problème d’incrémentation de Session Id au sein d’une ferme XenApp 6.5 R04 Us. L’effet de bord de ce problème d’incrémentation de Session Id était que les ID de session fermés (ces sessions n’étaient plus présentes sur les serveurs et aucun process n’était visible via un procmon ou autre) n’étaient jamais recyclés ce qui engendrait des Session ID avec des valeurs excessives.

SessionId_Count On constate bien dans l’App Center des Sessions Id élevés au vu du nombre de CCU sur ce silo 🙂

En lançant un process explorer nous avons constaté que seule les process des utilisateurs en cour étaient visibles (avec ceux du system) par contre en passant par un RamMap on constate des process csrss.exe “zombies” avec des Sessions ID associés (ce qui explique pourquoi les nouvelles sessions ne reprenaient pas d’ancien Session Id).

SessionId_Count1 Il ne reste plus qu’a trouver la cause 😉

En googlelant nous sommes rapidement tombés sur la KB75462 de chez McAfee décrivant exactement notre problématique.

Problem

CSRSS.exe sessions have open session objects even after the active user session is closed.
The session ID is not recycled when one user logs out and another person logs in. This can cause performance issues over time.
This issue is seen only on Windows Server 2008 with Service Pack 1.

Cause

McAfee has determined that this issue is a result of Microsoft Registry Filtering API not freeing 80 bytes of ObjectContexts. These 80 bytes include references to operating system resources (a process object that inherits a session object). The open session constitutes a resource leak that has a disproportionate impact on the operating system. If user sessions are spawned and terminated in excess, it causes in an equally large number of sessions that are not closed. This number increases until it impacts the operating system.As part of its Access Protection feature, VSE 8.8 must use the Registry Filtering API to protect the registry. When the Access Protection feature is enabled, bad behavior is exposed in Microsoft Registry Filtering API.

La KB75462 préconise la mise à jour du VSE en 8.8 patch 4, le passage du VSE en 8.8 patch 4 a bien corrigé le problème dans notre cas.

Mise à jour de XenApp_Check (XenApp 6.x) : 2.6

XenApp_Check pour XA 6 passe en 2.6, dans cette mise à jour nous avons modifié le check du nombre de serveur(s) publié(s) au sein d’une application afin que ce dernier prenne en compte les Groupes de tâches (Worker Groups).

Toutes les applications n’ayant qu’un seul serveur de publié en direct ou via les Worker Groups seront regroupées dans la section (section « Server in Application(s)).

Plus d’excuse pour les publications via les Worker Groups .

Le billet concernant XenApp_Check est ici .

XenApp_CheckXA6 2.6 (XenApp 6.x)

XenApp_CheckXA6.rar

XenApp_Usr

————————————————————————————————————
MAJ : 23/03/2015
V1.4

Rajout du refresh des sessions lors d’un logoff
La progressBar change de couleur en fonction de la charge du serveur hébergeant la session (vert de 0 à 5999, orange de 6000 à 8499 et rouge à partir de 8500)
Le champ username accepte la validation via la touche Entrée (Enter)
Refresh des process lorsqu’un process est tué via le bouton Stop
Correction de divers bug mineurs

————————————————————————————————————

MAJ : 22/12/2014
V1.3

Correction de bugs mineurs
Ajout de la section “Gpo Applied”
Possibilité d’exporter la Gpo sélectionnée au format HTML (il faut comme pré-requis que le Module GroupPolicy soit installé sur même le serveur que XenApp_Usr)
Possibilité d’exporter toutes informations de la session courante dans un fichier texte

————————————————————————————————————

C’est quoi XenApp_Usr ? 🙂

C’est un script PowerShell que nous avons mis en place et qui permet via une GUI de retrouver la ou les session(s) d’un utilisateur au sein d’une ferme XenApp.

Un fois la ou les sessions retrouvée(s), il suffit de sélectionner une session afin que les informations ci-dessous s’affichent dans la GUI :

Nom et version de la ferme XenApp
Application publiée
Serveur sur lequel la session est connectée
Etat de la session
Version du client ICA
Type de client
Nom du client
IP du client
Date et heure de la connexion
Imprimantes de la session
Processus lancés dans la session
Afficher la bande passante de la session ICA
Afficher la latence de la session ICA

A cela nous avons ajouté la possibilité d’effectuer les actions ci-dessous :

Fermer la session
Lancer un remote assistance sur la session
Stopper un process de la session

Ok la GUI fait un peu année 90 🙂

XenApp_Usr a été validé sur des fermes XenApp 6.5 R01, R03 et R04 (us et fr), la consommation mémoire est d’environ 60 Mo ( 🙁 faudra qu’on regarde pour diminuer ça).

Vos remarques et suggestions sont les bienvenues (au passage nous avons volontairement éviter les Splash Screen et Progress Bar).

Pour l’instant (et vu que le code n’est pas encore présentable) on ne livre que le ps1 compilé en binaire, la version ps1 arrive asap .

Au passage la GUI a été réalisée avec Powershell Studio de Sapien.

XenApp_Usr.rar

———————————————————
MAJ : 24/11/2014
V1.1
Correction de bugs mineurs
Ajout de la charge serveur (Load server)
———————————————————

Problème de reconnexion sur une application limitée à une instance

Au sein d’une ferme XenApp 6.5 R03 US, nous avions des utilisateurs qui ne pouvaient plus se connecter sur une application limitée à une instance par utilisateur.

En regardant les sessions des utilisateurs rencontrant ce type de problème nous avons constaté que les sessions étaient actives, en effet les sessions déconnectées passaient en active après un délai de 30 mn, les 30 mn correspondant à la “fin d’une session déconnectée” dans une GPO du silo applicatif.

Dans notre cas les sessions n’étaient pas fermées mais repassaient en active du fait que le process “splwow64.exe” (permet l’impression à partir d’application 32 bits sur des pilotes 64 bits) ne se fermait pas correctement (merci procmon, mais on aurait pu faire plus simple via un gestionnaire de tâche 🙂 ).

Un google plus loin nous tombons sur la CTX138940 qui dans le point 11 indique que dans pareil cas il faut créer (sauf si vous jouez avec la persistance de session) la clé de registre (REG_DWORD) “AllowLogoffSysModules” et lui donnez la valeur 1.

Simuler une latence dans une session ICA

Pour visualiser une latence dans une session ICA on a EdgeSight et pour les plus pauvres d’entre nous perfmon (et aussi HDX Monitor) avec les compteurs “Latence – Dernière enregistrée”, “Latence – écart de session”, “Latence – moyenne de session”, mais que donnent les valeurs de latence remontées visuellement dans une application publiée ?

qui a dit que ça ramait ?

TMnetsim (ça fait deux ans qu’on s’en sert et on fait le billet seulement maintenant 🙁 ) permet de simuler une latence (en jouant le rôle de proxy) pour se connecter à une application publiée (par exemple), outre que TMnetsim est gratuit, il est portable et très simple d’utilisation.

Télécharger TMnetsim et déziper dans un dossier son contenu
Créer un fichier ica custom permettant de lancer une application publiée (avec Citrix Quick Launch par exemple)
Modifier le fichier ica afin de faire pointer la partie adresse sur le serveur hébergeant TMnetsim et ajouter un port TCP comme par exemple 1495

Lancer TMnetsim.exe et renseigner le l’IP du serveur XenApp et les ports Inbound (dans notre cas 1495) et le port Outbound (1494), rentrez la latence que vous souhaitez dans le champ Delay Base (MS) puis cliquez sur le bouton Start (vous pouvez aussi choissir le type de Delay).

Double cliquez sur le fichier ICA précédemment crée et modifié

On constate bien que la connection ICA passe par TMnetsim

Il ne vous reste plus qu’a constater par vous même les effets de la latence au sein de votre application publiée 😉 .

Quelques liens sur TMnetsim :

http://www.tmurgent.com/appv/index.php/87-tools/performance-tools/177-tmnetsim-quick-and-easy-network-simulation-tool
https://4sysops.com/archives/free-tmnetsim-network-simulator-simulate-network-latency-and-packet-loss/

Publication du Remote Assistance

Comme vous le savez, en XenApp 6.5 le shadowing sur des sessions multi-écran cause problème (voir CTX125693), l’utilisation de MSRA (Microsoft Remote Assistance) permet de palier cette problématique (la seule contrainte est de connaitre à l’avance le nom du serveur hébergeant la session que l’on souhaite observer, ce qui est peu pratique à l’usage).

Au départ on souhaitait mettre en place une GUI permettant de faire du MSRA sans avoir à chercher où se trouve la session de l’utilisateur, en googlelant nous sommes tombés sur l’excellent script de nos collègues de DEPTIVE qui avait déjà (depuis 2012) mis en place un PowerShell permettant de rechercher un session ICA/RDP (le tout via une GUI) au sein d’une ferme et de lancer sur cette session un MSRA.

Nous avons juste rajouté/modifié les éléments ci-dessous afin qu’ils correspondent un peu plus à notre besoin :

Teste si le snapin Citrix est bien chargé
Si le champ username est vide le script n’affiche plus toutes les sessions ica/rdp ouvertes dans la ferme mais une erreur indiquant qu’il faut renseigner le champ username
Le bouton Connect est désactivé tant qu’une session n’est pas trouvée dans la ferme XenApp en cours
Ajout de la colonne application publiée (afin de bien cibler la session de l’utilisateur)
Ajout d’un compteur comptabilisant le nombre de sessions trouvées pour un utilisateur
Ajout du nom de la ferme en cours

Sur des grandes ferme avec what mille CCU on evite l’affichage de toutes les sessions de la ferme si on clique sur le bouton Search et que le champ username est vide

Rien de transcandant dans nos modifications mais c’est pratique 🙂

Si vous publiez le script sur un serveur avant l’agent EdgeSight installé alors n’oubliez pas d’exclure le process “msra.exe” dans l’agent EdgeSight (voir CTX131271).

Si vous souhaitez le reg pour l’importation c’est juste en dessous

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\rskcore]

“UviProcessList”=”rotatelogs.exe;msra.exe”

Pour plus d’information sur le Remote Assistance (et pour l’activer) c’est par ici.

Au passage pour ajouter le Remote Assistance sur un serveur en PowerShell :

import-module servermanager;get-windowsfeature "Remote-Assistance"|?{$_.installed -eq $False}|%{Add-WindowsFeature "Remote-Assistance"}

Quelques liens sur la configuration de Remote Assistance :

RemoteAssistance.ps1

Mise à jour de XenApp_Check : 2.5

MAJ :19/09/2014

La version XA5 passe en 2.5

Déjà plus d’un an depuis la dernière mise à jour de XenApp_Check (436 jours exactement), on ne vous fera pas le coup du “comme le temps passe vite” mais pas loin 😉 .

Dans cette mise à jour nous avons ajouté une section “UPM version” qui permet de vérifier si les agents UPM sont UpToDate (par rapport à la version que vous avez validée ) au sein de vos fermes et une section “Section statut” affichant les sections désactivées”.

La version UPM de référence dans XenApp_Check est la “5.0.0.111” (modifiable via la variable $UPMVer)
Nous avons aussi corrigé divers bugs mineurs et amélioré le temps d’exécution du script (réduction d’environ 15 % du temps d’exécution) en changeant le check WMI (on passe par un socket.TcpClient sur le port 135).

Seule la version XA6 passe en version 2.5, la version XA5 sera très prochainement mise à jour.

Désormais les fichiers XenApp_CheckXA6.ps1 et le fichier Ctx_FunctionXa6.ps1 sont regroupés au sein d’un fichier rar.

Comme d’habitude vos remarques et suggestions sont les bienvenues.

Merci pour les DL 😉

Le billet sur XenApp_Check

Recreation du compte de service Ctx_SmaUser

Ce billet juste pour mettre à dispo CtxSma20.exe (vu qu’on a lutté pour le retrouver 😉 ). En effet récemment nous avons dû recréer dans l’urgence le compte de service Ctx_SmaUser (sur un serveur membre d’une bonne vielle PS 4.0 R03 Fr) et bien sûr aucun moyen de mettre la main sur CtxSma20.exe (si vous avez un link up on le rajoutera dans ce billet), du coup direction la CTX106393 qui est la seconde solution pour récréer le Ctx_SmaUser (à la mano), son seul inconvénient est d’être un poil plus long ;).

A la question, “mais vous n’aviez pas sur vous un SSD rempli des tools indispensables” ? He bien non… pas ce jour là 🙂

Download_2
CtxSma20.exe