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

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

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

Каталог содержимого WSUS недоступен.
System.Net.WebException: Удаленный сервер возвратил ошибку: (401) Несанкционированный.
   в System.Net.HttpWebRequest.GetResponse()
   в Microsoft.UpdateServices.Internal.HealthMonitoring.HmtWebServices.CheckContentDirWebAccess(EventLoggingType type, HealthEventLogger logger)

И такая:

Права доступа для каталога D:WSUS установлены неправильно.

Windowsupdatelog даже за сегодня длинный: https://yadi.sk/i/DYoe-BuNs82Cq

Подскажите, куда копать?

  • Изменено

    30 мая 2016 г. 14:54

  • Изменен тип
    Vasilev VasilMicrosoft contingent staff
    2 июня 2016 г. 9:15
  • Изменен тип
    Dmitriy4722
    8 июня 2016 г. 10:20

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.

I have a problem with some machines presenting Windows Update error 0x80244017.

Situation:

Small school

Server 2016 STD as a guest under hyper-v. This server is the one and only, so it does everything FSMO, AD, WSUS, DHCP, DNS, etc. Hoping to acquire another server next year to provide backup AD, DHCP, etc. There’s a debian VM as well, running squid proxy
server to limit and log the students’ use of social media and other unwelcome websites. I used a registry patch to configure the proxy settings for IE and Edge, and a Group policy to set Chrome’s proxy settings (long story).

30 laptops W10Pro

I’m performing windows updates during school holidays. All but 3 laptops went OK. This was also the feature upgrade to 1903.

I inspect and approve the updates in WSUS.

I restart each laptop and sign in to the domain with my own account — I’m a member of domain administrators. 3 laptops just will not update, reporting windows update error 0x80244017. I’ve tried all the suggestions that came up with a search of that error:

Local Windows update troubleshooter (settings, update & security, troubleshoot, update troubleshooter)- couldn’t identify the problem

Download the Windows update troubleshooter (run as administrator) — couldn’t identify the problem. The only item identified was «BITS service was already started»

Manual reset of Windows update components — stop wuauserv, stop BITS, stop crypto, rename softwaredistribution data store and download, restart services  — didn’t fix the problem

Run SFC /scannow — found but didn’t fix problems. Data in CBS.log is beyond my experience.

Run DISM /online /cleanup-image /restorehealth — crashed at 87.6%. Data in log is beyond my experience.

Manual download and install updated servicing stack KB4512577 — installed, but didn’t fix the problem

Finally used the media creation tool to download and burn W10 1903 ISO to DVD, run in-place upgrade. Great! 1903 is now installed, but it still reports windows update error 0x80244017.

Removed the machine from the domain, renamed it, added it to the domain again, still got the problem.

Enabled the domain «Administrator» account, logged off the machine, logged in to the domain as «Administrator», and bingo! no error, only one or two updates, but it worked. Logged off, and back on again using my account, the error came
back.

So, to my mind, I have an authentication problem somewhere. All the other laptops were updated using my credentials.

Where can I find out what’s gone wrong? I don’t want to continue having to use the domain Administrator account to get these updates done.

cheers


Bernie Dwyer Clarity Computing Services

I have a problem with some machines presenting Windows Update error 0x80244017.

Situation:

Small school

Server 2016 STD as a guest under hyper-v. This server is the one and only, so it does everything FSMO, AD, WSUS, DHCP, DNS, etc. Hoping to acquire another server next year to provide backup AD, DHCP, etc. There’s a debian VM as well, running squid proxy
server to limit and log the students’ use of social media and other unwelcome websites. I used a registry patch to configure the proxy settings for IE and Edge, and a Group policy to set Chrome’s proxy settings (long story).

30 laptops W10Pro

I’m performing windows updates during school holidays. All but 3 laptops went OK. This was also the feature upgrade to 1903.

I inspect and approve the updates in WSUS.

I restart each laptop and sign in to the domain with my own account — I’m a member of domain administrators. 3 laptops just will not update, reporting windows update error 0x80244017. I’ve tried all the suggestions that came up with a search of that error:

Local Windows update troubleshooter (settings, update & security, troubleshoot, update troubleshooter)- couldn’t identify the problem

Download the Windows update troubleshooter (run as administrator) — couldn’t identify the problem. The only item identified was «BITS service was already started»

Manual reset of Windows update components — stop wuauserv, stop BITS, stop crypto, rename softwaredistribution data store and download, restart services  — didn’t fix the problem

Run SFC /scannow — found but didn’t fix problems. Data in CBS.log is beyond my experience.

Run DISM /online /cleanup-image /restorehealth — crashed at 87.6%. Data in log is beyond my experience.

Manual download and install updated servicing stack KB4512577 — installed, but didn’t fix the problem

