Настройка клиентов WSUS с помощью групповых политик

Каждый администратор осознает важность своевременных обновлений, особенно если это касается критических обновлений безопасности. Однако с ростом сети и увеличением числа программных продуктов это становится весьма непростой задачей. Значит самое время развернуть WSUS (Windows Server Update Services) — локальный сервер обновлений в вашей сети.

Этим вы убьете сразу несколько зайцев: значительно уменьшите загрузку канала и потребляемый интернет трафик, а также получите в руки мощный инструмент для контроля и управления процессом обновлений. Отныне все локальные ПК будут обновляться с вашего сервера и устанавливать только выбранные вами обновления.

Внимание! Данный материал предназначен для устаревших версий Windows Server, рекомендуем также ознакомиться с актуальной статьей: Windows Server 2012 — установка и настройка WSUS.

Приступим. Перед установкой WSUS следует подготовить сервер, мы будем использовать Windows Server 2008 R2, однако с небольшими поправками все сказанное будет справедливо для других версий Windows Server. Что нам понадобится:

• IIS 6 или выше,
• .NET Framework 2.0 или выше,
• Report Viewer Redistributable 2008,
• SQL Server 2005 SP2 Express или выше.

При скачивании обращаем внимание на разрядность, для 64-битной ОС скачиваем 64-битные версии продуктов.Пока идет скачивание добавим роли сервера. Нам понадобятся Веб-сервер (IIS) и Сервер приложений (в предыдущих версиях Windows Server установите .NET Framework). Сервер приложений устанавливается со значениями по умолчанию, а в Веб-сервере необходимо добавить следующие опции:

• ASP.NET
• Windows — проверка подлинности
• Сжатие динамического содержимого
• Совместимость управления IIS6

Добавив необходимые роли, установим Report Viewer и SQL Server c параметрами по умолчанию. Все готово, можно устанавливать WSUS.Запустив инсталлятор, выбираем установку сервера и консоли администрирования, папку установки. В параметрах базы данных указываем наш SQL-сервер. Остальные настройки можно оставить по умолчанию. Сразу после установки запустится мастер начальной настройки. Все опции довольно просты и понятны. В параметрах синхронизации указываем откуда наш сервер будет получать обновления: с сервера Microsoft или с другого WSUS сервера. Последний вариант следует использовать если вам требуется развернуть дополнительный сервер обновлений, например, для филиала. В этом случае подчиненный сервер будет получать только одобренные вами обновления.На следующей закладке, при необходимости, указываем параметры прокси-сервера, и выполняем первичное подключение. Будет загружена информация от вышестоящего сервера: списки продуктов, типов обновлений и т.д.При выборе продуктов не жадничайте, указывайте только то, что вам реально нужно, впоследствии вы всегда сможете изменить данный список.На следующей странице укажите какие классы обновлений вы хотели бы получать, здесь все зависит от политики обновлений на вашем предприятии. Следует помнить, что обновления драйверов и пакеты новых функций крайне не рекомендуется разворачивать автоматически, без предварительного тестирования. Если у вас нет возможности этим заниматься, то указывать эти классы вам ни к чему.Не забудьте также задать расписание для синхронизации с вышестоящим сервером. На этом первоначальная настройка закончена. Открыв консоль (доступна в меню Администрирование), первым делом запустите ручную синхронизацию, чтобы скачать все имеющиеся на сегодняшний день обновления для выбранных продуктов. В зависимости от того, чего и сколько вы выбрали при настройке, а также скорости вашего подключения это может занять продолжительное время.Пока идет синхронизация займемся настройкой клиентских ПК. Если у вас развернута Active Directory это можно сделать с помощью групповых политик. Откройте Управление групповой политикой, выберите необходимый объект и щелкнув правой кнопкой мышки нажмите Изменить. В открывшемся окне выберите Конфигурация компьютера — Политики — Административные шаблоны — Центр обновления Windows. Нас интересует параметр Указать размещение службы обновлений Microsoft в интрасети. Переводим его в положение Включено и указываем путь к нашему WSUS серверу в виде http:\ИМЯ_СЕРВЕРА.

