WSUS после статуса deprecated: когда оставлять, как реанимировать и куда уходить

Сносить WSUS в 2026 году не нужно: роль есть в Windows Server 2025 и поддерживается, просто новых функций не будет. Но строить на нём планы на пять лет я бы не стал. Внутри — кому WSUS реально нужен, как поставить его на SQL вместо WID, как реанимировать запущенный сервер и чем заменить.

Что на самом деле значит «WSUS устарел»

В таблице Microsoft «Features no longer in development» для Windows Server 2025 про WSUS написано коротко: «WSUS is no longer actively developed. All the existing capabilities and content continue to be available for your deployments». А в шапке той же страницы объяснено, что значит deprecated: компонент по-прежнему поставляется в Windows Server, поддерживается в проде и получает исправления безопасности и качества по жизненному циклу продукта. Переведу на человеческий: новых функций не будет, но роль есть в Windows Server 2025, работает и патчится. Дату удаления никто не называл. Рядом в той же таблице стоят NTLMv2, Network Load Balancing, WMIC и VBScript — компания уважаемая, и ни одна из этих вещей пока никуда не делась.

Куда практичнее для меня строчка про WID в той же таблице: «WID is used by several roles, including AD FS, AD RMS, IPAM, RD Connection Broker, and WSUS. Consider using a free or full version of SQL Server for these roles. WID will be removed from Windows in a future release». Внутренняя база — то, на чём стоит 90 % виденных мной инсталляций, и именно её обещали убрать. Поэтому, когда мы в АйТи-Фреш берём на себя закрытие уязвимостей Windows у нового клиента, первым делом смотрю, на чём живёт SUSDB. Если разворачиваете WSUS с нуля — ставьте его на SQL Server Express, а не на WID. При установке это лишние минут двадцать, а при вынужденной миграции через пару лет — рабочий день.

Моя позиция простая. WSUS — это не «мёртвая технология», это технология в режиме заморозки. Она перестала догонять облако (никакого Autopatch, никаких политик отсрочки, никакого нормального отчёта о комплаенсе), но продолжает делать ровно то, за что её ставили пятнадцать лет назад: скачать патчи один раз и раздать их по локальной сети под вашим контролем. Если вам нужно именно это — берите и не переживайте. Если вам нужно что-то большее — WSUS вам этого никогда и не давал.

• Deprecated ≠ unsupported: роль есть в Windows Server 2025, исправления безопасности приходят.
• Новых функций не будет — ждать поддержки чего-то современного бессмысленно.
• Windows Internal Database отдельно помечена «will be removed from Windows in a future release» — планируйте SQL.
• Дата удаления роли не объявлена: паниковать не с чего, но и бюджет на пять лет вперёд под WSUS не закладывайте.

Нужен ли вам WSUS на 30–50 рабочих местах

Честный ответ, который мне не всегда выгодно давать: в половине случаев — нет. WSUS ставят по инерции, потому что «так положено». А потом он полгода стоит с непроведённой синхронизацией, забивает диск, клиенты в консоли висят с последним отчётом от прошлой весны — и вся компания по факту не обновляется вообще. Это хуже, чем не иметь WSUS: без него машины хотя бы тянут патчи напрямую из Microsoft Update и остаются здоровыми.

Для офиса до 50 машин с приличным интернетом я в первую очередь смотрю на схему обновлений без WSUS: политики отсрочки плюс Delivery Optimization. Отсрочки настраиваются обычной групповой политикой, без Intune и подписок: качественные обновления откладываются на 7–14 дней, функциональные — на нужный срок, и вы получаете тот самый карантин перед раскаткой, ради которого обычно и городят WSUS. Delivery Optimization по умолчанию уже работает в режиме LAN (DODownloadMode=1): машины за одним внешним IP забирают куски патчей друг у друга. Режим Group (DODownloadMode=2) расширяет обмен на весь сайт AD или домен, в том числе между подсетями. Трафик наружу падает в разы без единого сервера, бесплатно.

