обновлено 25.03.2010
На блоге Ильи Сазонова обнаружил очень интересный материал: WSUS — сверка списка компьютеров с AD. Да и вообще, там регулярно появляется любопытная информация.
Позволю себе перенести то, что он выложил к себе с некоторыми моими комментариями и модификациями.
Что это и зачем это нужно? В каждой уважающей себя организации используется Active Directory как единый каталог и WSUS для централизованной установки обновлений. Но, по разным причинам, некоторые компьютеры могут не обновляться со WSUS. Причины тому могут быть самые разные: сбой агента обновления, файрволл, еще что-то … Главное – это то, что такие случае нужно выявлять и разбираться с ними индивидуально.
Итак
Текущая версия WSUS имеет API, который позволяет удаленное управление сервером. Чтобы его задействовать, необходимо установить на компьютер клиентскую часть сервера. После чего запускаем оболочку Powershell 2.0 и загружаем WSUS API:
[reflection.assembly]::LoadWithPartialName("Microsoft.UpdateServices.Administration")
Теперь надо подключаемся к удаленному серверу по имени «WSUS»:
$wsus = [Microsoft.UpdateServices.Administration.AdminProxy]::GetUpdateServer("WSUS", $false)
Второй параметр $false говорит о том, что будет использоваться HTTP протокол, а не HTTPS, т.е. не будет шифрования.
Скрипт Ильи работает, если у вас WSUS висит на стандартном порту. У меня же он висит на другом, нестандартном. Как поступить? А вот как (спасибо коллеге, нашел):
$wsus = [Microsoft.UpdateServices.Administration.AdminProxy]::GetUpdateServer("WSUS", $false,port_number)
Где port_number – номер нестандартного порта WSUS
Теперь получаем список всех компьютеров зарегистрированных на WSUS-сервере:
$WSUScomps = $wsus.GetComputerTargets()
Каждый элемент массива $WSUScomps это объект, а нам нужны только имена компьютеров. Получаем FQDN имена компьютеров:
$WSUSCompNames = $WSUScomps | ForEach { $_.FullDomainName.ToUpper() }
Перевод имени в верхний регистр не критичен (по умолчанию Powershell выполняет сравнение строк без учета регистра), но формально все же это надо сделать.
Следующий шаг – получение списка учетных записей компьютеров из Active Directory:
$ADcomps = (new-object System.DirectoryServices.DirectorySearcher([ADSI]”LDAP://ou=DEPS,dc=DOMAIN,dc=com”,"(&(objectCategory=computer)(!userAccountControl:1.2.840.113556.1.4.803:=2))")).findAll()
Тут конструкция !userAccountControl:1.2.840.113556.1.4.803:=2 исключает запрещенные (disabled) учетные записи компьютеров. LDAP://ou=DEPS,dc=DOMAIN,dc=RU задает корень поиска в дереве AD. objectCategory=computer – выбираем только учетные записи компьютеров.
Из объектов учетных записей компьютеров извлекаем имена компьютеров (также формально переводим их в верхний регистр):
$ADCompNames = $ADcomps | ForEach {$_.GetDirectoryEntry().dNSHostName.ToString().ToUpper()}
И последний шаг – получаем имена компьютеров, которые есть в Active Directory, но отсутствуют в WSUS:
$NoWSUSCompNames = $ADCompNames | Where { $WSUSCompNames -notcontains $_ }
Теперь нам остается проанализировать полученный список и разобраться почему выявленные компьютеры не получают обновления с WSUS. Для получения списка просто выведу на экран значения
$NoWSUSCompNames
В отдельной записи представлены скрипты, с помощью которых мы “чиним” агентов WSUS на клиентских компьютерах и серверах.
[…] я уже писал, как сверить список компьютеров, которые есть в AD с теми…. Если эти списки не совпадают, то у вас проблема и […]
Уведомление от Как починить WSUS agent на клиентской машине « Заметки IT Менеджера — 07.12.2009 @ 19:06 |
Я ввожу данные команды в ПоШ, но в итоге никаких списков не вижу. Они выполняются, но результат не отображается? Куда смотреть ?
комментарий от mak — 25.03.2010 @ 09:39 |
В конце скрипта сделайте вывод значения переменной на экран.
Сейчас исправлю в блоге
комментарий от itpadla — 25.03.2010 @ 10:34 |
Я так же заинтересовался этой статьей Ильи Сазонова. И в продолжение темы, поднятой им в этой статье, написал свой скрипт для устранения одной из причин, которые могут приводить к ситуации, описываемой Ильей (отсутствие в БД WSUS информации о компьютерах-клиентах)
Welcome ;)
комментарий от shs — 10.04.2010 @ 14:30 |
Не знаю как у вас, а у нас лечение удалением ключиков в реестре — это достаточно редкий случай. Часто клиент во WSUS есть, но потом перестал обновляться. Если пропустить время, то во время очистки он удалиться из базы WSUS, если нет — то просто не обновляется. Небольшой минус способа с очисткой ключей в registry в том, что комп будет найден заново.
Полный список способов починки WSUS — http://wp.me/pCU2B-1U
Ваш скрипт интересен удаленным выполнением из-под PowerShell 2, мы свои начинали писать еще для Windows 2000 и SUS 2.0 :-) Так что, может быть, и я перепишу их под такое применение.
комментарий от itpadla — 11.04.2010 @ 09:18 |
У нас так: в production компьютер отдается только, если он гарантированно обновляется с WSUS. БД WSUS чистим только вручную. Клиентов автоматического обновления, которые перестали обновляться, не видел уже года 2-3. Поэтому проблема «пропажи» компьютера из БД WUS по причинам, о которых вы говорите, нам не знакома.
Мой скрипт решает только ту проблему, которая описана в соответствующей kb (отсутствие информации о клонированном компьютере, который успешно обновляется с WSUS-сервера, в БД этого самого WSUS-сервера) и ни в коем случае не претендует на универсализм и панацею от всех проблем клиента автоматического обновления.
комментарий от shs — 11.04.2010 @ 11:01 |
А у нас — все наоборот. Наша процедура клонирования давно исключила возможность дублирования ID для WSUS и потому именно с этим у нас проблем или нету, или очень мало. В общем-то, при клонировании мы делаем то, что вы делаете своим скриптом. Просто методы могут применяться разные, в зависимости от способа клонирования, или это cmd/reg файл, или это скрипт в sysprep
А вот другие проблемы бывают.
комментарий от itpadla — 11.04.2010 @ 11:09 |
Последние проблемы, которые могу припомнить с клиентом Автоматического обновления – это проблема с обновлениями, содержащими MSI-пакеты (ЕМНИП), при которой «падал» не только клиент Автоматического обновления, но и еще несколько служб (Клиент сетей Майкрософт, служба Windows Audio и (сюрприз!) служба Журнал событий (из-за чего в логах была одна благодатная синева)). Но эта проблема давно решена соответствующими заплатками ОС и обновление самого клиента Автоматического обновления.
комментарий от shs — 11.04.2010 @ 11:19
Да, интересно … А у нас как раз такого не было :-)
Зато, чтобы заработала связка свеженамотанного сервера на W2008/W2008R2 или W2003 x64 приходится немного потанцевать с бубном. Именно поэтому, планирую как-нибудь, перенести WSUS с Windows Server 2002 R2 x32 на Windows 2008 R2 Server
комментарий от itpadla — 11.04.2010 @ 11:24 |