WSUS – Проблемы с клонированными клиентами с дублирующимися SusClientId

imageПри вводе в эксплуатацию партии новых рабочих станций HP с предустановленной ОС Windows 7 Pro OEM столкнулись с ситуацией, когда новые клиентские компьютеры успешно обновлялись с локального сервера WSUS, но при этом не появлялись на консоли WSUS. Вернее сказать, на консоли отображался лишь один новый компьютер, который последним обратился на WSUS. Изучив WindowsUpdate.log на нескольких таких клиентских компьютерах, стало очевидно, что каждый из них использует один и тот же SusClientId, что и приводит к цикличному переписыванию на WSUS сведений о новых клиентах. Информация об уникальном идентификаторе клиента WSUS оказалась идентичной в реестре на всех новых компьютерах из этой поставки.

image

Сверив SID на этих компьютерах, и убедившись в его идентичности, стало понятно, что «ноги растут» из некорректного разлива образа ОС.

image

Осознавать то, что один из крупнейших мировых вендоров позволяет себе и сегодня такие промахи, конечно неприятно, учитывая то, что степень фрустрации при этом сгущается ещё и воспоминаниями о Double UUID.

Описанию проблемы на WSUS с клиентами с идентичными SusClientId посвящена статья KB903262 - A Windows 2000-based, Windows Server 2003-based, or Windows XP-based computer that was set up by using a Windows 2000, Windows Server 2003, or Windows XP image does not appear in the WSUS console. Исходя из описанных в ней инструкций, мы можем создать пакетный файл, с помощью которого выполним регенерацию SusClientId и перерегистрацию клиента на WSUS:

rem === Останавливаем службу Windows Update
net stop wuauserv
rem === Удаляем идентификационные данные клиента Windows Update
reg delete HKLMSOFTWAREMicrosoftWindowsCurrentVersionWindowsUpdate /v PingID /f
reg delete HKLMSOFTWAREMicrosoftWindowsCurrentVersionWindowsUpdate /v AccountDomainSid /f
reg delete HKLMSOFTWAREMicrosoftWindowsCurrentVersionWindowsUpdate /v SusClientId /f
reg delete HKLMSOFTWAREMicrosoftWindowsCurrentVersionWindowsUpdate /v SusClientIDValidation /f
rem === Удаляем файловый кэш клиента Windows Update
del /f /s /q %WinDir%SoftwareDistribution*
rem === Запускаем службу Windows Update
net start wuauserv
rem === Вызываем форсированную перерегистрацию клиента Windows Update
wuauclt.exe /resetauthorization /detectnow

После выполнения этого пакетного файла на проблемной клиентской системе, через несколько минут клиент должен появиться на консоли WSUS как отдельная самостоятельная сущность.

Для того чтобы избежать подобной проблемы, при подготовке образа для развертывания ОС Windows перед выполнением «запаковки» ОС с помощью средства Sysprep, нужно создать файл Sysprep.inf в каталоге с файлом Sysprep.exe с следующим содержанием:

[GuiRunOnce]

Command0=”reg.exe delete HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionWindowsUpdate /v PingID /f”
Command1=”reg.exe delete HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionWindowsUpdate /v AccountDomainSid /f”
Command2=”reg.exe delete HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionWindowsUpdate /v SusClientId /f”
Command3=”reg.exe delete HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionWindowsUpdate /v SusClientIDValidation /f”

Дополнительные источники информации:

The WSUS Support Team Blog - Resolving the duplicate SUSClientID issue, or “Why don’t all my clients show up in the WSUS console?”

TechNet Forum - WSUS - Полезные советы

Всего комментариев: 3 Комментировать

  1. Обратная ссылка: Powershell — Сброс SusClientId на проблемных клиентах Windows Update в домене | Блог IT-KB /

  2. Anton /

    А если и после этой процедуры компьютер не появляется во WSUS ?

    1. Алексей Максимов / Автор записи

      Изучать WindowsUpdate.log на клиентской машине.

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