EventId

Erreur Web Interface : Invalid URI: The hostname could not be parsed.

Quoi de plus énervant que de retrouver des journaux Windows pollués d’erreurs à ne plus en finir, c’est dans ce contexte que nous avons trouvé certaines Web Interface.

Les Web Interface en questions (Windows 2008 Us R2, Web Interface 5.4) généraient l’Event ID 21002 toutes les 3 secondes :

Log Name:      Application
Source:        Citrix Web Interface
Event ID:      21002
Task Category: None
Level:         Error
Keywords:      Classic
Description:
Site path: C:\inetpub\wwwroot\Citrix\Site1.
Critical server error: System.UriFormatException: Invalid URI: The hostname could not be parsed.

Il ne reste plus qu’à trouver la source

Inutile de nous faire le coup du “mais où est ton Logstash, ElasticSearch et Kibana ou mieux ton SexiLog pour Citrix” 🙂

Un Wireshark après nous avons trouvé la cause, un cluster de F5 qui monitorait un Site Webi via un GET /Citrix/Site1/auth/login.aspx.

Une fois le monitor corrigé (via un Get sur le site webi /Citrix/Site1, sans auth/login.aspx) par nos collègues F5.

Erreur IMAService EventId 4007

Lors d’une migration entre deux fermes XenApp 6.5 R03 Fr, un de nos serveurs n’arrivait plus à démarrer son service IMA.

Dans le journal system nous avons retrouvé l’erreur ci-dessous :

Log Name: System
Source: IMAService
Event ID: 4007
Description:
Le service Citrix Independent Management Architecture (IMA) se ferme. Le fichier DSN n’a pas pu être mis à jour avec les informations récupérées depuis la stratégie de groupe. Erreur : 80000001h Fichier DSN : mf20.dsn Entrée DSN : DATABASE Paramètre de stratégie : VotreFerme Confirmez que le service réseau possède des permissions en écriture dans le fichier DSN.

Le problème venait de la valeur “DataSourceName” situé dans “HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\IMA”, cette dernière étant vide ça ne risquait pas de fonctionner.

Une fois la valeur DataSourceName renseignée, l’IMA redémarre sans problème

La CTX105292 traite au passage ce type de problème

Rechercher un EventId au sein d’une ferme XenApp

Il arrive lors de troubleshooting que l’on souhaite connaître la présence (ou pas) d’un EventId au sein des divers silo d’une ferme XenApp (ce qui permettra par la suite d’appliquer le correctif sur les silos impactés et au passage de faire une petite comm 😉 ).

Dans le cas présent il s’agissait de connaitre la liste des silos (avec leurs serveurs) rencontrant l’EventId 6005 (nous ferons très prochainement un billet sur cet EventId) afin de pouvoir appliquer la GPO corrigeant le problème sur les serveurs concernés.

On utilise la cmdlet Get-EventLog afin de retrouver l’EventID recherché (avec un filtre -Newest 500, suffisant pour constater ou pas la présence de l’EventId durant les derniers jours).

Au préalable modifier la valeur “6005” (et/ou changer le type de journal dans lequel vous allez effectuer votre recherche) par celui recherché en ligne 8 du script.

La liste des silo Impactés est affichée dans la colonne FolderPath

Search_Event_XenApp.ps1

Cela exclue pas l’utilisation d’un bon vieux Syslog ou un Graylog2 😉