client won't install newest 20H2 even though it says it needs it

Question

I recently approved 20H2 in WSUS. I looked for the most recent to approve which was a December 3, 2020 release of En-US x64 Business Editions. Strangely, the newest version of the 20H2 update doesn't say anything supersedes it, but it also doesn't supersede anything even though I can see previous 20H2 versions in WSUS. The November 9, 2020 release says it supersedes a previous release and no update supersedes it. Not sure why the December 3 release didn't supersede it.

Most clients liked the December 3 version that I approved, but 1 client in my pilot group reported to WSUS saying it needed it, but would never find it and try to install it. As soon as I approved the November release the client happily started downloading it.

What's up with these 20H2 releases? Should I leave both versions approved? I have a Windows Update Log if anyone wants to see it, but it looks fine to me.

Answer 1

I don't have a WAM license so I followed your instructions step by step. For some reason the final sync did not find any new updates. It appears that the SCW did not remove them because I can see upgrades in WSUS console still. Should I have unapproved them before running SCW?

Answer 2

It's possible the upgrades classification has an issue on your install. If you have a license for WAM, you can run

.\Clean-WSUS.ps1 -DirtyDatabaseCheck

if you don't, uncheck the Upgrades category, sync with Microsoft, run the Server Cleanup Wizard (SCW), go back and check the upgrades category, and sync with Microsoft.

Approve the upgrade that is 'needed' by the clients (after a time period as now all the upgrades are new, you'll have to wait until some check in).

Answer 3

@Adam J. Marshall

Yes I believe the latest SSU was installed on the client. Since SSU's are classified as Security updates I have them set to approve automatically on my client group. The machine saw no updates available before installing 20H2 so I would assume it had the latest SSU. I'm trying to contact the end user so I can remote to their machine to confirm their update history. Was going to try getting this via remote PowerShell, but it's not working over the VPN and the user is working remotely from home.

ESD MimeType was setup correctly (by following your site instructions if I recall correctly). Prior to setting up the ESD MimeType the December release of 20H2 also would not be detected by the pilot clients. This is my first time using WSUS to deploy new Windows builds so I just didn't need it setup before now.

I'm currently on Server 2012 R2 for my WSUS server.

Answer 4

Did the client have the latest SSU installed? I could see that being a cause.

I'd verify you have the correct setup for the ESD MimeType
https://www.ajtek.ca/wsus/how-to-setup-manage-and-maintain-wsus-part-3-windows-as-a-service-waas-and-group-policy-administrative-templates/

if your WSUS server is on 2016+, I've seen the requirement to change it to the application/octet-stream even though it comes with the application/vnd.ms-cab-compressed.

Answer 5

@Adam J. Marshall as mentioned above, I did do that. The report said the client needed the December update that I had already approved, but when the client checked for updates it did not download/install it. That's why I tried approving the November update to see if it would grab that one. Strangely, it did. No clue why.