Windows server 2016 не ставятся обновления

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

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

Картинка с сайта: blog.it-kb.ru

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

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

Картинка с сайта: blog.it-kb.ru

В ходе изучения ситуации по следам «коллективного разума» я обнаружил, что самые разнообразные проблемы 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"

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

Картинка с сайта: blog.it-kb.ru

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

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

Картинка с сайта: blog.it-kb.ru

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

Картинка с сайта: blog.it-kb.ru

В результате применения этой политики в системном реестре 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 в качестве источника для всех предлагаемых типов обновлений.

Картинка с сайта: blog.it-kb.ru

В результате применения этой политики в системном реестре 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.

Картинка с сайта: blog.it-kb.ru

В результате применения этой политики в системном реестре 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)

Картинка с сайта: blog.it-kb.ru

Причём избавиться от этой ошибки не поможет ни перезапуск службы, ни перезагрузка системы, а по свидетельствам очевидцев, эта ошибка воспроизводится так же и на 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.

Картинка с сайта: blog.it-kb.ru

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

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

gpupdate /force
UsoClient.exe startscan

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

Картинка с сайта: blog.it-kb.ru

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

Столкнулся с интересной ошибкой 0x80073712 при установке обновлений в Windows Server 2016. Как выяснилось позже, эта ошибка связана с повреждением хранилища компонентов Windows. В этой статье рассмотрим, как исправить хранилище компонентов в Windows 10 / 8.1 и Windows Server 2016/2012 R2 и восстановить работу Windows Update.

При попытке установить обновления в Центре обновления Windows появляется ошибка:

Картинка с сайта: winitpro.ru

В первую очередь я попробовал сбросить состояние службы Windows Update и очистить каталог SoftwareDistribution по рекомендациям из статьи “Сброс настроек Центра обновления Windows”, но это не помогло.

С помощью команды
dism /online /get-packages
я проверил, что все обновления находятся в статусе Installed.

Картинка с сайта: winitpro.ru

Довольно долго решал, с какой стороны подойди к этой проблеме, но в рамках траблшутинга мне понадобилось установить на Windows Server 2016 компонент .Net Framework 3.5. При установке компонента .Net с помощью DISM появилась характерная ошибка, которая и натолкнула меня на дальнейшие действия:

The request to add or remove features on the specified server failed. Installation of  one or more roles, role services or features failed. The component store has been corrupted. Error: 0x80073712.

Хранилище компонентов повреждено. Ошибка: 0x80073712.

Картинка с сайта: winitpro.ru

При этом в файле CBS.log можно найти такую строку (%WinDir%\Logs\CBS\CBS.log):

[HRESULT = 0x80073712 - ERROR_SXS_COMPONENT_STORE_CORRUPT]

Как вы видите, по какой-то причине хранилище компонентов вашей системы повреждено, в результате чего Windows Update не может получить данные из манифеста CBS (Component-Based Servicing) необходимые для установки обновлений. Вы можете восстановить хранилище компонентов с помощью встроенного функционала DISM.

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

В первую очередь проверьте состояние хранилища компонентов с помощью команды:

dism /online /cleanup-image /checkhealth

Если после выполнения анализа появилось сообщение “component store is repairable”, вы можете попытаться восстановить хранилище компонентов командой:

dism /online /cleanup-image /restorehealth

В некоторых случаях это достаточно. Но у меня утилита DISM выдала ошибку:

Error: 0x800f0906
The source files could not be downloaded.

В этом случае для восстановления Windows требуется установочный диск с вашим дистрибутивом Windows. Допустим, вы смонтировали ISO файл с вашим дистрибутивом Windows. Теперь нужно проверить список текущих редакций Windows в файле install.wim в подключенном образе (диске):

dism /Get-WimInfo /WimFile:e:\sources\install.wim

Картинка с сайта: winitpro.ru

В моем случае установлена редакция Windows Server 2016 Standard (Desktop Experience), поэтому в следующей команде я использую ее индекс – 2.

dism /online /cleanup-image /restorehealth /source:e:\sources\install.wim:2 /LimitAccess

Еще раз проверьте состояние хранилища компонентов:

Dism /Online /Cleanup-Image /CheckHealth

