Отложить получение обновлений компонентов windows server 2016

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

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

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

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«) мы можем получить состояние длительного ожидания.

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

• TechNet Forums : Windows Server 2016 Updates slow!
• Superuser : Windows Update stuck on Checking for updates
• Born’s Tech and Windows World : Windows Server 2016: Slow updates

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

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

Stop-Service "Windows Update"

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

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

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

То есть, как только мы отключаем данную опцию, включенную в 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.

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

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindowsWindowsUpdate]
"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 в качестве источника для всех предлагаемых типов обновлений.

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

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindowsWindowsUpdate]
"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.

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

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindowsWindowsUpdate]
"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 10.

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

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

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

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

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

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsUpdateUXSettings]
"DeferUpgrade"=dword:00000000

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

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

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

gpupdate /force
UsoClient.exe startscan

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

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

In Windows Server 2016 there are no GUI options available to change the update behavior.
In this blog I was outline the different ways to change the Windows Server 2016 Update settings.

Windows always looks at registry keys located in the following hive:
HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindowsWindowsUpdateAU

Typically there is a key named ‘AUOptions’ with a value in the range 2-5, and have the following meaning:

– 2 = Notify before download.
– 3 = Automatically download and notify of installation.
– 4 = Automatically download and schedule installation. Only valid if values exist for ScheduledInstallDay and ScheduledInstallTime.
– 5 = Automatic Updates is required and users can configure it.

But if there is a ‘NoAutoUpdate’ key with the value of ‘1’, no updates will be processed by Windows.

Powershell

You can change the registry key with the help of Powershell directly:

In Windows Server 2012 I used to change the setting using the .NET object as below, this doesnt work anymore in 2016 as the API only allows “GET” statements.

SCONFIG

Sconfig is basically a simple batch script, which is sufficient for configuration tasks such as update settings.
In the sconfig prompt you can select options ‘5’ to enter the update settings configuration and then choose:
A – Automatically scan, download and install updates. After installation perform a reboot.
D – Automatically scan, download updates
M – Never check for updates, trigger manually.

Open a command prompt with administrative permissions and run SCONFIG from there.

Group Policy

You can always use the trusted GPO’s in an Active Directory domain environment. The settings are located under ‘Local Computer Policy > Computer Configuration > Administrative Templates > Windows Components > Windows Update’.
You can configure the same range of numbers here.

More info on managing update polices with GPO’s here:
https://technet.microsoft.com/nl-nl/library/cc720539(v=ws.10).aspx

Scheduling Day / Time

When you set the update settings to “Automatically download and schedule installation” it could be that you also want to decide yourself which day/time it should update. This can be done using the ScheduledInstallDay and ScheduledInstallTime keys in the registry.

ScheduledInstallDay

Value
0	Install every day
1-7	Specific day of the week where Sunday =1 and Saturday = 7

ScheduledInstallTime

Value
0-23	Time of the day in 24-hour format

Setting the Scheduled Install Day to Tuesday:

Setting the Scheduled Install time to 6 AM:

The changes take effect after logoff

More info on this Windows Update settings here: https://msdn.microsoft.com/en-us/library/dd939844(v=ws.10).aspx

—

Thank you for reading my blog.
If you have any questions or feedback, leave a comment or drop me an email.

Darryl van der Peijl
http://www.twitter.com/DarrylvdPeijl

В этой статье речь пойдет о том, как правильно настроить ПК с Windows 10 или Windows Server 2016 на обновления с сервера WSUS. Причиной послужила некорректная информация об обновлениях на WSUS сервере для некоторых Windows 10 ПК и Win Server 2016 серверов. В полях «Необходимые обновления» (Needed Count) и «Установленные обновления» (Installed Count) отображаются нули, словно доступных обновлений нет и они никогда не устанавливались.

Проблема на Windows 10 ПК

Проблема на Windows Server 2016 сервере

Более того, компьютер может автоматически устанавливать обновления мимо сервера WSUS напрямую из Windows Update, игнорируя информацию об аппрувленных обновлениях.

---

РЕШЕНИЕ:

1. Необходимо жестко указать компьютеру обновляться только с WSUS.

