В пятницу коллегиально решали одну проблему. В ходе решения немного поржали, обмениваясь картинками про Друзь (Друзя? 🙂 ), Холмса и Сталина.
Товарищи программисты обратились с заявкой — периодически на их сервере останавливается служба Server (Lanman).
- Анализ журналов системы показал, что служба останавливается несколько раз в день. Обычно она перезапускается автоматически, но иногда не перезапускается 🙂
- Анализ дат остановки показал, что служба в прошлом году останавливалась 29 декабря, затем была одна остановка 4 января. И с 11 января остановки поперли несколько раз в день.
- Сопоставили в этом же журнале события об остановке с событиями об установке подключения принтера. Уточнили по другим событиям — служба останавливается при логоне.
- Провели тестовые логоны учетных записей программистов — служба останавливается.
- Проверил на своих пользовательских и административных учетных записях — служба не останавливается (хотя тест был некорректный 🙂 )
- Отключили все фичи RDP (принтеры, папки, другие устройства) — не помогло.
- Для исключения проблем с клиентом RDP проверили логин с учетной записью программиста с моего компьютера — проблема воспроизвелась.
- Проверили в настройках AD и RDP, что у них не запускаются никакие скрипты.
- Удалили профиль одного программиста — не помогло.
- Сравнил групповые политики своей учетной записи и учетной записи программиста. Различий не нашел 🙂
- Решил повтыкать на Process Monitor. 360 тысяч событий — это хардкор 🙂
- Пока крутил события, обнаружил запуск VBS-скрипта. Почитал текст скрипта — скрипт останавливает службу Browser и Server. Повезло :)))
После этого стали разбираться.
Этот скрипт вносит ФИО пользователя в поле «Описание» ПК, для облегчения нахождения связки «пользователь-ПК». Видимо, для ускорения обновления этой информации скрипт заодно перезапускал службы «обозревателя» и «сервера». Ну и, видимо, на этом сервере не успевал их перезапустить.
Скрипт запускался через пользовательскую групповую политику.
На моей административной записи этой групповой политики назначено не было. А пользовательская… не являлась локальным администратором сервера.
Поэтому тест №5 и оказался не показательным 🙁
Прочитал программистам мораль про недопустимость использования пользовательских учетных данных для администрирования сервера — сразу создал кучу административных учетных записей.
Заодно выпилил пару «legacy» скриптов из групповой политики.
Мда… Руки то оборвали создателю скрипта?
Найти не удалось.
Мы выпилили два простеньких скрипта.
Остался еще один, который под лупой рассматривать надо — vbs на 14кб ))
Проверили в настройках AD и RDP, что у них не запускаются никакие скрипты.
Как же проверяли, что скрипт не нашли?
Проверялся logon-script в свойствах учетной записи.
А искомый скрипт был в качестве стартовых скриптов пользовательской групповой политики.
Так как проверка №5 показала, что моя учетная запись с таким же набором групповых политик не останавливает службу, то к политикам приглядываться не стали.
VBS???? Скрипты?
Powershell давно уже шагает по планете.
И вообще, групповые политики это джигурда полная.
Вот тут, Фил, поподробнее 🙂
По поводу Powershell — я спорить не буду, но есть нюанс — достаточно массивная и инертная масса старых компьютеров с WinXP (порядка 20%).
А политики-то почему джигурда? Есть другие удобные средства управления виндовыми компами в домене?
Скрипты эти были написаны в незапамятные времена (еще до меня) и с тех пор не ревизировались.