Windows 10 в WSUS: настраиваем раздельные ветки для Win7 и Win10, чтобы обновления шли под контролем

С сентября у нас в парке появились первые рабочие станции на Windows 10 - тестовые машины, которые мы тогда поставили под GPO-управление и отключили телеметрию. Машин было немного, WSUS справлялся через пень-колоду, и мы это терпели как временное состояние. Теперь терпеть стало сложнее: Windows 10 расползается по паркам клиентов быстрее, чем ожидали. Пора выстраивать нормальный процесс.

Microsoft к этому моменту сделала своё домашнее задание: поддержка Windows 10 в WSUS на Windows Server 2012 R2 доведена до приемлемого состояния. Главное условие - KB3095113 на самом WSUS-сервере, добавляющий поддержку ESD-формата. Без этого KB синхронизация Windows 10 даёт ошибки при скачивании крупных накопленных обновлений. Мы с этим уже сталкивались осенью, теперь это закрытый вопрос.

Что изменилось в структуре обновлений

Windows 10 работает не так, как Windows 7. В WSUS это видно по классификациям: появилась новая категория «Upgrades» в дополнение к привычным «Updates» и «Security Updates». Это не просто патчи - это переходы между крупными версиями ОС. Если не разобраться с этим заранее, WSUS может начать одобрять апгрейды автоматически - и машины в парке начнут менять версию Windows без предупреждения.

Нас такая перспектива не устраивает. Поэтому первое, что настраиваем: в свойствах WSUS-сервера в разделе «Products and Classifications» включаем «Windows 10» как продукт и явно контролируем, что попадает в автоодобрение, а что - нет.

Категорию «Upgrades» в автоодобрение не пускаем. Только ручное. Обновления безопасности и критические апдейты - как обычно, через автоодобрение с задержкой в несколько дней.

Раздельные ветки в WSUS

Главное архитектурное решение - разделить компьютерные группы. У нас теперь три ветки:

• Windows 7 / 8.1 - существующая группа, к ней ничего не трогаем. Свои политики одобрения, свои тесты.
• Windows 10 - Pilot - небольшая группа тестовых машин, куда прилетают обновления сразу после одобрения на WSUS. Первый рубеж проверки.
• Windows 10 - Production - основная группа. Обновления попадают сюда с задержкой в одну-две недели после прохождения Pilot. Задержку реализуем через правила автоодобрения или просто ручным переносом одобрений.

Это не изобретение - та же схема, по которой давно живут обновления серверного парка. Просто теперь она нужна и на десктопах, потому что Windows 10 обновляется активнее Windows 7.

GPO для клиентов

На стороне клиентских машин - настройка через групповые политики. В сентябре мы уже прописывали адрес WSUS и базовые параметры. Теперь добавляем то, что тогда отложили.

Политика Defer Upgrades. Ветка Computer Configuration -> Administrative Templates -> Windows Components -> Windows Update. Политика «Defer Upgrades and Updates» - включаем. Это даёт возможность задержать не только обновления (Updates), но и переходы между версиями (Upgrades) на уровне самой ОС, в дополнение к тому, что контролирует WSUS. Двойная страховка.

Отключение Windows Update for Business на машинах, которые идут через WSUS. Если оба механизма активны одновременно, поведение становится предсказуемым плохо. Приоритет - WSUS, Windows Update for Business - выключить.

Планирование перезагрузок. Через политику «Schedule Restart» задаём время автоматической перезагрузки после установки обновлений. Для рабочих станций выбираем нерабочие часы. Перезагрузки в момент работы раздражают пользователей и создают лишние обращения в поддержку.

Как проверяем что всё работает

Стандартный способ - смотреть клиентский лог. В Windows 10 это уже не %windir%\WindowsUpdate.log в текстовом виде, а ETW-трейс. Читать его можно командой:

Get-WindowsUpdateLog

Она собирает трейс и кладёт читаемый текстовый лог на рабочий стол. Там видно: куда клиент ходит за обновлениями (должен быть адрес нашего WSUS), что нашёл, что скачал, что установил. Если что-то пошло в Microsoft напрямую - видно сразу.

Второй контрольный момент - консоль WSUS. В отчёте «Computer Status» проверяем, что Windows 10-машины числятся в нужных группах и последний контакт с сервером был недавно. Машина, которая молчит дольше трёх дней - повод посмотреть, не отвалилась ли политика.

Что ещё предстоит

Синхронизация Pilot и Production работает, машины обновляются через WSUS, апгрейды заблокированы - базовый порядок есть. Но остаётся открытый вопрос про SCCM. У части клиентов есть System Center, и там управление обновлениями Windows 10 немного другое: SCCM интегрируется с WSUS, но добавляет свой слой одобрений и свою логику deployment-колец. Это отдельная история, которую надо прорабатывать для каждого такого клиента индивидуально.

Пока управляем через чистый WSUS - это достаточно для парков без SCCM и даёт нормальный контроль без лишней сложности. Для клиентов на managed-обслуживании этот порядок теперь часть стандартного регламента: новые Windows 10-машины сразу попадают в Pilot-группу, через неделю - в Production.