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