Finally used the media creation tool to download and burn W10 1903 ISO to DVD, run in-place upgrade. Great! 1903 is now installed, but it still reports windows update error 0x80244017.

Removed the machine from the domain, renamed it, added it to the domain again, still got the problem.

Enabled the domain «Administrator» account, logged off the machine, logged in to the domain as «Administrator», and bingo! no error, only one or two updates, but it worked. Logged off, and back on again using my account, the error came
back.

So, to my mind, I have an authentication problem somewhere. All the other laptops were updated using my credentials.

Where can I find out what’s gone wrong? I don’t want to continue having to use the domain Administrator account to get these updates done.

cheers


Bernie Dwyer Clarity Computing Services

Содержание

  1. Методы решения ошибки 0x80244017
  2. Как исправить ошибку 0x80244017
  3. diflyon
  4. Журнал айтишника
  5. Ошибка 0x80240017 при загрузке или установке Центра обновления Windows в Windows 10
  6. Ошибка загрузки 0x0248007
  7. Ошибка Центра обновления Windows 0x80240017
  8. Управление системными патчами 0x80242017 ошибка агента обновлений windows 80242017
  9. Как исправить ошибку 0x80246017 в Windows 10?
  10. Шаг №1 Удаление файлов установки предыдущей Windows
  11. Шаг №2 Сброс нескольких разделов Реестра Windows

Методы решения ошибки 0x80244017

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

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

lazy placeholder

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

default avatar

lazy placeholder

Ошибка 0x80242017
Выше указанная проблема похоже, что возникает на недавно созданных машинах с базовой установкой 20H2, поэтому, когда Центр обновления Windows попытался перейти прямо к 2022-07 CU (KB5004945), у него не было обновления стека обслуживания с 2022-05 CU (KB5003173).
Рабочий вариант:
Скачать “Накопительное обновление 2022-05 для Windows 10 версии 20H2 для систем на базе x64 (KB5003173)” из каталога Центра обновления Windows, вручную установить его и перезагрузить компьютер, а после этого KB5004945 устанавливается из WSUS без дальнейших ошибок.
Т.е. установка KB5003173 является предварительным условием для установки KB5004945 и возможно дальнейших накопительных обновлений. Данная проблема исправляется также через DISM инсталляцией SSU-19041.1022-x64.cab.

Источник

userinfo v8diflyon

Журнал айтишника

Не смотря на то, что сейчас всё больше и больше пользователей переходят на Windows 10 c Windows 7 или Windows 8.1 тем не менее в корпоративном секторе остаются проблемы: совместимость некоторого ПО (например, КриптоПро) с Windows 10, а так же отсутствие бюджета на обновление лицензий операционной системы.

На днях я решил провести аудит информационных систем в компании и уладить лицензионные вопросы. В частности мне пришлось избавиться от уже привычной Windows 10 на рабочих ПК и вернуть OEM версии ОС, которые были предустановлены при копупке компьютеров. К сожалению, ПК оснащались в то время (2010г) Windows Vista Business и легально проапгрейдить бесплатно до Windows 10 её нельзя (должна быть минимум Windows 7).

Смирившись с этим досадным фактом, я ввёл в домен компании компьютеры на базе Windows Vista Business Edition (версия 6.0.6000).

В нашей доменной организации существует локальный WSUS (Windows Server Update Services), который работает под управлением Windows Server 2012 Standard. Обращаю внимание, что версия сервера без R2, потому что железо относительно старенькое и не поддерживает 2012 R2 из-за устаревшего BIOS. WSUS работает исправно, все компьютеры на базе Windows 7, 8.1 и 10 без проблем получают обновления и рапортуют о своём состоянии.

Теперь переходим к сути данной статьи.

Однако, я заметил, что появилась одна проблемка, компьютер на базе Vista Business почему-то не шлёт WSUS серверу отчет о состоянии. На WSUS постоянно сообщается, что данный компьютер «Not Yet Reported». А так же WSUS определяет и отображает в списке, что на этом компьютере установлена «Windows 6.0» вместо «Windows Vista Business».

При попытке выполнить

wuauclt /detectnow
wuauclt /reportnow

внешне ничего не меняется. Windows Update сообщает, что новых обновлений не найдено. На WSUS обновлений, которые нужно одобрить тоже не появляется.
Если заглянуть в журнал обновлений, то видно, что 3 обновления всё-таки были установлены: два обновления Definition Update for Windows Defender и одно Microsoft Silverlight.

Чтобы разобраться в этой проблеме почитаем лог событий Windows Update.
Стандартно он расположен в C:WindowsWindowsUpdate.log

Самое начало лога я пропускаю, там никаких серьёзных ошибок не было и трассировки описывали успешность загрузок обновлений в папку C:WindowsSoftwareDistributionDownload.
Нужно начинать смотреть с ключевого выражения «Logging initialized», обозначающее начало работы службы Windows Update.

