EdgeSight

Le EdgeSight du pauvre

———————–
MAJ 05/04/2016
———————–
Ajout du “ClientVersion” afin d’obtenir la version du receiver de chaque utilisateur

———————-

Suite à des BSOD provoqués par nos agents EdgeSight, nous avons dû en urgence désinstaller les clients EdgeSight d’un silo d’une ferme XenApp 6.5 R03 us (les dumps sont en cours d’analyse et pour l’instant le coupable est rskcore.sys).

Nous avons certes rétabli le service, mais nous avons perdu des informations utiles comme “qui lance les applications publiées” (informations disponibles en mode avancé) 🙁 .

Du coup nous avons mis en place un script PowerShell qui récupère les applications publiées lancées au sein de notre ferme, puis écrit tout ça dans un fichier à plat (on va rapidement passer ça dans une base sql).

Et voila ce que ça donne sous excel (on vous l’avais dit c’est le EdgeSight du pauvre 🙂 mais ça rend le service

Comment fonctionne le script ? Tout d’abord nous ne souhaitions pas installer d’agent sur chaque serveur membre de la ferme ou passer par un login script (bien que GETPUBAPP de chez Ctrl-Alt-Del aurait parfaitement fait l’affaire), une solution est donc d’interroger le ZDC via un serveur d’administration par exemple (et là on entend certains crier HOULA).

Le script en lui-même est on ne peut plus simple, en gros on fait un “Get-Xasession|?{$_.LogOnTime -gt $Date3}” ($Date3 étant égal à l’heure du jour moins une minute) toutes les minutes et on ne récupère que les sessions ouvertes la dernière minute.

Concernant la mise en place du script, plusieurs solutions sont possibles comme une tache planifiée, un service ou bien un login script computer. Nous avons opté pour un service afin que ce dernier puisse se relancer en cas de d’arrêt du script.

Pour la création du service on passe par un bon vieux SC (au préalable nous avions compiler notre script via PowerGui, le binaire sera lancé via SRVAny avec un compte admin de la ferme XenApp ) :

SC CREATE “ServiceName” binPath= “YourPath” DisplayName= “DisplayName” start= auto

Un tableau dynamique plus loin 😉

UsrApp.ps1

—————–
06/08/2014
—————–
Le script crée désormais un fichier de log par mois (NomDeLaFerme_Année-Mois_UsrApp.txt)

Erreur Java suite à l’installation d’un agent EdgeSight

Sur un silo applicatif (XenApp 5 R06 2003 32 bits sp1 Us + JRE 1.6.0_14-b08, oui la JRE n’est pas UpToDate) nous avons rencontré l’erreur Java ci-dessous suite à l’installation d’un client EdgeSight (5.3.4136.3 ).

Error occurred during initialization of VM
Could not reserve enough space for object heap
Could not create the java virutal machine

Sauf que dans notre cas et c’est là que ça devient marrant, l’erreur intervenait uniquement en bureau publié (et en bureau RDP).

En regardant le batch lançant l’application on constate que la partie -Xmx est à 1024 Mo (-Xmx1024M ), si on descend le Xmx l’application se lance sans erreur mais cette option n’est pas envisageable dans notre cas (problème de support de l’éditeur 🙂 ).

Si vous souhaitez en savoir plus sur l’Xmx : Xmx to set the maximum heap memory size

Dans notre cas la modification de la valeur UviProcessList (rajout de java.exe et javaw.exe dans les exclusions) dans HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\rskcore permet logiquement de bypasser l’erreur “Error occurred during initialization of VM“.

Une GPP après, le problème subsistait :).

La correction est venu via l’upgrade de l’agent Edgesight 5.3.4136.3 en 5.34140.4.

Quelques liens traitant de l’erreur :
http://www.archy.net/citrix-edgesight-5-2-1-could-not-create-the-java-virtual-machine
http://support.citrix.com/article/CTX115868
https://forums.oracle.com/forums/thread.jspa?messageID=6438592

F5 et les accents sur une application publiée

Il y a quelques temps certains de nos utilisateurs rencontraient un message d’erreur (“This published application currently is not available – Try connecting again later“) lors du lancement d’une application via des Web Interface (5.4 us – Windows 2008 R2 sp1 us) positionnées derrière des F5.

En regardant le launch.ica on s’aperçoit que le nom de l’application comporte un Ã suivie d’un © en lieu et place d’un “é”, on comprend vite que le F5 réécrit le launch.ica et qu’il n’aime pas les é 🙂 .

Une fois le nom de l’application modifié (remplacement du é par un e) le launch.ica est correctement réécrit par le F5 et l’application se lance sans problème.

En attendant un correctif de chez F5, il vous faut supprimer les é dans le nom de vos applications 🙂 .

