В 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_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 в качестве источника для всех предлагаемых типов обновлений.
В результате применения этой политики в системном реестре 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.
В результате применения этой политики в системном реестре 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 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.
С помощью Item-level targeting можем указать то, что данный параметр реестра будет обновляться только на системах семейства Windows Server 2016.
Для оперативной проверки результата выполняем на конечном сервере обновление групповых политик и инициируем процедуру проверки обновлений:
gpupdate /force
UsoClient.exe startscan
Убедимся в том, что после применения GPO в реестре на серверных системах с Windows Server 2016 применились изменения и в графической консоли настроек системы опция «Defer feature updates» отображается в выключенном состоянии.
Все последующие проверки обновлений Windows теперь должны начать работать напрямую с WSUS без длительных попыток обращения к Интернет-службам Windows Update.
Обнаружил одну интересную особенность в службе обновлений Windows Server 2016. В том случае, если у вас не используется внутренний WSUS сервер, и ОС должна обновляться напрямую с серверов Windows Update в Интернет, то при использовании прокси-сервера для доступа наружу, при попытке загрузить обновления через центр обновлений, в Windows Server 2016 процесс загрузки зависает на этапе скачивания апдейтов на 0% (Downloading Updates 0%).
Что интересно, клиенту Windows Update удалось отправить/загрузить метаданные обновлений (список необходимых обновлений успешно сформировался), но ни одно из них не загружается.
Сформируем и откроем журнал WindowsUpdate.log с помощью командлета Get-WindowsUpdateLog.
2018/06/04 16:24:21.8312332 588 4116 DownloadManager BITS job initialized: JobId = {E3AA21C9B-4BC2-443E-2342-8F693CE1443E}
2018/06/04 16:24:21.8436054 588 4116 DownloadManager Downloading from http://download.windowsupdate.com/c/msdownload/update/software/defu/2017/09/nis_engine_1af0e4b80bf4028f8dac56ebf186b392e4e72486.exe to C:\Windows\SoftwareDistribution\Download\f71ddf93ec2d087c819cf75c55ddfda2\1af0e4b80bf4028f8dac56ebf186b392e4e72486 (full file)
2018/06/04 16:24:21.8452605 588 4116 DownloadManager New download job {E3AA21C9B-4BC2-443E-2342-8F693CE1443E} for UpdateId F608EDA4-2E84-433A-A8C9-8117411F91A8.200
2018/06/04 16:24:21.8545291 588 4116 DownloadManager Download job E3AA21C9B-4BC2-443E-2342-8F693CE1443E resumed.
2018/06/04 16:24:21.8734449 588 4116 DownloadManager Failed to connect to the DO service; (hr = 80040154)
2018/06/04 16:24:21.8734462 588 4116 DownloadManager GetDOManager() failed, hr=80246008, hrExtended=80040154
2018/06/04 16:24:21.8734472 588 4116 DownloadManager Failed creating DO job with hr 80246008
2018/06/04 16:24:21.8772521 588 4116 DownloadManager DO download failed with error 80246008[Extended: 80040154], falling back to BITS and retrying with new Download Job.
Как вы видите, BITS не может закачать файлы с ошибкой 80246008.
Как оказалось, простая установка параметров прокси-сервера для Internet Explorer в Windows Server 2016 RTM (10.0.14393) не работает так, как в предыдущих версиях Windows. Чтобы клиент Windows Update в Windows Server 2016 мог получать доступ в Интернет через прокси, нужно принудительно указать системный прокси для winhttp.
Выведем текущие настройки прокси-сервера для WinHTTP:
netsh winhttp show proxy
Current WinHTTP proxy settings:
Direct access (no proxy server).
Как вы видите, параметры прокси-сервера для WinHTTP не заданы указаны.
Задать настройки системного прокси для WinHTTP можно так:
netsh winhttp set proxy proxy-server="192.168.0.14:3128" bypass-list="*.winitpro.ru"
Или так, импортировав настройки из IE (настройки прокси в Internet Explorer нужно предварительно задать вручную или настроить через GPO):
netsh winhttp import proxy source=ie
После изменения настроек прокси службу Windows Update нужно перезапустить:
Restart-service wuauserv
После того, как были указан прокси для WinHTTP, Windows Server 2016 начал закачивать обновления с узлов Windows Update.
Аналогичной проблеме подвержена RTM версия Windows 10.
Примечание. Если вручную скачать и установить последнее кумулятивное обновление из каталога обновлений Microsoft (вышедшее после ноября 2016 года), то обновления начинают устанавливаться нормально, даже если не указывать WinHTTP прокси. Судя по информации от Microsoft, этот баг был исправлен в версии агента обновления 10.0.14393.187 и выше.
Также не забудьте, что вы не сможете получать обновления через прокси сервер с авторизацией, т.к. клиент Windows Update не поддерживает возможность авторизации на прокси (в отличии от PowerShell). Чтобы корректно работала служба обновлений Windows, нужно на прокси сервере разрешить анонимный доступ к серверам обновлений Microsoft. Список URL указан ниже:
- update.microsoft.com
- * .update.microsoft.com
- download.windowsupdate.com
- * .download.windowsupdate.com
- download.microsoft.com
- * .download.microsoft.com
- windowsupdate.com
- * .windowsupdate.com
- ntservicepack.microsoft.com
- wustat.windows.com
- mp.microsoft.com
- * .mp.microsoft.com
The Windows update is sometimes a nightmare, especially on the business/work network. If you have direct internet without any proxy or WSUS servers, it will work without any issues most of the time. That is how it works on personal computers at home. But when there is a complicated setup with the different versions of servers, multiple Internet gateways, and proxy servers, you will face random issues with Windows updates. Recently I had a problem with Windows 2016 server where the Windows update stuck at 0% and did not move further.
In my case, it detected the available updates, but it stuck at 0% when it started downloading. I thought that something was wrong with the Internet connectivity, but the Internet browsing worked fine on the same server. After finding several solutions online, only one worked for me. In this post, I will share how to fix the Windows update stuck at 0% issue on the Windows 2016 server. By the way, it is a virtual machine running on Hyper-V.
WSUS Download Status Stuck At 0
Having the WSUS download status stuck at 0 can be caused by various issues, such as network connectivity problems, server overload, or corrupted update files. Users can try restarting the WSUS service, checking network connections, or resetting the Windows Update components to resolve this issue.
The steps below are applicable for Windows 2019 and 2022 server Operating Systems and if you face similar issues.
Fixed – Downloading Updates 0 Windows Server 2016/2019/2022
When encountering the message “downloading updates 0 Windows Server 2016,” it indicates that the server is not currently downloading any updates. This may be due to various reasons such as no available updates, network issues, or the update process being paused. It is advisable to ensure the server is connected to the internet and try again later.
Let me add the solution first, which worked for me after trying several steps. If this doesn’t work for you or your scenario is different, then proceed to other steps.
1) Check the Windows Firewall Service/status
In Windows 2016 (or 2019/2022 servers), the Windows firewall should be on and active to make Microsoft Updates work. In my case, I disabled the Windows firewall for some other purpose earlier. So, the update stuck at 0% without any progress.
Visit the Services under the server manager and make sure that the Windows firewall service is running.
Once I started the service, the Windows update started downloading automatically.
If this step doesn’t fix the issue, go to the next steps.
2) Check the Internet Proxy Settings
In most cases, Windows update can’t download the packages via the web proxy (though it depends on the authentication and security policy of the web proxy).
Check and confirm that there is no proxy setup on the web browser.
You should remove the proxy settings and provide direct Internet access to Windows servers to download Windows updates.
You can check the command prompt’s current and active proxy settings by the below input.
netsh winhttp show proxy3) Clean the Update Catalog Folder
There could be a reason that the Windows update content folder/file/catalog is corrupted, so the download is stuck at 0%. Cleaning up the folder may help to resume Windows updates successfully.
We need to stop the service before doing the cleanup,
Go to the Services and locate the Windows update service. Stop the service.
Once the service stops successfully, navigate to the following folder location and delete all content (files and folders).
C:\Windows\SoftwareDistribution
This is the place where Windows OS downloads the updates. Cleaning up these files/folders and starting the service may help.
After deleting the files, start the same Windows Update service you stopped initially. This will restart the update service and download the updates stuck at 0% on the Windows 2016/2019 server earlier.
I tried steps 2 and 3 first, but it did not help. My server never had a proxy server for Internet access. Deleting the content from the particular location and restarting the Windows Update service did not help either. Enabling the Windows firewall worked for me in the end. You can try these steps and share the outcome of which method helped download the Windows updates from Windows 2016/2019 servers stuck at 0%.
Skip to content
Message ignored as component is disabled.
Some computers install software updates successfully while some don’t.
This was the issue reported by one of my clients. Initially I found they set a deadline which is a future date for the deployment. So I asked them to go with As soon as possible if they want to install updates immediately.
However, they came back telling that it does not work either. That sounds weird. I asked for the client CCM logs, where I could see that the deployment policy was well applied as indicated in PolicyAgent.log.
instance of CCM_PolicyAgent_PolicyRuleApplied
{
ClientID = "GUID:BA642019-A244-484B-8B9F-B71C0920C97F";
DateTime = "20201207135716.204000+000";
PolicyID = "{3749C3F1-3187-4268-9E8D-BBF73F417C22}";
PolicyNamespace = "\\.\ROOT\ccm\policy\Machine\RequestedConfig";
PolicySource = "SMS:MTR";
PolicyVersion = "1.00";
ProcessID = 7200;
RuleCondition = "";
RuleID = "{Rule_{3749C3F1-3187-4268-9E8D-BBF73F417C22}}";
ThreadID = 7488;
};
But when I was checking the UpdatesDeployment.log a strange message caught my eye.
12-07-2020 21:57:19.206 UpdatesDeploymentAgent 5876 (0x16f4) Message received: '
{F17D64D8-77D3-4247-BAF0-5EB81BAF95E7}
'
12-07-2020 21:57:19.206 UpdatesDeploymentAgent 5876 (0x16f4) Message ignored as component is disabled.
12-07-2020 22:00:00.013 UpdatesDeploymentAgent 1232 (0x4d0) CUpdateAssignmentsManager received a SERVICEWINDOWEVENT START Event
12-07-2020 22:00:00.018 UpdatesDeploymentAgent 1232 (0x4d0) Suspend activity in presentation mode is selected
12-07-2020 22:00:00.018 UpdatesDeploymentAgent 1232 (0x4d0) At least one user has elected to suspend non-business hours activity when in presentation mode. Checking for presentation mode.
12-07-2020 22:00:00.018 UpdatesDeploymentAgent 1232 (0x4d0) Proceeding to non-business hours activites as presentation mode is off.
12-07-2020 22:00:00.021 UpdatesDeploymentAgent 1232 (0x4d0) Auto install during non-business hours is disabled or never set, selecting only scheduled updates.
12-07-2020 22:00:00.021 UpdatesDeploymentAgent 1232 (0x4d0) A user-defined service window(non-business hours) is available. We will attempt to install any scheduled updates.
12-07-2020 22:00:00.021 UpdatesDeploymentAgent 1232 (0x4d0) Attempting to install 0 updates
That led me to thinking that Software Update Agent on those clients may not be enabled as they should.
Due to the customer could not remote onto any of those clients, I asked to run remotely this command to verify the setting.
Get-WmiObject -Namespace "ROOT\ccm\Policy\Machine\ActualConfig" -Query "SELECT * FROM CCM_SoftwareUpdatesClientConfig"The command returned the following result (I just pasted piece of the key information. The actual result is really quite long.) –
AssignmentBatchingTimeout : 0
BrandingSubTitle :
BrandingTitle :
ComponentName : SmsSoftwareUpdate
ContentDownloadTimeout : 864000
ContentLocationTimeout : 604800
DayReminderInterval : 120
DynamicUpdateOption : 0
Enabled : False
EnableExpressUpdates : False
EnableThirdPartyUpdates : False
ExpressUpdatesPort : 8005
ExpressVersion : 10.0.14393.953
GroupPolicyNotificationTimeout : 120
HourReminderInterval : 15
MaxScanRetryCount : 48
NEOPriorityOption : 0
PerDPInactivityTimeout : 0
ReminderInterval : 1440
Enable is False.
Thus, I provided the following solution –
- Go to Client Settings and find the specific customized client settings for those computers in SCCM console.
- Set in Software Update Enable software updates on clients to Yes.
After that they told me the next day the issue was gone.