Ошибка обновления windows 10 0x8024401b

Hi,

I am trying to install the software updates for my new image build during the build and capture task sequence. The error I’m having is 0x8024401B. Could this be due to the fact that my client is in a workgroup? How can I solve this issue?

The update mechanism in my SCCM 2012 environment is working, I tested it on other clients.

The error 0x8024401B means that there is a Proxy authentication error, which I don’t understand because there is only traffic on the intranet (but there is a proxy on the network). In the WindowsUpdate log you see that he tries to contact my Software update
point.

The error in the status messages looks like:

Action output: ThreadID = 3448;
};

Successfully submitted event to the Status Agent.
End TS policy evaluation
Policy evaluation initiated
GetIPriviledgedInstallInterface successful
Refreshing Updates
Successfully initiated RefreshUpdates operation
Waiting for RefreshUpdates complete notification from Updates Deployment Agent
Notification received, RefreshUpdates have been completed
Signaled RefreshComplete notification
Received RefreshUpdates complete notification from Updates Deployment Agent
RefreshUpdates operation has been completed, hr=0x8024401b
RefreshUpdates(), HRESULT=8024401b (e:nts_sccm_releasesmsclientosdeploymentinstallswupdateinstallswupdate.cpp,906)
InstallUpdates(pInstallUpdate, tType, sJobID, sActiveRequestHandle), HRESULT=8024401b (e:nts_sccm_releasesmsclientosdeploymentinstallswupdatemain.cpp,248)
Setting TSEnv variable SMSTSInstallUpdateJobGUID=
Process(pInstallUpdate, tType), HRESULT=8024401b (e:nts_sccm_releasesmsclientosdeploymentinstallswupdatemain.cpp,304).

The UpdatesHandler.log looks like:

CupdatesAgent:FinalConstruct entered
CupdatesAgent:FinalConstruct entered
Initiating updates scan for checking applicability.
Successfully initiated scan.
Updates scan completion received, result = 0x8024401B

 Can someone help me with this?

Thanks in advance!

Gr.

Hi,

I am trying to install the software updates for my new image build during the build and capture task sequence. The error I’m having is 0x8024401B. Could this be due to the fact that my client is in a workgroup? How can I solve this issue?

The update mechanism in my SCCM 2012 environment is working, I tested it on other clients.

The error 0x8024401B means that there is a Proxy authentication error, which I don’t understand because there is only traffic on the intranet (but there is a proxy on the network). In the WindowsUpdate log you see that he tries to contact my Software update
point.

The error in the status messages looks like:

Action output: ThreadID = 3448;
};

Successfully submitted event to the Status Agent.
End TS policy evaluation
Policy evaluation initiated
GetIPriviledgedInstallInterface successful
Refreshing Updates
Successfully initiated RefreshUpdates operation
Waiting for RefreshUpdates complete notification from Updates Deployment Agent
Notification received, RefreshUpdates have been completed
Signaled RefreshComplete notification
Received RefreshUpdates complete notification from Updates Deployment Agent
RefreshUpdates operation has been completed, hr=0x8024401b
RefreshUpdates(), HRESULT=8024401b (e:nts_sccm_releasesmsclientosdeploymentinstallswupdateinstallswupdate.cpp,906)
InstallUpdates(pInstallUpdate, tType, sJobID, sActiveRequestHandle), HRESULT=8024401b (e:nts_sccm_releasesmsclientosdeploymentinstallswupdatemain.cpp,248)
Setting TSEnv variable SMSTSInstallUpdateJobGUID=
Process(pInstallUpdate, tType), HRESULT=8024401b (e:nts_sccm_releasesmsclientosdeploymentinstallswupdatemain.cpp,304).

The UpdatesHandler.log looks like:

CupdatesAgent:FinalConstruct entered
CupdatesAgent:FinalConstruct entered
Initiating updates scan for checking applicability.
Successfully initiated scan.
Updates scan completion received, result = 0x8024401B

 Can someone help me with this?