DISM должна вернуть:
Повреждение хранилища компонентов не обнаружено (No component store corruption detected).

Картинка с сайта: winitpro.ru

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

Windows Server 2016 не скачивает обновления через прокси

Обнаружил одну интересную особенность в службе обновлений Windows Server 2016. В том случае, если у вас не используется внутренний WSUS сервер, и ОС должна обновляться напрямую с серверов Windows Update в Интернет, то при использовании прокси-сервера для доступа наружу, при попытке загрузить обновления через центр обновлений, в Windows Server 2016 процесс загрузки зависает на этапе скачивания апдейтов на 0% (Downloading Updates 0%).

Картинка с сайта: hand.post-ap.ru

Что интересно, клиенту Windows Update удалось отправить/загрузить метаданные обновлений (список необходимых обновлений успешно сформировался), но ни одно из них не загружается.
Сформируем и откроем журнал WindowsUpdate.log с помощью командлета Get-WindowsUpdateLog.

Как вы видите, BITS не может закачать файлы с ошибкой 80246008.

Как оказалось, простая установка параметров прокси-сервера для Internet Explorer в Windows Server 2016 RTM (10.0.14393) не работает так, как в предыдущих версиях Windows. Чтобы клиент Windows Update в Windows Server 2016 мог получать доступ в Интернет через прокси, нужно принудительно указать системный прокси для winhttp.

Картинка с сайта: hand.post-ap.ru

Выведем текущие настройки прокси-сервера для WinHTTP:

netsh winhttp show proxy

Direct access (no proxy server).

Как вы видите, параметры прокси-сервера для WinHTTP не заданы указаны.

Задать настройки системного прокси для WinHTTP можно так:

netsh winhttp set proxy proxy-server=»192.168.0.14:3128″ bypass-list=»*.winitpro.ru»

Картинка с сайта: hand.post-ap.ru

Или так, импортировав настройки из IE (настройки прокси в Internet Explorer нужно предварительно задать вручную или настроить через GPO):

netsh winhttp import proxy source=ie

После изменения настроек прокси службу Windows Update нужно перезапустить:

После того, как были указан прокси для WinHTTP, Windows Server 2016 начал закачивать обновления с узлов Windows Update.

Аналогичной проблеме подвержена RTM версия Windows 10.

Также не забудьте, что вы не сможете получать обновления через прокси сервер с авторизацией, т.к. клиент Windows Update не поддерживает возможность авторизации на прокси (в отличии от PowerShell). Чтобы корректно работала служба обновлений Windows, нужно на прокси сервере разрешить анонимный доступ к серверам обновлений Microsoft. Список URL указан ниже:

Чтобы корректно работала служба обвинений (последнее слово точно должно быть таким?)

А то! Вы обвиняетесь в том, что давно не обновляетесь!

Скорее так:
Вы обвиняетесь в том, что используете процессор не последнего поколения и приговариваетесь к отключению от обновлений!

На самом деле это довольно логично. Ведь если на машине не залогинен никакой пользователь, то откуда брать настройки прокси? Если же мы говорим о сервере, то чаще всего там ситуация именно такая. Следовательно если настроить автоматическое получение обновлений, то работать оно не сможет т.к. нет залогиненого пользователя и нет настроек прокси. Другое дело, что я бы не стал на серверах настраивать автоматическое обновление, но это уже каждый сам решает.
По поводу списка доменов. После _долгих_ экспериментов я пришел к такому списку:
*.microsoft.com
microsoft.com
*.windowsupdate.com
windowsupdate.com
*.trafficmanager.net
trafficmanager.net

Открывать более детально по поддоменам не вижу смысла. Во-первых их там реально много. Во-вторых ну нет ничего страшного если будет доступ к *.microsoft.com, а вот жизнь сисадмину упростит сильно. Я прошу учесть, что такой список родился не на пустом месте, а в результате мониторинга сетевой активности. Дело в том, что система помимо собственно обновлений обращается еще к различным ресурсам (например проверяет списки отозванных сертификатов — CRL). Это тоже важные ресурсы наряду с обновлениями. И я рекомендую открыть анонимный доступ к этим доменам не только с серверов но и с рабочих станций.

