Скачивание обновлений 0 процентов windows server 2016

goro2205
Участник форума

Зарегистрирован: 25.08.2014
Пользователь #: 153,092
Сообщения: 416

Не устанавливаются накопительные обновления на Windows Server 2016

Здравствуйте! С июля 2019 г. началась проблема: не устанавливаются накопительные обновления для Windows Server 2016, версия 1607 , ни в ручном (из .msu-пакетов), ни в автоматическом (из центра обновлений) режиме. Все остальные обновления устанавливаются без проблем! Обновления скачиваются, начинается процесс установки, но примерно на 5-10 % процесс завершается Ошибкой 0x80073701 с сообщением «Нам не удалось установить обновления. Отмена установки».

Последнее накопительное обновление, которое не удалось установить, это KB4525236.

Для решения проблемы испробовано следующее:

— установка обновлений вручную

— Очистка папки SoftwareDistribution

— Dism / Online / Cleanup — Image / CheckHealth — все в порядке, не смотря на это было выполнено также RestoreHealth

— sfc / scannow -тоже все в порядке

— Gоследнее обновление SSU стоит

— Отключение и старт служб bits , wuauserv, appidsvc , cryptsvc -тоже не дал результатов

— А нтивирус отсутствует

— Запуск скрипта- также безрезультатно

$arch = Get-WMIObject -Class Win32_Processor -ComputerName LocalHost | Select-Object AddressWidth

Write-Host «1. Stopping Windows Update Services. »
Stop-Service -Name BITS
Stop-Service -Name wuauserv
Stop-Service -Name appidsvc
Stop-Service -Name cryptsvc

Write-Host «2. Remove QMGR Data file. »
Remove-Item «$env:allusersprofileApplication DataMicrosoftNetworkDownloaderqmgr*.dat» -ErrorAction SilentlyContinue

Write-Host «3. Renaming the Software Distribution and CatRoot Folder. »
Rename-Item $env:systemrootSoftwareDistribution SoftwareDistribution.bak -ErrorAction SilentlyContinue
Rename-Item $env:systemrootSystem32Catroot2 catroot2.bak -ErrorAction SilentlyContinue

Write-Host «4. Removing old Windows Update log. »
Remove-Item $env:systemrootWindowsUpdate.log -ErrorAction SilentlyContinue

Write-Host «5. Resetting the Windows Update Services to defualt settings. »
«sc.exe sdset bits D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;AU)(A;;CCLCSWRPWPDTLOCRRC;;;PU)»
«sc.exe sdset wuauserv D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;AU)(A;;CCLCSWRPWPDTLOCRRC;;;PU)»

Write-Host «6. Registering some DLLs. »
regsvr32.exe /s atl.dll
regsvr32.exe /s urlmon.dll
regsvr32.exe /s mshtml.dll
regsvr32.exe /s shdocvw.dll
regsvr32.exe /s browseui.dll
regsvr32.exe /s jscript.dll
regsvr32.exe /s vbscript.dll
regsvr32.exe /s scrrun.dll
regsvr32.exe /s msxml.dll
regsvr32.exe /s msxml3.dll
regsvr32.exe /s msxml6.dll
regsvr32.exe /s actxprxy.dll
regsvr32.exe /s softpub.dll
regsvr32.exe /s wintrust.dll
regsvr32.exe /s dssenh.dll
regsvr32.exe /s rsaenh.dll
regsvr32.exe /s gpkcsp.dll
regsvr32.exe /s sccbase.dll
regsvr32.exe /s slbcsp.dll
regsvr32.exe /s cryptdlg.dll
regsvr32.exe /s oleaut32.dll
regsvr32.exe /s ole32.dll
regsvr32.exe /s shell32.dll
regsvr32.exe /s initpki.dll
regsvr32.exe /s wuapi.dll
regsvr32.exe /s wuaueng.dll
regsvr32.exe /s wuaueng1.dll
regsvr32.exe /s wucltui.dll
regsvr32.exe /s wups.dll
regsvr32.exe /s wups2.dll
regsvr32.exe /s wuweb.dll
regsvr32.exe /s qmgr.dll
regsvr32.exe /s qmgrprxy.dll
regsvr32.exe /s wucltux.dll
regsvr32.exe /s muweb.dll
regsvr32.exe /s wuwebv.dll

Write-Host «7) Removing WSUS client settings. »
REG DELETE «HKLMSOFTWAREMicrosoftWindowsCurrentVersionWindowsUpdate» /v AccountDomainSid /f
REG DELETE «HKLMSOFTWAREMicrosoftWindowsCurrentVersionWindowsUpdate» /v PingID /f
REG DELETE «HKLMSOFTWAREMicrosoftWindowsCurrentVersionWindowsUpdate» /v SusClientId /f

Write-Host «8) Resetting the WinSock. »
netsh winsock reset
netsh winhttp reset proxy

Write-Host «9) Delete all BITS jobs. »
Get-BitsTransfer | Remove-BitsTransfer

Write-Host «10) Attempting to install the Windows Update Agent. »
if($arch -eq 64) <
wusa Windows8-RT-KB2937636-x64 /quiet
>
else <
wusa Windows8-RT-KB2937636-x86 /quiet
>

Write-Host «11) Starting Windows Update Services. »
Start-Service -Name BITS
Start-Service -Name wuauserv
Start-Service -Name appidsvc
Start-Service -Name cryptsvc

Write-Host «12) Forcing discovery. »
wuauclt /resetauthorization /detectnow

Write-Host «Process complete. Please reboot your computer.»

— Запуск средства устранения неполадок выдает:

Обнаружена потенциальная ошибка базы данных Центра Обновления Windows -> Не исправлено.

Возможные проблемы могут мешать работе Центра обновления Windows.
Исправить повреждение базы данных Центра обновления Windows -> Завершено

Завершено! но все же не исправлено и так при каждом вызове Средства устранения неполадок.

Adblock
detector

Sometimes the Windows update is a nightmare, especially on the business/work network. If you have direct internet without any proxy or WSUS servers, it is going to 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 in place with the different versions of servers, multiple Internet gateways, and proxy servers, then you will face random issues with Windows update. 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 when it started downloading, it stuck at 0%. 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’m going to share how to fix the Windows update stuck at 0% issue on Windows 2016 server. By the way, it is a virtual machine running on Hyper-V.

The below steps are applicable for Windows 2019 and 2022 server Operating Systems also if you face similar issues.

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 server manager, 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 to Windows servers to download Windows updates.

You can check the current and active proxy settings in the command prompt by the below input.

netsh winhttp show proxy

3) Clean the Update Catalog Folder

There could be a reason that 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 stopped successfully, navigate to the following folder location and delete all content (files and folders).

C:WindowsSoftwareDistribution

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 that stuck at 0% on Windows 2016/2019 server earlier.

I tried steps 2 and 3 first, but it did not help in my case. 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 on which method helped to download the Windows updates from Windows 2016/2019 servers that stuck at 0%.

В 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.