Установка и первоначальная настройка сервера WSUS представлена в части 1.

Описание разделено на две страницы из-за объема. На данной странице поясняется, как добавить клиентов через GPO в группу и утвердить обновления вручную или автоматически.

 

Группы компьютеров.

Все компьютеры в сети разделены на три группы:

1-тестовая группа.

2-обычные компьютеры пользователей.

3-сервера.

Создаем эти группы.

 

Указываем понятное название.

 

В результате получилось две группы.

Для серверов нужно создать отдельную группу. В данном случае она не показана, чтоб не усложнять понимание. Участников групп распределяем через GPO.

 

Групповая политика (GPO).

Создаём объект групповой политики на контроллере домена.

Первоначально GPO создается на тестовом OU, и после проверки корректной работы привязывается на рабочий OU.

Необходимо создать 3 разных GPO для тестовой группы, рабочих ПК и серверов, потому что каждая GPO добавляет в одну группу.

Указываем удобное рабочее название, например, WSUS-ON-TEST-GROUP-GPO (WORKSTATIONS-GROUP-GPO, SERVERS-GROUP-GPO и тп). Кратко, для примера будет WSUS-ON-GPO.

ON в названии – потому что эта GPO будет включать настройку. Для отключения нужна соответствующая GPO тоже, с OFF в названии.

 

Редактируем созданную GPO.

 

Выполняем настройку для компьютера. Переходим в центр обновления Windows по пути:

Конфигурация компьютера >> Политики >> Административные шаблоны >> Компоненты Windows >> Центр обновления Windows.

 

Редактируем следующие политики.

 

Политика «Указать размещение службы обновлений Майкрософт в интрасети» – перенаправляет клиентские компьютеры с Интернета на корпоративный сервер WSUS для получения обновлений.

Активируем – «Включено».

Указываем адреса.

Сервер обновлений:

Сервер состояния:

 

Политика «Разрешить клиенту присоединение к целевой группе» – позволяет автоматически распределять компьютеры по группам на сервере WSUS.

Активируем – «Включено».

Указываем имя целевой группы.

 

Политика «Настройка автоматического обновления» – определяет, как и когда обновления устанавливаются на клиентских компьютерах.

Активируем настройки:

«Включено».

Режим: 4 – автоматическая загрузка и установка по расписанию.

День установки: Каждый день

Время установки: 3:00 (по умолчанию), но лучше выбрать 13:00 или другое окно в рабочее время, когда компьютеры включены.

 

Политика «Не подключаться к расположениям Центра обновления Windows в Интернете» – запрещает компьютерам получать обновления напрямую из Интернета. Все обновления идут только через WSUS.

Активируем – «Включено».

 

Политика «Не выполнять автоматическую перезагрузку при автоматической установке обновлений, если в системе работают пользователи» – предотвращает автоматическую перезагрузку компьютера во время работы пользователя.

Активируем – «Включено».

 

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

 

Распределение по группам.

Далее настраиваем использование созданной GPO при распределении компьютеров по группам.

Переходим на WSUS-сервер >> Параметры >> Компьютеры.

 

Отмечаем «Использовать на компьютерах групповую политику или параметры реестра». Эта настройка позволяет централизованно управлять распределением компьютеров по группам WSUS через AD и GPO, исключая ручное администрирование.

Когда правило включено WSUS не позволяет вручную перемещать компьютеры между группами, берет группу из настроек реестра клиента, распределение компьютеров происходит автоматически.

 

Проверка настроек на клиенте.

Проверяем на тестовом клиенте получает ли он GPO. Обновляем GPO через cmd или PowerShell.

 

В реестре должны появиться пути на WSUS-сервер. Проверяем. Переходим в реестр.

Win+R

Если записи есть, значит GPO применилась.

 

Проверка через PowerShell.

 

Проверяем доступность порта (powershell).

Тест порта проходит. Но компьютер клиента в списке сервера не появился. Одна из причин, по которой клиенты не появляются на сервере – брандмауэр Windows или программа, его контролирующая (например, KES). В данном случае была именно эта причина. Нужно открыть порт 8530 для заданных сетей или добавить сеть в доверенные для антивируса. Первый вариант предпочтительнее.

 

Проверяем службу wuauserv (cmd).

WUAUServ – Windows Update Automatic Update Service (Служба автоматического обновления Windows). Обеспечивает работу центра обновления Windows – поиск, загрузку и установку обновлений. На клиентских компьютерах эта служба отвечает за связь с сервером WSUS для получения одобренных обновлений.

Через cmd.

или в PowerShell

