Jump to content


asgeirsig

After upgrading to SCCM 1610 some systems are unable to download Windows updates

Recommended Posts

After upgrading to SCCM 1610, systems which have automatically upgraded the configuration manager client to version 5.00.8458.1005 are unable to perform Windows Update. In Software Center they are stuck at "Downloading (0% complete)".

Systems with older versions of the client (e.g. version 5.00.8412.1307, and possibly older client) have no problem downloading and installing the updates.

 

Any idea what might be the problem?

Share this post


Link to post
Share on other sites


what do the WUAHandler.log, PatchDownloader.log and UpdatesHandler.log files reveal ?

Share this post


Link to post
Share on other sites

I am having this same issue, with UpdatesDeployment.log reporting error 0x87d00215 - "Item not found" for all updates

 

All of my clients are on version 5.00.8458.1005

 

Did you have a resolution for this in the end?

 

I am investigating further now...

Share this post


Link to post
Share on other sites

I cannot seem to make any headway with this, I have seen another post on Technet, with similar characteristics to this issue here https://social.technet.microsoft.com/Forums/en-US/e5a3a864-2d0c-40be-b7c7-d27b48bee17c/failed-to-get-sdm-ci-for-update-from-type-store-error-0x80070002?forum=ConfigMgrCompliance&prof=required which seem to inidicated that the SUP

and WSUS components should be removed and then re added again..

 

I have carried out a client scan while monitoring ScanAgent.log, UpdatesDeployment.log, UpdatesHandler.log and UpdatesStore.log in the same merged view within CMTrace, and the process seems to end producing multiple errors like the below

 

Failed to get SDM CI for update (Site_1AAA8919-CE7D-43A2-8BAF-D95647C0D2B9/SUM_e7e45f84-3523-4cd3-ab9e-685437758ebf) from type store, error = 0x80070002

Failed to GetSupersededUpdatesFromDigest for the update

Share this post


Link to post
Share on other sites

that error translates to

The system cannot find the file specified.

Source: Windows
-----
%1

Source: Winhttp
-----

so it sounds like it's looking for an update that isn't in your update package, have you checked this to verify ?

 

Share this post


Link to post
Share on other sites

Hi Niall,

 

I am just trying to work out how to match the SUM guid to the update itself.. any advice on this?

 

Did you see the recent comments on the Technet post I mentioned or do you think this is an unrelated issue?

 

Regards

 

Leon

Share this post


Link to post
Share on other sites

what updates are these Leon ? can you give me any examples ?

Share this post


Link to post
Share on other sites

Failed to get SDM CI for update (Site_1AAA8919-CE7D-43A2-8BAF-D95647C0D2B9/SUM_62a927af-8bc2-4ede-b504-d638e1e0c066) from type store, error = 0x80070002

Failed to get SDM CI for update (Site_1AAA8919-CE7D-43A2-8BAF-D95647C0D2B9/SUM_593ada2f-ccdd-4c31-abc2-045386837346) from type store, error = 0x80070002

 

My understanding is that the SUM_ guid can be matched to an actual update?

Share this post


Link to post
Share on other sites

if you look at the content information for a given update see does it match your guid's in the SUM_ part of what you posted

Share this post


Link to post
Share on other sites

Haven't had the chance to investigate, but this is somehow related to the sccm client as computers which still have client version 5.00.8412.1307 have no problem downloading and installing the updates. Only the newer clients like 5.00.8458.1005 and 5.00.8458.1007 just create the folders in c:\windows\ccmcache but do not download the updates.

Share this post


Link to post
Share on other sites

Not sure if it is significant but in the LocationServices.log I see these differences:

 

Update gets downloaded to computer:
Distribution Point='net:http://wsus.ds.download.windowsupdate.com/d/msdownload/update/software/secu/2016/12/windows6.1-kb3207752-x64_47a878b920c5094a0e73c053e8f602df1fbb8286.cab',Locality='REMOTE', DPType='WUMU', Version='0', Capabilities='<Capabilities/>', Signature='', ForestTrust='FALSE', LocationServices 20.12.2016 21:23:09 3868 (0x0F1C)
Update does not download to computer:
Distribution Point='net:http://wsus.ds.download.windowsupdate.com/c/msdownload/update/software/secu/2016/12/windows8.1-kb3205401-x64_321b77e058ef0377d84e6f0d25b360a05a363ad3.cab',Locality='WUMU', Version='0', Capabilities='<Capabilities/>', Signature='', ForestTrust='FALSE', LocationServices 20.12.2016 21:38:37 2180 (0x0884)

Share this post


Link to post
Share on other sites

Greetings! I have also been struggling with a similar issue, seemingly only on client operating systems. Our single primary site was at 1606, did the update to 1610 without issue, then enabled the site-wide client upgrade over 30 days. I realized that our clients were actually still on 1511, though. When I deployed December updates, I included them in a newly created 2016 Software Update Group, deleted all the previous SUGs, then created new ones for 2015 and for 2014 and Prior--all deployed in December.

 

What I noticed was that I had about 2500 machines out of ~10K that were in an error state when viewing the deployment through the Monitoring workspace. The error is

 

“Failed to install updates”, Error Code: 0x80040e37, Error Description: unknown error (-2147217865).

 

When I look at one of the affected clients, I also saw messages like those previously reported in the UpdatesDeployment.log

 

Failed to get SDM CI for update from type store, error = 0x80070002

Failed to GetSupersededUpdatesFromDigest for the update

 

UpdatesHandler.log,

 

Since then, I have deployed January updates to our pilot groups and found that the pilot servers were updated properly, but the clients just sit with updates in Software Center as "Past Due - Will Be Installed." This is a required deployment, ASAP/ASAP, with no maintenance window on the clients, and I even tried it outside of business hours although I thought it ignores that after the deadline anyway.

 

The weird thing is that I can install an update locally from Software Center. I have a case open with Microsoft, but haven't gotten anywhere yet.

Share this post


Link to post
Share on other sites

It seems that the problem in my case was the new feature "Delay enforcement of this deployment according to user preferences, up to the grace period defined in client settings" on the Scheduling tab of the Software Update Deployment that wasn't working as I had intended. The clients just stayed with the required software update as "Past Due - Will be installed." Hopefully that helps somebody else. Maybe a bug that will be fixed in a later update.

  • Like 1

Share this post


Link to post
Share on other sites

It seems that the problem in my case was the new feature "Delay enforcement of this deployment according to user preferences, up to the grace period defined in client settings" on the Scheduling tab of the Software Update Deployment that wasn't working as I had intended. The clients just stayed with the required software update as "Past Due - Will be installed." Hopefully that helps somebody else. Maybe a bug that will be fixed in a later update.

Thank you so much. This helped in my case and resolved the problem. It's sickening that there is no logfile telling about the problem. I wasted a couple of hours searching for the root cause. :D

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...