2016-06-22 03:28:20:577 1148 bc4 Misc =========== Logging initialized (build: 6.0.6000.16386, tz: +0400) ===========
2016-06-22 03:28:20:640 1148 bc4 Misc = Process: C:Windowssystem32svchost.exe
2016-06-22 03:28:20:718 1148 bc4 Misc = Module: c:windowssystem32wuaueng.dll
2016-06-22 03:28:20:577 1148 bc4 Service *************
2016-06-22 03:28:20:796 1148 bc4 Service ** START ** Service: Service startup
2016-06-22 03:28:20:874 1148 bc4 Service *********
2016-06-22 03:28:20:953 1148 bc4 Agent * WU client version 6.0.6000.16386
2016-06-22 03:28:20:953 1148 bc4 Agent * Base directory: C:WindowsSoftwareDistribution
2016-06-22 03:28:21:031 1148 bc4 Agent * Access type: No proxy
2016-06-22 03:28:21:109 1148 bc4 Agent * Network state: Connected

Смотрим дальше по логу:

2016-06-22 03:29:06:277 1148 bc4 Agent *********** Agent: Initializing global settings cache ***********
2016-06-22 03:29:06:277 1148 bc4 Agent * WSUS server: http://wsus.abcde.ru:8530
2016-06-22 03:29:06:277 1148 bc4 Agent * WSUS status server: http://wsus.abcde.ru:8530
2016-06-22 03:29:06:277 1148 bc4 Agent * Target group: (Unassigned Computers)
2016-06-22 03:29:06:277 1148 bc4 Agent * Windows Update access disabled: No
2016-06-22 03:29:06:387 1148 bc4 Agent * Found 98 persisted download calls to restore

Видим, что агент получает настройки для обращения к локальному WSUS и что найдено 98 запросов на возобновление загрузок.
Затем идёт блок с подробным описанием, какие загрузки обновлений возобновляются:

2016-06-22 03:29:06:512 1148 bc4 DnldMgr Download manager restoring 6 downloads
2016-06-22 03:29:06:794 1148 bc4 DtaStor Update service properties: service registered with AU is <9482f4b4-e343-43b6-b170-9a65bc822c77>
2016-06-22 03:29:06:794 1148 bc4 Agent * Succeeded to load 98 persisted download calls
2016-06-22 03:29:06:810 1148 bc4 DnldMgr Retrieved 13 persisted download jobs
2016-06-22 03:29:06:810 1148 bc4 DnldMgr *********** DnldMgr: Restoring download [no. 0] ***********
2016-06-22 03:29:06:810 1148 bc4 DnldMgr * BITS JobId =
2016-06-22 03:29:06:810 1148 bc4 DnldMgr * ServiceId = <9482f4b4-e343-43b6-b170-9a65bc822c77>
2016-06-22 03:29:06:810 1148 bc4 DnldMgr * UpdateId = .101
2016-06-22 03:29:06:935 1148 bc4 DnldMgr * Restored download job.
2016-06-22 03:29:06:935 1148 bc4 DnldMgr *********** DnldMgr: Restoring download [no. 1] ***********
.
2016-06-22 03:29:07:326 1148 bc4 DnldMgr *********** DnldMgr: Restoring download [no. 12] ***********
2016-06-22 03:29:07:326 1148 bc4 DnldMgr * BITS JobId = <6ccf2afd-0c79-489d-9ef1-135834cb7f3c>
2016-06-22 03:29:07:326 1148 bc4 DnldMgr * ServiceId = <9482f4b4-e343-43b6-b170-9a65bc822c77>
2016-06-22 03:29:07:342 1148 bc4 DnldMgr * UpdateId = <03b49cbc-210d-4451-ad36-85464a076c1b>.101
2016-06-22 03:29:07:373 1148 bc4 DnldMgr * Restored download job.

Видим начало инициализации Автоматического обновления и получения настроек

2016-06-22 03:29:07:389 1148 bc4 AU ########### AU: Initializing Automatic Updates ###########
2016-06-22 03:29:07:389 1148 bc4 AU # WSUS server: http://wsus.abcde.ru:8530
2016-06-22 03:29:07:389 1148 bc4 AU # Detection frequency: 1
2016-06-22 03:29:07:389 1148 bc4 AU # Approval type: Scheduled (Policy)
2016-06-22 03:29:07:389 1148 bc4 AU # Scheduled install day/time: Every day at 20:00
2016-06-22 03:29:07:389 1148 bc4 AU # Auto-install minor updates: Yes (Policy)
2016-06-22 03:29:07:405 1148 bc4 AU Setting AU scheduled install time to 2016-06-22 16:00:00

