PENDING Missing Classifications and Products

[JermB]

NEW CM server
OS: Server 2025 (26100.32860)
SQL: SQL 2022
ADK: Latest
Server name: CM

The "Upgrades" checkbox is missing from the Classifications tab, and all modern iterations of Window 10 or later are missing from the Products Tab. SUP role was removed, re-add... no change. Uninstalled SUP role, then WSUS role entirely. Cleaned up what the Role removal missed (Delete WSUSPool from Application Pools in IIS, and "WSUS Administration" from Sites, deleted my "WSUSContent" folder (H:\WSUS), confirmed that SUSDB is gone (in SSMS) then rebooted.

Attempted fix:
Step 1 - Install WSUS Role via PowerShell (no WID, only SQL, with Management Tools)
Install-WindowsFeature -Name UpdateServices-Services, UpdateServices-DB -IncludeManagementTools

Step 2 - Run Post-Install Task via PowerShell
WsusUtil.exe PostInstall SQL_INSTANCE_NAME="CM" CONTENT_DIR="H:\WSUS"

(At this point, a new SUSDB can be seen in SSMS)

Step 3 - Add SUP role in CM, wait and confirm successful install (watch the SUPSetup.log)

Step 4 - Check NOTHING (the suggested method for a new CM server) in Classifications and/or Products tab in SUP, we just want the metadata!

Step 5 - Open PowerShell via menu in CM console, then run: Sync-CMSoftwareUpdate -FullSync $True (same as running software sync in the console)

Step 6 - 15 mins, wsusmgr.log shows "sync completed" (noted the expected warnings "does not contain classifications/categories, sync will do nothing")

Step 7 - Back in the CM console > SUP settings, check only Critical Updates and Security Updates (still not checking any Products, only shows Windows XP, etc)

Step 8 - Sync again, nothing changes/updates... dead in the water.. no modern products, nor "Upgrades" option under Classifications!!

We have an older CM server that is in production:
Server 2016
SQL 2017
Win10 ADK... runs perfectly! Obtains Classifications/Products without a single hiccup so I do not think this is related to firewall access settings/blocks.

Please help! I will gladly provide logs, etc.. upon request

 

[pabecot]

NEW CM server
OS: Server 2025 (26100.32860)
SQL: SQL 2022
ADK: Latest
Server name: CM

The "Upgrades" checkbox is missing from the Classifications tab, and all modern iterations of Window 10 or later are missing from the Products Tab. SUP role was removed, re-add... no change. Uninstalled SUP role, then WSUS role entirely. Cleaned up what the Role removal missed (Delete WSUSPool from Application Pools in IIS, and "WSUS Administration" from Sites, deleted my "WSUSContent" folder (H:\WSUS), confirmed that SUSDB is gone (in SSMS) then rebooted.

Attempted fix:
Step 1 - Install WSUS Role via PowerShell (no WID, only SQL, with Management Tools)
Install-WindowsFeature -Name UpdateServices-Services, UpdateServices-DB -IncludeManagementTools

Step 2 - Run Post-Install Task via PowerShell
WsusUtil.exe PostInstall SQL_INSTANCE_NAME="CM" CONTENT_DIR="H:\WSUS"

(At this point, a new SUSDB can be seen in SSMS)

Step 3 - Add SUP role in CM, wait and confirm successful install (watch the SUPSetup.log)

Step 4 - Check NOTHING (the suggested method for a new CM server) in Classifications and/or Products tab in SUP, we just want the metadata!

Step 5 - Open PowerShell via menu in CM console, then run: Sync-CMSoftwareUpdate -FullSync $True (same as running software sync in the console)

Step 6 - 15 mins, wsusmgr.log shows "sync completed" (noted the expected warnings "does not contain classifications/categories, sync will do nothing")

Step 7 - Back in the CM console > SUP settings, check only Critical Updates and Security Updates (still not checking any Products, only shows Windows XP, etc)

Step 8 - Sync again, nothing changes/updates... dead in the water.. no modern products, nor "Upgrades" option under Classifications!!

We have an older CM server that is in production:
Server 2016
SQL 2017
Win10 ADK... runs perfectly! Obtains Classifications/Products without a single hiccup so I do not think this is related to firewall access settings/blocks.

Please help! I will gladly provide logs, etc.. upon request

Hello,
I have the same environment and the same problems...
NEW CM server
OS: Server 2025 (26100.32860)
SQL: SQL 2022
ADK: Latest
Server name: CM

In addition to the information...
Following synchronization:
Warning in MECM log file (wsyncmgr.log)
WARNING: Request filter does not contain any known categories. Sync will do nothing. SMS_WSUS_SYNC_MANAGER 06/17/2026 10:52:55 13772 (0x35CC)

Warning in the WUS log file (SofwareDistribution.log)
2026-06-18 14:30:53.835 UTC Warning WsusService.58 DBConnection.ExecuteCommandNoResult SqlException occurred.
Number 50000 and message invalid update identity in XML for update 9EC61B38-6EFE-4C8F-9C99-02FBC0C1EA3E\100

Please help!

 

[JermB]

Hello,
I have the same environment and the same problems...
NEW CM server
OS: Server 2025 (26100.32860)
SQL: SQL 2022
ADK: Latest
Server name: CM

In addition to the information...
Following synchronization:
Warning in MECM log file (wsyncmgr.log)
WARNING: Request filter does not contain any known categories. Sync will do nothing. SMS_WSUS_SYNC_MANAGER 06/17/2026 10:52:55 13772 (0x35CC)

Warning in the WUS log file (SofwareDistribution.log)
2026-06-18 14:30:53.835 UTC Warning WsusService.58 DBConnection.ExecuteCommandNoResult SqlException occurred.
Number 50000 and message invalid update identity in XML for update 9EC61B38-6EFE-4C8F-9C99-02FBC0C1EA3E\100

Please help!

Ours is working now... the fix? Enable an automatic sync that runs every hour... and wait... days apparently. Also make sure your compatibility level is no higher than 150 for your CM_XYZ database.

 

[pabecot]

Ours is working now... the fix? Enable an automatic sync that runs every hour... and wait... days apparently. Also make sure your compatibility level is no higher than 150 for your CM_XYZ database.

Ok thank you for information, my CM_XYZ database compatibility is set to 160.
I modify the parameter in SSMS, then i wait.......
I prevent you when the synchronisation will be OK.

 

[JermB]

Ok thank you for information, my CM_XYZ database compatibility is set to 160.
I modify the parameter in SSMS, then i wait.......
I prevent you when the synchronisation will be OK.

Also, just FYI... The 150 compatibility is not related to the sync issues but, when you attempt to add your first driver package, it will fail with a level higher than 150, so just get that part over with now. As for the classifications Tab, check only Critical and Security... let it run (1 hour sync) and check it at least once a day. For us, around day 4 did we finally see Windows 11 as an option to check... after that, it ran for 8 hours, then I saw Windows Defender, Office 365 updates in the Products tab... so nearly a full work week of it just processing worked for us!

 

[JermB]

Also, just FYI... The 150 compatibility is not related to the sync issues but, when you attempt to add your first driver package, it will fail with a level higher than 150, so just get that part over with now. As for the classifications Tab, check only Critical and Security... let it run (1 hour sync) and check it at least once a day. For us, around day 4 did we finally see Windows 11 as an option to check... after that, it ran for 8 hours, then I saw Windows Defender, Office 365 updates in the Products tab... so nearly a full work week of it just processing worked for us!

I forgot! When you do get things going, make sure that Backup and Indexing is OFF in the built-in maintenance tasks. Use Ola's script instead as it does a way better job (trust me, you'll feel it when using the CM console)!! https://ola.hallengren.com/sql-server-index-and-statistics-maintenance.html

 

[pabecot]

Ok thank you for information, my CM_XYZ database compatibility is set to 160.
I modify the parameter in SSMS, then i wait.......
I prevent you when the synchronisation will be OK.

Perfect, is ok..
Thank you very much JermB

 

[pabecot]

Also, just FYI... The 150 compatibility is not related to the sync issues but, when you attempt to add your first driver package, it will fail with a level higher than 150, so just get that part over with now. As for the classifications Tab, check only Critical and Security... let it run (1 hour sync) and check it at least once a day. For us, around day 4 did we finally see Windows 11 as an option to check... after that, it ran for 8 hours, then I saw Windows Defender, Office 365 updates in the Products tab... so nearly a full work week of it just processing worked for us!

FYI
For the compatibility level 150 for drivers...
Before the problem, I had no problems with drivers with MCM 2603 (DB - 160)

 

[xponard]

Hello we had the behavior on our side.

ConfigMgr 2503, on Windows Server 2019,
ConfigMgr SQL, on Windows Server 2019,

ConfigMgr/SUP was kind of broken due to bad impromptus restarts-power off, corrupted some files locally on C:\ volume.
1) Fixing bad files by chkdsk+dism+sfc commands
2) Fixing the ConfigMgr/SUP by (add/remove the SUP role)
- removing SUP/removing the Update Service feature/cleaning local files, deleting the SUSDB, restarting
- readding the Update Service, doing post-install Update Service tasks, adding SUP role, selecting 0 classifications/products, launching the initial synch from ConfigMgr
3) > Facing the same issue of you : after 15min, No change made to SMS database (wsyncmgr.log)
> manually launch sync from Update Service console : cancelled automatically after 30min or 60-90min
> resulting in never completed the initial sync.
>> Cause : ConfigMgr interferring in the initial sync of Update Services and cancel it after some delay.