В редакторе групповых политик «Конфигурация компьютера — Административные шаблоны — компоненты Windows — Центр обновления Windows» включаем политику «Не подключаться к расположениям Центра обновления Windows в Интернете»

При этом в ветке реестра

HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindowsWindowsUpdate

создается параметр DoNotConnectToWindowsUpdateInternetLocations типа REG_DWORD со значением «1»

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

2. Самый главный враг в данной проблеме — Dual Scan, который появился в Windows 10 Anniversary update 1607

Понятие Dual Scan представляет собой такую комбинацию настроек в Windows 10 1607 и выше, при которой клиенты начинают игнорировать настройки локального WSUS сервера, параллельно обращаясь для сканирования на наличие новых обновлений на внешние сервера Windows Update.
Сканирование обновлений выполняется одновременно и на WSUS сервере и на серверах WU, однако клиент принимает апдейты только от серверов WU. Таким образом, все обновления/патчи с локального WSUS, относящиеся к категории Windows будут игнорироваться такими клиентами. Т.е. обновления Windows в таком режиме получаются из интернета, а обновления драйверов и других продуктов со WSUS.

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

• «Указать размещение службы обновлений Майкрософт в интрасети» (Specify intranet Microsoft update service location)
• Любая из политик принадлежащих центру обновления для бизнеса:

a) Либо галочка «Приостановить обновления» («Defer Feature Upgrades»)

Одна из разновидностей галочки

Одна из разновидностей галочки

            b) Либо включенные политики отложенной установки обновлений «Конфигурация компьютера — Административные шаблоны — компоненты Windows — Центр обновления Windows — Центр обновления Windows для бизнеса»

3.  Таким образом, проверяем и отключаем описанные в п.2 функции и политики отложенной установки обновлений:

• Снимаем флажок «Приостановить обновления» («Defer Feature Upgrades»)
• Отключаем (переводим в состояние «не задано») все политики Центра обновлений Windows для бизнеса: «Конфигурация компьютера — Административные шаблоны — компоненты Windows — Центр обновления Windows — Центр обновления Windows для бизнеса» 

4. Также необходимо удалить следующие ключи реестра, если они есть:

HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindowsWindowsUpdate

• BranchReadinessLevel
• DeferFeatureUpdatesPeriodInDays
• DeferQualityUpdatesPeriodInDays
• DeferUpdatePeriod
• DeferUpgradePeriod
• ExcludeWUDriversInQualityUpdate
• PauseDeferrals
• PauseFeatureUpdates
• PauseQualityUpdates

HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsUpdateUXSettings

• BranchReadinessLevel
• DeferFeatureUpdatesPeriodInDays
• DeferQualityUpdatesPeriodInDays
• ExcludeWUDriversInQualityUpdate
• DeferUpgrade

Примечание: Если вы установили для соответствующих групповых политик значение «Не настроено» или «Отключено», ключи не будут удалены, а только установлены в ноль (DWORD) в реестре.

5. Крайне желательно удалить проблемный ПК из WSUS, а затем перерегистрировать его по новой, запустив на компьютере cmd от имени администратора и выполнив команду:

wuauclt /detectnow /resetauthorization

Компьютер может отрепортиться спустя несколько часов.

В результате, мы должны увидеть корректную информацию на WSUS и обновление ПК с WSUS-сервера будет происходить корректно.

---

Резюме: При настройке ПК Windows 10 и серверов Windows Server 2016 на обновление с WSUS, не включаем параметры «отложить обновления» (defer upgrades) и политики центра обновления Windows для бизнеса.

---

Материалы по теме:

• Достаточно хорошая и подробная статья на русском о проблеме с Dual Scan

http://winitpro.ru/index.php/2017/10/12/effekt-dual-scan-v-windows-10-i-problemy-obnovleniya-so-wsus/

• Также по следам раскрытия проблемы

http://blog.tofte-it.dk/wsus-windows-10-clients-error-0x8024500c/

• О Dual Scan на сайте Microsoft

https://blogs.technet.microsoft.com/wsus/2017/05/05/demystifying-dual-scan/