И инициализацию основных данных для рапорта

2016-06-22 03:29:07:405 1148 bc4 Report *********** Report: Initializing static reporting data ***********
2016-06-22 03:29:07:405 1148 bc4 Report * OS Version = 6.0.6000.0.0.65792
2016-06-22 03:29:07:405 1148 bc4 Report * OS Product Type = 0x00000006
2016-06-22 03:29:07:593 1148 bc4 Report * Computer Brand = R-StyleComputers
2016-06-22 03:29:07:593 1148 bc4 Report * Computer Model = Proxima_
2016-06-22 03:29:07:593 1148 bc4 Report * Bios Revision = ECG3510M.86A.0118.2010.0113.1426
2016-06-22 03:29:07:593 1148 bc4 Report * Bios Name = Default System BIOS
2016-06-22 03:29:07:593 1148 bc4 Report * Bios Release Date = 2010-01-13T00:00:00
2016-06-22 03:29:07:593 1148 bc4 Report * Locale/>
Дальше идёт блок трассировки поиска обновлений, где нас ожидают различные проблемы:

2016-06-22 03:29:07:593 1148 bc4 AU AU finished delayed initialization
2016-06-22 03:29:07:593 1148 bc4 AU #############
2016-06-22 03:29:07:593 1148 bc4 AU ## START ## AU: Search for updates
2016-06-22 03:29:07:593 1148 bc4 AU #########
2016-06-22 03:29:07:608 1148 c14 DnldMgr *********** DnldMgr: Downloading regulation Odf ***********
2016-06-22 03:29:07:608 1148 c14 DnldMgr * ServiceId = <9482f4b4-e343-43b6-b170-9a65bc822c77>
2016-06-22 03:29:07:608 1148 c14 DnldMgr * URL = http://www.update.microsoft.com/odf/v6odf.xml
2016-06-22 03:29:07:608 1148 bc4 AU 00, error = 0x80242017
2016-06-22 03:31:47:659 1148 c14 Handler FATAL: UH: 0x800f0823: CreatePackage failed in CCbs::CreatePackage
2016-06-22 03:31:47:659 1148 c14 Agent WARNING: Failed to evaluate Installable rule, updateId = <8d15e24b-503c-4da5-b317-8c7dd4b1ea50>.1 00, error = 0x80242017
2016-06-22 03:31:47:659 1148 c14 Handler FATAL: UH: 0x800f0823: CreatePackage failed in CCbs::CreatePackage
2016-06-22 03:33:11:547 1148 c14 Agent WARNING: Failed to evaluate Installed rule, updateId = .1 01, error = 0x800F0900
2016-06-22 03:33:11:547 1148 c14 Handler FATAL: UH: 0x800f0900: CreatePackage failed in CCbs::CreatePackage
2016-06-22 03:33:11:782 1148 c14 Agent WARNING: Failed to evaluate Installed rule, updateId = <407b6b44-298c-42be-83bd-9a473a74f17a>.1 01, error = 0x800F0900
2016-06-22 03:33:13:455 1148 c14 Handler FATAL: UH: 0x800f0900: CreatePackage failed in CCbs::CreatePackage
2016-06-22 03:33:13:455 1148 c14 Agent WARNING: Failed to evaluate Installed rule, updateId = <28152b93-6549-49d2-82be-f6f980c1f52a>.1 01, error = 0x800F0900
2016-06-22 03:33:13:471 1148 c14 Handler FATAL: UH: 0x800f0900: CreatePackage failed in CCbs::CreatePackage
2016-06-22 03:33:18:709 1148 c14 Agent * Found 0 updates and 79 categories in search
2016-06-22 03:33:18:709 1148 c14 Agent *********
2016-06-22 03:33:18:709 1148 c14 Agent ** END ** Agent: Finding updates [CallerId = AutomaticUpdates]

Ошибка 0x800f0823 соответствует 0xf0823 CBS_E_NEW_SERVICING_STACK_REQUIRED (Package needs a newer version of the servicing stack).
Ошибка 0x80242017 означает WU_E_UH_NEW_SERVICING_STACK_REQUIRED (The OS servicing stack must be updated before this update is downloaded or installed).
То есть требуется обновление Обслуживающего стека (OS servicing stack) KB955430.

Обслуживающий стек — это компонент, используемый для управления установкой и удалением обновлений программного обеспечения, языковых пакетов и дополнительных функций ОС Windows. Это обновление необходимо для успешной установки и удаления пакета обновления, оно также повышает производительность и обеспечивает правильную установку пакета обновления. Источник.

Ошибка 0x800f0900 соответствует 0xf0900 CBS_E_XML_PARSER_FAILURE unexpected internal XML parser error.
То есть возникает какая-то внутренняя ошибка при разборе XML файла. Вероятно, есть проблемы с MSXML Parser (не установлен, старая версия).

