Elusive87

Всем доброго времени суток.

Давеча решил наваять сценарий, который будет поочерёдно опрашивать компьютеры по указанной площадке, собирать нужную мне информацию и генерировать отчёт со статистикой в HTML файл. Казалось бы - что сложного? Но неожиданно я нашёл довольно-таки странный подводный камень - на некоторых компьютерах при опросе WMI не отвечает. Его служба запущена, порт слушается, авторизация проходит а дальше совсем глухо, скрипт замирает на этом месте и бесконечно ждёт ответ. Ладно бы API какую-нибудь ошибку выплюнул - так нет, зависает и всё. И дело не в скрипте. Пробовал для эксперимента сделать запрос обычным "тестером" (wbemtest) - картина та же, "тестер" зависает. Погуглил, выяснил, что WMI тоже может стать corrupted. Захотел выяснить что там у него сломалось - скачал WMIDiag.vbs, запустил на "прокажённой" машине... сам WMIDiag тоже завис на определённом этапе. :-D

Но моя изначальная цель - выявить "чёрную дыру" (именно таким образом называют данных глюк в "буржунете") и, если что, добавить соответствующую информацию в отчёт. Как её выявить не "наступая" на неё? Пробовал вариант -AsJob gwmi командлета с замером времени (до начала задание и 30 сек после). И столкнулся с другим подводным камнем. "Работа" не всегда ведёт себя как ей полагается. На половине машин она не может завершиться, т. е. статус рабочего объекта Running никогда не исчезает. И это вовсе не означает, что с WMI там что-то не так - отправляешь запрос и сразу же получаешь ответ, а через Job - фигушки.

Вот и получается замкнутый круг. Каким ещё образом можно выявить испорченный WMI на удалённой машине, не подвесив при этом скрипт?