80244017 ошибка обновления windows через wsus

Recently configured WSUS on Server 2012 RC for a lab environment in preparation for RTM and ran into a configuration problem. Clients were failing to download updates and reporting error 0x80244017. After ensuring my RC installation was updated with KB 2627818 and that the clients had KB 2720211, I double checked that clients could access the WSUS site: https://wsusserver:8531/ClientWebService/client.asmx (you’ll receive a YSOD .NET error if you load that in a web browser, it’s normal). The C:WindowsWindowsUpdate.log file contained the following error information:

WARNING: Download job failed because of proxy auth or server auth.
Error 0x80244017 occurred while downloading update; notifying dependent calls.

After some brief troubleshooting, I came across a post that suggested it was an authentication problem, but anonymous authentication had been configured in IIS appropriately. I compared NTFS permissions of the WSUS folder with a working installation in our production environment, and found that the local Users group did not have permissions. After granting the Users group Read permissions, clients were able to successfully download updates.

Если обновлять Windows с помощью WSUS, то можно не получить желаемого, увидев ошибку с кодом 0x80244017. Она означает, что какой-то нюанс блокирует загрузку необходимых файлов апдейтов.

Как исправить ошибку 0x80244017

Решается неисправность следующими методами:

1. Убедитесь в наличии прав. Аккаунты клиентских ПК должен иметь допуски на получении информации (Чтение) с сервера. Также в настройках IIS на WSUS нужно подключаться к сети под аккаунтом Администратора домена.
2. Измените параметры подключения к серверу. Адрес WSUS переименуйте на http://grizzly, проверьте корректность DNS на сервере и клиенте таким образом, чтобы при подсоединении не применялся FQDN. Во многих случаях это устраняет ошибку 0x80244017.

Записки IT специалиста

Технический блог специалистов ООО»Интерфейс»

• Главная
• Устраняем ошибки Windows Update при работе через прокси-сервер Squid

Устраняем ошибки Windows Update при работе через прокси-сервер Squid

При работе с прокси-сервером Squid вы можете столкнуться с ситуацией, когда служба Windows Update или WSUS перестанут получать обновления. Ситуация действительно неприятная и проявляется она чаще всего уже «по факту», когда клиентские машины перестают получать обновления и нужно срочно принимать меры. Однако такое поведение службы обновления давно известно и отражено в документации. Сегодня мы разберем подробно причину возникновения ошибки и покажем возможные действия по ее устранению.

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

• 0x80244017
• 0x80244018
• 0x80244019
• 0x8024401B
• 0x80244021

Для ее возникновения требуется сочетание нескольких факторов: наличия в сети прокси-сервера с аутентификацией пользователей и службы WPAD. Неподготовленного администратора данная ошибка застает врасплох, однако существует статья KB896226, которая подробно проливает свет на проблему и способы ее решения:

Чтобы устранить эту проблему, убедитесь, что прокси-сервер или брандмауэр настроены для анонимного доступа к веб-сайту Центра обновления Windows.

Если коротко, то суть происходящих событий следующая: для доступа к серверам Центра обновлений система использует службу Windows HTTP (WinHTTP), которая в свою очередь поддерживает автоматическое получение настроек прокси через WPAD. Т.е. все запросы к серверам обновлений будут автоматически направлены на прокси, это не доставляет проблем до тех пор, пока прокси-сервер не начинает требовать аутентификации клиентов. Службы Windows Update не могут пройти аутентификацию и возникает проблема с получением обновлений.

Чтобы избавиться от этой ошибки следует выполнить рекомендации Microsoft и обеспечить анонимный доступ к серверам обновлений. Сделать это можно достаточно просто и несколькими способами. Рассмотрим их подробнее.

Squid

Система контроля доступа Squid дает в руки администратора мощный инструмент управления и этим следует пользоваться. Тем более что стоящая перед нами задача ничем не отличается от URL-фильтрации по спискам, о которой мы рассказывали ранее.

Создадим отдельный список для служб Windows Update:

и внесем в него следующие записи:

За его основу мы взяли список из KB896226 который актуализировали и дополнили исходя из собственного опыта и наработок коллег.

Теперь создадим элемент ACL для работы со списком:

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

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

Существует также еще один вариант — направить трафик к серверам обновлений минуя прокси-сервер. В этом нам поможет протокол WPAD, точнее специальные правила в PAC-файле. На наш взгляд этот метод менее предпочтителен, но вполне имеет право на существование.

Для его реализации добавьте в файл wpad.dat следующие инструкции:

Изменения вступают в силу сразу, перезапускать службы не требуется.

При использовании данного метода следует принять во внимание еще один момент — если вы принимали меры по запрету обхода прокси, например, при помощи iptables, то следует явно разрешить соединения к серверам обновлений. На текущий момент указанным серверам соответствуют следующие IP-адреса:

Собственно, поэтому не рекомендуем данный способ, так как поддерживать один список доменных имен для Squid проще, чем два, тем более что соответствие доменных имен IP-адресам может меняться. В любом случае теперь вы понимаете источник проблемы и можете самостоятельно выбрать наиболее предпочтительный способ ее решения.

Дополнительные материалы:

Помогла статья? Поддержи автора и новые статьи будут выходить чаще:

Или подпишись на наш Телеграм-канал:

Ошибка 0x80240017 при загрузке или установке Центра обновления Windows в Windows 10

Недавно, когда я обновлял свою Windows 10, при установке обновления я получил Ошибка Центра обновления Windows 0x80240017 . Вы также можете получить сообщение Ошибка загрузки 0x0248007 , в котором обновления могут не загрузиться. Я перезагрузил компьютер и попытался снова, но не смог продолжить успешно – я снова получил ту же ошибку. Если вы тоже столкнулись с этой проблемой, возможно, то, что я сделал, может вам тоже помочь.

Ошибка загрузки 0x0248007

Ошибка Центра обновления Windows 0x80240017

Щелкните правой кнопкой мыши кнопку «Пуск», чтобы открыть меню WinX. Выберите Командная строка (Администратор).

Теперь напечатайте следующий один за другим и нажмите Enter:

Это остановит фоновую интеллектуальную службу передачи и службу обновления Windows .

Теперь перейдите в папку C: Windows SoftwareDistribution и удалите все ее содержимое. Я предлагаю вам нажать Ctrl + A, чтобы выбрать все, а затем удалить.

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

Теперь вы сможете удалить файлы из указанной папки Software Distribution .

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

Запустите Центр обновления Windows еще раз и посмотрите, помогло ли это.

Мне удалось загрузить и установить обновления успешно. Я надеюсь, что это работает и для вас.

Если это не так, запустите средство устранения неполадок Центра обновления Windows и посмотрите, поможет ли это.

80244017 ошибка обновления windows через wsus

Вопрос

История такая. Около 3х лет стоял и нормально работал WSUS. Некоторое время назад перестал работать, ни консоль не запускалась, ни к базе не подключался, соответственно и клиенты не обновлялись, намертво вобщем, переустановка роли WSUS не помогала. По этим и некоторым другим причинам было принято решение переустановить серверную ОС полностью, с новым именем (роли на нём некритичные), в политики изменения внесены с новым именем wsus-сервера.

Сервер: Windows server 2012 R2. Роли: Hyper-V, WSUS.

Заново установили WSUS со встроенной БД, настроили, заново даже скачали контент(т.е. синхронизация проходит нормально), постепенно появились клиенты, предоставили отчёты о состоянии. Затем клиенты пытались установить обновления, неудачно, о чём и приходили отчёты на WSUS. Со стороны клиента: клиент ищет обновления на wsusе, находит, но при попытке скачивания происходят отказы с ошибкой 80244017. Причём не скачиваются обновления ни на рабочих станциях, ни на серверах, ни на самом сервере с WSUSом.

WSUS Client Diagnostics Tool выдаёт следующее:

Checking Machine State
Checking for admin rights to run tool . . . . . . . . . PASS
Automatic Updates Service is running. . . . . . . . . . PASS
Background Intelligent Transfer Service is running. . . PASS

GetFileVersion(szEngineDir,&susVersion) failed with hr=0x80070002

Автоматическое устранение неполадок на клиенте положительных результатов не дало . Сканирование системы командой DISM.exe /Online /Cleanup-image /Restorehealth выполнено успешно (компоненты восстановлены)

Wuauclt.exe /resetauthorization /detectnow пробовали.

Со стороны сервера в журналах такая ошибка:

80244017 ошибка обновления windows через wsus

This forum has migrated to Microsoft Q&A. Visit Microsoft Q&A to post new questions.

Answered by:

Question

The client has stopped getting updates for some time. The problem is with BOTH WSUS server, AND Windows update site.
I have tried everything I can think of, but I still get the errors 0x80244017 and 0x80190191.