Les F5 en question étaient des 1600/3600 (BIG-IP 11.2.0 Build 2451.0 Hotfix HF1)

Erreur : The Citrix System Monitoring Agent cannot contact the Citrix End User Experience Monitor….

Le contexte : Plusieurs fermes (4.5 R06/5 R06 en 32/64 bits et XA6.0/6.5 R01 le tout en us), au sein de ces fermes des serveurs rencontraient l’erreur :

Event Source: Citrix System Monitoring Agent
Event ID: 109
Description: The Citrix System Monitoring Agent cannot contact the Citrix End User Experience Monitor. EUEM data will not be collected. Contact Citrix Support.

La cause vient du fait que les serveurs n’ont pas d’accès à internet alors que le service “Citrix End User Experiencing Monitoring” tente de se connecter à crl.microsoft.com afin de valider un certificat.

La CTX120846 permet de contourner ce problème en créant un fichier “SemsService.exe.config”sur chaque serveurs rencontrant le problème dans “c:\Program Files\ Citrix\ EUEM\Service\”.

Le contenu du fichier “SemsService.exe.config” :

<? xml version = “1.0” encoding = “utf-8”>
<configuration> <runtime>
<generatePublisherEvidence enabled=”false” />
</ runtime>
</ configuration>

Il existe aussi la solution GPO qui consiste à désactiver la mise à jour automatique des certificats racines 🙂 .

Mais car il y a un mais dans notre cas 😉 , l’activation de ce setting n’est pas possible dans l’immédiat, donc direction un script powershell qui va copier le fichier SemsService.exe.config sur l’ensemble des serveurs d’une ferme.

Le script EdgeSightCopySemsService_exe_config.ps1 check l’Os archicture de chaque serveur et test si le répertoire c:\Program Files\ Citrix\ EUEM\Service\ (ou c:\Program Files (x86)\ Citrix\ EUEM\Service\) existe, puis vérifie que le fichier “SemsService.exe.config” n’est pas déjà présent, s’il n’est pas présent il le copie sur le serveur.

Rentrer en ligne 6 dans le script le share où se trouve le fichier SemsService.exe.config dans votre infra.

EdgeSightCopySemsService_exe_config.ps1

En attendant de passer ça en GPO faute de mieux ça fera l’affaire 🙂 .

Pour en savoir un peu plus sur l’EUEM c’est par ici.

Edgesight : Event ID 1309 – Source ASP.NET 2.0.50727.0

Sur un serveur Edgesight 5.4 (2008 R2 sp1 Us) nous avons rencontré un nombre important d’event “1309” avec comme source “ASP.NET 2.0.50727.0”.

Log Name:      Application
Source:        ASP.NET 2.0.50727.0
Event ID:      1309
Task Category: Web Event
Level:         Warning
Description:
Event code: 3005
Event message: An unhandled exception has occurred.
Event ID: 1c67873e29fa45d6a65cd9d22b71ac12
Event sequence: 3396
Event occurrence: 438
Event detail code: 0

Après un google nous avions trouvé la ctx132116 qui dans notre cas n’a pas fonctionné (modification du fichier web.config), un thread (sur le forum Citrix) traitant de l’erreur 1309 nous a permis de résoudre cette erreur.

Allez dans le Gestionnaire de serveur, puis dans IIS, puis allez dans le site Edgesight (logiquement ce dernier est situé dans le Default Web site).

Cliquez sur Application Settings (paramètres d’application)
Cliquez sur Ajouter (dans la colonne Actions)

Ajoutez le paramètre aspnet:MaxHttpCollectionKeys (nous avons opté pour une valeur de 50000 au départ, puis nous avons rabaissé la valeur à 30000).

La ctx132116 explique comment attribuer une valeur au départ à aspnet:MaxHttpCollectionKeys puis conseille d’augmenter ou réduire cette valeur passer 24 H.

Script : recherche de version agent Edgesight

Récemment nous avons eu besoin d’extraire des listes de serveurs au sein de fermes XA6.5, n’ayant pas la version de l’agent EdgeSight de référence ainsi que les serveurs n’ayant pas d’agent EdgeSight installé.

Nous avons donc écrit un script powershell permettant de remonter ces informations dans un fichier htm.

Au préalable il faut renseigner la version de l’agent EdgeSight validé dans votre production ligne 11 du script.

Dans notre cas une 5.4.0.5107 que notre collègue Net2Sys affectionne 😉

11 serveurs n’ont pas d’agent et un n’est pas à jour.
C’est paradoxal mais on évite de passer par EdgeSight pour la version des agents 🙂

White paper : Logon Optimization

