Machine not getting updates from SUP - Error 0x8024400D

[DPE1983]

Hi guys,

 

Running SCCM 2012 R2 SP2 CU1 on a Server 2008 R2. WSUS installed locally.

 

After applying Novembers updates to my clients, i'm seeing clients fail when requesting updates from my SUP.

The Windowsupdate.log states:

 

2015-12-08 08:21:09:680 740 890 PT + ServiceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}, Server URL = http://xyz.de:8530/ClientWebService/client.asmx

2015-12-08 08:21:09:696 740 890 PT WARNING: Cached cookie has expired or new PID is available

2015-12-08 08:21:09:696 740 890 PT Initializing simple targeting cookie, clientId = 7df18679-3e0f-4745-9c8b-2435c23fcec1, target group = , DNS name = xyz

2015-12-08 08:21:09:696 740 890 PT Server URL = http://xyz.de:8530/SimpleAuthWebService/SimpleAuth.asmx

2015-12-08 08:21:11:209 740 890 PT WARNING: SyncUpdates failure, error = 0x8024400D, soap client error = 7, soap error code = 300, HTTP status code = 200

2015-12-08 08:21:11:209 740 890 PT WARNING: SOAP Fault: 0x00012c

2015-12-08 08:21:11:209 740 890 PT WARNING: faultstring:Fault occurred

2015-12-08 08:21:11:209 740 890 PT WARNING: ErrorCode:InvalidParameters(7)

2015-12-08 08:21:11:209 740 890 PT WARNING: Message:parameters.OtherCachedUpdateIDs

2015-12-08 08:21:11:209 740 890 PT WARNING: Method:"http://www.microsoft.com/SoftwareDistribution/Server/ClientWebService/SyncUpdates"

2015-12-08 08:21:11:209 740 890 PT WARNING: ID:f0938c9c-e2e3-48a2-9d5b-8007a2e9080e

2015-12-08 08:21:11:209 740 890 PT WARNING: PTError: 0x8024400d

2015-12-08 08:21:11:209 740 890 PT WARNING: SyncUpdates_WithRecovery failed.: 0x8024400d

2015-12-08 08:21:11:209 740 890 PT WARNING: Sync of Updates: 0x8024400d

2015-12-08 08:21:11:209 740 890 PT WARNING: SyncServerUpdatesInternal failed: 0x8024400d

2015-12-08 08:21:11:209 740 890 Agent * WARNING: Failed to synchronize, error = 0x8024400D

2015-12-08 08:21:11:209 740 890 Agent * WARNING: Exit code = 0x8024400D

As you can see, the error that is reported is 0x8024400D. Looking up this error in CMTrace it translates to:

SOAP client found the message was malformed; fix before resending.

Source: Windows Update Agent

I'm seeing posts here and there about this issue, however it does not seem to be a general one. Is anyone here experiencing the same issues with fully patched Win7 machines?

So far, the machines having these issues have WU Agent versions 7.6.7601.19016 and 7.6.7601.19046.

Attached is the WindowsUpdate.log from one of the affected clients. Naturally, i've tried re-installing the WUAgent but to no avil, and as some of my machines recieve updates with no issue i am not considering this a issue with my SUP/SCCM. Also, the WSUS component of SCCM is all healthy and happy, and the WSUS database is clean of obsolete and unneeded updates.

Hoping for some help here..

Thanks guys.

WindowsUpdate.log

[DaveWibble]

Hi

 

Did you manage to fix this problem?

 

I am having the same issue with several of my machines, with the same SOAP fault, InvalidParameters(7) and 0x8024400d errors in both WSUS and SCCM logs. I've now seen this on both Windows 7 machines and Server 2008 R2 SP1 boxes. The machines I am looking at have picked up and installed some patches with no problems, but then others are now stuck, displayed in SCCM as failed. Its not the same updates on all machines, and I've checked other machines which use identical images and they have no problems. I've even tried completely rebuilding a couple of the machines with the problem, and the same thing has happened again on them, with the same updates as they failed on previously!

 

Already tried updating WSUS agent to latest, renaming the Windows\SoftwareDistribution folder, cleaning WSUS database - all no effect.

 

Anyone with any additional suggestions or help would be very much appreciated! Happy to add any additional info or logs if useful.

 

Thanks

Dave

[ryan.davisson]

I'm having the exact same issues on the same timeline in our organization. We have a large number of clients that appear to be patching just fine, but a subset that simply started to fail the scanagent with error 0x8024400d during the first week of December. We've also tried reinstalling the WUAgent, repairing WMI and uninstalling/reinstalling the SCCM client, but nothing is working for those clients. Any luck figuring out your issue?

[Iroqouiz]

Did you guys ever find a solution to this?

[HBacon]

I have the same problem with all my Windows 7 clients. Has anyone found the solution for this problem?

 

Regards,

 

Hans

[FBF]

Just in case my solution helps anybody suffering from this issue (0x80072ee2 error code). And without reinstalling WSUS.

In my case I have 3 SUPs. Updates Deployments are usually going well for almost all the machines. However yesterday I had to deploy urgently a KB from 5 months ago to some machines that supposedly already should have been installed.

Since most of the computers were able to deploy updates I thought of a specific problem on those PC's. I checked the SCCM client logs but nothing. Then I checked the C:\windows\windowsupdate.log (they are W7). There I found the infamous 0x80072ee2 error code. Nothing useful on the Internet. Tried to verify if there was a connection issue. Nope, the client can reach the WSUS/SUP TCP ports. Then I started realising that always the same SUP server was referenced where the error appeared.

I logged into that server and restarted the "WSUS Server" service and tried running the updates scan again. Nothing seemed to happened, but then I read carefully the error description: SendRequestUsingProxy failed for <http://sup01.domain.com/Content/7A/BDB34A0FD82AA65E1E173D46371ACB9BAD142FDB.txt>. error 0x80072ee2. That URL didn't work from any computer, but switching to another SUP server it worked (http://sup02.domain.com/Content/7A/BDB34A0FD82AA65E1E173D46371ACB9BAD142FDB.txt). Went back to the "SUP01" server, opened IIS Manager, browsed to "SUP01\Sites\WSUS Administration" and clicked on the "Content" dir. Well, I must admit that I previously had a bad time with that folder because of our multiple SUP servers configuration so it was familiar.

And there it was: At some moment the address of the network folder where WSUS Content dir was located was changed by SysAdmin requirements, and somehow that address was updated on every SUP (IIS) server but the SUP01. Once I set the proper path (via the Basic Settings button) I clicked on "Test Settings" to verify everything is correct. A new window with two green checks should be listed. Now you can clic on the virtual "Content" dir and all the folder content will be listed. There's one thing more to do: You need to restart the "WsusPool" Application Pool (it may take some time). Maybe you should want to restart the "WSUS Server" service. After that you should be able to browse the http://sup01.domain.com/Content/7A/BDB34A0FD82AA65E1E173D46371ACB9BAD142FDB.txt URL from anywhere, and of course, run a updates scan action.

To sum it up:

• Find the failing SUP server from windowsupdate.log
• Try to browse the URL windowsupdate.log reported the 0x80072ee2 error code for.
• Login to that SUP server and open IIS Manager (not IIS 6 Manager, please).
• Browse to "SUP01\Sites\WSUS Administration" and click on "Content". If the content of this folder is not expanded, then there's a problem with IIS accessing to this folder, which translates to SUP not working.
• With the focus on the "Content" folder click on the  "Basic Settings" in the "Actions" pane.
• Make sure the specified "Physical path" exists and it's the one you specified when you set up WSUS.
• Click on "Test Settings". If both check actions don't return a green check, please make sure the server IIS account or the alternative user account you may have specified in "Connect as" button has the proper rights specified by the WSUS documentation.
• Once the "Test Settings" button returns two green checks, save the changes and try to browse the virtual "Content" dir from the IIS Manager.
• If the browsing succeeded, go to "Application Pools" and restart (I did Stop/Start) the "WsusPool".
• Finally, maybe you would like to restart the "WSUS Server" service on the SUP server.

This post is provided AS-IS with no warranties or guarantees and confers no rights. Use these information at your own risk.