Статус RUNNING.

Но, служба не обязательно должна быть постоянно RUNNING. Служба стартует автоматически, когда пришло время запланированной проверки обновлений, выполняется wuauclt или usoclient, пользователь нажал «Проверить обновления», системе нужно отправить отчёт в WSUS. После выполнения задачи служба останавливается сама.

wuauclt – клиент автоматического обновления Windows.

usoclient – клиент оркестратора сеансов обновления (управление сеансами обновлений).

Можно проверить тип запуска (cmd).

START_TYPE : DEMAND_START – значит ок.

Специально вручную запускать эту службу не нужно. Это плохая практика. Правильный способ – зайти в центр обновления Windows и проверить наличие обновлений. ОС Windows сама запускает нужные триггеры, wuauserv стартует, клиент регистрируется в WSUS, отправляется отчёт. Это официально поддерживаемый способ.

 

Проверка через браузер.

Должен скачиваться файл wuident.cab

 

Так же можно проверить события Event Viewer. Среди них должны быть такие:

Event ID 16 – контакт с WSUS.

Event ID 44 – отчёт отправлен.

Event ID 31 или 41 – ошибки.

 

В результате проделанной настройки тестовый клиент появился в WSUS-сервере в разделе «Все компьютеры».

Так как применена настройка «Использовать на компьютерах групповую политику или параметры реестра», изменить группу компьютера вручную не получится. Настройка не активна.

Можно убедится, что клиенту было назначено переместиться в выбранную группу через GPO командой PowerShell (на клиенте).

Если этого не произошло, вариантов действий два: 1- подождать, 2- на клиенте выполнить команды.

Немедленная проверка обновлений.

 

Отправка данных о состоянии обновлений на сервер WSUS.

 

Если клиентов сотни, то вар.2 не подходит. Для теста можно убедиться что работает. После выполнения команд или ожидания, компьютер в нужной группе.

Для отображения новых компьютеров нажимаем кнопку «Обновить».

 

​

Управление обновлениями.

Проверяем синхронизацию. Убеждаемся, что она выполняется успешно.

Синхронизация – это обмен метаданными между WSUS-сервером и Microsoft Update. Во время синхронизации WSUS получает только информацию, а не пакеты .cab/.msu. Это метаданные обновлений, для каждого апдейта KB номер, к какому продукту относится, класс (Security, Cumulative, Upgrade и т.д.), supersedence (что чем заменено), требования (версия ОС, архитектура) и тд.

Файлы начнут загружаться только после утверждения обновления для группы компьютеров.

 

Переходим в обновления. Настраиваем фильтр.

Утверждение: Не утверждено.

Состояние: Требуется.

Таким выбором мы можем увидеть обновления, которые ещё не разрешены и обновления, которые реально нужны клиенту.

Среди обнаруженных фильтром обновлений первые 4 строки Windows 11, version 25H2 класс: Upgrades – это Feature Update (переход на новую версию Windows). По сути переустановка ОС. Пакет большого размера. Для теста WSUS не подходит.

Последняя строка – это накопительное обновление для Windows 11 Version 24H2, класс: «Обновления системы безопасности». Это обычное накопительное обновление, стандартный ежемесячный патч. Это идеальный вариант для теста WSUS.

 

Утверждаем это обновление. Отмечаем группу с компьютерами, на которую это обновление будет распространяться.

 

Можно настроить автоматическое утверждение. Об этом в конце страницы.

Далее начнется автоматическое скачивание пакета обновлений.

Если скачивание не началось – утверждаем это обновление на все компьютеры для проверки. Тестовый ПК мог находиться там до начала утверждения.

Просмотр состояния возможен в разделе «Обновления».

Убедиться что сервер скачивает файлы, можно посмотрев логи (на сервере).

Согласно логам процесс активно идет. Ожидаем.

 

Просмотр статуса на клиенте через центр обновлений.

 

Просмотр лога обновления на клиенте.

В логе видно, что источник обновления – WSUS. Установка выполнится по расписанию.

 

Далее существует несколько вариантов работы. В случае с нашей организацией главной целью было переориентировать все компьютеры на WSUS, чтоб не перегружать интернет-канал и получать обновления для всех клиентов из одной локальной точки. За обновлениями некому следить, поэтому в данном случае настроено автоматическое утверждение всех критических обновлений, чтоб не заходить каждый раз, каждый месяц и не подтверждать это вручную. Feature upgrades под ручным контролем. Для серверов отдельное обновление с утверждение вручную. Далее как это настроено.

 

Правила автоматического утверждения.