WSUS я оставляю или ставлю, когда есть хотя бы один из факторов: канал в интернет узкий или платный по трафику (филиал на LTE, точка с резервным каналом); сеть изолирована и наружу не ходит; нужен именно ручной аппрув каждого патча с журналом «кто и когда одобрил» — например, под сервер 1С, который капризничает после кумулятивных обновлений; или парк за сотню машин, где без централизованного отчёта вы просто не знаете, что происходит. Есть и тонкость про филиалы: по умолчанию Delivery Optimization не раздаёт пиринговый трафик через VPN, так что для сети точек с тонкими туннелями локальный сервер обновлений или BranchCache всё ещё выигрывают. Всё остальное — вкусовщина.

• Ставить WSUS: узкий или платный канал, изолированный сегмент, обязательный ручной аппрув, парк 100+ машин.
• Можно обойтись: офис до 50 машин с нормальным интернетом — GPO-отсрочки + Delivery Optimization (LAN по умолчанию или Group, DODownloadMode=2).
• Гибрид, который я часто делаю: WSUS только для серверов (жёсткий контроль), рабочие станции — на Windows Update с отсрочками.
• Категорически не делать: поставить WSUS «чтобы был» и не заходить в консоль.

Как я ставлю WSUS, чтобы он прожил дольше года

Требования Microsoft к железу выглядят скромно: процессор x64 от 1,4 ГГц, плюс 2 ГБ RAM сверх того, что нужно самой ОС и остальным службам, и «40 GB or greater is recommended» под контент. Буквально этим цифрам верить не надо. Для Unified Update Platform документация отдельно предупреждает, что сервер скачивает примерно 10 ГБ контента на каждую версию Windows и архитектуру процессора. То есть каждая связка «версия Windows × архитектура» — ещё десяток гигабайт. Я закладываю отдельный том минимум на 300 ГБ и никогда не кладу WSUSContent на диск C:.

Порядок действий на новом сервере у меня такой. Ставлю роль с опцией SQL вместо WID и отдаю ей инстанс SQL Server Express на этой же машине. Помните про потолок Express — 10 ГБ на базу: для ухоженной SUSDB в офисе на 50 машин это с большим запасом, а для запущенной может стать проблемой, поэтому чистка из пятого раздела обязательна. Затем postinstall с явным указанием тома под контент, чтобы мастер не утащил его куда попало. Подробный пошаговый разбор мастера есть в статье про настройку сервера обновлений WSUS, здесь — только то, что я делаю иначе:

# роль + консоль, без WID
Install-WindowsFeature -Name UpdateServices-Services, UpdateServices-DB, UpdateServices-RSAT `
  -IncludeManagementTools

# postinstall: контент на отдельный том, база в локальный SQL-инстанс
& "$env:ProgramFiles\Update Services\Tools\wsusutil.exe" postinstall `
  SQL_INSTANCE_NAME="WSUS-01\SQLEXPRESS" CONTENT_DIR="D:\WSUS"

Дальше — сеть. По умолчанию клиенты ходят на WSUS по двум портам: 8530 (HTTP) и 8531 (HTTPS). Документация объясняет логику: по HTTPS идут метаданные обновлений, а сами файлы — по HTTP, их целостность защищена подписью и хэшем, который клиент получает по защищённому каналу. Весь сайт под TLS увести нельзя: «You can't configure the entire WSUS website to require TLS. WSUS is designed to encrypt update metadata only». Требовать TLS надо только для виртуальных каталогов SimpleAuthWebService, DSSAuthWebService, ServerSyncWebService, APIremoting30 и ClientWebService — и не для Content, Inventory, ReportingWebService и SelfUpdate. Сертификат привязывается командой wsusutil configuressl <DNS-имя сервера>, а в политике клиентов адрес должен быть FQDN с HTTPS-портом, например https://wsus.example.local:8531, иначе всё развалится на проверке имени.

Клиентов направляю групповой политикой, а не руками в реестре. Но реестр знать надо — по нему быстрее всего диагностировать. Адрес сервера живёт в HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate в значениях WUServer и WUStatusServer (оба REG_SZ), а поведение автообновлений — уровнем ниже, в подключе AU: UseWUServer=1, AUOptions (4 — «скачать и установить по расписанию»), NoAutoRebootWithLoggedOnUsers, ScheduledInstallDay/ScheduledInstallTime. Группы я всегда делаю через client-side targeting: политика «Enable client-side targeting», в консоли WSUS в Options → Computers переключатель «Use Group Policy or registry settings on computers». Тогда новая машина сама падает в нужную группу, а не в Unassigned Computers, где её никто не заметит.

