Recently I helped my Customer with a CMG configuration. The Clients are not hybrid joined, so we needed to use PKI infrastructure. For the Pilot the Customer decided to bring a new 2016 Server and configure it for SSL-enabled MP and SUP in the current HTTP environment (SCCM is installed on Windows Server 2012 R2).
Everything looked ok until the second SUP was prepared. We used https://www.windowsmanagementexperts.com/configmgr-add-second-software-update-point/configmgr-add-second-software-update-point.htm as a guide and pointed the new WSUS to the primary database. That was a mistake – the secondary WSUS was installed ok, but the primary went down and could not start anymore. I tried to run wsusutil postinstall with specified content folder and database, but WSUS was not happy anyway. wsusutil log revealed that the new 2016 WSUS actually updated WSUS DB schema and the old 2012 R2 WSUS could not access it anymore 
. The error message suggested to upgrade WSUS to the same version…
Hopefully we had a backup of the DB, so I deleted the new WSUS, restored the DB with the old schema and re-run wsusutil postinstall content_dir=*MYFOLDER* SQL_Instance_Name=*MySQLNAME*. After that the primary WSUS started and with some time SUP connected to it correctly.
After that I install a new WSUS on the 2016 server again, but this time I used a local folder for content and WID for the WSUS database. Next, I moved database from WID to my SQL server with a different name (since SUSDB already existed there) and tweaked registry settings in WSUS Server configuration to point it to the new location. step-by-step is here: https://docs.microsoft.com/en-us/windows-server/administration/windows-server-update-services/manage/wid-to-sql-migration
registry settings for SQL name and DB name (if the name was changed):
Lesson learned: it is always better to use the same OS version for site systems in your SCCM infrastructure.
Like this:
Like Loading...
Related
