Windows 10 Feature Update to 22H2 Failing through MECM

Question

Windows 10 Feature Update to 22H2 Failing through MECM

Austin 21

I am currently deploying a Feature Update using MECM to get our environment updated from Windows 10 20H2 to Windows 10 22H2. However, I am seeing intermittent failures where some clients are failing to download the update. The error message on the failed clients has thus far been the same "0X80244019 - Same as HTTP status 404 - the server cannot find the requested URI (Uniform Resource Identifier)."

Regular monthly client updates have been processing fine, and application deployments via MECM seem to run fine as well. I'm wondering if there's potentially an issue with our WSUS server that could be causing the problem. Below is a log of the failure off of one of the test clients I tried to apply the 22H2 Feature Update to that I obtained from the Get-WindowsUpdate command in Powershell.

Thanks!

276617-windowsupdate-22h2.txt

2 answers

Your answer

Answer 1

AllenLiu-MSFT 49,316 Microsoft External Staff

Hi, @Austin

Thank you for posting in Microsoft Q&A forum.

Does any Windows 10 20H2 upgrade to Windows 10 22H2 successfully?
Have we checked the UpdatesDeployment.log, UpdatesHandler.log, ContentTransferManager.log, WUAHandler.log, WindowsUpdate.log?

We can follow this guidance for troubleshooting:
https://learn.microsoft.com/en-us/troubleshoot/mem/configmgr/update-management/track-software-update-deployment-process?source=recommendations#deployment-evaluation-and-update-installation-on-clients

If the answer is the right solution, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".
Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Austin 21 Reputation points

2023-01-06T14:37:39.86+00:00

Thank you for the response, and yes I had looked through the WUAHandler and UpdateDeployment logs without spotting anything obvious. Unfortunately, the test clients that had succeeded in the 22H2 update were long enough ago that the WindowsUpdate log doesn't show the 22H2 update processing. Looking through UpdatesHandler.log it looks like this computer hit the same error that the current ones are with CAS failed to download update (20418c7a-9263-4abd-9e5c-5a6239f6164e). Error = 0x80244019. Releasing content request. UpdatesHandler 11/28/2022 1:20:02 PM 7496 (0x1D48) showing up. However, on its next try it looks like it succeeded without me having done anything.

I see the same thing in WUAHandler.log where it has Unexpected HRESULT for downloading complete: 0x80244019 WUAHandler 11/28/2022 1:20:02 PM 7496 (0x1D48) showing up a few times before it suddenly succeeded.

Looking back to one of the clients that failed the 22H2 update, they are showing the same errors, except they haven't re-tried and succeeded. It also isn't ideal to have the updates continually fail on the first few passes, which it seems was actually the case even for the ones that succeeded in the Feature Update. Let me know if you'd like me to post any other logs from either of the systems. I will look through the link you posted when I get a chance.

Thanks!
Austin 21 Reputation points

2023-01-09T18:42:19.073+00:00

I went through the list of steps in the software update process, and it appears that it is successfully checking the policy, triggering it, completing the scans in WUAHandler and UpdatesDeployment. It then gets to the UpdatesHandler to trigger the download step for the feature update where it then repeatedly fails to download.

Steps:
UpdatesDeployment evaluating the job:

UpdatesHandler receiving the scan (interestingly, it states no download info associated with the job):

WUAHandler then completes its scan:

UpdatesHandler then initiates its download, which fails:

This process of scanning for updates, finding the 22H2 feature update and identifing it is needed, and then failing to download then repeats a few times with the same resulting error in WUAHandler.log Unexpected HRESULT for downloading complete: 0x80244019 WUAHandler 1/5/2023 1:25:10 PM 2656 (0x0A60)

All the clients I'm testing on have Windows 10 20H2, and are correctly identifying as 'required' for the 22H2 feature update. Let me know if there's any other information on the issue that would be helpful.

Thanks!
AllenLiu-MSFT 49,316 Reputation points Microsoft External Staff

2023-01-10T08:06:31.987+00:00

Hi, @Austin

It sounds strange, we can check CAS.log, ContentTransferManager.log, LocationServices.log, and DataTransferService.log for more details about downloading process according to the link in my first reply.
Austin 21 Reputation points

2023-01-10T14:51:35.253+00:00

Going through and looking at the listed logs, it seems like the order is different from the link provided. The only entries I see within ContentTransferManager.log are timestamped as occurring before UpdatesDeployment evaluated the job.

Entries in ContentTransferManager.log:

The corresponding entries in CAS.log:

Entires in LocationServices.log:

Entries in DataTransferService.log:

Tracking the steps in the link you posted leads me to see that nothing ever gets created in the ContentTransferManager as the entries are blank for the day of the attempted update. Does that mean something is preventing the CTM job from being created and initiating the download?
AllenLiu-MSFT 49,316 Reputation points Microsoft External Staff

2023-01-11T07:44:27.7433333+00:00
Hi, @Austin

According to the log, it seems the CTM job is not created successfully, the logs do not help much.

By the way, make sure the feature update is distributed to the DP successfully.

And based on my research, the error code 0X80244019 is related to the windows update agent.

You may take a failure machine try the below steps to see if it works:

Note: BEFORE PROCEEDING, MAKE SURE TO BACKUP THE FOLLOWING KEY "HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate"

Click Start, then RUN, type regedit and hit ok

Browse to the following key:"HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate"

Delete the entire key.

Click start again, then run and this time type services.msc and hit ok.

Scroll down to the bottom and right click on "Windows Update" and hit restart.

Retry the feature update installation to see if it helps.

Answer 2

After some more troubleshooting, it ended up being some issue with the enablement package version of the 22H2 update. I'm not sure what was causing it to sometimes succeed and other times fail, however once I switched to using the Feature Update in MECM that doesn't use the enablement package it started working. It seemed that the failure was caused by the client attempting to reach out to Microsoft to download the updates since the enablement package Feature Updates don't download any of the update files to the DP, and instead tell the clients to reach out directly to Microsoft for the download.

I'm now having an issue where most clients on 20H2 aren't showing as requiring that update, however that'll be another Q&A if I can't figure it out.

Share via

Windows 10 Feature Update to 22H2 Failing through MECM

2 answers

Your answer