Windows Server 2016 и длительное ожидание проверки обновлений Windows Update

Windows Server 2016 and long wait for Windows Update checksВ Windows Server 2016 можно столкнуться с ситуацией, когда встроенный клиент Windows Update очень долго выполняет проверку обновлений. Характерно то, что проблема может проявляться плавающим образом и воспроизводиться не всегда. Замечено, что чаще всего проблема проявляется в случае, если система была недавно включена или перезагружена. В этой заметке мы поговорим о том, какие могут быть причины у такого поведения и как это можно попробовать исправить.

При попытке вызвать проверку обновлений из интерфейса настроек системы в Settings > Update & security > Windows Update мы можем столкнуться с длительным циклом ожидания в статусе "Checking for updates..."

Update status is Checking for updates ... in Windows Server 2016

Результатом такого ожидания может стать возникновение ошибки типа:

We couldn't connect to the update service. We'll try again later, or you can check now. If it still doesn't work, make sure you're connected to the Internet.

Это привносит проблемы и в других операциях обслуживания системы.

 

Отражение проблемы с Windows Update в Failover Cluster Manager

В качестве примера отрицательного влияния проблемной работы Windows Update можно привести мастер проверки конфигурации кластера, вызываемый из оснастки Failover Cluster Manager. В ходе выполнения валидации кластера, на этапе сбора информации об установленных на кластерных узлах обновлениях ("List Software Updates") мы можем получить состояние длительного ожидания.

List Software Updates in Failover Cluster Manager

В ходе изучения ситуации по следам "коллективного разума" я обнаружил, что самые разнообразные проблемы c Windows Update в Windows Server 2016 известны давно и с ними столкнулись многие:

Методом "а если попробовать…" было выявлено, что в качестве обходного решения в вышеописанной ситуации с Failover Cluster Manager, может быть простой перезапуск службы "Windows Update".

Возможно, потребуется сделать лишь остановку этой службы, а запустится служба через несколько секунд автоматически. Если служба не остановилась с первого раза (остановка привела к ошибке), то пробуем выполнить остановку повторно. Выполнить остановку службы можно как через оснастку управления службами services.msc, так и через PowerShell.

Stop-Service "Windows Update"

Сразу после того, как служба будет остановлена (а затем сама автоматически запустится) мы увидим сдвиг в работе механизма проверки обновлений.

Stop Service Windows Update with PowerShell

В случае с кластером, выполнить остановку/перезапуск службы "Windows Update" нам может потребоваться на всех узлах кластера, начиная с того, на котором запущен мастер проверки.

В попытках понять, что же не так с проверкой обновлений в Windows Server 2016 и проведения ряда экспериментов с видимыми настройками клиента Windows Update в графической среде, стало очевидно то, что наличие включённой опции "Defer feature updates" в Settings > Update & security > Windows Update > Advanced options явным образом влияет на воспроизведение проблемы.

Defer feature updates option in Windows Update Advanced options in Windows Server 2016

То есть, как только мы отключаем данную опцию, включенную в Windows Server 2016 по умолчанию, то механизм проверки обновлений начинает работать так, как мы этого от него ожидаем при наличии сервера WSUS.

Дальнейшее изучение вопроса показало, что причиной странного поведения клиента Windows Update может являться механизм "Dual Scan" (подробней в статьях "Improving Dual Scan on 1607" и "Demystifying Dual Scan"), который заставляет при проверке обновлений в качестве источника использовать не только форсировано настроенный в доменных групповых политиках сервер WSUS в локальной сети, но и Интернет-службы Windows Update.

Соответственно, при условии, что компьютеры имеют ограниченный доступ в Интернет или не имеют его вовсе, может возникнуть эффект длительного ожидания с возникновением ошибок разного содержания.

Чтобы решить описанную проблему, нам потребуется провести настройку групповой политики Active Directory, с помощью которой настраиваются наши серверы на базе Windows Server 2016. Однако, как выяснилось, в этом вопросе всё не так очевидно, понятно и однозначно, как хотелось бы.

 

Варианты решения с готовыми политиками GPO (неработающие в нашем случае)

Примечание: Если важен только готовый рецепт и не интересны эксперименты по следам ранее предложенных в Интернете приёмов(которые в нашем случае не помогли), то можете смело пропустить этот раздел заметки и читать заключительный раздел.

В ранних выпусках Windows 10 (с версии 1607) и Windows Server 2016 за отключение попыток использования онлайн репозитория Windows Update отвечала политика:

"Do not allow update deferral policies to cause scans against Windows Update"

в разделе:

Computer Configuration > Administrative Templates > Windows Components > Windows Update.

Group Policy - Do not allow update deferral policies to cause scans against Windows Update

В результате применения этой политики в системном реестре Windows появляется параметр DisableDualScan, установленный в 1:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate]
"DisableDualScan"=dword:00000001

И, судя по старым статьям, на более ранних версиях Windows 10 описанная политика могла быть полезна для решения проблемы.

Однако, в более поздних версиях Windows 10 (начиная с версии 2004), Windows 11, а так же, возможно, в более новых версиях Windows Server, данная политика была перенесена в подраздел Legacy Policies и была заменена новой политикой:

"Specify source service for specific classes of Windows Updates"

в разделе:

Computer Configuration > Administrative Templates > Windows Components > Windows Update > Manage updates offered from Windows Server Update Service.

Предполагается включение этой политики и выбор WSUS в качестве источника для всех предлагаемых типов обновлений.

Group Policy - Specify source service for specific classes of Windows Updates

