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

Обнаружил одну интересную особенность в службе обновлений 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

Как вы видите, параметры прокси-сервера для 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

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

Если нажать кнопку Retry, то обновление снова завершается ошибкой. Накопительное обновление KB4103720 никак не хочет устанавливаться. Посмотреть какое обновление вызвало ошибку можно в журнале обновлений Update history.

Пошерстив Интернет, нашёл несколько советов, которые могут помочь в таком случае.

Аналогичная ошибка при установке обновлений:

• KB4103720
• KB4103723

Первый совет, который мне не помог

Установить опцию «При обновлении Windows получать обновления для других продуктов Майкрософт». Захожу в дополнительные настройки Advanced option и включаю «Give me updates for other Microsoft products when I update Windows».

Говорят, что обновление может не устанавливаться, если оно зависит от какого-то другого, необязательного обновления. Я, правда, в этом сомневаюсь.

Мне не помогло.

Второй совет, который мне не помог

Обновить вручную антивирус. Антивирусные базы должны обновляться автоматически, но из-за ошибки этого не происходит. Даже есть это не поможет, то хотя бы антивирус будет обновлён. Я в этом способе тоже сомневаюсь. Хотя, если у вас стоит какой-то другой антивирус, то он может мешать обновлениям, его можно попытаться отключить. У меня на сервере стоит только защитник Windows.

Запускаю Windows Defender. Да, базы не обновлены.

Нажимаю кнопку Update definitions.

Антивирусные базы обновляются.

Мне не помогло.

Третий совет, который мне не помог

Если сервер находится в домене, то, возможно, обновление скачивается с WSUS. Оно может быть битым или вообще ненужным. Можно отключить обновление через WSUS, чтобы сервер скачал патч напрямую из Microsoft.

Я уже пользовался этим способом при ошибке 0x80244011.

Windows Server 2016 — отключаем обновление через WSUS

Мне не помогло.

Четвёртый совет, который мне не помог

Через панель управления устраняем неполадки с центром обновления Windows.

Панель управления → Устранение неполадок → Система и безопасность → Центр обновления Windows.

Начинается поиск проблем, мешающим обновлению.

Найдена какая-то проблема и исправлена. Замечательно, но…

Мне не помогло.

Пятый совет, который мне не помог

Все обновления перед установкой скачиваются в директорию SoftwareDistribution. А подписи обновлений хранятся в папке catroot2. Эти папки можно почистить или удалить, но придётся остановить несколько служб.

Я воспользовался скриптом для командной строки:

Net Stop bits
Net Stop wuauserv
Net Stop appidsvc
Net Stop cryptsvc
Ren %systemroot%\SoftwareDistribution SoftwareDistribution.bak
Ren %systemroot%\system32\catroot2 catroot2.bak
Net Start bits
Net Start wuauserv
Net Start appidsvc
Net Start cryptsvc

Скрипт останавливает несколько сервисов м переименовывает папки SoftwareDistribution и catroot2. Потом снова запускает остановленные службы.

Мне не помогло.

Шестой совет, который мне помог

Проблемное обновление можно скачать из каталога Windows и установить вручную.

https://www.catalog.update.microsoft.com/Home.aspx

Нахожу в каталоге проблемное накопительное обновление KB4103720 для Windows Server 2016. Скачиваю и запускаю.

Обновление успешно устанавливается.

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

Вместо заключения

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

Windows Server 2016 является одной из наиболее популярных операционных систем для серверов. Однако, при установке накопительных обновлений, пользователи иногда сталкиваются с ошибками, которые могут затруднить процесс.

Одной из самых распространенных ошибок является ошибка «Не удалось установить обновление». Эта ошибка может возникнуть по разным причинам, включая проблемы с интернет-соединением, поврежденные файлы системы или конфликты с установленными программами.

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

Далее, вам следует проверить целостность файлов системы. Для этого можно воспользоваться инструментом «Проверка целостности системных файлов». Если этот инструмент обнаружит поврежденные файлы, он автоматически попытается восстановить их.

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

Если приведенные выше рекомендации не помогли, вы можете обратиться в службу поддержки Microsoft или обратиться к сообществу пользователей операционной системы Windows Server 2016 для получения дополнительной помощи.

Как решить проблему с установкой обновления накопительного обновления на Windows Server 2016

Установка накопительных обновлений важна для поддержания безопасности и стабильности операционной системы Windows Server 2016. Однако иногда пользователи могут столкнуться с проблемами при установке таких обновлений. В этом руководстве мы рассмотрим несколько шагов, которые помогут вам решить проблему с установкой накопительного обновления.

1. Проверьте наличие достаточного места на диске:

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

2. Перезагрузите сервер:

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

3. Отключите антивирусное ПО:

Некоторые антивирусные программы могут блокировать установку обновлений. Попробуйте отключить антивирусное ПО временно и запустить установку обновления снова.

4. Используйте инструмент Windows Update Troubleshooter:

Windows Update Troubleshooter — это встроенный инструмент Windows, предназначенный для автоматического исправления проблем с установкой обновлений. Запустите инструмент и следуйте инструкциям на экране для решения проблемы.

5. Установите обновление вручную:

Если все остальные методы не работают, вы можете попробовать скачать и установить обновление вручную. Посетите официальный сайт Microsoft, найдите подходящее накопительное обновление для вашей версии Windows Server 2016 и следуйте инструкциям по установке.

Надеемся, что эти шаги помогут вам решить проблему с установкой накопительного обновления на Windows Server 2016. Если проблема все еще не решена, рекомендуется обратиться в службу поддержки Microsoft для получения дальнейшей помощи.

Проверьте доступность сети

Перед установкой накопительного обновления Windows Server 2016 убедитесь, что у вас есть стабильное подключение к сети интернет. Обновление требует загрузки файлов с серверов Microsoft, поэтому отсутствие или нестабильность сети может привести к ошибке установки.

Для проверки доступности сети выполните следующие действия:

1. Убедитесь, что компьютер подключен к сети и имеет доступ к Интернету.
2. Проверьте работоспособность сетевого адаптера и правильность настроек сетевых подключений.
3. Запустите команду «ping» для проверки доступности серверов Microsoft. Например, выполните команду «ping www.microsoft.com» и проверьте, получаете ли вы ответ от сервера.
4. Если у вас есть прокси-сервер или персональный брандмауэр, убедитесь, что они не блокируют доступ к серверам Microsoft. Проверьте настройки прокси-сервера и брандмауэра и добавьте соответствующие исключения, если необходимо.

Если после выполнения всех вышеперечисленных действий сеть работает стабильно и вы можете получить доступ к серверам Microsoft, попробуйте установить накопительное обновление снова.