Если вы используете различные инструменты деплоя ОС из образов или имеете большое количество виртуальных машин, то наверняка замечали что далеко не все развернутые ОС отправляют отчет на сервер WSUS или вообще пропадают с сервера.
В этой статье я расскажу почему так происходит и как с этим бороться Предположим вы деплоите ваши рабочие станции из эталонного образа ОС или клонируете виртуальные машины из преднастроенного шаблона, скорее всего после или во время деплоя вы запускаете на них sysprep, но обнуляете ли вы SusClient >
Тут то и кроется корень проблемы, после клонирования у машин остается один и тот же SusClientId.
Посмотреть его можно в реестре, по следующему пути:
HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionWindowsUpdate
Значения которые нам нужны называются — SusClientId и SusClientIdValidation.
Данные значения должны быть уникальными на каждой машине, если это не так, то машины будут перерегистрироваться на WSUS затирая таким образом соседей с таким же SusClientId.
Чтобы это исправить нужно выполнить следующие команды:
В данной статье рассматривается:
Часто при развертывании новой ОС на компьютере используют метод разворачивания ОС из образа, при это не производятся рекомендуемые действия для смены индификаторов клонированной ОС. Что приводит к тем или иным проблемам в последующей работе.
Одной из проблем является, что все клоны для сервера WSUS представляются одним именем и отображаются как одна УЗ с часто меняющимся данными. Для решения данной проблемы мы должны сбросить индификаторы WSUS на клонированных ОС на компьютерах.
Сам bat файл. Запуск необходимо производить с правами Администратора.
В Windows 10 wuauclt заменен на UsoClient
Клиенты WSUS не хотят обновляться после смены сервера?
Тогда мы идем к вам. (С)
У всех бывали ситуации, когда что-нибудь переставало работать. В данной статье речь пойдет о WSUS (более подробную информации о WSUS можно получить здесь и здесь). А точнее о том, как заставить клиентов WSUS (т.е. наши с вами компьютеры) заново получать обновления после переноса или восстановления существующего сервера обновлений.
Итак, ситуация следующая
Сдох сервер WSUS. Точнее RAID-контроллер аж 2000 года выпуска. Но радости этот факт не прибавил. После непродолжительной возни (с попытками восстановить RAID, загубленный помирающим контроллером), было принято решение послать все развернуть новый WSUS-сервер.
В итоге мы получили работающий WSUS, на который почему-то не коннектились клиенты.
Моменты: WSUS привязан с FQDN через внутренний DNS-сервер, WSUS-сервер прописан в групповых политиках и распространяется на клиентов через AD, настройки для сервера по-умолчанию, перед началом всех действий обновите сам WSUS и выполните синхронизацию обновлений.
После анализа ситуации, было выявлено несколько ключевым моментов
- Клинч клиента (речь о wuauclt) при попытке соединиться с SID старого сервера WSUS.
- Проблема с неустановленными обновлениями, скачанными со старого WSUS-сервера.
- Парковка служб влияющих на работу wuauclt (речь о wuauserv, bits и cryptsvc). Парковка произошла по разным причинам, которые детально не анализировались.
В итоге все решение вылилось в маленький скрипт, который распространяется групповыми политиками через AD или собственными руками (и ногами). Скрипт использует наиболее безопасный вариант починки и не приносил ни одного негативного результата уже на протяжении полугода использования.
Опишу, что делается (для особо любопытных)
Паркуем службу сервера обновлений, чистим дескриптор безопасности службы связи с WSUS, удаляем имеющиеся обновления от предыдущего WSUS, чистим реестр от упоминаний о предыдущем WSUS, стартуем службы автоматического обновления (wuauserv), фоновую интеллектуальную службу передачи (bits) и службу криптографии (cryptsvc), в самом конце принудительно стукаемся в WSUS с обнулением авторизации, обнаружением нового WSUS и генерацией отчета на сервер.
И как всегда: все действия описанные выше и ниже вы выполняете на свой страх и риск. Пожалуйста, удостоверьтесь в том что все необходимые данные сохранены до выполнения скрипта.