here is a snippet of the log;
2010-02-08 14:10:51:465 4308 10d8 COMAPI ————-
2010-02-08 14:10:51:465 4308 10d8 COMAPI — START — COMAPI: Search [ClientId = MicrosoftUpdate]
2010-02-08 14:10:51:465 4308 10d8 COMAPI ———
2010-02-08 14:10:51:480 1032 143c Agent *************
2010-02-08 14:10:51:480 4308 10d8 COMAPI >— RESUMED — COMAPI: Search [ClientId = MicrosoftUpdate]
2010-02-08 14:11:36:075 4308 1444 COMAPI — Updates found = 0
2010-02-08 14:11:36:075 4308 1444 COMAPI — WARNING: Exit code = 0x00000000, Result code = 0x80244017
2010-02-08 14:11:36:075 4308 1444 COMAPI ———
2010-02-08 14:11:36:075 4308 1444 COMAPI — END — COMAPI: Search [ClientId = MicrosoftUpdate]
2010-02-08 14:11:36:075 4308 1444 COMAPI ————-

Answers

2010-02-10 09:40:44:219 1032 11fc Agent * Access type: Named proxy
2010-02-10 09:40:44:219 1032 11fc Agent * Default proxy: https://FINSYS2;http://FINSYS2
2010-02-10 09:40:44:219 1032 11fc Agent * Default proxy bypass: ;FINSYS2

2010-02-10 09:41:29:658 1032 11fc Agent * WSUS server: http://grizzly.MY.DOMAIN:80
2010-02-10 09:41:29:658 1032 11fc Agent * WSUS status server: http://grizzly.MY.DOMAIN:80

One possible contributing factor is the combination of a proxy client configuration with a Fully Qualified URL for the WSUS server.

Generally speaking, Windows clients have this undesirable behavior of routing requests for FQDN URLs direct to the proxy server, despite a bypass being configured.

I would suggest changing your WSUS URL to http://grizzly and ensuring that DNS services are properly configured on the DNS Server and the client(s), so that the FQDN is not required within the confines of local network resources.

Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
Principal/CTO, Onsite Technology Solutions, Houston, Texas
Microsoft MVP — Software Distribution (2005-2010)
My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
My Blog: http://onsitechsolutions.spaces.live.com

The client has stopped getting updates for some time. The problem is with BOTH WSUS server, AND Windows update site.
I have tried everything I can think of, but I still get the errors 0x80244017 and 0x80190191.

here is a snippet of the log;

2010-02-08 14:10:51:465 4308 10d8 COMAPI ————-
2010-02-08 14:10:51:465 4308 10d8 COMAPI — START — COMAPI: Search [ClientId = MicrosoftUpdate]
2010-02-08 14:10:51:465 4308 10d8 COMAPI ———

2010-02-08 14:11:06:684 1032 143c Misc WARNING: DownloadFileInternal failed for http://download.windowsupdate.com/v9/windowsupdate/redir/muv4wuredir.cab: error 0x80190191

This client is not using WSUS; this detection was performed against Microsoft Update.

The client is receiving an HTTP 401 error trying to access the MU site — most likely because it’s being blocked by a proxy server.
Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
Principal/CTO, Onsite Technology Solutions, Houston, Texas
Microsoft MVP — Software Distribution (2005-2010)
My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
My Blog: http://onsitechsolutions.spaces.live.com

You are correct, for that snippet I was testing against windows update, but it is the same when I go against my WSUS server (enforced by GPO). Errors are identical. I have tried renaming the softwaredistribution folder and still no go.

Then. since this is a =WSUS= forum, let’s have a look at the =WSUS= detection event.

But. if the errors truly are identical, then you’re choices are fairly limited — either something on the client is blocking permission for outbound access, or some device sitting between that client and both the WSUS Server and the Internet.

Specifications on the client will be helpful to know as well, including the last time it did successfully get updated from MU or WSUS. Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
Principal/CTO, Onsite Technology Solutions, Houston, Texas
Microsoft MVP — Software Distribution (2005-2010)
My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
My Blog: http://onsitechsolutions.spaces.live.com

Here is the current log.
The problem is several months old, but I found it only recently.
I have applied SP2.

The client and wsus server and on the same netwrok segment, no firewalls, or IPSEC. I am able, from the local admin account, to navigate to the testing links with no errors.
http://grizzly.MY.DOMAIN:80/selfupdate/wuident.cab

There does apear to be a proxy (due to sharepoint) but I have removed it and no effect (I have replaced it). I am willing to try anything agian with step by step instructions if it is believed I haven’t done something correctly.