Также советуем настроить опцию Настройка автоматического обновления, которая полностью повторяет аналогичную настройку на клиентских ПК. Через некоторое время, необходимое для обновления групповых политик, компьютеры вашей сети начнут подключаться к серверу и получать обновления. Если ваша сеть имеет одноранговую структуру, то вам придется настраивать каждый ПК в отдельности. Делается это через Редактор локальной групповой политики (Пуск — Выполнить — gpedit.msc), сам процесс настройки полностью аналогичен вышеописанному.Контролировать количество ПК и их статус вы можете в разделе Компьютеры консоли администрирования.Информации вполне достаточно, чтобы быстро оценить общую ситуацию и обратить внимание на проблемные места. Красные крестики указывают на то, что на данных ПК произошли ошибки в обновлении, с каждым таким случаем надо разбираться в отдельности. По каждому обновлению формируется детальный отчет, содержащий все необходимые для анализа проблемы данные.Также рекомендуем разбить ПК на группы, для каждой группы можно назначить свою политику обновлений. Так в отдельную группу можно выделить сервера, для которых автоматически устанавливать только критические обновления безопасности. Вот мы и подошли к еще одной важной настройке сервера — автоматическом одобрении. Клиентские ПК могут получать только одобренные обновления, но каждый раз делать все вручную нереально, поэтому часть обновлений можно одобрять автоматически. Откроем Параметры — Автоматические одобрения и активируем уже имеющуюся там политику, которая позволяет автоматически устанавливать критические обновления и обновления безопасности.Здесь вы можете создавать свои правила и назначать их любой группе ПК. Например мы создали правило: автоматически одобрять все обновления MS Office группы Рабочие станции.Просмотреть все доступные обновления можно в разделе Обновления, здесь же можно одобрять их вручную. Мы рекомендуем завести один или несколько тестовых ПК (можно виртуальных) и тестировать на них обновления и пакеты новых функций и только после этого одобрять обновления для установки. Одобрить обновления можно как для всех ПК, так и для группы, в качестве примера мы одобрили установку пакета Silverlight для группы Рабочие станции.В качестве обслуживания сервера стоит время от времени (где-то раз в месяц) проводить очистку сервера. Это позволит избежать черезмерного увеличения размеров базы за счет удаления невостребованных, уже не нужных и неодобренных вами обновлений.На этой ноте мы и закончим наше повествование, материал данной статьи позволит вам быстро развернуть и сделать базовые настройки сервера обновлений. С задачей тонкой настройки вы должны без труда справиться самостоятельно.

В одной из предыдущих статей мы подробно описали процедуру установки сервера WSUS на базе Windows Server 2012 R2 / 2016. После того, как вы настроили сервер, нужно настроить Windows-клиентов (сервера и рабочие станции) на использование сервера WSUS для получения обновлений, чтобы клиенты получали обновления с внутреннего сервера обновлений, а не с серверов Microsoft Update через Интернет. В этой статье мы рассмотрим процедуру настройки клиентов на использование сервера WSUS с помощью групповых политик домена Active Directory.

Содержание:

Групповые политики AD позволяют администратору автоматически назначить компьютеры в различные группы WSUS, избавляя его от необходимости ручного перемещения компьютеров между группами в консоли WSUS и поддержки этих групп в актуальном состоянии. Назначение клиентов к различным целевым группам WSUS основывается на метке в реестре на клиенте (метки задаются групповой политикой или прямым редактированием реестра). Такой тип соотнесения клиентов к группам WSUS называется client side targeting (Таргетинг на стороне клиента).

Предполагается, что в нашей сети будут использоваться две различные политики обновления — отдельная политика установки обновлений для серверов (Servers) и для рабочих станций (Workstations). Эти две группы нужно создать в консоли WSUS в секции All Computers.

Совет. Политика использования сервера обновлений WSUS клиентами во многом зависит от организационной структуры OU в Active Directory и правил установки обновлении в организации. В этой статье мы рассмотрим всего лишь частный вариант, позволяющий понять базовые принципы использования политик AD для установки обновлений Windows.

В первую очередь необходимо указать правило группировки компьютеров в консоли WSUS (targeting). По умолчанию в консоли WSUS компьютеры распределяются администратором по группам вручную (server side targeting). Нас это не устраивает, поэтому укажем, что компьютеры распределяются в группы на основе client side targeting (по определенному ключу в реестре клиента). Для этого в консоли WSUS перейдите в раздел Options и откройте параметр Computers. Поменяйте значение на Use Group Policy or registry setting on computers (Использовать на компьютерах групповую политику или параметры реестра). 