Citrix vient de mettre à jour son White paper “Logon Optimization”, à lire impérativement si vous souhaitez comprendre et optimiser vos logons (qui ne le voudrait pas 🙂 ) .

Un schéma que vous connaissez déjà 😉

Sympa ce screenshot Edgesight qui vous donnes la définition des divers abréviations contenu dans le tableau “détail de démarrage du serveur”

Ho le beau PLSD (temps de chargement du profil), reste plus qu’à…. 🙂

Impossibilité d’exécuter une tâche à distance sur un agent EdgeSight 5.4

Sur un serveur EdgeSight (EdgeSight 5.4 en Windows 2003 sp2 Fr) nous avions l’erreur ci-dessous lors de l’exécution manuelle des tâches à distance sur un agent :

Une erreur s’est produite lors de la connexion à la machine : Accès Refusé : vous n’avez pas la permission d’accéder à cette ressource.

La CTX111046 traite le problème en recommandant de modifier le valeur RemoteSecurity ou bien la valeur RemoteSecurityGroup (HKEY_LOCAL_MACHINE\Software\Citrix\System Monitoring\Agent\Core\4.00\), ces deux valeurs permettent de fixer le niveau de sécurité des accès à distance de l’agent.

Valeur RemoteSecurity avant modification

Une fois la valeur RemoteSecurity passé à 0, l’exécution de tâche fonctionne sans problème (bien sûr il est déconseiller de laisser la valeur RemoteSecurity à 0 dans un environnement de production) .

EdgeSight : problème d’inscription de serveur

Recensement nous avons rencontré un problème d’inscription de serveur (Serveur XenApp 6.5 fr avec un agent Edgesight 5.4) au sein d’un EdgesSight 5.4.

En effet le serveur refusait de s’inscrire dans Edgesight, aucune log côté serveur EdgeSight, idem sur le serveur XenApp récalcitrant (aucun event system et appli), le fichier SYS_EVENT_TXT.txt (C:\ProgramData\Citrix\System Monitoring\Data) ne donnant rien non plus, nous avons opter pour la solution bourrin ci-dessous.

Afin de pouvoir inscrire le serveur nous avons du réaliser les actions ci-dessous (c’est trash mais bon) :

arrêter les services “Serveur Firebird : CSMInstance” (FirebirdServerCSMInstance) et “Agent de surveillance système Citrix” (RSCorSvc)
Supprimer les fichiers EdgeSight.ini et RSDATR.FDB dans C:\ProgramData\Citrix\System Monitoring\Data
Relancez les services « Agent de surveillance système Citrix » et « FirebirdServerCSMInstance »

Quelques liens pratique sur le sujet :
http://support.citrix.com/article/CTX112209
http://support.citrix.com/article/CTX116547

EdgeSight : Exception générale de données utiles : Error calling es_alert_add_alert_param for instance

Récemment nous recevions des alertes de type “Exception générale de données utiles : Error calling es_alert_add_alert_param for instance…” provenant de notre serveur EdgeSight (5.4 sous Windows 2003 sp 2 + SQL 2005 sp2).

La CTX117433 détaille les tables de la base de données EdgeSight, nous apprenons que le fichier Edgesight_FG5.ndf comprend les tables suivantes :

FG5 alert : Stability data (errors, faults, hangs, Windows Event Log, hardware errors, and so on).
FG5 alert_param* : Values and strings specific to the Stability data in the alert table.
FG5 system_perf : System performance information including user time peak/total, privileged time, total processor time, data bytes per second, disk time, page faults, reset connections, and so on.
FG5 drive_space : Total and available space on agent device hard drives.

En regardant sur notre serveur EdgeSight (qui héberge sa prope base) nous remarquons que la taille du fichier EdgeSight_FG5.ndf (fichier de données secondaire) est importante (6 Go) pour une ferme xenapp 6 de 8 serveurs.

Nous avons pu constater que ce fichier peut atteindre facilement des dizaines de Go dans certains cas.

En bas de la CTX11433, on comprend mieux pourquoi la base prend autant de place 🙂 .

Effectivement en regardant de plus près côté SQL on s’aperçoit que la table alert se fait plaisir.

Vu que les events de sécurité sont très verbose, l’idéal est de ne pas tous remonter dans EdgeSight.

Depuis la version 5.4, la console EdgeSight (auparavant la version 5.3 ne permettait de le faireque via le registre sur les serveurs directement) permet de limiter le nombre d’events remontés dans EdgeSight.

Dans notre exemple nous sommes radical, reste à affiner cela en fonction de vos besoins

Sinon plus radical (si vous remontez les events par un syslog par exemple) serais de faire un “DELETE FROM alert” sur votre table alert (bon ok la c’est hyper radical 🙂 ).