Tag Archives: synchronisation error

How not to manage WSUS

When attempting to migrate my Config Manager 2012 site to HTTPS, I bit the WSUS shaped bullet and migrated the WSUS IIS side over. It was relatively straight forward, and there is a guide here. What? You’re surprised I didn’t leach it from TechNet and post it under my name? Tsk!

Interestingly this seems to be a relative after thought for a Config Manager administrator, and indeed the guides which seem to breeze through this topic. Woe betide anyone who merely flips the HTTPS switch in their Software Update Points without first migrating their WSUS backend. However I digress…

Anyway, I migrated both WSUS and the Config Manager Software update Points (SUPs) to SSL, and noticed the Config Manager component flagged as red. I delved into this log, and found that the primary SUP was failing to complete its synchronisation.

I tried running the WSUS clean up wizard; this worked on the downstream server, however I could see there were a lot of updates to be dealt with as per below.



It would not complete on the primary server though. It failed every time when I chose the first option, as per the screen shot below. I could run through everything else, but if I selected the first option the wizard would spit out an error stating it had lost connection to the database, and I had to reset the node.


I need another clean up wizard, to clean up my wizard.

So what to do? Well in my defense, this was not down to the SSL work. My first reaction was that this was because the WSUS database had not been maintained correctly, and had ballooned to over 30GB in size. I decided to pull it all down, and start again. I took the following remedial steps:

  • Removed the SUP from the downstream server
  • Removed the SUP from the primary server
  • Uninstalled WSUS from the downstream server and rebooted
  • Uninstalled WSUS from the primary server and rebooted

So, both servers were happy enough. I plunged right back in and did the following:

  • Installed WSUS on the primary server
  • Ran through the config wizard as far as the Start Connecting screen
  • Installed the KBs required for Config Manager integration (KB2734608-x64 and KB2720211-x64)
  • Installed WSUS on the downstream server

I could not get it to connect to the existing SQL database on the primary server. I think this is a limitation of using a Windows Internal Database (WID), as opposed to installing SQL and telling WSUS to use *that*.

  • Installed the KBs required for Config Manager integration (KB2734608-x64 and KB2720211-x64)
  • Ran through the config wizard as far as the Start Connecting screen
  • Installed the SUP role on the primary server
  • Fired off a sync

…and I got a new error! I think this was down to having System Centre Updates Publisher (SCUP) installed. The error in the WSUS sync log indicated it was trying to sync an unknown item. I unticked all the products from within Config Manager and finally got a clean sync. I then selected my products but yet again I received the same error. I reviewed the logs:



…and found that it was complaining about two specific product types; I unticked these two items, and things finally started to work!

Seven or so hours later, and the sync finally completed. The existing update binaries in my Config Manager deployments have been reused; the WSUS database is 2GB and the cleanup wizard works fine! I then installed the SUP on the downstream server, and once Config Manager reported the install was complete, unticked all the erroneous language options barring English in WSUS on the downstream server.

It’s also worth noting that in both instances where I installed WSUS/SUP on the downstream server, the downstream server defaulted to all languages. The primary server did not display this behaviour. I have read that if the downstream server is configured for all languages, then the primary server will synchronise with its source for all languages too.

Installing SUP and WSUS on the downstream server may well have been the trigger for this issue, as the language behaviour caused the primary server to sync all the extra updates.