• SQL Express вместо WID — на перспективу удаления WID из Windows.
• WSUSContent — отдельный том от 300 ГБ, никогда не C:.
• Порты 8530/8531; если меняете — только соседние номера, HTTP ровно на единицу меньше HTTPS.
• TLS — только на пять служебных виртуальных каталогов; Content, Inventory, ReportingWebService и SelfUpdate оставить без требования TLS.
• Client-side targeting + отдельная GPO только под WSUS, слинкованная на OU, а не на весь домен.

Разбор: сеть салонов на 46 рабочих мест и семь месяцев без патчей

Салон красоты «Образ и стиль» — пять салонов и небольшой офис, 46 рабочих мест: стойки администраторов, кассы, кабинеты управляющих, бухгалтерия, склад косметики. Три сервера в офисе, домен на двух контроллерах, салоны подключены к офису VPN-туннелями на 50–100 Мбит/с. Смесь Windows 11 23H2 и десятка ещё не переведённых машин на Windows 10 22H2 — про то, что с ними делать после окончания поддержки, я подробно писал в разборе Windows 10 после окончания поддержки. WSUS развернул прежний подрядчик за три года до нас: Windows Server 2019, база на WID, контент на том же диске D:, что и файловая шара. Заявка звучала вовсе не про обновления: «кончается место на D:, купите диск». Место кончалось потому, что WSUSContent весил 412 ГБ из 500.

Первое, что я смотрю в такой ситуации, — не диск, а отчётность. В консоли 46 компьютеров, у 39 последний контакт семь месяцев назад. В логе агента на клиентах (Get-WindowsUpdateLog) — ошибка 0x80244022, это HTTP 503 от сервера. Дальше всё сложилось за десять минут: пул приложений WsusPool в IIS упирался в лимит приватной памяти (по умолчанию 1 843 200 КБ, около 1,8 ГБ) и перезапускался десятки раз в сутки. Он не выдерживал объёма базы: SUSDB разросся до 9,8 ГБ, около 11 400 обновлений были заменены новыми и ни разу не отклонены, а в продуктах синхронизации стояли Windows 7, Office 2010 и SQL Server 2008 — всё то, чего в компании не было в принципе. Плюс включённая классификация Drivers, которая и дала основной вес контента.

Что делали, по порядку. Сначала IIS: снял лимит приватной памяти, увеличил очередь и отключил остановку пула по простою, иначе никакие операции с базой не доживали до конца.

$ac = "$env:windir\system32\inetsrv\appcmd.exe"
& $ac set apppool /apppool.name:WsusPool /queueLength:2000
& $ac set apppool /apppool.name:WsusPool /cpu.resetInterval:"00:15:00"
& $ac set apppool /apppool.name:WsusPool /recycling.periodicRestart.privateMemory:0
& $ac set apppool /apppool.name:WsusPool /processModel.idleTimeout:"00:00:00"

Потом — чистка. Сняли лишние продукты и классификации в Options, отклонили superseded, прогнали cleanup по одному ключу за раз (об этом ниже), переиндексировали SUSDB. Итог через четыре рабочих дня: WSUSContent — 94 ГБ вместо 412, SUSDB — 2,1 ГБ вместо 9,8, синхронизация с Microsoft Update — 4 минуты вместо 40, отчитались 46 машин из 46. Отдельным подарком выяснилось, что 9 компьютеров на стойках администраторов были клонами одного образа с одинаковым SusClientId — в консоли они схлопывались в один объект, так что картина была ложной ещё до поломки. Диск покупать не понадобилось, а WSUS мы оставили осознанно: салоны сидят на тонких VPN-туннелях, и раздача патчей из офиса по расписанию ночью их разгружает.

