Unified update platform (UUP) FAQ's

[Bala_Delli]

After a month of UUP update release, sharing best practices based on our field and feedback through multiple channels.

1. Will UUP patch work for CB 2111 and below?

Our pre-req is Configuration Manager Version 2203 and above as per our release documents. For Configuration Manager Version 2111 (Lesser than this are unsupported now) to patch UUP updates for windows 11 22H2 seamlessly, enable delta download setting using client settings in ConfigMgr.

When this option is set, delta download is used for all Windows update installation files, not just express installation files.

2. Please be sure to select the appropriate update classifications in your ADRs.

If you have ADRs configured to auto-approve Security Updates, be sure to specify the “Security Updates” classification in your ADR settings. 

If you would like to take advantage of all the great features of UUP and utilize UUP feature updates to upgrade endpoint clients to Windows 11 22H2, be sure to include the “Upgrades” classification in your ADRs. This will ensure that as endpoint clients go through the OS upgrade they will receive the latest security updates as part of the upgrade and will only need to reboot once.

If you do not want to utilize UUP feature updates to upgrade endpoint clients right now, you will want to exclude the “Upgrades” classification from your ADRs.

Note: The feature updates will be released every month but there will be sharing of content for the old files and the new content should be only a few hundred MBs between the month releases. See Question 9 for more details on deduplication.

3. ConfigMgr + Adaptiva integrated solutions

Adaptiva has released a patch for its customers to support the UUP. The public documentation can be found here: https://adaptiva.com/blog/using-unified-update-platform-with-adaptiva-onesite. Note that Adaptiva has asked customers not to enable delta download from the client settings and this is our recommendation from ConfigMgr 2203+ onwards only (which is our recommended version as well but as mentioned before for UUP to work with ConfigMgr 2111 there is a requirement to enable delta download from client settings.)

4. ConfigMgr console on Windows Server 2012 R2 cannot download the UUP Quality update fails to verify cert signature

PatchDownloader.log
Verifying file trust C:\Users\admin\AppData\Local\Temp\2\CAB291B.tmp.wim Software Updates Patch Downloader 
Authentication of file C:\Users\admin\AppData\Local\Temp\2\CAB291B.tmp.wim failed, error 0x800b0004 Software Updates Patch Downloader 
Attempting to delete 0 byte tmp files from previous downloads Software Updates Patch Downloader 
ERROR: DownloadUpdateContent() failed with hr=0x80073633 Software Updates Patch Downloader

Workaround: Patch the Windows Server 2012 R2 with 2023 4B (April CU) which then fixes this issue.

5. ConfigMgr Patchdownloader component may fail to verify (*.psf files) if the UUP patches were synched before ConfigMgr 2111 version.

The issue will persist even if ConfigMgr version is upgraded to ConfigMgr 2111+ if the updates were synched before ConfigMgr was on a lesser version than version 2111.

 Sample error in PatchDownloader.log

Verifying file trust C:\WINDOWS\TEMP\CAB6062.tmp.psf               Software Updates Patch Downloader      

Authentication of file C:\WINDOWS\TEMP\CAB6062.tmp.psf failed, error 0x800b0004              Software Updates Patch Downloader  

Attempting to delete 0 byte tmp files from previous downloads             Software Updates Patch Downloader           

ERROR: DownloadUpdateContent() failed with hr=0x80073633      Software Updates Patch Downloader      

The below SQL query will help you identify the issue.

-- Sample check for 2023-04 Cumulative Update for Windows 11 Version 22H2 for x64-based Systems (KB5025239).
-- Replace the unique update id below if you are searching for a different UUP update

IF EXISTS( select  all SMS_CIContentFiles.CI_UniqueID,SMS_CIContentFiles.Content_ID,SMS_CIContentFiles.FileName,SMS_CIContentFiles.FileSize,
SMS_CIContentFiles.IsSigned,SMS_CIContentFiles.SecuredTypeID,SMS_CIContentFiles.SourceURL from vSMS_CIContentFiles AS SMS_CIContentFiles
WHERE SMS_CIContentFiles.CI_UniqueID='3157dbaf-04f5-49fc-baef-300bbd6d121a' AND FileName like '%.psf' and isSigned= 1 )