Переходим в настройку Параметры >> Автоматические утверждения.

 

Создаем новое правило №1. Это будет правило для обновления тестовой группы компьютеров.

 

Содержание правила.

 

Пояснение каждого пункта.

Когда обновление затрагивает конкретный класс – определяет тип обновлений, к которым применяется правило автоутверждения.

Критические обновления – исправления серьёзных ошибок.

Накопительные пакеты обновления – основные ежемесячные обновления.

Обновления системы безопасности – патчи безопасности.

Обновления – не критичные, но нужные исправления.

Такая настройка позволяет автоматически утверждать только важные и обязательные обновления, исключая драйверы и необязательные пакеты.

 

Когда обновление затрагивает конкретный продукт – ограничивает правило обновлениями только для выбранных продуктов Microsoft.

Основной и достаточный вариант: Windows 10 и Windows 11, для серверов Windows Server 2019-2025. Такая настройка покрывает накопительные обновления, обновления безопасности, критические обновления, обычные обновления ОС.

 

Утвердите обновление для – определяет группу компьютеров WSUS, для которой обновление будет автоматически утверждено.

Выбираем тестовую группу.

 

Правило №2.

Создаем второе правило для основной группы компьютеров, которое выполнит авто обновление через 7 дней. Все настройки аналогичные, добавляется срок выполнения и другая группа.

 

Установить крайний срок для – задает срок, после которого установка обновления становится обязательной.

В конце указываем логичное понятное название для правила.

 

В результате два правила.

Как это работает.

Обновление вышло. Выполнилось на тестовой группе компьютеров. Наблюдаем. Если ни каких проблем не проявляется в течение 7 дней ничего не делаем. Обновление устанавливается на остальные ПК. Если обновление окажется проблемным, то в течение 7 дней нужно это заметить и отключить автоматическое обновление до следующего раза.

Для серверов не нужно создавать автоутверждений. Отдельная группа и только ручное утверждение.

 

Расписание.

 

При установке роли WSUS было указано время 1 час ночи.

Это время синхронизации WSUS, а не установки. В 01:00 WSUS подключается к Microsoft Update и проверяет наличие обновлений.

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

Клиенты устанавливают обновления самостоятельно при следующем обращении к WSUS, согласно политике Windows Update (по умолчанию через каждые 22 часа).

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

Эффективные параметры установки обновлений на клиенте определяются результирующей групповой политикой и проверяются через gpresult, rsop.msc и параметры реестра Windows Update.

Просмотр GPO на клиенте.

В сформированной результирующей политике переходим в Центр обновления Windows. Выбираем GPO «Настройка автоматического обновления».

И видим, во первых, то что применяется GPO из контроллера домена, во вторых время обновления – 3:00, как мы это и указывали ранее.

 

Проверка через PowerShell.

UseWUServer = 1 – использовать сервер WSUS.

NoAutoUpdate = 0 — автообновления включены.

AUOptions = 4 – автоматическая установка по расписанию.

ScheduledInstallDay  = 0 – каждый день.

ScheduledInstallTime = 3 – 03:00 часа ночью.

NoAutoRebootWithLoggedOnUsers = 1 – если пользователь залогинен, то перезагрузки не будет, будет уведомление.

Значит, клиент каждые сутки в 03:00 проверяет утверждённые обновления и устанавливает их. Но в это время все компьютеры выключены как правило.

Что происходит, если ПК был выключен.

В 03:00 плановое окно установки. ПК выключен – окно пропущено. После включения в 08:00 Windows Update не считает это просроченной задачей планировщика. Он запускается по своим триггерам (первое подключение к сети, простой системы, внутренние таймеры). В результате установка может начаться через 10-90 минут после включения, а может ждать следующего окна, то есть нет гарантированного времени установки. Поэтому 3:00 это не очень удачное время для обновления клиентов. Оно больше подходит для серверов.

В итоге плановое время установки обновлений назначено (через GPO) на 13:00. ПК включены, время совпадает с перерывом, отложенный перезапуск. Выбор дневного окна обеспечивает предсказуемую установку и управляемость процесса.

Если пользователь оставил ПК и ушел, то перезапуск произойдет через некоторое время простоя. Если пользователь активен, то перезапуск произойдет, когда вечером компьютер будет выключен естественным способом при уходе с работы. Если пользователь неделями не перезагружает ПК и всегда залогинен, то обновление будет установлено, но активируется только после перезапуска. В таком случае можно настроить еще одну GPO отключающую все компьютеры в сети в определенное время.

 

Дополнение.

​

​

​