Despite multiple articles of howto maintain a WSUS database for performance and scalability – there was always a performance issue dragging across which made all the cleanup jobs take forever. An earlier (not able to find it again) Technet Forum post clarified that this was due to all clean-up jobs beeing dependent on the Stored Procedure spDeleteUpdate, and this generates a temporary table that doesnt have an index for the appropiate columns. Unfortunately I werent able to find this post again – but lo, and behold – Microsoft confirmed the behaviour!
The fix is simply to alter the Stored Procedure spDeleteUpdate and append the following line during the creation of the temporary table;
After you restore a ConfigMgr Primary Site Server there are some losses of information that gets annoying.
Sample; WSUS Catalog version is stored in the registry and the ConfigMgr database. It seems that the registry alone is enough to reset the used WSUS Catalog version, however Registry alone is not enough to restore the catalog version with ConfigMgr 1606.
Roger Zander described the behaviour and gave the right path, however some additional steps were required for ConfigMgr 1606.
Step 1. Identify the necessary catalog version that is required (see Roger Zanders previous description)
Step 2. Update the registry (see Roger Zanders previous description)
Step 3. Update the database. Locate the table dbo.Update_SyncStatus within the ConfigMgr database. Choose Edit Top 200 rows (and there – you are now unsupported by Microsoft).
Update the ContentVersion to match your Catalog Version
Step 4. Trigger a new “Synchronize Software Updates”