И в догонку (хотя это уже не относится к обновлениям). Касаемо загрузки CRL. На машинах с которых идёт активная работа с интернетом (как правило это юзерские машины) системный компонент MicrosoftCryptoAPI постоянно обращается к различным доменам для скачивания CRL. Так вот если используется выход в интернет через прокси, то для корректной работы этого механизма тоже должен быть прописан системный прокси, это во-первых. Во-вторых MicrosoftCryptoAPI обращается к прокси тоже анонимно (за редким исключением). И в-третьих всё это усугубляется тем, что доменов куда он может обратится множество. Таким образом если прокся не выпустит анонимные обращения от MicrosoftCryptoAPI, то система проверки отзыва сертификатов функционировать не будет. Причём это не вызывает никаких видимых эффектов. Просто тихо не работает и всё. Чем это грозит и насколько критично каждый пусть сам додумает.

Источник

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

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

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

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

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

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

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

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

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 «HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate» /v AccountDomainSid /f
REG DELETE «HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate» /v PingID /f
REG DELETE «HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate» /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 «12) Forcing discovery. »
wuauclt /resetauthorization /detectnow

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

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

Источник

Устранение неполадок Центра обновления Windows Windows Update troubleshooting

Применимо к: Windows10 Applies to: Windows 10

Если при использовании Центра обновления Windows возникают проблемы, начните со следующих действий: If you run into problems when using Windows Update, start with the following steps:

Запустите встроенное средство устранения неполадок Центра обновления Windows, чтобы устранить распространенные проблемы. Run the built-in Windows Update troubleshooter to fix common issues. Перейдите в Параметры > Обновление и безопасность > Устранение неполадок > Центр обновления Windows. Navigate to Settings > Update & Security > Troubleshoot > Windows Update.

Установите последнее обновление стека обслуживания (SSU), которое соответствует вашей версии Windows, из каталога Центра обновления Майкрософт. Install the most recent Servicing Stack Update (SSU) that matches your version of Windows from the Microsoft Update Catalog. Дополнительные сведения об обновлениях стека обслуживания см. в разделе Обновления стека обслуживания. See Servicing stack updates for more details on servicing stack updates.

Убедитесь, что вы установили последние обновления Windows, накопительные пакеты обновления. Make sure that you install the latest Windows updates, cumulative updates, and rollup updates. Чтобы проверить состояние обновления, обратитесь к соответствующей истории обновлений для вашей системы: To verify the update status, refer to the appropriate update history for your system:

Опытные пользователи также могут обратиться к журналу, созданному Центром обновления Windows, для дальнейшего изучения. Advanced users can also refer to the log generated by Windows Update for further investigation.

При использовании Центра обновления Windows могут возникнуть следующие сценарии. You might encounter the following scenarios when using Windows Update.

Почему мне предлагается более старое обновление? Why am I offered an older update?

Обновление, которое предлагается на устройстве, зависит от нескольких факторов. The update that is offered to a device depends on several factors. Ниже приведены некоторые из наиболее распространенных атрибутов: The following are some of the most common attributes:

Если предлагаемые обновления не являются самыми актуальными, возможно, ваше устройство управляется сервером WSUS, и вам предлагаются обновления, доступные на этом сервере. If the update you’re offered isn’t the most current available, it might be because your device is being managed by a WSUS server, and you’re being offered the updates available on that server. Кроме того, если устройство входит в группу развертывания, администратор намеренно замедляет развертывание обновлений. It’s also possible, if your device is part of a deployment group, that your admin is intentionally slowing the rollout of updates. Так как развертывание начинается медленно и измеряется, все устройства не получат обновление в один и тот же день. Since the deployment is slow and measured to begin with, all devices will not receive the update on the same day.

Мое устройство застыло при проверке. My device is frozen at scan. Почему? Why?

Пользовательский интерфейс параметров взаимодействует со службой обновления Orchestrator, которая, в свою очередь, взаимодействует со службой Центра обновления Windows. The Settings UI communicates with the Update Orchestrator service that in turn communicates with to Windows Update service. Если эти службы неожиданно останавливаются, это может привести к такому поведению. If these services stop unexpectedly, then you might see this behavior. В таких случаях выполните следующие действия: In such cases, follow these steps:

Закройте приложение «Параметры» и снова откроете его. Close the Settings app and reopen it.

