ctxblog – Page 19

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)

Cacher des applications dans une Web Interface

Récemment nous souhaitions cacher des applications publiées d’un site Web Interface sur un pool de Web Interface 5.4 (us) dédiées, sans modifier le fichier WebInterface.conf (voir la CTX122133 qui au passage nous avait déjà rendu service 🙂 ).

L’idée était de le faire via le champ description des applications (comme la CTX123969 mais qui ne fonctionne qu’avec les sites XenApp Services) et de modifier le champs description d’une ou plusieurs applications publiées via un script powershell (tout en gardant l’ancienne description).

Nous somme tombés sur un post de Miguel Contreras sur le Citrix blog qui justement met en ligne un code à insérer dans le fichier global.asax.cs et qui correspond exactement à notre recherche.

Une fois le fichier global.asax.cs modifié il ne reste plus qu’à rajouter au début du champs description des applications un “@” (dans notre cas nous avions remplacé le @ par la chaîne =HIDE=).

Par contre ne pas perdre de vu que si vous cachez toutes les applications d’un dossier Web Interface, le dossier sera quand même visible dans la Web Interface 😉 .

global.asax.cs

App_Change_Description.ps1

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.

Bonne année 2013

Nous vous souhaitons une bonne et heureuse année 2013 (santé et plein de bons projets citrix 😉 ).

Mise à Jour de XenApp_Check : 2.0

La 2.0 est portée sur les deux versions de XenApp_Check (XA5/XA6x).

La 2.0 rajoute/modifie :

Récupération du répertoire d’exécution de XenApp_Check afin de renseigner la variable $Path
Modification du path function file . \\your share\XenApp_Check\Ctx_Functions.ps1 par . $Path’Ctx_FunctionsXA6.ps1
Création automatique du répertoire Backup (pouquoi on ne l’a pas fait avant 🙂 ).
Ajout d’un check Wmi afin d’éviter les Time out WMI sur les différents checks lorsque WMI n’est pas accessible (là pour le coup si vous avez des serveurs qui ont des problèmes WMI, la durée d’exécution de XenApp_check sera diminuée d’au moins 30 % ).

Test de Project Accelerator

Pour ceux qui ne connaissent pas Project Accelerator, ça se passe par ici (dans les grandes lignes Project Accelerator vous apporte une assistance dans la conception d’architecture de type “virtualisation de poste de travail” ).

Vous trouverez ci-dessous via des Screenshots, les étapes nous ayant permis de créer un projet.

Franchement pour une bêta c’est vraiment pas mal et en plus c’est gratuit 🙂 .

Problème d’affichage des HotFix dans l’Appcenter (XA 6.5)

Dans une de nos fermes XA6.5 R01 nous avons rencontré un problème d’affichage d’HotFix dans une console Appcenter. Bien que nous soyons plus orienté script pour remonter ce type d’infos, certains préféreront visualiser l’information en GUI (et il n’y a pas de raison que cela ne fonctionne pas en plus 😉 ).

C’est pas ici qu’on verra nos HotFix 🙁

La CTX132713 fournit un hotfix corrigeant ce problème d’affichage (le problème venant de la lecture de ferme XA6.5 comprenant un mixte de serveurs en mode “Controller” et “Session-host”.

Une fois le HotFix DSCXAMx650W002 installé les Hotfix remontent bien dans l’Appcenter (sauf si dans votre Appcenter vous remontez un mix de fermes XA 6.0/6.5 ).

Un petit rappel des rôles XA 6.5

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.

Mise à Jour de XenApp_Check : 1.6

Cela faisait longtemps que nous n’avions pas fait de mise à jour de XenApp_Check (05/09/2012), dans cette mise à jour nous avons rajouté des éléments demandés par certains d’entre vous (au passage merci à tous ceux qui nous proposent des idées d’upgrade 😉 ), XenApp_Check passe donc en 1.6.

Dans cette 1.6 nous avons rajouté le seveur TS/RDS (la valeur remonte depuis le seveur exécutant XenApp_Check, dans la prochaine version il est prévu que tous les serveurs soient checkés par rapport au serveur exécutant XenApp_Check) et le nombre de Worker Groups dans la section “Général Détails”, nous avons rajouté la section “server type” qui permet de connaitre le nombre de serveurs physiques et/ou virtuel au sein d’une ferme.

La mise à jour 1.6 est pour l’instant porté sur XenApp_Check XA6x , la version XA5 sera rapidement mise à jour.

Erreur PerfOS (Event ID :2011) sur windows 2008 R2

Au détour d’un troubleshooting XenApp XA 6.5 (US Sp1) nous sommes tombés sur l’erreur (qui polluait le journal application) :

Log Name:      Application
Source:        Microsoft-Windows-PerfOS
Event ID:      2011
Level:         Error
Description:
Unable to collect System Pagefile performance data. The first four bytes (DWORD) of the Data section contains the status code.

A la lecture de cet event nous étions partis pour exécuter la commande “lodctr /R“, mais vu que les compteurs perfmon ne présentaient aucun problème il était inutile de reconstruire les compteurs perfom.

La résolution était on ne peut plus simple, nous n’avions pas sur les serveurs présentant l’erreur PerfOS, de fichier d’échange de configuré. Une fois le fichier d’échange configuré nous n’avons plus rencontré l’erreur PerfOs.