PRINT 'UUP Updates likely synched before upgrading to 2111. This will need correction, Please call Microsoft support to correct this.'

ELSE

PRINT 'You are not likely affected by the UUP PSF update signing issue'

If you get the output of the above query as 

'UUP Updates likely synched before upgrading to 2111. This will need correction, please call Microsoft support to correct this.' then likely you are affected and open a support case with Microsoft to correct the issue.

6. UUP updates installed as a part of OSD TS in "Install Software Updates" step (Fixed 2309 or later)

There is a known issue that is currently investigated. The issue is the Delta Download component of CCMEXEC not starting on time and the updates timeout on the first scan, later scans are not impacted.

Workaround: Add a restart step in between two install software updates steps. This will allow UUP updates to be successfully downloaded and installed in the second attempt.

Resolution: Upgrade to CB 2309 and upgrade the client. This issue is addressed.

7. Does offline servicing work with UUP updates?

No. Offline servicing images with UUP QU updates from the ConfigMgr console is not supported.

8.  Are Delivery Optimization (DO) and Delta Download (DD) components different ? What is ConfigMgr dependency on DO?

Delivery Optimization is a Windows technology to deliver content in a smart way reducing internet bandwidth owned by the Windows team and Delta Download is a component which is an http listener for requests owned by the ConfigMgr team.

Delivery Optimization is a peer-to-peer distribution technology available in Windows 11 and Windows 10 that allows devices to share content, such as updates, that the devices have downloaded from Microsoft over the internet. DO is a part of the Windows OS. Delta Download is a http listener and is a component of ConfigMgr.

ConfigMgr requires the DO client as it invokes the Delta download listener to download the content (as we configure the alternate content location URL in WUA policy to point to Delta Download Listener URL). The Invocation flow is WUA (Windows Update Agent) -> DO (Delivery Optimization) -> DD (Delta Download). Hence even if we don't enable DO, ConfigMgr would automatically enable DO by setting these two policies.

This is visible in the UpdateDOGPO.log

SetDOGPOSettings: Set Windows DO group policy to DOGroupId =  DeliveryMode = group

Customers should not create any GPO settings to disable these policies OR edit the registry to disable the DOSVC service or from services console.

9.  Update Supersedence changing to 6 months default for new installs. How does update supersedence affect UUP scenarios?

• Refer the blog for the announcement details for this change. 
• The default for expiring updates which are superseded will only change for the new installations and the existing ones will not be altered from whatever the current setting is.

10. Does ConfigMgr have deduplication of files at source and distribution points?

Deduplication at the source in ConfigMgr : When PatchDownloader component downloads a file it checks if the file exists in the same share and creates a hard link for the already existing file instead of re-downloading it.

Scenario 1
If the files/folders for previous UUP update source package are on the same volume but different share name, customers don't go into creating hard link path at all.

Scenario 2(a)
If the Package path has a common share \\machine\share but different folders inside it (which is the normal case) like  \\machine\share\jan and \\machine\share\feb we go to the hard link and create the hard link for the file with the Patchdownloader.log entry Content already downloaded. Created link for ContentID

Scenario 2(b)
Same scenario as 2(a) but the PatchDownloader here finds the same file present in a different share first apart from being present on the same share. Here the PatchDownloader doesn't go deep and check if the file is also present on the same share and fails to create the hard link. But here it doesn't download from internet again but copies the file from the other share to this share. Log entries fail to create hard link with error 17 (which is it thinks these are different drives). Could not create hard link: \\MachineNetbios\UpdatesPackage\2302_Win11_21H2_UUP\b1e9d019-7dec-4eee-b7e4-9e8eae99d89b.1\19222DDC6156FBE5570C3A6DDF69759662F93AEE_FeatureOnDemand.wim -> \\ MachineNetbios\22-11-UUPWin11\bcb528ff-85c2-4372-8b91-20bd0c7fa1e4\19222DDC6156FBE5570C3A6DDF69759662F93AEE_FeatureOnDemand.wim. LastErr=17