И дальше идёт концовка блока проверки обновлений:

2016-06-22 03:33:18:724 1148 c14 Report REPORT EVENT: <45a0c7aa-9b17-4cd8-93e7-f04f3a8898cd>2016-06-22 03:29:07:405+0400 1 202 102 <00000000-0000-0000-0000-000000000000>0 0 AutomaticUpdates Success Content Install Reboot completed.
2016-06-22 03:33:18:724 1148 e84 AU >>## RESUMED ## AU: Search for updates [CallId = ]
2016-06-22 03:33:18:724 1148 e84 AU # 0 updates detected
2016-06-22 03:33:18:724 1148 e84 AU #########
2016-06-22 03:33:18:724 1148 e84 AU ## END ## AU: Search for updates [CallId = ]
2016-06-22 03:33:18:724 1148 e84 AU #############
2016-06-22 03:33:18:724 1148 e84 AU Setting AU scheduled install time to 2016-06-22 16:00:00
2016-06-22 03:41:14:186 1148 420 Report Uploading 1 events using cached cookie, reporting URL = http://wsus.abcde.ru:8530/ReportingWebService/ReportingWebService.asmx
2016-06-22 03:41:16:436 1148 420 Report Reporter successfully uploaded 1 events.

Сообщающий о том, что обнаружено 0 обновлений и рапорт был выгружен на WSUS, хотя на самом WSUS никаких сведений о рапорте не получено.

Попробуем выполнить обновление в интерактивном режиме, то есть выполнить команду wuauclt /detectnow и посмотрим лог.

2016-06-22 03:44:00:782 1148 fd8 AU Triggering AU detection through DetectNow API
2016-06-22 03:44:00:782 1148 fd8 AU Triggering Online detection (interactive)
2016-06-22 03:44:00:782 1148 bc4 AU #############
2016-06-22 03:44:00:782 1148 bc4 AU ## START ## AU: Search for updates
2016-06-22 03:44:00:782 1148 bc4 AU #########
2016-06-22 03:44:00:782 1148 bc4 AU >## RESUMED ## AU: Search for updates [CallId = <9980c425-6bbf-404e-a82b-f64212c725ea>]
2016-06-22 02:48:05:115 1148 1e8 AU # 0 updates detected
2016-06-22 02:48:05:115 1148 1e8 AU #########
2016-06-22 02:48:05:115 1148 1e8 AU ## END ## AU: Search for updates [CallId = <9980c425-6bbf-404e-a82b-f64212c725ea>]
2016-06-22 02:48:05:115 1148 1e8 AU #############

Получаем ту же картину, что и в неинтерактивном режиме: ошибки 0x800f0823 и 0x800F0900.

2016-06-22 02:48:10:100 1148 6e0 Report REPORT EVENT: <2bc87e9d-d36b-441a-bcc7-6e575f313ff0>2016-06-22 02:48:05:099+0400 1 147 101 <00000000-0000-0000-0000-000000000000>0 0 AutomaticUpdates Success Software Synchronization Windows Update Client successfully detected 0 updates.
2016-06-22 02:48:10:100 1148 6e0 Report REPORT EVENT: 2016-06-22 02:48:05:099+0400 1 153 101 <00000000-0000-0000-0000-000000000000>0 0 AutomaticUpdates Success Pre-Deployment Check Reporting client status.

Видно, что агент посылает рапорт, но WSUS его либо не получает, либо не понимает. И ещё странно, что WSUS не понимает, что у меня на ПК установлена Windows Vista, а определяет её как Windows 6.0.

Вначале я погуглил.
Предлагалось выполнить wuauclt /resetauthorization /detectnow но это не помогло.
Предлагалось проверить настройки IIS, но всё было корректно.
Предлагалось кардинально переустановить WSUS, но я был не согласен в виду того, что другие ПК без проблем получают обновления.

Однако, автономного установщика у последней версии агента обновления Windows 7.6.7600.256 не существует. Можно скачать и установить агент обновления Windows версии 7.4.7600.226, а затем последняя версия установится самостоятельно через систему обновлений. Скачать WUA 7.4.7600.226.

После установки новой версии WUA мой WSUS начал правильно определять, что на ПК установлена Windows Vista Business и стал получать рапорты состояния в результате чего WSUS определил какие обновления необходимы для данного ПК.

В логе теперь пишется версия WU client version 7.4.7600.226:

2016-06-22 22:20:17:756 1156 580 Service ** START ** Service: Service startup
2016-06-22 22:20:17:756 1156 580 Service *********
2016-06-22 22:20:18:100 1156 580 Agent * WU client version 7.4.7600.226
2016-06-22 22:20:18:100 1156 580 Agent * Base directory: C:WindowsSoftwareDistribution
2016-06-22 22:20:18:100 1156 580 Agent * Access type: No proxy
2016-06-22 22:20:18:115 1156 580 Agent * Network state: Connected