> My solution :
I) ConfigMgr - SUP component properties : Disable synchronization schedule
II) Update Service - launch 'Synchronize Now' button
> ConfigMgr don't stops the sync anymore
> after 2-3 hours, the sync is done and the products are all back in SUP properties console
III) enabling back Synchronization Schedule, adding some products, launching synch from ConfigMgr...

Hope it can helps.
Regards,

 

[pabecot]

Hello we had the behavior on our side.

ConfigMgr 2503, on Windows Server 2019,
ConfigMgr SQL, on Windows Server 2019,

ConfigMgr/SUP was kind of broken due to bad impromptus restarts-power off, corrupted some files locally on C:\ volume.
1) Fixing bad files by chkdsk+dism+sfc commands
2) Fixing the ConfigMgr/SUP by (add/remove the SUP role)
- removing SUP/removing the Update Service feature/cleaning local files, deleting the SUSDB, restarting
- readding the Update Service, doing post-install Update Service tasks, adding SUP role, selecting 0 classifications/products, launching the initial synch from ConfigMgr
3) > Facing the same issue of you : after 15min, No change made to SMS database (wsyncmgr.log)
> manually launch sync from Update Service console : cancelled automatically after 30min or 60-90min
> resulting in never completed the initial sync.
>> Cause : ConfigMgr interferring in the initial sync of Update Services and cancel it after some delay.