Thanks in advance!

Gr.

При работе с прокси-сервером 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 часов практики и доступ навсегда.

специальное предложение

0x8024401B часто может появляться из-за неправильно настроенных параметров системы или из-за нарушений в реестре Windows. Эту ошибку относительно быстро и легко исправить, если использовать PC Repair, настроенную на решение всех распространенных проблем с реестром.

Эта страница доступна на других языках:
English |
Deutsch |
Español |
Italiano |
Français |
Indonesia |
Nederlands |
Nynorsk |
Português |
Українська |
Türkçe |
Malay |
Dansk |
Polski |
Română |
Suomi |
Svenska |
Tiếng việt |
Čeština |
العربية |
ไทย |
日本語 |
简体中文 |
한국어

This issue isn’t specifically related to Configuration Manager or Windows Updates, but it does seem that Windows Updates itself could behave better to prevent this.

When Windows Updates attempts to connect to the WSUS server (or SUP), you will see the WINDOWSUPDATE.LOG show the client attempting to open the client.asmx file from the WSUS server. The lines following show this connection failing with “SyncUpdates failure, error = 0x8024401B, soap client error = 10, soap error code = 0, HTTP status code = 407” followed by several more 0x8024401b errors.

These errors are an “HTTP Authentication required” failure. For some reason the client is unable to access the content.

In the instance I was dealing with, the problem isn’t the client connecting to the actual WSUS server. There was an automatic configuration for a proxy.pac file in Internet Explorer and Windows Update was (correctly) also using this to determine how to connect to the server. Unfortunately it was failing all the “DIRECT” rules which it should have matched against and being told to go to the proxy server. So the authentication request is actually coming from the proxy server.

The reason it was failing? The FQDN of the WSUSServer entry was in UPPER CASE and the proxy.pac file was only matching against lower case host names. This may seem crazy, but the proxy.pac matching is indeed case-sensitive.

e.g. A proxy.pac with a rule to match “.domain.com” will not match against a connection to “WSUS.DOMAIN.COM”. It would match “WSUS.domain.com” as it is only the domain part of the FQDN it is checking against.

Most (all?) web browsers will convert whatever URL you type into lower case automatically, so you probably don’t see this issue in normal browsing. It is only when you have “badly behaved” apps like automatic updates that don’t do this, combined with a proxy.pac that also doesn’t handle case insensitivity.

SOLUTION

There are several ways this can be corrected.

Fix the proxy.pac file (Preferred)

1. Fix the proxy.pac file so that it automatically converts host FQDN strings to lower case before checking them against the rules. This means the host “WSUS.DOMAIN.COM” would be converted to “wsus.domain.com” and then it would check against the rules. This is the best/easiest fix. Here’s a great site explaining everything you could want to know about how to do this: http://webdebug.net/2014/01/proxy-pac-file-tricks-and-tips/
2. Add an extra matching rule for the upper case condition. e.g. an entry in proxy.pac to match both “.domain.com” AND “.DOMAIN.COM”. While this will work, it is still fallible if someone was to have “.domain.COM” or “DOMAIN.com”. It’s also rather non-obvious to another person who comes along later and wonders why there are “duplicate” rules.

WSUS Only (without ConfigMgr)

• Check your GPO’s or other reg injection scripts and make sure the WSUS server FQDN is entered in lower case to match the proxy.pac

ConfigMgr 2007

• You can change the properties of the Site server “Intranet FQDN”. Just make sure to enter it all lower case. That value is the one used to populate the client machines with the name of the SUP server

ConfigMgr 2012

• You need to specify the name of the server as lower case when you first create the site server in the console. You can’t change it afterwards as there is no “Intranet FQDN” entry as there is in 2007. There are methods involving changing the site server name directly in the database, but this is not officially supported by Microsoft (as with most direct DB editing)
• If you are running a SUP as a separate server, then remove the role, delete the site server and re-create it with a lower case name. As clients check in and run the scan policy, they will update with the “new” name of the site server in lower case