Далее видим, что в новой версии изменился путь до файла сервера регулирования (Regulation server)

2016-06-22 22:21:20:387 1156 e18 DnldMgr Regulation server path: https://www.update.microsoft.com/v6/UpdateRegulationService/UpdateRegulation.asmx.
2016-06-22 22:21:21:059 1156 e18 DnldMgr * Regulation call complete. 0x00000000
2016-06-22 22:21:21:355 1156 e18 DnldMgr *********** DnldMgr: New download job [UpdateId = <297050cf-1305-4ec2-a00d-a173de49c416>.101] ***********
2016-06-22 22:21:21:371 1156 e18 DnldMgr * All files for update were already downloaded and are valid.
2016-06-22 22:21:21:449 1156 e18 DnldMgr *********** DnldMgr: New download job [UpdateId = .101] ***********
2016-06-22 22:21:21:465 1156 e18 DnldMgr * All files for update were already downloaded and are valid.
2016-06-22 22:21:21:933 1156 d44 DnldMgr BITS job completed successfully

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

2016-06-22 22:22:38:022 1156 d44 DnldMgr *********** DnldMgr: New download job [UpdateId = <5c4cef27-75eb-4a9a-a000-ee515fa4ff0b>.101] ***********
2016-06-22 22:22:40:364 1156 d44 DnldMgr * BITS job initialized, JobId = <68d84bf8-76f2-4211-8345-1830ecec3eee>
2016-06-22 22:22:40:442 1156 d44 DnldMgr * Downloading from http://au.download.windowsupdate.com/msdownload/update/software/crup/2009/01/windows6.0-kb958481-x86_bb04066c04a58d50e2634654ea79ac19e21d0bb5.psf to C:WindowsSoftwareDistributionDownload39587d8a1d7edb0e533dac1ad0b51969bb04066c04a58d50e2634654ea79ac19e21d0bb5-1 (17 subranges).
2016-06-22 22:22:40:520 1156 f24 DnldMgr BITS job completed successfully
2016-06-22 22:22:40:613 1156 f24 Misc Validating signature for C:WindowsSoftwareDistributionDownload88c2b87e4d67f91e2b681a8a841ad45a8b5036b48590c52e3edba8e297cd3017b7a3043c:
2016-06-22 22:22:40:645 1156 f24 Misc Microsoft signed: Yes
2016-06-22 22:22:40:645 1156 f24 DnldMgr Download job bytes total = 1424736, bytes transferred = 1424736

Но, несмотря на значительные подвижки, мы пока всё ещё видим ошибки 0x800f0823 и 0x800f0900:

2016-06-23 02:24:40:074 1156 854 PT +++++++++++ PT: Synchronizing server updates +++++++++++
2016-06-23 02:24:40:074 1156 854 PT + ServiceId = <3da21691-e39d-4da6-8a4b-b43877bcb1b7>, Server URL = http://wsus.abcde.ru:8530/ClientWebService/client.asmx
2016-06-23 02:25:35:155 1156 854 Handler FATAL: UH: 0x800f0900: CreatePackage failed in CCbs::CreatePackage
2016-06-23 02:25:35:155 1156 854 Agent WARNING: Failed to evaluate Installed rule, updateId = .101, hr = 800F0900
2016-06-23 02:25:35:155 1156 854 Handler FATAL: UH: 0x800f0900: CreatePackage failed in CCbs::CreatePackage
2016-06-23 02:25:35:296 1156 854 Handler FATAL: UH: 0x800f0900: CreatePackage failed in CCbs::CreatePackage
2016-06-23 02:25:35:296 1156 854 Agent WARNING: Failed to evaluate Installed rule, updateId = <407b6b44-298c-42be-83bd-9a473a74f17a>.101, hr = 800F0900
2016-06-23 02:25:35:296 1156 854 Handler FATAL: UH: 0x800f0900: CreatePackage failed in CCbs::CreatePackage
2016-06-23 02:25:36:217 1156 854 Handler FATAL: UH: 0x800f0900: CreatePackage failed in CCbs::CreatePackage
2016-06-23 02:25:36:217 1156 854 Agent WARNING: Failed to evaluate Installed rule, updateId = <28152b93-6549-49d2-82be-f6f980c1f52a>.101, hr = 800F0900
2016-06-23 02:25:36:217 1156 854 Handler FATAL: UH: 0x800f0900: CreatePackage failed in CCbs::CreatePackage
2016-06-23 02:26:11:860 1156 854 Handler FATAL: UH: 0x800f0823: CreatePackage failed in CCbs::CreatePackage
2016-06-23 02:26:11:860 1156 854 Agent WARNING: Failed to evaluate Installed rule, updateId = <8d15e24b-503c-4da5-b317-8c7dd4b1ea50>.100, hr = 80242017
2016-06-23 02:26:11:860 1156 854 Handler FATAL: UH: 0x800f0823: CreatePackage failed in CCbs::CreatePackage
2016-06-23 02:26:11:860 1156 854 Agent WARNING: Failed to evaluate Installable rule, updateId = <8d15e24b-503c-4da5-b317-8c7dd4b1ea50>.100, hr = 80242017
2016-06-23 02:26:11:860 1156 854 Handler FATAL: UH: 0x800f0823: CreatePackage failed in CCbs::CreatePackage
2016-06-23 02:26:17:844 1156 854 PT +++++++++++ PT: Synchronizing extended update info +++++++++++

