Заметки IT Менеджера

25.03.2010

WSUS — сверка списка компьютеров с AD


обновлено 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 на клиентских компьютерах и серверах.

Реклама

9 комментариев »

  1. […] я уже писал, как сверить список компьютеров, которые есть в AD с теми…. Если эти списки не совпадают, то у вас проблема и […]

    Уведомление от Как починить WSUS agent на клиентской машине « Заметки IT Менеджера — 07.12.2009 @ 19:06 | Ответить

  2. Я ввожу данные команды в ПоШ, но в итоге никаких списков не вижу. Они выполняются, но результат не отображается? Куда смотреть ?

    комментарий от mak — 25.03.2010 @ 09:39 | Ответить

    • В конце скрипта сделайте вывод значения переменной на экран.
      Сейчас исправлю в блоге

      комментарий от itpadla — 25.03.2010 @ 10:34 | Ответить

  3. Я так же заинтересовался этой статьей Ильи Сазонова. И в продолжение темы, поднятой им в этой статье, написал свой скрипт для устранения одной из причин, которые могут приводить к ситуации, описываемой Ильей (отсутствие в БД WSUS информации о компьютерах-клиентах)
    http://shss.wordpress.com/2010/02/18/remote-wsus-client-reset-kb903262/

    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 | Ответить

  4. У нас так: в 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 | Ответить


RSS feed for comments on this post. TrackBack URI

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

Блог на WordPress.com.

%d такие блоггеры, как: