3 votes

Détecter les WMI corrompus

Quand WMI est corrompu, il échouera de la manière la plus étrange, certaines requêtes (la plupart d'entre elles) fonctionneront, d'autres lanceront des exceptions, certaines expireront et quelques-unes renverront simplement aucun résultat (ou des résultats partiels/erronés).

Comme j'ai un travail de surveillance système WMI important et compliqué, j'aimerais être capable de repérer un référentiel WMI corrompu avant d'exécuter le script. Le déterminer à partir du comportement du script est difficile (en raison des nombreuses façons dont WMI peut échouer) et il est souvent possible de passer un temps considérable à déterminer s'il s'agit d'une erreur système ou WMI.

Je cherche essentiellement une méthode que je puisse exécuter au début de mon script PowerShell pour déterminer à l'avance si WMI est corrompu.

4voto

Jonas Söderberg Points 21

Il existe un script fourni par l'équipe des services de support produit de Microsoft qui est spécifiquement conçu pour repérer et diagnostiquer les bases de données WMI corrompues, le Utilitaire de diagnostic WMI.

Plus d'informations sur la manière d'utiliser cela sur Dépannage WMI avec WMIDiag.

Malheureusement, je ne suis pas sûr de l'utilité de cela pour vous si vous souhaitez lancer cela au début de l'exécution d'une tâche, c'est plus le genre de chose que les gens ont tendance à configurer pour s'exécuter automatiquement sur l'ensemble de leur parc informatique régulièrement afin de signaler les machines nécessitant une vérification.

2voto

gWaldo Points 11827

Une façon de le faire (si vous définissez le comportement d'échec de votre script sur 'ignorer') serait d'assigner l'instruction gwmi à une variable, puis de vérifier la variable de cette variable.

$connectToWMI = gwmi win32_service -computername [nomordinateur]

ensuite, vérifiez l'état ou la valeur de la variable (en utilisant write-host pour voir à quoi vous attendre en cas de connexion réussie et d'échec)

Il semble également que vous puissiez définir des Traps pour vérifier les erreurs, mais je ne l'ai pas utilisé. Cela ressemble à ceci :

trap [Exception] {continue}

-4voto

mfinni Points 35332

Je n'ai pas de réponse à la question spécifique, mais pourquoi est-ce important? Vous recevez une notification de votre script qu'il a échoué, et vous devez ensuite le corriger manuellement. Cette notification se produit parce que le script a échoué. Si vous ajoutiez du code supplémentaire dans le script pour d'abord vérifier si WMI est corrompu, le flux de travail resterait exactement le même.

/edit - OK - vous avez donc différentes façons potentiellement inconnues que WMI peut échouer s'il est corrompu? Et vous demandez une seule méthode pour vérifier s'il est corrompu? Alors vous êtes dans l'impasse. Je remarquerai que vous dites

"(et par la suite passer du temps à comprendre s'il a échoué pour des raisons système importantes ou s'il est simplement dû à un WMI corrompu)"

Eh bien, alors vous avez besoin de meilleurs codes de retour et peut-être d'une meilleure conception fonctionnelle dans votre script. Si votre script ne vous dit pas pourquoi il a échoué, réparez-le. gWaldo a une bonne suggestion ci-dessous concernant le piégeage. À ce stade, je pense que vous feriez mieux de revoir ce que vous faites et ensuite de passer du temps sur StackOverflow.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X