MECM Software Updates not working on task sequences or newly imaged PC

Question

MECM Software Updates not working on task sequences or newly imaged PC

Rouleau, Mark C 5

We recently restored our site server and WSUS to a newer server. Everything is working peachy-keen except for the Software Update step in our TS, which seems to hang. It used to work fine with our Win10 22H2 image. Nothing else has changed as far as I can tell. In addition, newly imaged PCs don't seem to be getting updates. Existing PCs seem to be getting

WUAHandler.log looks fine, confirmed that the imaged computer can connect to port 8530 on the site server. ScanAgent, UpdatesStore and UpdatesHandler as well.

I am seeing this error reoccurring in UpdatesDeployment.log:

Failed to attach update to the automation wrapper, error = 0x87d00215

Anyone run into this?

I should mention, other devices on the network are getting updates, site components are all green status.

The task sequence execution engine failed executing the action (Install Software Updates) in the group (Install Software) with the error code 2147943860

Action output: ... refer to logs: UpdatesDeployment.log, UpdatesHandler.log, UpdatesStore.log, wuahandler.log, WindowsUpdate.log

Waiting for RefreshUpdates complete notification from Updates Deployment Agent

FALSE, HRESULT=800705b4 (C:__w\1\s\src\client\OsDeployment\InstallSWUpdate\installswupdate.cpp,1522)

WaitForRefreshUpdatesComplete(spInstall), HRESULT=800705b4 (C:__w\1\s\src\client\OsDeployment\InstallSWUpdate\installswupdate.cpp,1677)

RefreshUpdates(bForceOnlineScan), HRESULT=800705b4 (C:__w\1\s\src\client\OsDeployment\InstallSWUpdate\installswupdate.cpp,1157)

InstallUpdates(pInstallUpdate, tType, sIdStr, sCallerStr, sJobID, sActiveRequestHandle), HRESULT=800705b4 (C:__w\1\s\src\client\OsDeployment\InstallSWUpdate\main.cpp,308)

Setting TSEnv variable SMSTSInstallUpdateJobGUID=

Process(pInstallUpdate, tType, sIdStr, sCallerStr, sPendingRebootUpdateIDs), HRESULT=800705b4 (C:__w\1\s\src\client\OsDeployment\InstallSWUpdate\main.cpp,409)

Time-out expired waiting for updates refresh complete notification.. The operating system reported error 2147943860: This operation returned because the timeout period expired.

6 answers

Your answer

Answer 1

1. 2207
Alas, we had completely forgotten about the SCUP on the old server. It hadn't been used in several years but we never uninstalled it.
No software updates are installed during the task sequence.
Required for Installation from cached mode.

I recently completely removed the SUP role from the server and am re-adding it, as well as redownloading and redistributing the updates. ~~I believe based on limited testing that this will fix our issues. Will mark as solved if it does~~.

Removing the SUP role and re-adding, then redownloading and redistributing fixed the issue.

Answer 2

Duchemin, Dominique 2,006

Hello,

For 0x87wd00215

https://learn.microsoft.com/en-us/archive/blogs/george_bethanis/cm12-sp1-clients-are-not-able-to-download-software-updates-error-setjobtimeoutoptions-failed-error-0x87d00215-updateshandler

For 800705b4

I have the same issue now and it seems to be related to the Network... still investigating ... firewall (Network & Local), access, ...

Thanks,

Dom

Rouleau, Mark C 5 Reputation points

2023-03-01T21:26:29.9133333+00:00

I looked at that link, but this is failing on every task sequence, so I don't think that's a viable solution.

Answer 3

CherryZhang-MSFT 6,491

Hi @Rouleau, Mark C,

1, Whether the newer server is using the same FQDN and IP as the older server?

2, Please help resync the update on SCCM console to see if it is successful? Please try to recreate the task sequence to test if it is successful?

3, Please help upload the full logs of the following logs for our reference:

Smsts.log, UpdatesDeployment.log, UpdatesHandler.log, UpdatesStore.log, wuahandler.log, WindowsUpdate.log

Looking forward to your reply.

Best regards,
Cherry

Rouleau, Mark C 5 Reputation points

2023-03-02T13:30:09.4033333+00:00
Same FQDN and IP address.

Updates are synchronizing normally. I did redeploy the distribution packages yesterday, but it didn't seem to help. I also redistributed the existing SUGs to, in this case, Unknown Computers.

I will upload the logs later today. Thank you for your help.
Rouleau, Mark C 5 Reputation points

2023-03-02T17:41:35.0433333+00:00

WindowsUpdate.log

I uploaded the other files in another post.

Answer 4

Rouleau, Mark C 5

I created a new VM with a stripped down version of our regular task sequence. See attached logs.

smsts.log

UpdatesDeployment.log

UpdatesDeployment-20230302-104905.log

UpdatesHandler.log

UpdatesHandler-20230302-104855.log

UpdatesStore.log

WUAHandler.log

The Windows Update log was too large to upload. I'll see if I can shrink it or copy/paste it into a new entry.

CherryZhang-MSFT 6,491 Reputation points

2023-03-03T09:22:39.94+00:00

Hi @Rouleau, Mark C,

Have you enabled https in your environment? Can you find the certificate “069BF1CE3F57F06C4B6EE661FDCC0465C877D304” or “5B33F099A7C7079D4C94F7EA0DFDF60B95A21258” in Machine\Root store or Machine\TrustedPublisher store on client?

I will be sharing for you if I have any update!

Thanks for your time.

Best regards,
Cherry
Rouleau, Mark C 5 Reputation points

2023-03-03T14:06:06.7733333+00:00

We use eHTTP throughout our environment. I have triple checked that for the MP, DP, SUP, and client communication settings on the site.

The 069* and 5b33 certs looks to be the WSUS self-signed certificate. Both are in Machine\Root and Machine\TrustedPublisher
Rouleau, Mark C 5 Reputation points

2023-03-03T17:53:53.34+00:00

I should add, I am trying to run a task sequence with the "Install Software Updates" step on a VM, and it appears to be stuck. I'm running a powershell script on that device, and it is unable to find those two certs.

Answer 5

Rouleau, Mark C 5

I might have solved it. It looks like an issue with the Network Access Account. After I deleted and re-added it, I was able to apply a test update to my task sequence. I will be able to confirm for sure next week.

CherryZhang-MSFT 6,491 Reputation points

2023-03-06T06:00:14.4633333+00:00

Hi @Rouleau, Mark C,

Thanks for your feedback, hope things are going well. I'm writing to see If there's anything else we can help please feel free to let us know, we will do our best to help you.

Thanks for your time.

Best regards,
Cherry
Rouleau, Mark C 5 Reputation points

2023-03-06T16:38:26.86+00:00

Alas, it still appears to be broken. I had created a small handful of updates and redownloaded them to their own distribution group and deployed to unknown computers, and that worked. However, when I applied the rest of my software updates to all unknown computers, I get the same timeout I was getting.

Those two certificates that you discovered were (I believe) old SCUP certificates, no longer in use. We use PatchMyPC instead.
CherryZhang-MSFT 6,491 Reputation points

2023-03-08T09:35:24.4766667+00:00

Hi @Rouleau, Mark C,

1, What is the SCCM version you are using?

2, Has SCUP been removed before you restored the site server and WSUS? Please help make sure that the SCUP has been completely removed.

3, For a test machine, all updates cannot be installed, or just some updates cannot be installed? I found the record “SwitchO365Management - O365 not installed on this machine yet. Skip.” in the logs.

4, Which software update install type you are selected in the task sequence? Required for installation or available for installation? The screenshot for your reference:

Looking forward to your feedback.

Best regards,
Cherry

Share via

MECM Software Updates not working on task sequences or newly imaged PC

6 answers

Your answer