Запустите Services.msc и проверьте, запущены ли следующие службы: Start Services.msc and check if the following services are running:

Обновления компонентов не предлагаются, в то время как другие обновления Feature updates are not being offered while other updates are

Устройства под управлением Windows 10 версии 1709–Windows 10 версии 1803, которые настроены на обновления из Центра обновлений Windows (включая Центр обновления Windows для бизнеса), могут устанавливать обслуживающие обновления и обновления определений, но никогда не предлагают обновления компонентов. Devices running Windows 10, version 1709 through Windows 10, version 1803 that are configured to update from Windows Update (including Windows Update for Business) are able to install servicing and definition updates but are never offered feature updates.

Проверка windowsUpdate.log выявит следующую ошибку: Checking the WindowsUpdate.log reveals the following error:

Код ошибки 0x80070426 преобразуется в: The 0x80070426 error code translates to:

Помощник по входу в учетную запись Майкрософт (MSA или wlidsvc) — это служба, о которой идет речь. Microsoft Account Sign In Assistant (MSA or wlidsvc) is the service in question. Служба DCAT Flighting (Идентификатор службы: 855E8A7C-ECB4-4CA3-B045-1DFA50104289) полагается на MSA для получения глобального идентификатора устройства для устройства. The DCAT Flighting service (ServiceId: 855E8A7C-ECB4-4CA3-B045-1DFA50104289) relies on MSA to get the global device ID for the device. Без запуска службы MSA глобальный идентификатор устройства не будет создан и отправлен клиентом, а поиск обновлений компонентов никогда не будет завершен успешно. Without the MSA service running, the global device ID won’t be generated and sent by the client and the search for feature updates never completes successfully.

Чтобы устранить эту проблему, сбросьте службу к значению MSA StartType по умолчанию — «вручную». To resolve this issue, reset the MSA service to the default StartType of «manual.»

Проблемы, связанные с HTTP/прокси-сервером Issues related to HTTP/Proxy

Центр обновления Windows использует WinHttp с запросами частичного диапазона (RFC 7233) для загрузки обновлений и приложений с серверов Центра обновления Windows или локальных серверов WSUS. Windows Update uses WinHttp with Partial Range requests (RFC 7233) to download updates and applications from Windows Update servers or on-premises WSUS servers. Поэтому прокси-серверы в сети должны поддерживать запросы HTTP RANGE. Therefore proxy servers on the network must support HTTP RANGE requests. Если прокси-сервер был настроен в Internet Explorer (на уровне пользователя), но не в WinHTTP (на уровне системы), подключение к Центру обновления Windows не будет выполнено. If a proxy was configured in Internet Explorer (User level) but not in WinHTTP (System level), connections to Windows Update will fail.

Чтобы устранить эту проблему, настройте прокси-сервер в WinHTTP с помощью следующей команды netsh: To fix this issue, configure a proxy in WinHTTP by using the following netsh command:

Также можно импортировать параметры прокси-сервера из Internet Explorer с помощью следующей команды: netsh winhttp import proxy source=ie You can also import the proxy settings from Internet Explorer by using the following command: netsh winhttp import proxy source=ie

Если при загрузке через прокси-сервер произошла ошибка 0x80d05001 DO_E_HTTP_BLOCKSIZE_MISMATCH или вы заметили высокую загрузку процессора во время загрузки обновлений, проверьте конфигурацию прокси-сервера, чтобы разрешить выполнение запросов HTTP RANGE. If downloads through a proxy server fail with a 0x80d05001 DO_E_HTTP_BLOCKSIZE_MISMATCH error, or if you notice high CPU usage while updates are downloading, check the proxy configuration to permit HTTP RANGE requests to run.

Вы можете применить правило, разрешающее запросы HTTP RANGE для следующих URL-адресов: You might choose to apply a rule to permit HTTP RANGE requests for the following URLs:

*.download.windowsupdate.com
*.dl.delivery.mp.microsoft.com *.delivery.mp.microsoft.com

Если вы не можете разрешить запросы RANGE, вы будете загружать больше содержимого, чем необходимо в обновлениях (так как delta patching не будет работать). If you can’t allow RANGE requests, you’ll be downloading more content than needed in updates (as delta patching will not work).