Теперь можно создать GPO для настройки клиентов WSUS. Откройте доменную консоль управления групповыми политиками (Group Policy Management) и создайте две новые групповые политики: ServerWSUSPolicy и WorkstationWSUSPolicy.

Групповая политика WSUS для серверов Windows

Начнем с описания серверной политики ServerWSUSPolicy.

Настройки групповых политик, отвечающих за работу службы обновлений Windows, находятся в разделе GPO: Computer Configuration -> Policies-> Administrative templates-> Windows Component-> Windows Update (Конфигурация компьютера -> Административные шаблоны -> Компоненты Windows -> Центр обновления Windows).

В нашей организации мы предполагаем использовать данную политику для установки обновлений WSUS на сервера Windows. Предполагается, что все попадающие под эту политику компьютеры будут отнесены к группе Servers в консоли WSUS. Кроме того, мы хотим запретить автоматическую установку обновлений на серверах при их получении. Клиент WSUS должен просто скачать доступные обновления на диск, отобразить оповещение о наличии новых обновлений в системном трее и ожидать запуска установки администратором (ручной или удаленной с помощью модуля PSWindowsUpdate) для начала установки. Это значит, что продуктивные сервера не будут автоматически устанавливать обновления и перезагружаться без подтверждения администратора (обычно эти работы выполняются системным администратором в рамках ежемесячных плановых регламентных работ). Для реализации такой схемы зададим следующие политики:

• Configure Automatic Updates (Настройка автоматического обновления): Enable. 3 – Auto download and notify for install (Автоматически загружать обновления и уведомлять об их готовности к установке) – клиент автоматически скачивает новые обновлений и оповещает об их появлении;
• Specify Intranet Microsoft update service location (Указать размещение службы обновлений Майкрософт в интрасети): Enable.  Set the intranet update service for detecting updates (Укажите службу обновлений в интрасети для поиска обновлений): http://srv-wsus.winitpro.ru:8530, Set the intranet statistics server (Укажите сервер статистики в интрасети): http://srv-wsus.winitpro.ru:8530 – здесь нужно указать адрес вашего сервера WSUS и сервера статистики (обычно они совпадают);
• No auto-restart with logged on users for scheduled automatic updates installations (Не выполнять автоматическую перезагрузку при автоматической установке обновлений, если в системе работают пользователя): Enable – запретить автоматическую перезагрузку при наличии сессии пользователя;
• Enable client-side targeting(Разрешить клиенту присоединение к целевой группе): Enable. Target group name for this computer (Имя целевой группу для данного компьютера): Servers – в консоли WSUS отнести клиенты к группе Servers.

Примечание. При настройке политики обновления советуем внимательно познакомиться со всеми настройками, доступными в каждой из опций раздела GPO Windows Update и задать подходящие для вашей инфраструктуры и организации параметры.

Политика установки обновлений WSUS для рабочих станций

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

В данной GPO (WorkstationWSUSPolicy) мы указываем:

• Allow Automatic Updates immediate installation (Разрешить немедленную установку автоматических обновлений): Disabled — запрет на немедленную установку обновлений при их получении;
• Allow non-administrators to receive update notifications (Разрешить пользователям, не являющимся администраторами, получать уведомления об обновлениях): Enabled — отображать не-администраторам предупреждение о появлении новых обновлений и разрешить их ручную установку;
• Configure Automatic Updates: Enabled.   Configure automatic updating: 4 — Auto download and schedule the install. Scheduled install day: 0 — Every day. Scheduled install time: 05:00 – при получении новых обновлений клиент скачивает в локлаьный кэш и планирует их автоматическую установку на 5:00 утра;
• Target group name for this computer:Workstations – в консоли WSUS отнести клиента к группе Workstations;
• No auto-restart with logged on users for scheduled automatic updates installations:Disabled — система автоматически перезагрузится через 5 минут после окончания установки обновлений;
• Specify Intranet Microsoft update service location: Enable.  Set the intranet update service for detecting updates: http://srv-wsus.winitpro.ru:8530, Set the intranet statistics server: http://srv-wsus.winitpro.ru:8530 –адрес корпоративного WSUS сервера.