Summary

It is recommended to have a single share for all the UUP monthly packages \\machine\UUP and then creating folders inside it for each months. for eg.. \\machine\share\jan and \\machine\share\feb . In this case ConfigMgr will create hard links instead of downloading the actual files again.

Note
If you actually check the properties of the folder it will still show the size of the actual file and not hard link. Use DU.exe from sysinternals suite to find the actual size of a folder.

E:\UpdatesPackage\2302_Win11_21H2_UUP>E:\DU\du.exe .

DU v1.62 - Directory disk usage reporter
Copyright (C) 2005-2018 Mark Russinovich
Sysinternals - www.sysinternals.com 

Files: 14
Directories: 2
Size: 9,675,198,236 bytes
Size on disk: 9,675,227,136 bytes

Note

To find all the hard link references to a file use the fsutil command.
fsutil harlink list <full_file_path>

11. Why does ConfigMgr UUP On-Prem download a 3-5GB wim when I want to install a very small FOD/LP package?

This is an issue with the size attribute on the file as we don't download the full file for FOD/LP but only the needed byte ranges. Since we download the needed byte ranges only, the size that gets displayed for the file is the cumulative size of the file till that range. Meaning if the small FOD package is around 3035627519 of the byte range in the file, we will display the size of the file as around 2.82 GB. While in actuality we only downloaded the file ranges between 3034578944-3035627519 for the 1 MB FOD package. To confirm the actual size of the file on disk you can check the properties of the file and verify the "Size on disk".

12. Deduplication at the distribution points in ConfigMgr : Distribution Points in ConfigMgr are already designed to have a SIS (Single instance storage) in the form of Content Library. So we store any file only once no matter how many packages it is present in. More on ConfigMgr Content Library design here .

For more details ref the actual windows blog and Configuration blog.

Thank you, 

The Configuration Manager team 

[BryanDam]

@Bala_Delli: Thanks for the detailed write up here.  Have a couple follow up questions for clarification.

>Update Supersedence changing to 6 months default for new installs

The announcement explains the change itself but doesn't explain why that is the recommendation. I have guesses of course but they're just that. Why is 6 months better than 3 months? Is 0 months (immediately supersede) a terrible idea and if so why?

I can't quite make sense out of your Scenario 2(b) as it sounds a lot like Scenario 1 where the files exist on the same volume but different share name. Can you clarify the scenario where ConfigMgr is going to outright copy the file locally?

>It is recommended to have a single share for all the UUP monthly packages \\machine\UUP and then creating folders inside it for each months. for eg.. \\machine\share\jan and \\machine\share\feb
This recommendation just doesn't make a lot of sense to me as a long-time ConfigMgr admin. ConfigMgr software update content is controlled by Deployment Packages. Most organizations are not creating new Deployment Packages every month and they certainly should not be forced to do so to get the benefits of UUP. If UUP benefits from having all the content on the same share that's fine, but if it needs a specific folder structure then ConfigMgr itself should see to that folder structure, not the administrator on a monthly basis.

[sutliff1805]

Thanks for the write-up however there is a conflict in the first paragraph.  "enable delta download setting using client settings in ConfigMgr."  The help link associated to this setting says that enabling this will prevent clients from downloading 3rd party updates from the CMG.  That's a big problem.. we patch a huge list of 3rd party products.

I am also completely confused by the share for monthly packages.  I'm sure for Package Source, most admins have a single share (smart ones have a DFS share name that points to a physical share on the network storage system so when the storage system is replaced/renamed we don't care)... and we have a SUP folder and then a source package..  I can't imagine anyone creating a new share every month..

