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

Question

question

PazPaz-2801 asked Jan 14, '21 PazPaz-2801 commented Jan 19, '21

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

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]

windows-server-update-services

5 |1600 characters needed characters left characters exceeded

Attachments: Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

Answer 1 · 2021-01-15T06:38:15.987Z

RitaHu-MSFT answered Jan 15, '21 PazPaz-2801 commented Jan 19, '21

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.

3.png (2.8 KiB)

· 5

5 |1600 characters needed characters left characters exceeded

Attachments: Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

PazPaz-2801 · Jan 19, 2021 at 04:56 PM

This was the key detail that helped me solve this issue. As Adam and Rita noted, the test PCs had dual scan running on them. Even though the group policy they had applied to them when they were in production did not contain any policies that would have initiated Dual Scan, the PCs were dual scanning all the same. I suspect that the previous admin either set the registry keys manually in the base image, or set them through a script.

I ended up testing two approaches to fixing this. One way was deleting all the keys involved in dual scan using a script. The other way was setting the DisableDualScan registry key to 1. Of course, a new group policy that did not start a dual scan boondoggle was also necessary.

Thank you to Adam and Rita!

2 ·

PazPaz-2801 · Jan 15, 2021 at 06:18 PM

Hello RitaHu-MSFT,

The output is identical on each of my test machines. Please see the below. It seems like WSUS should be the default?

$MSUS.Services | select Name, IsDefaultAUService

Name IsDefaultAUService

Windows Server Update Service False
Windows Update True

0 ·

AJTek-Adam-J-Marshall PazPaz-2801 · Jan 15, 2021 at 06:24 PM

You have Dual Scan going on.

https://www.ajtek.ca/wsus/dual-scan-making-sense-of-why-so-many-admins-have-issues/

0 ·

PazPaz-2801 AJTek-Adam-J-Marshall · Jan 15, 2021 at 09:13 PM

I don't understand how Dual Scan was enabled... all WUfB policy settings are set to Not Configured in my test policy and in the old policy that was used before I started here.

Thanks for your suggestions, I will test more next week.

0 ·

Show more comments

Answer 2 · 2021-01-14T19:02:40.187Z

AJTek-Adam-J-Marshall answered Jan 14, '21 PazPaz-2801 commented Jan 15, '21

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/

· 1

5 |1600 characters needed characters left characters exceeded

Attachments: Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

PazPaz-2801 · Jan 15, 2021 at 06:01 PM

Hi Adam,

I fixed the link! Thank you for noticing that and for your suggestions. I was deleting the computers from WSUS and running the script you suggested. It results in the computer contacting WSUS again and me being able to reassign the PC to a group, but the updates do not download.

I went ahead and approved x64 and x86 versions of the Feature Updates, both Consumer and Business. My PC downloaded the business version, and since we use the MAK licenses, I thought we were all business versions. Who knows what happened in the past, so I will try Consumer too.

I declined any updates I didn't need, so unfortunately I can't use the Failed/Needed view. I did review my declined updates and made sure the most recent version of all cumulative updates and SSU updates were available.

1 ·

Answer 3 · 2021-01-18T06:20:12.29Z

RitaHu-MSFT answered Jan 18, '21 PazPaz-2801 commented Jan 19, '21

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.

3.png (23.7 KiB)

· 1

5 |1600 characters needed characters left characters exceeded

Attachments: Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

PazPaz-2801 · Jan 19, 2021 at 04:51 PM

This policy was set on the original WSUS policy that was in use, but it did not seem to make a difference on my PCs. I ended up having to remove the registry entries manually.

1 ·

question