Переходим к WSUS и проверяем какие обновления требует наша Windows Vista Business.
Обнаруживаем 151 обновление для Vista и одобряем их установку. Через некоторое время Windows Vista обнаруживает обновления и предлагает их установить.

Источник

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

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

lazy placeholder

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

lazy placeholder

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

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

lazy placeholder

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

lazy placeholder

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

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

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

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

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

Источник

Управление системными патчами 0x80242017 ошибка агента обновлений windows 80242017

Thanks for your feedback.

After deploying the software update, there might be seven steps to troubleshoot the common issues.

Step 1: We could check Policyagent.log. When policy is received, the following entry is logged in PolicyAgent.log:

We could check if Deployment Unique Id on the console is consistent with policy id displayed in PolicyAgent.log.

I notice that that the required column is zero? Why would that be?
We could check if the SSU is required by UpdatesStore.log.

Step 3: If the update is required, the content could be detected before downloading. We could refer to UpdatesDeploymentAgent.log.

Step 4: The content could be downloaded. we could refer to UpdatesHandler.log, CAS.log, and ContentTransferManager.log. Here is a screenshot about ContentTransferManager.log.

Step 5: After the download is completed, detection could be followed before installation. We could refer to UpdatesHandler.log,ScanAgent.log, UpdateStore.log, WindowsUpdate.log and WUAHandler.log.

Step 6: Software update could be installed. We could refer to Windowsupdate.log and UpdatesDeployment.log.

Step 7: After the updates are installed, Updates Deployment Agent checks whether any updates require a reboot, and then it notifies the user if client settings are configured to allow such notification. We could refer to UpdatesDeployment.log and UpdateStore.log.

Thanks for your time.

Best regards,
Amanda You

Please remember to mark the replies as answers if they help.

Источник

Как исправить ошибку 0x80246017 в Windows 10?

Ошибку 0x80246017 можно встретить во время попытки выполнить обновление операционной системы Windows 10. Совершенно недавно, Майкрософт выпустили обновление под номером KB4020102, и люди, которые пытаются содержать свои компьютеры в постоянно обновленном состоянии, попытались установить его вручную.

Однако, процесс установки обновления у некоторых из них заканчивался уже указанной ошибкой 0x80246017. Более тщательное исследование проблемы показало, что это обновление также не могло быть установлено автоматически для огромного количества пользователей.

Если обладатель ПК проверит историю в Центре обновления Windows, то он обнаружит, что обновление KB4020102 было загружено в систему, но, по каким-то причинам, оно не было установлено. Хотя, некоторыми пользователями было указано, что ошибка 0x80246017 может происходить не только с упомянутым обновлением, то также и со многими другими.

lazy placeholder

Итак, что же происходит во время появления этой ошибки? Сначала все идет нормально, обновление скачивается, устанавливается, но на определенном моменте процесс останавливается, а затем на экране появляется примерно следующее сообщение о возникших во время установки обновления проблемах.

Согласно Майкрософт, причина ошибки 0x80246017 относится в сборке 9926 для Windows 10, которая была выпущена еще в Январе 2015 года. Хоть и прошло огромное количество времени, но, так сказать, остатки записей в Реестре Windows могут вмешиваться в процесс установки теперешних обновлений.

Важная заметка: любое неаккуратное изменение записей Реестра Windows может привести к серьезным проблемам с работоспособностью операционной системы или даже к синим экранам смерти.

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

Итак, давайте теперь рассмотрим непосредственно способ, с помощью которого вы сможете попытаться избавиться от ошибки 0x80246017 при обновлении Windows 10.

Шаг №1 Удаление файлов установки предыдущей Windows

Шаг №2 Сброс нескольких разделов Реестра Windows

По загрузке Windows 10, снова попробуйте загрузить и установить обновление для ОС, с которым ранее возникала проблема в виде ошибки 0x80246017.

Источник

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

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

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

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

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

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

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

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

Squid

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

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

touch /etc/squid3/wu

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