[PanuSaukko]

Thank you for the great blog article. I have some additional questions.

About Delivery Optimization: 

What could be the reason if ConfigMgr 2303 client doesn't have UpdateDOGPO.log? And the corresponding local group policy settings (Download Mode/Group ID) are missing.
Do you need to enable Use ConfigMgr Boundary Group for DO ID client setting? 
Is UpdateDOGPO.log introduced in ConfigMgr 2303?
Does ConfigMgr client set  HKLM:\software\policies\microsoft\windows\windowsupdate: UpdateServiceUrlAlternate = http://localhost:8005? It seems that if UpdateServiceUrlAlternate is not set, the client cannot download updates. 

[Robin Clive-Matthews]

Bit rubbish that you've just dropped support for offline servicing - this saves a lot of time during OSD.

Are you planning on fixing that at some point in the (hopefully near) future?

[CristopherAlaya]

@Robin Clive-Matthews 

Might I suggest looking into some of the community tools that handle offline servicing of OS Media.  The two most popular ones I'm aware of are OSDBuilder and WIMWitch.  

If you're not comfortable with community tools, Microsoft also offers updated patched media every month via MSDN and the Volume Licensing download portal.  

Admittedly, this is not the easiest transition if using thick images but if you have thin images, it's much better and more reliable than in-console servicing.  

[Sainath_Katekar]

Do we have step by step guide to enable UUP update on MECM.

[Dominik_Ecke]

Since Microsoft introduced UUP in March, we are unable to successfully install any Windows 11 22H2 clients with SCCM / MECM OSD.

Reason: as soon as the Software Updates step is running and installing a cumulative update, the TS never recovers after the reboot. It simply breaks. The smsts.log simply stops just before the reboot - the log even stays in "C:\_SMSTaskSequence" folder and is not moved to "C:\Windows\CCM\Logs" folder anymore. It does not contain any errors! It simply stops (no more entries after the unexpected reboot occurred).

Additional info:

• SCCM CB 2207 in use (Hotfix packs installed)
• Software Update step uses the "retry on unexpected reboot" checkbox
• we also set the SMSTSWaitForSecondReboot TS variable to 600 (tried without and with)
• the issues do NOT occur when installing Windows 10 (same TS, only difference is the applied OS)

Anyone else having that issue or maybe even a solution?

[JayCF]

@Dominik_Ecke We have the EXACT same issue (only difference is we are on 2203.) 

I have a ticket open with MS right now and all they can say is the issue is related to the CU forcing a double restart (I don't really see it when watching but it does fit) and that the issue is supposedly with the CU itself and NOT SCCM. MS developers are supposedly looking into it right now but no ETA given for a fix.

MS support keeps reminding me in each call that Patching in OSD TS is "supported but not recommended" There workarounds are thus far:

1) Take the patching out of the OSD and let it patch after.

2) Update the WIM file from the MS website monthly so that it included the CU and thus not require during that patching task.

We have grugently set out TS task to patch Win10 only for now and let it patch after the TS completes because updating the TS with an updated WIM file leaves gaps during testing and we have 27 DP (some on slow links) that we'd have to distribute to… 

If any new working info comes from my ticket, I'll post it in the comments...

[pro2type]

We have several clients with 0% downloading issue in Software Center with Windows 11 and UUP patches. 

Stuck on downloading 0% and after reboot it says failed with 0x80d02002. Some computers are successfully installing the monthly patches. 

Any tips?

[Bala_Delli]

Check whether the DO is waiting for content or the clients are with latest Version, If possible upgrade to latest 2303 and client version to check.

[RossMcleod1982]

@JayCF @Dominik_Ecke i was initially having the issue of the download being stuck. Went to the effort of going to 2303 with the hotfix that resolves this. Now I get the issue with the double reboot. Very frustrating. If you eventually get anywhere with MS it would be good to know.

Thanks 

[NaAlexey]

Hello!

We met issue that described in point 5. SQL query show on problem.

