Auto Deployment Rule download failed 0X87D20417

[dverbern]

Hello,

 

We have several Auto Deployment Rules (ADRs) for managing server and workstation updates.

Over the last few days, several of our ADRs have started reporting an error "Auto Deployment Rule download failed" with code "0X87D20417".

 

When I check the "ruleengine.log" on our SCCM02P site server, it reports these lines:

 

Downloading content with ID 16803330 in the package SMS_RULE_ENGINE

Failed to download the update from internet. Error = 12002 SMS_RULE_ENGINE

Failed to download ContentID 16803330 for UpdateID 16812681. Error code = 12002

This is repeated for several more updates.

The code "12002" seems to refer to timeout trying to access the Internet.

We have a proxy server in place that this servers sits behind, but we also have a service account in AD to authenticate through the proxy, so that shouldn't be an issue.

Can anyone advise any other avenues of investigation we can use?

Thanks very much.

 

[Ocelaris]

What does your wsyncmgr.log say? Are you failing to do synchronizations completely? there are a few more WSUS logs to check out like WSUSCTL.log (connection to WSUS Server) and WCM.log. Open up the wsus console (not the SCCM console) and see if your synchronizations are failing or just your ADR rules... look at the site that it's trying to connect to and test running IE as the service account using PSEXEC. If it's the computer account do psexec -i -s -d cmd which will give you a command prompt as the computer account in which you can launch IE and test the proxy connection.

[dverbern]

Thanks Ocelaris, I'll try your suggestions.

 

I've just now created a new ADR and new package and almost all updates are downloaded successfully, just a few are failing, like before.

Its almost like the downloads at Microsoft end are corrupt or something ...

[Ocelaris]

I had a few sync/downloads fail because of a license (EULA) file not found... basically the synchcronizations were working but then the clients were failing because Microsoft never had the license.txt file. The solution was to grab it from another WSUS serve which previously had it; or to do a full wsusutil /reset which retries to download everything. I bet if you look in the clients that are failing they'll tell you exactly which file is missing. i.e. "trying to reach http://server/1/a/393930403-3039303-39303039/EULA.txt but cannot find it" etc... and then you go to your directory on your WSUS and see if it indeed is there (it's not). but the WSUSUtil.exe tools under c:\program files\update services\ is what I believe Microsoft and I used to reset the record of what had been downloaded or not to our WSUS server.

[dverbern]

Hi Ocelaris, I don't think our downloads are failing because of EULA issues - we have selected to automatically accept any EULAs.

 

I've just re-ran a recreated ADR and sure enough, most content that makes up the update downloads without problems, just a few seem to bomb out.

 

Example:

Failed to download ContentID 16803363 for UpdateID 16812720. Error code = 12002 SMS_RULE_ENGINE 2/04/2014 9:20:32 AM 6292 (0x1894)

It would be very useful if I could look up the ContentID somewhere and find out what update/file SCCM is trying to pull down, because at least that way I could check its size and search for traces of it somewhere on our site server.

Once again, if anyone has encountered this issue, advice appreciated!

[dverbern]

Update - if I view the PatchDownloader.log, I can see specific updates being downloaded and then bombing out after 90%, per attached image.

 

[Ocelaris]

Found this little blurb:

 

http://social.technet.microsoft.com/Forums/en-US/5a9596d3-6f0b-4907-a788-efc06601a88a/there-was-an-error-downloading-the-software-update-12002?forum=configmanagersecurity

 

from the post: 12002 = "timeout" and it seems like it revolves around proxy. Can you either bypass the proxy temporarily or open it up to your Computer account temporarily? Maybe check the IE Proxy settings on the SCCM Server?

[dverbern]

Thanks Ocelaris, I'll double-check our proxy settings now.

[Ocelaris]

Another way you can test your proxy settings "as the computer" account is to open a command prompt (as admin), and run "psexec -i -s -d cmd" which will open a new command prompt "as the computer" then launch Internet explorer from wherever it resides in c:\program files\etc... and try to open that web page from microsoft that it's having trouble with. i.e. http://wsus.ds.download.microsoft.com----.exe and see if you can open the file. that will rule out any proxy issues (I'm assuming that this wsus download process is running as the computer account).

[dverbern]

Ocelaris, another excellent suggestion, sorry about the delay responding. I appreciate your effort. I DO suspect my issue is proxy-related, so I'll try your steps now.