Généralement lorsque vous rencontrez une erreur WMI vous avez un ou plusieurs événements dans les journaux Windows, et bien ça c’est quand tout va bien 🙂 .
Dans le cas présent nous avions une application “Premium” 7/24 (en gros si elle tombe vous avez les cinq continents au tel avec des mots diplomatiques) qui refusait de se lancer sur deux serveurs sur dix. Le listener ICA était ok sur les deux serveurs (publication/connexion sur un notepad ok), en regardant le launcher de la fameuse appli, on se rend compte que le batch, lance un vbs qui lui lance son petit frère qui lui-même appelle sa tante…bref à un moment il y a une requête WMI qui échoue et pas de log applicative .
En lançant la requête localement sur un des serveurs incriminés on s’est aperçu que la couche WMI était corrompu (pour la réparer voir notre billet “Erreur WMI : Espace de noms non valide…..“.
Afin d’anticiper ce type de problème nous avons mis en place un PowerShell qui va checker si les namespace “root\default” et “root\citrix” répondent bien sur tous les serveurs membres d’une ferme XenApp.
Au passage avant le test de Namspace on teste si le port TCP 135 est bien ouvert (sur un timeout de 1000 millisecondes) histoire de ne pas se prendre des timeouts de fou dans sur les serveurs situé dans des DMZ ou autre).
On va aussi en profiter pour intégrer ce check WMI dans XenAppCheck 😉
WmiCheckNameSpace.ps1
