This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(243.2, 8%, 33%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EKB%3C/text%3E%3C/svg%3E)
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.
This morning I unchecked Upgrades in options again and waited more than 2 hours. I ran SCW and it removed nothing. I just tried running it again 2 hours after that and it still sees nothing to remove.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(297.6, 24%, 38%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ERH%3C/text%3E%3C/svg%3E)
@Klish, Brian
It seems that the time zone are different between your environment and mine. Please refer to the below picture:
In my opinion, the feature updates for windows 10 20H2 are as the same as your environment.
In addition, the issue is more related with Windows Update. As we all know, WSUS is responsible to deploy updates not for the update itself. In order to get the better support, please try to post this issue on the windows team. Here is the related link for your reference:
https://learn.microsoft.com/en-us/answers/topics/windows-10-general.html
Thanks for your understanding and cooperation.
By unchecking the upgrades category in options, and syncing with MS, it should auto-expire all of these and running the SCW should be enough to clean out the physical data files, before re-checking and re-approving and re-downloading.
WSUS is finicky. Perhaps you did it too fast. Uncheck it again, wait an hour, perform a sync, and repeat the process.
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?
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).
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.