In patchdownloader.log there are errors on invalid signature of .psf files of Windows 11 updates that starts from 2023-03.

Is there any manual of what to do with such problem? Maybe we need to do something with DB, clear something in tables?

[NaAlexey]

I found how to resolve issue in point 5.

If you cant sync particular update, for example 2023-04 how in article, you need to find all .psf files that are in this update.

Make SQL query like this

SELECT *
  FROM vSMS_CIContentFiles
  WHERE CI_UniqueID = '3157dbaf-04f5-49fc-baef-300bbd6d121a' AND FileName like '%.psf' and IsSigned=1

You will get all .psf files from this update that needs to be corrected in DB. Something like this:

You need File_ID's.

Next make new query with your File_ID's:

SELECT *
  FROM CI_Files
  where  FileName like '%.psf' and File_ID in (72057594038044265,72057594038044148,72057594038044262)

 And see if that files have IsSigned=1.

Than make update

update CI_Files
  set issigned=0
  where FileName like '%.psf' and File_ID in (72057594038044148,72057594038044262,72057594038044265) and IsSigned=1 

That's it! Problem for this update resolved.

Try to download it again.

[KarolJ]

I have upgraded ConfigMgr to 2303 recently, I was not having the 0% download issue with patching, but I've just started facing this issue with a feature update to Win11 22H2 - only on selected devices, the experience is that content doesn't pre-cache and if a user clicks install, the installation times out and after 3-5 retries it just gets downloaded and installed ... @RossMcleod1982 can you please share your experience, how did 2303 fix your problem and what were the symptoms in your environment?

@Bala_Delli I'm already on 2303, but how can I check "whether the DO is waiting"? Which log should I check, DeltaDownload.log? Could you please confirm if the "Allow clients to download delta content then the option is available" client setting should be mandatory to set to "Yes"?

[Bala_Delli]

@KarolJ yes, deltadownload.log should help you.

DeltaDownload.log

Records information about the download of express updates and updates downloaded using Delivery Optimization.

[KarolJ]

@Bala_Delli thanks, this is the log I've been reviewing, in this log I could see "Unable to read existing WUA Group Policy object. Error = 0x80070002." on the affected clients, other logs connected to update installation process showed that there is a timeout.

• Can you please comment on the "Allow clients to download delta content then the option is available" client setting, if it should be mandatory to set to "Yes"?
  • If yes, should this be set to "Yes" for all operating systems in the environment or are there any exceptions? I'm asking as there is a thread on the same issue on Servers here, where the solution is to set this client setting to "No" - which is confusing for me, especially when only a part of the devices that I manage (Windows 10 21H2) has the problem.

[Bala_Delli]

If the server is 2303 and client is 2303 then this setting is automatically taken care of, no need to set to No.  Not sure if GPO is conflicting as we are setting using Local group policy. it is not able to read WSUS server setting. Can you reach support, troubleshooting in chat is really tough until we check all logs.

[KarolJ]

Hi @Bala_Delli thanks for your reply!
I've been doing more investigation on the devices that i can see the deltadownload.log and I can see that clients affected by the issue do not have "UpdateServiceUrlAlternate" set in registry in "HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate", the not affected devices have this registry created and set to "http://localhost:8005".
Can you tell me how exactly this registry item is being created? Is it based on some particular MECM client setting? Or should it just be created out of the box if the client version is at least on the 2303 level?

P.S.

After reviewing several client logs, I could see that this error "Unable to read existing WUA Group Policy object. Error = 0x80070002." just comes and goes, the earliest entries I could find were from February 2023 ..., so it's not a GPO conflict and I'm wondering what else could affect it.

[Bala_Delli]

Client will change this through client settings, we have done few fixes in 2211 and 2303 client versions for DO and UUP. You did not confirm whether the client is upgraded to 2303 or not but as per i can see it is 2303 server version? Please upgrade client and check this out.

[KarolJ]