В Windows 10 1607 и выше, несмотря на то, что вы указали им получать обновления с внутреннего WSUS, все еще могут пытаться обращаться к серверам Windows Update в интернете. Эта «фича» называется Dual Scan. Для отключения получения обновлений из интернета нужно дополнительно включать политику Do not allow update deferral policies to cause scans against Windows Update (ссылка).

Совет. Чтобы улучшить «уровень пропатченности» компьютеров в организации, в обоих политиках можно настроить принудительный запуск службы обновлений (wuauserv) на клиентах. Для этого в разделе Computer Configuration -> Policies-> Windows Setings -> Security Settings -> System Services найдите службу Windows Update и задайте для нее автоматический запуск (Automatic).

Назначаем политики WSUS на OU Active Directory

Следующий шаг – назначить созданные политики на соответствующие контейнеры (OU) Active Directory. В нашем примере структура OU в домене AD максимально простая: имеются два контейнера – Servers (в нем содержаться все сервера организации, помимо контроллеров домена) и WKS (Workstations –компьютеры пользователей).

Совет. Мы рассматриваем лишь один довольно простой вариант привязки политик WSUS к клиентам. В реальных организациях возможно привязать одну политику WSUS на все компьютеры домена (GPO с настройками WSUS вешается на корень домена), разнести различные виды клиентов по разным OU (как в нашем примере – мы создали разные политики WSUS для серверов и рабочих станций), в больших распределенных доменах можно привязывать различные WSUS сервера к сайтам AD, или же назначать GPO на основании фильтров WMI, или скомбинировать перечисленные способы.

Чтобы назначить политику на OU, щелкните в консоли управления групповыми политиками по нужному OU, выберите пункт меню Link as Existing GPO и выберите соответствующую политику.

Совет. Не забудьте про отдельную OU с контроллерами домена (Domain Controllers), в большинстве случаев на этот контейнер следует привязать «серверную» политику WSUS.

Точно таким же способом нужно назначить политику WorkstationWSUSPolicy на контейнер AD WKS, в котором находятся рабочие станции Windows.

Осталось обновить групповые политики на клиентах для привязки клиента к серверу WSUS:

gpupdate /force

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

Данный reg файл можно использовать для переноса настроек WSUS на другие компьютеры, на которых не удается настроить параметры обновлений с помощью GPO (компьютеры в рабочей группе, изолированных сегментах, DMZ и т.д.)