• Симптом «кончается место» → реальная проблема «никто не обновляется семь месяцев».
• 0x80244022 на клиенте = 503 от IIS = чаще всего падающий WsusPool.
• 412 → 94 ГБ контента и 9,8 → 2,1 ГБ базы дало снятие лишних продуктов, Drivers и отклонение superseded.
• Клоны одного образа с общим SusClientId искажают отчётность ещё до всяких поломок.

Обслуживание: то, чего почти никто не делает

WSUS не самообслуживается. Он деградирует линейно и предсказуемо: каждый месяц приезжает новая порция кумулятивных обновлений, старые становятся superseded, но остаются и в базе, и на диске. Через полтора года без чистки любой сервер приходит ровно к состоянию, которое мы увидели в салонах. Поэтому на каждом WSUS у меня висит регламентное задание, и это не опция. Про то, как вписать его в общий патч-менеджмент Windows на 50 ПК с группами и пилотом, есть отдельный материал.

Штатный инструмент — Invoke-WsusServerCleanup из модуля UpdateServices. У него шесть ключей: -DeclineSupersededUpdates, -DeclineExpiredUpdates, -CleanupObsoleteUpdates, -CleanupObsoleteComputers, -CleanupUnneededContentFiles, -CompressUpdates. Практическая деталь из моего опыта, которой в справке по командлету нет: на запущенной базе не запускайте их все разом. Я видел, как такой вызов молотит сутками и падает по таймауту, ничего толком не завершив. Первый раз иду по одному ключу, начиная с отклонения superseded, — после него остальные шаги проходят заметно быстрее.

$w = Get-WsusServer
# первый прогон на запущенной базе — строго по одному ключу
$w | Invoke-WsusServerCleanup -DeclineSupersededUpdates
$w | Invoke-WsusServerCleanup -DeclineExpiredUpdates
$w | Invoke-WsusServerCleanup -CleanupObsoleteUpdates
$w | Invoke-WsusServerCleanup -CompressUpdates
$w | Invoke-WsusServerCleanup -CleanupObsoleteComputers
$w | Invoke-WsusServerCleanup -CleanupUnneededContentFiles

Второй обязательный пункт — переиндексация SUSDB. У WID нет ни планов обслуживания, ни SQL Agent, поэтому индексы там сами не перестраиваются никогда. К WID подключаются через SQL Server Management Studio или sqlcmd по именованному каналу \\.\pipe\MICROSOFT##WID\tsql\query (сама база — %windir%\wid\data\SUSDB.mdf), и раз в месяц гоняют скрипт переиндексации, который Microsoft публикует в руководстве по обслуживанию WSUS. В салонах после переиндексации консоль стала открываться за 6 секунд вместо полутора минут. И третье: команда wsusutil.exe reset заставляет сервер сверить метаданные в базе с файлами на диске и докачать недостающее. Полезно после аварийной чистки, но на большом контенте она работает часами и грузит канал.

• Раз в месяц: cleanup по ключам + переиндексация SUSDB.
• Раз в квартал: ревизия списка продуктов и классификаций в Options → Products and Classifications.
• Классификацию Drivers держать выключенной, если вы осознанно не раздаёте драйверы через WSUS.
• Мониторить: свободное место на томе контента, статус последней синхронизации, число машин с Last Contact старше 7 дней.
• Резервная копия — SUSDB и экспорт настроек; восстановление «с нуля» с перекачкой сотен гигабайт контента займёт сутки.

Клиенты не отчитываются: чек-лист диагностики

Порядок, в котором я проверяю. Первое — доходит ли клиент до сервера вообще: Test-NetConnection wsus.example.local -Port 8530 и открытие в браузере http://wsus.example.local:8530/selfupdate/wuident.cab. Если файл скачивается — транспорт живой, проблема в агенте или в базе сервера. Если нет — смотрим IIS и брандмауэр, а не клиента. Второе — применилась ли политика: reg query HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate /s. Удивительно часто там пусто, потому что GPO слинкована не на ту OU или отфильтрована WMI-фильтром.

Третье — дубли SusClientId. Это самая недооценённая проблема в парках, собранных клонированием: все машины из одного образа приходят на WSUS под одним идентификатором и в консоли выглядят как один компьютер, который «то Windows 10, то Windows 11». Лечится сбросом идентификатора и полной пересборкой кэша агента:

Stop-Service wuauserv, bits -Force
$k = 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate'
Remove-ItemProperty -Path $k -Name SusClientId,SusClientIdValidation -ErrorAction SilentlyContinue
Remove-Item -Path "$env:windir\SoftwareDistribution" -Recurse -Force -ErrorAction SilentlyContinue
Start-Service bits, wuauserv
# wuauclt /detectnow удалён начиная с Windows Server 2016 — используем COM
$au = New-Object -ComObject Microsoft.Update.AutoUpdate
$au.DetectNow()

Четвёртое — MIME-типы под Unified Update Platform. С 28 марта 2023 года Windows 11 22H2 и новее получают качественные обновления через UUP, и если на сервере IIS не знает типов .wim (application/x-ms-wim) и .msu (application/octet-stream), клиенты на 22H2+ просто не смогут поставить патчи. Обычно эти типы приезжают с кумулятивным обновлением самого сервера (для Windows Server 2016/2019/2022 — 2023-02 CU или новее), но на серверах, которые сами месяцами не обновлялись, их нет. Добавлять надо на уровне сервера IIS, а не сайта — сайт WSUS Administration должен унаследовать запись, иначе получите ошибку про дубликат mimeMap. И пятое: лог агента на клиенте больше не текстовый, собирается командой Get-WindowsUpdateLog из ETW-трейсов в файл на рабочем столе.

• 0x80244022 — HTTP 503, упал WsusPool. Смотреть IIS, а не клиента.
• 0x8024401C — таймаут запроса к серверу, обычно та же перегруженная база.
• 0x80244010 — превышено число переходов при детекте; чаще всего лечится чисткой SoftwareDistribution.
• 0x80072EE2 — сетевой таймаут: порт, DNS, прокси или неверный FQDN в политике.
• Машина видна в консоли, но «Not yet reported» — почти всегда дубликат SusClientId или незапущенный wuauserv.

План выхода: что я делаю с WSUS у клиентов прямо сейчас

Единого правильного ответа на «чем заменить WSUS» в 2026 году нет, и любой, кто говорит обратное, что-то вам продаёт. Microsoft фактически предлагает три дороги: Windows Autopatch и Intune (нужны лицензии и Entra-инфраструктура — для конторы на 40 мест это заметные деньги и заметная перестройка), Configuration Manager (из пушки по воробьям), либо просто политики отсрочки на клиентском Windows Update без всякого сервера. Для российского юрлица, которое к тому же не факт что имеет доступ к облачным подпискам, третий вариант чаще всего и оказывается рабочим.

Поэтому мой практический план на ближайшие два года такой. Живые, ухоженные WSUS не трогаю: они работают и поддерживаются. Новые ставлю только там, где есть реальное обоснование из второго раздела, и обязательно на SQL Express. Всё остальное перевожу на схему «GPO с отсрочками + Delivery Optimization» — по сути это Windows Update for Business без облачной части, и для парка до 50 машин её хватает. Как только Microsoft назовёт дату удаления роли — а рано или поздно это случится, — у меня будет отработанная схема, а не паника.

И последнее, про приоритеты. Если у вас сейчас есть WSUS и вы не знаете, в каком он состоянии, — не начинайте с миграции. Начните с одного вопроса: когда последний раз ваши машины реально ставили патчи. Ответ на него важнее выбора инструмента раз в двадцать. Компанию ломают не потому, что она использует устаревший WSUS, а потому, что три месяца назад не встал патч на уязвимость, для которой уже месяц как есть публичный эксплойт.

• Работающий WSUS — оставить и обслуживать по регламенту, не мигрировать «из-за статуса deprecated».
• Новые инсталляции — только на SQL Express и только с обоснованием.
• Офисы до 50 мест без узкого канала — GPO-отсрочки + Delivery Optimization, сервер не нужен.
• Intune/Autopatch — считать TCO заранее: лицензии, Entra, переучивание админа.
• Главная метрика — не «есть ли WSUS», а «какой процент машин поставил патчи этого месяца».

Частые вопросы