> My solution :
I) ConfigMgr - SUP component properties : Disable synchronization schedule
II) Update Service - launch 'Synchronize Now' button
> ConfigMgr don't stops the sync anymore
> after 2-3 hours, the sync is done and the products are all back in SUP properties console
III) enabling back Synchronization Schedule, adding some products, launching synch from ConfigMgr...

Hope it can helps.
Regards,

J'ai finalement la cause du problème, le catalogue initiale WSUS est corrompu.
Avant d'installer le rôle SUP dans MCM, je configure uniquement mon WSUS....
Respecter les étapes suivantes :

# Ouvrir la console WSUS

# Arrêter WSUS
Stop-Service WsusService -Force

<#
Modifier Langues : Fr et UK uniquement
Modifier Classifications : le minimum exMise à jour des définitions)
Modifier Produits : le minimum exWindows 10 Features on demand)
#>

# Redémarrer service WSUS
iisreset
Restart-Service WsusService

# Forcer une synchro PowerShell côté WSUS
[void][reflection.assembly]::LoadWithPartialName("Microsoft.UpdateServices.Administration")
$wsus = [Microsoft.UpdateServices.Administration.AdminProxy]::GetUpdateServer()
$sub = $wsus.GetSubscription()
$sub.StartSynchronization()

<#
Cette synchro ignore les updates invalides et permet à WSUS de reconstruire correctement :
la liste des classifications
la liste des produits
les catégories nécessaires à MECM
Après la synchro PowerShell (SoftwareDistribution.log dans C:\Program Files\Update Services\LogFiles)
#>


# Vérifier si synchro en cours
$sub.GetSynchronizationStatus()


# Attendre Synchro initiale en cours (durée environ 2H00)
Surveiller le fichier : C:\Program Files\Update Services\LogFiles\SoftwareDistribution.log

# Relancer Synchro 2H00 en cours (durée environ1')
Surveiller le fichier : C:\Program Files\Update Services\LogFiles\SoftwareDistribution.log

# WSUS opérationnel – Configuration SUP fonctionne parfaitement