Windows Registry Editor Version 5.00[HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindowsWindowsUpdate]"WUServer"="http://srv-wsus.winitpro.ru:8530""WUStatusServer"="http://srv-wsus.winitpro.ru:8530""UpdateServiceUrlAlternate"="""TargetGroupEnabled"=dword:00000001"TargetGroup"="Servers""ElevateNonAdmins"=dword:00000000[HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindowsWindowsUpdateAU]"NoAutoUpdate"=dword:00000000 –"AUOptions"=dword:00000003"ScheduledInstallDay"=dword:00000000"ScheduledInstallTime"=dword:00000003"ScheduledInstallEveryWeek"=dword:00000001"UseWUServer"=dword:00000001"NoAutoRebootWithLoggedOnUsers"=dword:00000001

Также удобно контролировать применённые настройки WSUS на клиентах с помощью rsop.msc.

И через некоторое время (зависит от количества обновлений и пропускной способности канала до сервера WSUS) нужно проверить в трее наличие всплывающего оповещений о наличии новых обновлений. В консоли WSUS в соответствующих группах должны появиться клиенты (в табличном виде отображается имя клиента, IP, ОС, процент их «пропатченности» и дата последнего обновлений статуса). Т.к. мы политиками привязали компьютеры и серверы к различным группам WSUS, они будут получать только обновления, одобренные к установке на соответствующие группы WSUS.

Примечание. Если на клиенте обновления не появляются, рекомендуется внимательно изучить на проблемном клиенте лог службы обновлений Windows (C:WindowsWindowsUpdate.log). Обратите внимание, что в Windows 10 (Windows Server 2016) используется другой формат журнала обновлений WindowsUpdate.log. Клиент скачивает обновления в локальную папку C:WindowsSoftwareDistributionDownload. Чтобы запустить поиск новых обновлений на WSUS сервере, нужно выполнить команду:

wuauclt /detectnow

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

wuauclt /detectnow /resetAuthorization

В особо сложных случаях можно попробовать починить службу wuauserv так. При возникновении ошибки 0x80244010 при получении обновлений на клиентах, попробуйте изменить частоту проверки обновлений на сервере WSUS с помощью политики Automatic Update detection frequency.

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

Третья заметка из серии про WSUS. Первая — тут, вторая — тут

Настройка компьютеров рабочей группы или отдельно стоящих серверов<o>

Для настройки компьютеров в данном случае потребуется оснастка «Редактор объекта групповой политики». Чтобы ее открыть, сделайте следующее:<o>

1. Выбрать на сервере оснастку «Редактор объектов групповой политики».<o>
2. Хочу создать правило для обновления ОС компьютера. Открываю во вкладке «Конфигурация компьютера» ветку Политики – Административные шаблоны – Компоненты Windows – Центр обновления Windows<o>
3. Выбираю правило «Настройка автоматического обновления».<o>
4. В окне настройки автоматического обновления включаю правило и указываю параметры. По умолчанию выбран режим настройки №3 – автоматическая загрузка и уведомление об установке. Возможна так же установка обновлений по расписанию. Далее —  «Применить» и «Следующий параметр»<o>
5. Следующий параметр — правило «Указать размещение службы обновлений Майкрософт в интрасети», указать расположение службы обновлений, а так же сервер статистики (у меня в этой роли выступает мой же сервер). Жмем — ОК. <o>
6. Закрыть оснастку<o>

Все… правила начнут действовать сразу.<o>

Настройка компьютеров домена<o>

Для настройки компьютеров домена на обновление с корпоративного сервера WSUS необходимо иметь права администратора домена Windows (банально звучит 🙂 ).<o>Для настройки вам потребуется оснастка GPMC (Group Policy Management Console — Оснастка Управления Групповой Политикой).<o>Шаги по настройке: 1. Запустить с помощью меню Пуск — Выполнить — GPMC.msc<o>2. Открыть ветку Домены – Имя_Домена – Объекты групповой политики и правой кнопкой мыши выбрать меню «Создать» 3. В поле «Имя» указать имя нового объекта групповой политики (у меня — “WSUS Group Policy”), ОК. 4. В правом окне оснастки найти имя объекта и правой кнопкой выбрать «Изменить». Откроется оснастка «Редактор управления групповыми политиками» 5. Далее, необходимо выполнить те же самые шаги, что описаны в предыдущем разделе.<o>Объект групповой политики (GPO) создан, но созданный GPO является лишь голым каркасом. Для того, чтобы оно заработала, необходимо сделать привязку этой GPO к контейнеру Windows AD. Именно те компьютеры домена, которые находятся в этом контейнере, будут выполнять эти инструкции (т.е. обновляться). <o>Важно:

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

Далее привязываем созданные объекты групповых политик к соответствующим контейнерам Windows AD.<o>У примеру нужно обновлять все компьютеры домена ( в принципе так и надо).<o>1. Открыть в оснастке «Управление групповой политикой» «Лес: Имя_Леса – Домены – Имя_домена» 2. выбираем меню «Связать существующий объект групповой политики…» 3. В окне «Выбор объекта групповой политики» найти соответствующий GPO. Жамкаем ОК.<o>

Фильтры WMI для GPO<o>

Правила хорошего сисадминского тона — обновлять клиентские и серверные ОС с помощью отдельных групповых политик домена. В данном случае предполагаю, что:<o>

•  — серверные ОС лучше обновлять вручную в рамках плановых регламентных работ (осторожность и еще раз осторожность, бывают печальные последствия);<o>
•  — клиентские ОС лучше обновлять автоматически. Обновлять их вручную весьма проблематично, а пользователи это делать не будут (даже если им показать как).<o>

Реализуем вышеуказанное:<o>1. в оснастке GPMC.msc следует создать раздельные GPO. Я создал такие:<o>

• ServerOS WSUS Group Policy<o>
• ClientOS  WSUS Group Policy<o>

и настроил их на ручной (автоматическая загрузка и уведомление об установке) и автоматический режимы обновления ОС соответственно.<o>2. в той же оснастке создаю два WMI-фильтра. Именно эти фильтры и будут определять, которая из выше указанных GPO будет действовать при обновлении каждого компьютера вашей сети.<o>3. связать фильтры WMI с соответствующими GPO, а обе эти GPO уже можно будет связать прямо с доменом или сайтом.<o>

Создание фильтров:

В оснастке GPMC идем по ветке Лес — Домены — _Имя_домена_ — Фильтры WMI. Правой кнопкой «Создать» создаем фильтр с именем Server OS’s and DC<o>Добавляем в него запрос в пространство rootCIMv2<o>select * from Win32_OperatingSystem where ProductType=»2″ or ProductType=»3″<o><o>Этот фильтр позволит GPO с именем «ServerOS WSUS Group Policy» работать только с компьютерами под управлением серверных OS Windows (в том числе, с контроллерами домена).<o>Аналогично создаем фильтр с именем Client OS’s<o>Добавляем в него запрос в rootCIMv2<o>select * from Win32_OperatingSystem where ProductType=»1″<o>(ProductType=”1″ — Work Station; ProductType=”2″ — Domain Controller; ProductType=”3″ — Server)<o>Этот фильтр позволит GPO с именем «ClientOS WSUSGroupPolicy» работать только с компьютерами под управлением клиентских OSWindows независимо от версии <o>С фильтрами вроде как разобрались.<o>Далее необходимо связать GPO ServerOS WSUS Group Policy и ClientOS WSUS Group Policy с соответствующими фильтрами. Как вариант, это можно сделать следующим образом: в ветке «Объекты групповой политики» выбрать нужный GPO, далее  внизу «Фильтр WMI» выбрать нужный фильтр из выпадающего списка. Благодаря такой настройке клиентские компьютеры домена будут обновляться автоматически, а сервера будут покорно ждать вашего внимания.<o>На этом настройка закончена.<o>

А проверка?<o>

В результате всех вышеуказанных действий, ждем начала обновления компьютеров домена. Обновились? Значит все хорошо.<o>Если не пошли обновления, можно предпринять следующие шаги:<o>Необходимо посмотреть в журналах оснастки управления сервером WSUS появление записей о состоянии клиентов автоматического обновления.<o>Убедиться, что настроенная политика действует на клиентов WSUS. Посмотреть в панели управления — Центр обновления Windows, что там есть надпись: «Контролирует системный администратор» (для Windows 7/Vista/2008/2008R2) Если этого нет – швах, неправильная настройка.<o>Но в принципе это не значит, что это ошибка. Возможно, компьютер еще не применил свои настройки с контроллера домена.<o>Можно поторопить (через командную строку):<o>gpupdate /force<o>После обновления групповых политик, на компьютер начнется загрузка обновлений Windows.<o>

Если все же не работает:<o>

Причин может быть масса, как и способов решения:<o>1. Если загрузка с сервера WSUS  не происходит совсем: <o>сервер WSUS недоступен (перепроверить настройки встроенный firewall, сервер IIS и т.п)<o>сервер WSUS настроен неверно <o>в настройках GPO был неверно указан адрес сервера WSUS (я кстати ошибся именно так J )<o>— сервер WSUS работает по нестандартному порту. Например, WSUS сервер находится по адресу http://bla—bla.local:8080, а при настройке адреса в GPO, не указан номер порта совсем или указан другой<o>2. Если загрузка обновлений не происходит только на отдельные компьютеры<o>на компьютере-клиенте WSUS не запущены необходимые службы <o>не отработал GPO для отдельных компьютеров. Придётся разбираться с каждым отдельно. <o>Лог WSUS-клиента вот тут —> c:WindowsWindowsUpdate.log<o>Используемые источники:

• https://interface31.ru/tech_it/2010/10/ustanavlivaem-i-nastraivaem-wsus.html
• https://winitpro.ru/index.php/2014/01/22/nastrojka-gruppovyx-politik-wsus/
• https://vlsdtv.blogspot.com/2013/04/windows-server-update-services-wsus.html