WSUS не видит Windows Server 2025: два сценария которые ломают патчинг · Системный администратор Ижевск

Развернули новые серверы на Windows Server 2025, а в WSUS они не появляются — или появляются, но висят с нулевым количеством нужных обновлений. Дедлайн патчинга через три дня, руководство смотрит в дашборд, а там всё зелёное, потому что новых машин просто не видно. Разбираем два сценария, которые вызывают эту проблему, и чиним каждый по отдельности.

Симптомы

Windows Server 2025 не появляется в консоли WSUS (или появляется, но с пустым списком актуальных обновлений)
Клиент успешно достигает WSUS по сети, GPO применена, но в логах — тишина
wuauclt /detectnow запускается без ошибок, но результата нет
На нескольких новых серверах одинаковый SusClientId в реестре

Сценарий 1: Windows Server 2025 не добавлен как продукт в WSUS

Самая частая причина — сисадмин добавил роль WSUS давно, продукты настроил один раз и забыл. Windows Server 2025 появился как отдельная ветка продуктов только в конце 2024 года, и если вы не заходили в Options → Products and Classifications после этого — ваш WSUS просто не знает, что такой продукт существует.

Диагностика

Проверьте, включены ли нужные продукты:

powershell

Import-Module UpdateServices
$wsus = Get-WsusServer
$wsus | Get-WsusProduct | Where-Object { $_.Product.Title -like "*Server 2025*" }

Если вывод пустой или у всех строк Enabled: False — это ваша проблема.

Решение

Включаем все варианты Windows Server 2025 через PowerShell:

powershell

Import-Module UpdateServices
$wsus = Get-WsusServer
$wsus | Get-WsusProduct | Where-Object {
    $_.Product.Title -like "*Windows Server 2025*"
} | Set-WsusProduct

После этого запускаем синхронизацию вручную:

powershell

$subscription = $wsus.GetSubscription()
$subscription.StartSynchronization()

Дождитесь завершения синхронизации — это может занять от 10 минут до часа в зависимости от канала. После этого WSUS начнёт видеть обновления для Server 2025 и предлагать их клиентам.

✅ Проверка: снова выполните первый запрос — теперь у продуктов должно быть Enabled: True.

Сценарий 2: Дублирование SusClientId после клонирования VM

Вы развернули несколько серверов из одного шаблона Hyper-V или VMware — Sysprep прошёл, машины в домене, всё выглядит нормально. Но в WSUS вместо пяти новых серверов вы видите одну запись, которая периодически «мигает».

Причина: SusClientId — уникальный идентификатор клиента WSUS в реестре — был создан до Sysprep или не был очищен при клонировании. Все клоны приходят в WSUS с одинаковым GUID, и сервер считает их одной машиной.

Диагностика

На нескольких серверах проверьте значение:

powershell

Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate' |
    Select-Object SusClientId, SusClientIdValidation, PingID

❌ Если SusClientId одинаковый на разных машинах — именно это и ломает отчётность.

Для масштабной проверки по домену можно сравнить значения с нескольких машин через Invoke-Command:

powershell

$servers = @('srv01','srv02','srv03','srv04','srv05')
Invoke-Command -ComputerName $servers -ScriptBlock {
    (Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate').SusClientId
} | Group-Object | Where-Object { $_.Count -gt 1 }

Если Group-Object показывает группы с Count > 1 — у вас дубликаты.

Решение

Сбрасываем идентификатор клиента. Выполните на каждой затронутой машине:

powershell

# Остановить службу обновлений
Stop-Service wuauserv -Force

# Удалить дублирующийся идентификатор
Remove-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate' `
    -Name 'SusClientId' -ErrorAction SilentlyContinue
Remove-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate' `
    -Name 'SusClientIdValidation' -ErrorAction SilentlyContinue
Remove-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate' `
    -Name 'PingID' -ErrorAction SilentlyContinue

# Запустить службу — новый GUID будет создан автоматически
Start-Service wuauserv

# Принудительно зарегистрироваться на WSUS
wuauclt /resetauthorization /detectnow
Start-Sleep -Seconds 10
UsoClient StartScan

Для массового применения через GPO можно оформить этот скрипт как Startup Script, но делайте это осторожно — выполнение на уже рабочих машинах сбросит их историю обновлений в WSUS.

✅ Проверка: через 10-15 минут откройте консоль WSUS → Computers → All Computers. Каждая машина должна появиться с уникальным именем и начать отчитываться.

Если оба сценария исключены

Если продукт добавлен, SusClientId уникален, но серверы всё равно не отчитываются — проверьте ещё три вещи:

Подключение к WSUS:

powershell

Test-NetConnection wsus-server.corp.local -Port 8530

GPO действительно применена:

powershell

gpresult /r | Select-String -Pattern 'WUServer|WUStatusServer'

Оба параметра должны указывать на ваш WSUS-сервер.

Логи клиента:

powershell

Get-WinEvent -LogName 'Microsoft-Windows-WindowsUpdateClient/Operational' -MaxEvents 50 |
    Where-Object { $_.LevelDisplayName -eq 'Error' }

Ошибки в логе, как правило, прямо указывают на причину — TLS-проблема, недоступный эндпоинт или конфликт политик.

Итог

Windows Server 2025 ломает WSUS-отчётность чаще всего по двум причинам: забытый продукт в настройках сервера и одинаковые SusClientId на клонированных VM. Первое чинится за пять минут через PowerShell, второе требует сброса идентификатора на каждой машине. После исправления дайте клиентам 15-20 минут и проверьте консоль — серверы должны появиться и начать репортить корректно.