@Bala_Delli can you share more details, on how does the client populate the "UpdateServiceUrlAlternate" registry entry? What I'm asking is, is there a specific setting in the console, that needs to be set in a particular way, or it just does it to "http://localhost:8005", no matter what you set?

Sorry, I wasn't clear, MECM was upgraded to 2303 and the clients were also upgraded, so the client version is 5.00.9106.1022. Today I've compared results from my daily laptop (not affected by the issue) with a colleagues laptops (has the 0x80070002 error in DeltaDownload.log), both are running Windows 11 22H2, both have MECM client version 5.00.9106.1022 and both clients in MECM report as healthy, the RSOP were almost identical, except for this one setting "Windows Components/Windows Update/Manage updates offered from Windows Server Update Service/Specify intranet Microsoft update service location/Set the alternate download server:" is populated on my device with "http://localhost:8005" and it's not populated on his devices. I have removed the registry entry on my device and after a policy update the setting came back (as expected) and on his device a policy update had no influence on this setting. We have re-installed his MECM client from the console and it cured the problem, then we also removed the registry entry on his device and re-applied the policy to make sure it comes back and it did. For the moment this looks to be a bug as he has the same MECM client version as he had before re-installing the client.

[KarolJ]

Happy New Year! 

I've been reviewing logs on affected devices and I could see that intermittently WUAhandler.log has sometimes this entry “Group policy settings were overwritten by a higher authority (Domain Controller) to: Server  and Policy NOT CONFIGURED”.

I don't have GPOs in the environment configuring "Specify intranet Microsoft update service location", this is configured by the MECM client via Local Policy - checked and confirmed by a gpresult report. Could it be that the referenced GPO is a GPO that configures DeliveryOptimization "Download Mode" to "HTTP only (0)"? Actually should this GPO be configured or should it be also handled by the MECM client? @Bala_Delli can you please share your opinion on this?

[VikrantVerma19]

Hello @Bala_Delli i have the similar issue like @KarolJ in my environment and would like to understand if you have any inputs on this query. 

Moreover, I am not able to find the backend Work flow of Windows UUP like how the patches get downloaded  what services they use now, How the Staging and content downloads work and most important thing what is the role of "UpdateServiceUrlAlternate" reg in this and how it impact the content downloads. 

It is getting a bit difficult to nail the issue without above information. 

let me know if you have any MS documentation on this as I am unable to find one. 

[Daincha]

@Dominik_Ecke and @JayCF 

Hi there - wonder if any update on your issue described above? We're suffering same issue, unable to finish win11 23h2 build because install software update step would break the TS by reboots. 

Same issue with our Win10->11 In-place upgrade Task sequence, once we start to install updates it breaks the task sequence and upgrade failed. 

Thank you in advance! 

[Bala_Delli]

@Daincha - we have fixed the reboot issue in 2309, please check and update us.

[Daincha]

@Bala_Delli  - I am already on MECM 2309, however issue persists. Machine will get multiple rebooted by Install Software Update step, and no matter you selected retry after unexpected reboot or what, Win11 OSD build fails. I am uncertain if it's specific to February cumulative updates or it will continue to . From smsts.log, I can see after reboot triggered by install update, it simply dropped the task sequence and quit itself, it's a disaster as it will happen randomly like 50% changes of duplication. 

MECM2309 + ADK 11 22H2/WinPE patched with February Cumulative updates.  

[Bala_Delli]

@Daincha - I guess you are using ADK 10.1.25398.1 then we have not added to support. If the older version 10.1.22621.1 then it must be a new issue. can you raise a support ticket?

[Robin Clive-Matthews]

@Daincha have you installed Update rollup for Microsoft Configuration Manager version 2309 - Configuration Manager | Microsoft L... KB25858444?

Issues fixed include:

"Due to a timing issue, a double reboot can still prevent a Task Sequence from running, even when the SMSTSWaitForSecondReboot variable is set. This problem can happen during an operating system deployment, combined with an update that requires two reboots."

