Overview
- This video tutorial will look at different scenarios within ConfigMgr where you may want to either rebuild or relocate a WSUS server. We will look at three different scenarios:
Scenario 1: Full WSUS rebuild WSUS on existing Server/SUP
Scenario 2: Migrate the WSUS server (SUSDB + Content + Frontend) to a new server
Scenario 3: Migrate the WSUS server (Content + Frontend) to a new server use existing SQL
Topics in Video
- Introduction: (0:00)
- Overview of the scenarios that will be covered: (0:39)
- Verifying if you changed the IIS configurations for WSUS to the recommended settings: (2:50)
- WSUS Maintenance and Supersedence Rules: (5:12) Jumping into Scenario 1: Full WSUS rebuild WSUS on existing Server/SUP: (8:56)
- Reviewing the Products & Classification tab in the Software Update Point Component Properties: (9:41)
- Running a Software Update Point Synchronization: (11:37)
- Expired third-party updates in ConfigMgr: (12:55)
- Purging expired third-party updates out of ConfigMgr Database: (16:18)
- Unsubscribing from Third-Party Software Update Catalogs before WSUS rebuild: (17:43)
- Uninstalling WSUS: (19:06)
- Deleting WSUS database from SQL Server Management Studio: (21:16)
- Clean install of WSUS: (23:00)
- Restarting the SMS_WSUS_CONFIGURATION_MANAGER component: (26:39)
- Run Software Update Point Sync to trigger WSUS to pull the latest catalog from Windows Update: (29:34)
- Running WSUS Server Configuration Wizard: (32:54)
- Viewing updated Products and Classification list in WSUS: (34:37)
- Getting our products to configure in ConfigMgr: (34:50)
- Running another SUP synchronization to pull down updates for products we have configured: (37:16)
- Publishing third-party updates into WSUS (to be continued): (38:25)
- Moving on to Scenario 2: Migrate the WSUS server (SUSBD + Content + Frontend) to a new server (40:33)
- Verifying you’re not currently running a synchronization by viewing the wsyncmgr.log: (41:40)
- Backing up SUSBD: (41:52)
- Copying the SUSDB.bak file from Demo2 to the new remote sitesystem Server that we are migrating to: (43:03)
- Copying WSUS content to the new remote sitesystem Server: (43:56)
- Restore database on new remote sitesystem server: (45:20)
- Install WSUS on the new remote server: (47:34)
- Viewing updates in WSUS on the new remote server: (49:22)
- Install an additional Software Update Point: (50:25)
- Giving the remote server access to the SUSDB to do the maintenance to the database: (53:31)
- Removing SUP role from Demo2 and make sitesystem the top-level SUP: (56:06)
- Running a SUP sync: (57:00) Add new sitesystem server to our Boundary Group in ConfigMgr: (58:06)
- Viewing the WCM.log and wsyncmgr.log to confirm synchronization completed: (58:37)
- Viewing the LocationServices.log on our client to show that it detected the SUP change: (58:54)
- Exporting our Patch My PC settings to the new remote sitesystem server: (59:22)
- Run PowerShell script to remove some WSUS components that are no longer required on Demo2: (1:00:06)
- Detach database from Demo2: (1:00:24)
- Re-installing Patch My PC publisher and importing settings to new remote sitesystem server: (1:01:47)
- Export WSUS certificate from Demo2 to new remote sitesystem server: (1:02:19)
- Running a sync in the Patch My PC publisher: (1:03:42)
- Revisiting Scenario 1 to verify WSUS is fully configured in ConfigMgr: (1:04:53)
- Enable Patch My PC and SCUP Updates in SUP components product tab and Run a SUP sync: (1:05:18)
- Verifying third-party updates synced into ConfigMgr: (1:06:23)
- Jumping back into scenario 2 to check the IIS for best practice configurations: (1:06:53)
- Starting Scenario 3: Migrate the WSUS server (Content + Frontend) to new server use existing SQL server: (1:08:00)
- Creating a WSUS folder in the new remote sitesystem server: (1:09:44)
- Verifying you’re not currently running a synchronization by viewing the wsyncmgr.log: (1:09:49)
- Copying current WSUS folder to the new remote sitesystem Server: (1:10:14)
- Install WSUS on the new remote server: (1:10:54)
- Install an additional Software Update Point: (1:14:21)
- Removing SUP role from Demo3 and make sitesystem the top-level SUP: ( 1:16:43)
- Run a SUP sync: (1:17:31)
- Run PowerShell script to remove some WSUS updateservices from Demo3: (1:18:07)
- Verify WSUS is running on new remote sitesystem sever: (1:19:39)
- Add new sitesystem server to our Boundary Group in ConfigMgr: (1:20:05)
- Viewing the LocationServices.log and ScanAgent.log on our client to show that it detected the SUP change: (1:20:26)
- Restart server and view WCM.log to verify that it successfully configured: (1:20:58)
- Wrap-up: (1:21:32)
Helpful Resources:
I'm Justin Chalfant! I'm the founder of
Hi there
Very helpful post, thank you.
Is Scenario 3 also possible when the new remote server has newer os newer wsus version?
best regards
Michael
Thank you for the instructional video, it is very helpful. I had a question which kind of echoes Michael’s comment. In our situation we are needing to migrate our SUP from a windows 2012 r2 server to server 2019. Doing an in-place OS upgrade is not an option. I am wondering if this affects the 3 scenarios you have described? It seems like there are limitations/problems moving wsus installation from older OS to newer version?
Thanks for all the great videos, Justin! I have a similar question to Michael and Gary. Are the steps in Scenario 3 still valid if your new and old SUPs are running on different OS, thus different versions of WSUS? I’m concerned about DB corruption if I connect the new WSUS to the shared / remote DB.
Hey Mike,
Yeah, that should work. Just be aware if you upgrade the OS from 2016 to 2019/2022 and you use third-party updates, be aware if this scenario: https://patchmypc.com/duplicate-patch-my-pc-category-listed-in-software-update-point-products-tab#:~:text=The%20duplicate%20categories%20are%20caused,vendor%20category%20in%20the%20database.