Обновление не применимо к компьютеру The update is not applicable to your computer

Наиболее распространенные причины этой ошибки описаны в следующей таблице: The most common reasons for this error are described in the following table:

Проблемы, связанные с конфигурацией брандмауэра Issues related to firewall configuration

Ошибка, которая может возникнуть в журналах Центра обновления Windows: Error that you might see in Windows Update logs:

Перейдите в services.msc и убедитесь, что служба брандмауэра Windows включена. Go to Services.msc and ensure that Windows Firewall Service is enabled. Остановка службы, связанной с брандмауэром Windows в режиме повышенной безопасности, не поддерживается корпорацией Майкрософт. Stopping the service associated with Windows Firewall with Advanced Security is not supported by Microsoft. Дополнительные сведения см. в разделе Отключение брандмауэра Windows. For more information, see I need to disable Windows Firewall.

Проблемы, возникающие в связи с конфигурацией конфликтующих политик Issues arising from configuration of conflicting policies

Центр обновления Windows предоставляет широкий спектр политик конфигурации для управления поведением службы Центра обновления Windows в управляемой среде. Windows Update provides a wide range configuration policy to control the behavior of the Windows Update service in a managed environment. Хотя эти политики и могут настраивать параметры на детальном уровне, неправильная настройка или установка конфликтующих политик может привести к неожиданному поведению. While these policies let you configure the settings at a granular level, misconfiguration or setting conflicting policies may lead to unexpected behaviors.

Устройство не может получить доступ к файлам обновления Device cannot access update files

Убедитесь, что устройства могут достичь необходимые конечные точки Центра обновления Windows через брандмауэр. Ensure that devices can reach necessary Windows Update endpoints through the firewall. Например, для Windows 10 версии 2004 следующие протоколы должны иметь возможность достигать следующих конечных точек: For example, for Windows 10, version 2004, the following protocols must be able to reach these respective endpoints:

Не используйте протокол HTTPS для конечных точек, которые указывают HTTP, и наоборот. Be sure not to use HTTPS for those endpoints that specify HTTP, and vice versa. Подключение приведет к ошибке. The connection will fail.

Конкретные конечные точки могут отличаться в зависимости от версий Windows 10. The specific endpoints can vary between Windows 10 versions. См., например, раздел Конечные точки подключения Windows 10 Корпоративная 2004. See, for example, Windows 10 2004 Enterprise connection endpoints. Похожие статьи для других версий Windows 10 доступны в содержании рядом. Similar articles for other Windows 10 versions are available in the table of contents nearby.

Обновления не загружаются из конечной точки интрасети (WSUS или Диспетчер конфигураций) Updates aren’t downloading from the intranet endpoint (WSUS or Configuration Manager)

Устройства с Windows 10 могут получать обновления из различных источников, включая Центр обновления Windows в Интернете, службы Windows Server Update Services и другие. Windows 10 devices can receive updates from a variety of sources, including Windows Update online, a Windows Server Update Services server, and others. Для определения источника обновлений Windows, используемых в настоящее время на устройстве, выполните следующие действия. To determine the source of Windows Updates currently being used on a device, follow these steps:

Проверьте выходные данные параметров Name и OffersWindowsUPdates, которые можно интерпретировать в соответствии с этой таблицей. Check the output for the Name and OffersWindowsUPdates parameters, which you can interpret according to this table.

В среде имеется неудачная настройка You have a bad setup in the environment

В этом примере для групповой политики, заданной через реестр, система настроена на использование WSUS для загрузки обновлений (обратите внимание на вторую строку): In this example, per the Group Policy set through registry, the system is configured to use WSUS to download updates (note the second line):

Из журналов Центра обновления Windows: From Windows Update logs:

Как показано в следующих журналах, автоматическое обновление запускает сканирование и не находит для него утвержденных обновлений. As shown in the following logs, automatic update runs the scan and finds no update approved for it. Таким образом, сообщается, что обновления для установки или загрузки отсутствуют. So it reports there are no updates to install or download. Это вызвано неправильной конфигурацией. This is due to an incorrect configuration. Сторона WSUS должна утвердить обновления для Центра обновления Windows, чтобы получать обновления и устанавливать их в указанное время в соответствии с политикой. The WSUS side should approve the updates for Windows Update so that it fetches the updates and installs them at the specified time according to the policy. Так как этот сценарий не включает диспетчера конфигураций, невозможно установить неутвержденные обновления. Since this scenario doesn’t include Configuration Manager, there’s no way to install unapproved updates. Ожидается, что агент операционной аналитики будет выполнять сканирование и автоматически запускать загрузку и установку, но этого не произойдет с этой конфигурацией. You’re expecting the operational insight agent to do the scan and automatically trigger the download and installation but that won’t happen with this configuration.

Использование высокой пропускной способности в Windows 10 через Центр обновления Windows High bandwidth usage on Windows 10 by Windows Update

Пользователи могут увидеть, что Windows 10 использует всю пропускную способность в разных офисах в контексте локального компьютера. Users might see that Windows 10 is consuming all the bandwidth in the different offices under the system context. Это поведение реализовано намеренно. This behavior is by design. Компоненты, которые могут использовать пропускную способность, выходят за рамки компонентов Центра обновления Windows. Components that might consume bandwidth expand beyond Windows Update components.

Следующие групповые политики могут помочь смягчить эту ситуацию: The following group policies can help mitigate this situation:

Другие компоненты, подключающиеся к Интернету: Other components that connect to the internet:

Источник

Не обновляется windows server 2016

Вопрос

Ответы

Попытаюсь возобновить данную тему. Прошло почти 2 года. Что-то изменилось по данному вопросу? Какие варианты поднять версию с 1607 до 1709?

Поднимать не до 1709
а до Windows Server 2019

Все ответы

и не придет. это другая линия разработки и распространения.

и через поиск скачать и установить вручную нужный апдейт?

что я делаю не так?

возможно разрядность, язык системы другие. В http://catalog.update.microsoft.com вбейте в поиск (1709) и выберите свой вариант пакета обновления для 2016.

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

Получение Windows Server версии 1709

Для этого выпуска следует применять чистую установку.

Для этого выпуска следует применять чистую установку.

т.е. имеющиеся сервера не обновить?

а на вопрос слабо ответить? я вижу что там обновления для 1709.

2модератор: сорри, не сдержался 🙂

во-первых, не для себя просил, ибо сам писал раньше (но, видимо, не нашлось и пары секунд чтобы это прочитать):

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

Получение Windows Server версии 1709

Для этого выпуска следует применять чистую установку.

Так это что получается мне нужно заново ставить систему на сервер? Бред какой-то. А другого пути нет?

Почему эти обновления не ставятся как на обычной десятке?

Почему эти обновления не ставятся как на обычной десятке?

По приведенной ссылке написано где брать образы. Они недоступны для всех. Даже для партнёров нет.

Возможно, имя образ можно будет обновиться in-place (поверх установленной). На неделе проверю, если образ будет

Так это что получается мне нужно заново ставить систему на сервер? Бред какой-то. А другого пути нет?

Почему эти обновления не ставятся как на обычной десятке?

ну как бы нагляднее объяснить. 🙂

. как вы себе представляете обновление, например полноценного сервера на nano?

здесь примерно та же ситуация. это если очень грубо сравнивать.

то что я сейчас напишу является только моим субъективным восприятием ситуации и не претендует на истину.

во-первых, Hyper-V не совсем тождественно понятию «виртуализация»

во-вторых, для мониторинга, управления и прочего серверами WS 201* Hyper-V успешно используется W10 или полноценные сервера 201*, через диспетчер серверов например

в-третьих, 1709 (на мой взгляд) позиционируется в первую очередь как гостевая ОС в системах виртуализации, либо как платформа для виртуализации в дата-центрах. отсюда и уклон в удаленное управление и отсутствие междумордия за ненадобностью

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

Источник

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.

Картинка с сайта: www.sysprobs.com

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.

Картинка с сайта: www.sysprobs.com

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.

Картинка с сайта: www.sysprobs.com

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 proxy

3) 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.

Картинка с сайта: www.sysprobs.com

Once the service stops successfully, navigate to the following folder location and delete all content (files and folders).

C:\Windows\SoftwareDistribution

Картинка с сайта: www.sysprobs.com

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