I've yet to verify if this works, but if you've not installed the update and set the variable then that's definitely worth doing 🙂

[Daincha]

@Robin Clive-Matthews  Many thanks Robin, I have the feeling this is it! I don't know why nobody else complains about this issue,  but I hope this KB would solve it for me. Finger crossed!  

@Bala_Delli  We installed correct ADK/ winpe version 10.1.22621.1, we had an advisory ticket opened with microsoft and it's the confirmed version compatible with SCCM 2309.  What Robin suggests above seems could save me from it. I will give it a try. 

[sutliff1805]

We managed to get March 2024 UUP working!
After all the other w11 and ConfigMgr problems were fixed we still were not patching successfully the majority of the time with the UUP update.
I found we had a GPO that set the WSUS server.  All the other fields were blank but I noticed one of them was the UpdateServiceUrlAlternate.
Since it did not have a value I never gave it much thought but I realized it's one of several things that is set and controlled by that policy... 
We changed that policy to not enabled and now ConfigMgr is able to control DO and it works!  Just in time for the 1 yr anniversary of UUP in the enterprise.

[KarolJ]

@sutliff1805 can you please write more details on your findings?

• Did you have the WSUS server set via "Group Policy" or "Group Policy Preferences"?
• Was the GPO targeted to all clients, if so were they all affected or just some?
• Where exactly did you see the "UpdateServiceUrlAlternate" set as blank, in the GPO?
• What have you set in the client settings on "Allow clients to download delta content"? Yes or No?

I'm also fighting a similar issue, it occurs only on some devices, where the GPOs that I have in the environment are targeted to all client devices, but I have not seen a GPO that would set WSUS nor the UpdateServiceUrlAlternate.
As for your comment that you saw "UpdateServiceUrlAlternate" set to blank, I can see in the WUAHandler.log on the affected devices, that there is no entry for "UpdateServiceUrlAlternate" and at that moment the registry entry for "UpdateServiceUrlAlternate" is no present.

[sutliff1805]

@KarolJ Hello,
- Yes, it was set several years ago in a domain group policy to force all domain joined clients to connect to WSUS where the ConfigMgr client was published as a mandatory update (wsus deployment of ConfigMgr client).  We changed this to 'Not Configured'.  The 'Set the alternate download server' was blank and I forgot that it's a setting on this template that is enabled so therefore a blank field is still a setting.

- Yes, all clients, but only w11 22h2 and 23h2 clients obtain the monthly cumulative updates via UUP and thus only they were having problems.  After setting to 'not configured' I could GPUpdate a pc, restart it, and almost immediately it would begin downloading the updates from the on-site DP.

- The "UpdateServiceUrlAlternate" is the registry value that is set by the GPO.. \HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate

I persistently monitored this value as ConfigMgr is supposed to set it and I kept wondering why it was not set -- although ocassionally I would find it set.  Many computers were managing to patch after several days so my theory is that ConfigMgr would set it and begin working then break when GPO reset it to a blank every 15 minutes..

- Regarding Client Settings
-- Client Cache Settings: "BranchCache" is NO, "peer cache" is NO

