WSUS - Existing clients will not detect or download Feature Updates, but freshly installed clients do

Question

Hello,

I am a brand new admin at an old org that has many 1803, 1903, and 1909 PCs. The previous admins did not keep up with updates to the 300 desktops here. They only updated MS Office on these PCs. After abandoning their old WSUS server and their old Group Policy, I began using a new server (2016 with 14393) and a new policy. The new WSUS server provided cumulative updates to my 1909 desktop and also provided the 20H2 Feature Update to my desktop. However, no other existing Win10 PCs (1803, 1809, 1903, and 1909) will download the 20H2 feature update, or any other feature update that I have tried. They continue to download MS Office updates normally.

• I have confirmed that only the most recent Feature Update is downloaded and applied to my upgrade group in WSUS.
• I have created a new, stripped down basic group policy and placed my test machines in an OU that is blocked from inheriting any policy except this new WSUS policy
• GPUpdate /force, reboots, and GPResult show that only this new policy is applied to the test PCs.
• I have run the AJ Tek suggested cleanup script many times. The computers appear in WSUS where the updates show up as "Install" but also as "Not Applicable."
• I have manually run the Servicing Stack update for the appropriate version of Windows on each test PC (version verified with WinVer.exe).
• Existing PCs are able to communicate with WSUS, because I can telnet to 8530 on WSUS from test PCs, and the existing PCs download MS Office updates normally.
• I do get an "8024500C" error when I manually try to check for updates from the control panel, but I do not get that error when I use the PowerShell command to check for updates.

To make this more interesting, I have downloaded an 1803 ISO from Microsoft and used Rufus to create an installer. I then joined the test computers that I installed 1803 on to the domain and linked them to the new group policy. They immediately show up in the WSUS console, where I then add them to the upgrade group. These new installations show that they need 20H2 right away, and they download it alongside the most recent Defender definitions. By morning, the 20H2 update is installed and the computer is working fine. The newly upgraded PCs then reach out and download the 20H2 SSU and a .NET LCU from WSUS without a problem.

Any advice on getting my older, existing PCs to download and install the Feature Upgrades? I'm out of ideas. WSUS can be fussy, but I've never had this kind of trouble with it. I've attached a log from a PC that fails to download updates.

[56723-postable-logs.txt][3]

Answer 1

Hi PazPaz-2801,

Thanks for your posting on this forum.

According to the information you provided, the error 0X8024500C indicated that the clients could not connect to the 7971f918-a847-4430-9279-4a52d1efe18d service.
According to this link, the 7971f918-a847-4430-9279-4a52d1efe18d service is Microsoft Update.

Reference picture:

In order to help me research further, please help to follow the below step to check the default update source:
Open the PowerShell as an administrator on the clients and enter the below command:

$MUSM = New-Object -ComObject "Microsoft.Update.ServiceManager"  
  
$MUSM.Services | select Name, IsDefaultAUService  

Please consider sharing the result with me. Note that protect your personal information while provide the the result.

Regards,
Rita

---

If the response is helpful, please click "Accept Answer" and upvote it.
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.

Answer 2

First, I'm assuming you mean the client side script?
https://www.ajtek.ca/wsus/client-machines-not-reporting-to-wsus-properly/

If not, DELETE the computers from the WSUS MMC Console and run the above client side script on each affected computer. The issue sounds like a client side issue if a new build of 1809 can successfully download/upgrade through WSUS.

Also, make sure you're approving the CORRECT upgrades - I see you've approved the Business editions - Are you sure you've got the Business Edition installed? https://www.ajtek.ca/wsus/windows-10-upgrades-business-editions-vs-consumer-editions/

Finally, again, making sure you're approving the correct upgrades, use the Approvals Process in part 6 of my guide to scope the view to UNAPPROVED updates that are Failed or NEEDED.
https://www.ajtek.ca/wsus/how-to-setup-manage-and-maintain-wsus-part-6-selecting-your-test-systems-the-approvals-process/

Answer 3

Hi PazPaz-2801,

Thanks for your feedback.

It seems that this issue is related with dual scan. Only if you have enabled the the two policies on the clients, the dual scan will trigger:
Either of the “deferral” policies belonging to Windows Update for Business
Select when Preview Builds and Feature Updates are received
Select when Quality Updates are received

As you are probably aware, Windows 10 version 1607 introduced new Dual Scan behavior for enterprises that wanted Windows Update (WU) to be their primary update source while Windows Server Update Services (WSUS) provided all other content. In this scenario, the WU client automatically scans against both WSUS and WU, but it only accepts scan results for Windows content from WU.

We could enable the below policy to prevent dual scan:
Do not allow update deferral policies to cause scans against Windows Update

Reference picture:

Thanks for your time and have a nice day.

Regards,
Rita

---

If the response is helpful, please click "Accept Answer" and upvote it.
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.