В результате применения этой политики в системном реестре Windows появляется 4 параметра с соответствующими именами, установленных в 1:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate]
"SetPolicyDrivenUpdateSourceForFeatureUpdates"=dword:00000001
"SetPolicyDrivenUpdateSourceForQualityUpdates"=dword:00000001
"SetPolicyDrivenUpdateSourceForDriverUpdates"=dword:00000001
"SetPolicyDrivenUpdateSourceForOtherUpdates"=dword:00000001

Логично предполагать, что включать и настраивать данную политику резонно лишь для серверных систем, которые в локальных сетях, как правило, обновляются с сервера WSUS и имеют ограниченный доступ в Интернет. Для клиентских же систем, часть из которых может оказаться мобильными и периодически перемещающимися из локальной сети во внешние сети с доступом в Интернет, в некоторых ситуациях может оказаться логичней использовать настроенный по умолчанию механизм выбора источника (то есть, чтобы в качестве дополнительного источника мог выступать онлайн репозиторий Windows Update).

Эксперименты с двумя выше описанными политиками показали, что на данный момент времени сами по себе (ни по отдельности ни вместе) эти политики не решают проблему в нашем конкретном случае.

В ходе дальнейшего изучения опыта борьбы коллег со странностями работы Windows Update в Windows Server 2016 обнаружил статью "Windows admin blog : Некорректное отображение информации на WSUS | Проблемы обновления со WSUS (Dual Scan)", где в качестве одного из решений предложено включение "олдскульной" политики:

"Do not connect to any Windows Update Internet locations"

в разделе:

Computer Configuration > Administrative Templates > Windows Components > Windows Update > Manage updates offered from Windows Server Update Service.

Group Policy - Do not connect to any Windows Update Internet locations

В результате применения этой политики в системном реестре Windows появляется параметр DoNotConnectToWindowsUpdateInternetLocations, установленный в 1:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate]
"DoNotConnectToWindowsUpdateInternetLocations"=dword:00000001

Однако, практика показала, что применение данной политики может привести к появлению новой ошибки в ходе проверки обновлений:

There were some problems installing updates, but we'll try again later. If you keep seeing this and want to search the web or contact support for information, this may help: (0x8024500c)

Windows Update status error 0x8024500c

Причём избавиться от этой ошибки не поможет ни перезапуск службы, ни перезагрузка системы, а по свидетельствам очевидцев, эта ошибка воспроизводится так же и на Windows 10.

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

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

 

Отключение опции "Defer feature updates" с помощью GPP

В конечном итоге пришлось прибегнуть к помощи Group Policy Preferences (GPP) для управления опцией "Defer feature updates", отображаемой в графической оболочке Windows Server 2016.

Отключение данной опции приводит к следующему изменению в системном реестре:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsUpdate\UX\Settings]
"DeferUpgrade"=dword:00000000

Соответственно, для настройки серверов с Windows Server 2016 на явное отключение данной опции мы можем создать в доменной групповой политике, применяемой к серверам, объект GPP, настраивающий параметр реестра DeferUpgrade.

Add Group Policy Preferences GPP for Defer feature updates option

С помощью Item-level targeting можем указать то, что данный параметр реестра будет обновляться только на системах семейства Windows Server 2016.

Для оперативной проверки результата выполняем на конечном сервере обновление групповых политик и инициируем процедуру проверки обновлений:

gpupdate /force
UsoClient.exe startscan

Убедимся в том, что после применения GPO в реестре на серверных системах с Windows Server 2016 применились изменения и в графической консоли настроек системы опция "Defer feature updates" отображается в выключенном состоянии.

Defer feature updates option in Registry

Все последующие проверки обновлений Windows теперь должны начать работать напрямую с WSUS без длительных попыток обращения к Интернет-службам Windows Update.

Только один комментарий Комментировать

  1. Vladimir /

    Добрый день! Вы упомянули в своей статье мою статью (сделали ссылку на сайт Windows admin blog : Некорректное отображение информации на WSUS | Проблемы обновления со WSUS (Dual Scan)) и указали, что этот способ плохой и создает новую ошибку. В моем случае никаких ошибок нет, и данная политика (DoNotConnectToWindowsInternetLocations) используется мною на десятках (если не сотне) серверов Windows (в противном случае, сервер может начать качать обновления мимо WSUS).

    Ваша ошибка была во включенной опции Defer Upgrades, о чем вы в конечном итоге и сообщили в решении, однако, если бы вы внимательно читали мою статью, то я об этой опции как раз и упоминал, что она активирует опцию Dual-scan.
    То есть ваша ошибка - одновременно включенные политики "отложить обновления" (defer upgrades) и использования политик на Wsus, таким образом, включив параметр "не подключаться к расположениям обновлений windows в интернете" вы запретили обновлениям качаться из интернета (потому что ваши политики на wsus были некорректно настроены и обновления по сути оттуда не получали и закрыли последнюю лазейку обновлениям качаться напрямую из интернета).

    Еще раз цитирую с моего сайта для понимания:
    Эффект Dual Scan появляется при наличии одновременно работающих комбинаций политик:

    * «Указать размещение службы обновлений Майкрософт в интрасети» (Specify intranet Microsoft update service location)
    * Любая из политик принадлежащих центру обновления для бизнеса:
    a) Либо галочка «Приостановить обновления» («Defer Feature Upgrades»)
    b) Либо включенные политики отложенной установки обновлений «Конфигурация компьютера — Административные шаблоны — компоненты Windows — Центр обновления Windows — Центр обновления Windows для бизнеса»

    Dual-Scan - зло

Добавить комментарий