update.microsoft.com
windowsupdate.microsoft.com
download.microsoft.com
ntservicepack.microsoft.com
c.microsoft.com
crl.microsoft.com
productactivation.one.microsoft.com

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

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

acl wu url_regex -i "/etc/squid/wu"

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

http_access allow wu

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

WPAD

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

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

if (dnsDomainIs(host, "update.microsoft.com")) {return "DIRECT";}
if (dnsDomainIs(host, "windowsupdate.microsoft.com")) {return "DIRECT";}
if (dnsDomainIs(host, "download.microsoft.com")) {return "DIRECT";}
if (dnsDomainIs(host, "ntservicepack.microsoft.com")) {return "DIRECT";}
if (dnsDomainIs(host, "c.microsoft.com")) {return "DIRECT";}
if (dnsDomainIs(host, "crl.microsoft.com")) {return "DIRECT";}
if (dnsDomainIs(host, "productactivation.one.microsoft.com")) {return "DIRECT";}

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

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

23.78.92.229
80.68.78.155
80.68.78.146
94.245.126.128
134.170.58.221
134.170.58.222
134.170.185.126
191.232.80.55
207.46.22.245

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

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

Home
> Microsoft, Windows Server, Windows Update, WSUS > WSUS Error – Windows Update Failed 80244017

August 13, 2014
mpayze Leave a comment
Go to comments

Problem

Using WSUS and clients getting an error on install – Windows Update Failed 80244017

Resolution

Even though Domain Users had Read/Write access I was able to fix this error by adding WSUSServerusers with read/execute privileges to the WsusContent folder and it’s subfolders.

Categories: Microsoft, Windows Server, Windows Update, WSUS

Comments (0)

Trackbacks (0)

Leave a comment

Trackback

  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Enter your comment here…

Fill in your details below or click an icon to log in:

Gravatar

Email (required) (Address never made public)

Name (required)

Website

WordPress.com Logo


You are commenting using your WordPress.com account.
( Log Out / 
Change )

Twitter picture


You are commenting using your Twitter account.
( Log Out / 
Change )

Facebook photo


You are commenting using your Facebook account.
( Log Out / 
Change )

Cancel

Connecting to %s

Notify me of new comments via email.

Notify me of new posts via email.

Changing VM NIC on VMware Virtual Machines from E1000 to VMXNET3
Regedit.exe – File System Error (-1073741819)

RSS feed

  • Google
  • Youdao
  • Xian Guo
  • Zhua Xia
  • My Yahoo!
  • newsgator
  • Bloglines
  • iNezha

New Stuff

  • Server Upgrade – NETLOGON – Service Issues
  • SSL VPN access to TFS Server – Critical Error – SharePoint Foundation – 8321
  • The operation failed because: The attempt at remote directory server to remove directory was unsuccessful. “Access is denied.”
  • Error when attempting to run a published app via RDS website
  • WSUS – Error during Cleanup wizard -SQL Timeout

Old Stuff

  • October 2017
  • March 2017
  • December 2016
  • November 2016
  • September 2016
  • May 2016
  • October 2014
  • August 2014
  • July 2014
  • June 2014
  • May 2014
  • January 2014
  • December 2013
  • November 2013
  • October 2013
  • August 2013
  • February 2013
  • October 2012
  • July 2012
  • December 2011
  • October 2010
  • September 2010

Categories

  • Active Directory
  • Antivirus & Malware
  • Apple
  • BootCamp
  • Certificates
  • Desktop Support
  • DNS
  • E-mail
  • Event Viewer
  • Exchange
  • Hardware
  • IIS
  • Mavericks
  • Microsoft
  • Networking
  • Office
  • pfSense
  • PowerShell
  • RDS
  • ReadyNAS
  • Server 2012
  • Server 2016
  • SharePoint
  • ShoreTel
  • SMB
  • SQL
  • ssh
  • SSL VPN
  • Symantec Backup Exec 15
  • Symantec Backup Exec 2012
  • Symantec Backup Exec 2014
  • TFS
  • Tor
  • Uncategorized
  • VirtualBox
  • VirtualCenter Server
  • Visual Studio
  • vmWare
  • vmWare vCenter Converter Standalone
  • VOIP
  • vSphere Web Client
  • WatchGuard
  • WDS
  • Windows 10
  • Windows 8
  • Windows 8.1
  • Windows Server
  • Windows Update
  • WSUS
  • XXCOPY

Понравилась статья? Поделить с друзьями:
  • 80244010 ошибка обновления windows 7 через wsus
  • 80072efe ошибка обновления windows vista как исправить
  • 80072efe ошибка обновления windows server 2012 r2
  • 8024400a ошибка обновления windows 7 как исправить
  • 80243004 ошибка обновления windows server 2008 r2