-- Delivery Optimization:
"Use Microsoft Connected Cache server": NO. 
"Use CM Boundary Groups for DO Group ID": this can be YES (and on each Boundary Group it's set to not allow peer downloads (e.g. "Allow peer downloads in this boundary group" is not enabled). thus forcing everyone to use their local DP - and it is YES in my lab but in production it is set to NO.
-- Software Updates: "Allow clients to download delta content when the option is available": No.  

In my 8-month long case with Microsoft I learned that with w11 UUP, after I think the Sep or Oct cumulative update and on ConfigMgr build 2309 the updates should start working.  
WUA (Windows Update Agent) invokes Windows DO (Delivery Optimization) to locate the content and DO uses delta download.  Delta download then creates jobs, seen in CMBitsjob.log.  Delta Download then creates the Content Transfer Manager request.  CTM then requests the location (DP or branchcache or peercache) and creates the Data Transfer Service (DTS) job.  DTS then downloads the content.  

[KarolJ]

Hi @sutliff1805,

thanks a lot for a detailed description of your issue!

I just checked again all GPOs, but none have the setting you mention configured. I also monitor the registry on a bunch of devices to see when and by which process the "UpdateServiceUrlAlternate" registry entry is being altered, in majority of cases it's being removed by svchost.exe and in a scenario that we don't observe update installation issues, it's being re-created by the same process up to 3 seconds later. So I see this as some conflict, the interesting thing is, this doesn't happen at every policy processing cycle ..., it can be untouched for a few days, then it's removed and re-created.

Another scenario, is that the registry entry is being removed by svchost.exe and gone for up to 1,5h and re-created by "C:\Windows\System32\wbem\WmiPrvSE.exe" - in the time, where the entry is missing, clients cannot download content.

Using Policy Analyzer, I have reviewed the "C:\Windows\System32\GroupPolicy\Machine\Registry.pol" file, while the issue was present and "UpdateServiceUrlAlternate" was missing there ..., so I see it as missing in Local Policy. Forcing a machine policy retrieval cycle on the client, doesn't fix the problem, only a client re-installation restores the setting in "C:\Windows\System32\GroupPolicy\Machine\Registry.pol"

So if "C:\Windows\System32\GroupPolicy\Machine\Registry.pol" is altered by svchost.exe, should I turn my attention to the MECM client/client settings? Is it possible to have a MECM client settings conflict? They have priorities ...

[sutliff1805]

@KarolJ Hello,
svchost.exe is just the operating system process that runs services like WMI, print spooler, firewall, antivirus, etc., etc., etc.   You can simply delete the file C:\Windows\System32\GroupPolicy\Machine\Registry.pol then run gpupdate /force and it will recreate the file.  Sounds like you're on the right track.  As for MECM I believe it does re-apply the client configuration settings the same way (local machine policy).  MECM should be configuring DO and if it cannot or if something is interrupting that then we have our download for eternity issue.  It has become complicated with the new Windows technologies being inserted into our old familiar process.  Good luck.  

[NBclientmanager]

Hi

As far as I have tried to analyze update settings from MCM client vs GPO, I have seen that not the Policy refresh does update the registry values but the update cycles do.

[KarolJ]

Hey @sutliff1805,

sorry, it was a mental shortcut in my comment with the svchost.exe - that it's the local policy, as you write there can be a lot of things behind it. I did enable GPO debug logging, so I can see that when the registry change happens, there is noise in the GPO debug log and I can see the registry entries being removed and UpdateServiceUrlAlternate is not always re-created, hence I'm stating it's policy that is causing the issue.

I have a few VMs, where I monitor the registry and 2 of them have the same GPOs applied as all client devices in the environment and they have the issue occasionally, annother VM is in the Computers container in AD - it gets only 2 GPOs and the local policy - this one had no registry changes for 3 weeks and then the registry entries were removed and recreated. I've disabled local policy processing on this VM this week and I'm going to observe if the issue happens again, but it's going to take time ...

I have one GPO that configures "DOdownloadMode", maybe that could be connected - on the other hand the one VM in the Computers container doesn't have that GPO applied and it's registry entries were re-created. So it doesn't have a content download issue (0% downloading), but as far as I understand it, there had to be a conflict as the registry entries were removed and re-created.

I also have an observation on my daily laptop, the registry entries were untouched for 11 days, before being re-created (without UpdateServiceUrlAlternate), it looks like the further from last patching session, the issue is observed less often. 

[KarolJ]

Hi @Bala_Delli,

after a long fight with this issue user t3chdi from Reddit seems to have found a workaround for the problem and described it in his blog , I have not tested it yet, but it looks promissing!

Can you please share if Microsoft is aware of this issue and is there any plan to release a fix for MECM/Windows in the nearest future?