POSH for Switching from using non-shared to shared SUPDB on CM12 SUPs
It is generally recommended to use shared SUSDB In your CM12 environment when you have multiple SUPs (Software Update Points) in a single primary site. Thus, have you ever had the need to switch from using SUPs with their own SUPDBs to shared SUPDB? We did this simply to avoid the clients in failed state for long periods and to avoid that network cost. Below is the script that I put together to switch from using non-shared SUPDB to shared SUPDB on our SUPs>
This script pretty much follows the general guideline of setting up your SUPs with shared SUPDB. However, since we had already had it set in place where our SUPs were already using their own SUPDBs, so this will uninstall WSUS off your existing SUP or remove the role (windows feature) so that it can reset which DB it’s pointing to. Then it follows it up with post configuration to put things back, and to where your SUPs are pointing to that single or common shared WSUS Database.
General guideline of installing multiple SUPs with Shared SUPDB.
- Prepare the Database server, create the share (WSUSContent) and create the WSUS group that has access to the share
- Install the first SUP with WSUS pointing to the common SUPDB and move its content to a Central\shared location (copy content)
- Install the subsequent SUPs with WSUS pointing to the common SUPDB and move its content to a Central\shared location (-skip copy)
Here’s what the menu prompt looks like:
Quick breakdown of what each above does:
DB option
- Creates the WSUSContent directory and shares it out
- Then it creates the local WSUS Content group
SUP1
- Removes the role and adds it back
- Runs the post configuration using WSUSUTIL and points to the remote SUPDB
- Runs the post configuration using WSUSUTIL and moves the content
- Adds the SUP1 computername to WSUS Administrators group that has access to the content
- Sets the Virtual Content access to use a service account (Change user and pass in this the script)
SUPX
- Removes the role and adds it back
- Runs the post configuration using WSUSUTIL and points to the remote SUPDB
- Runs the post configuration using WSUSUTIL and moves the content with -skipcontent
- Adds the SUP1 computername to WSUS Administrators group that has access to the content
- Sets the Virtual Content access to use a service account (Change user and pass in this the script)
Lastly, this creates a log in the same folder you run this script under. $scriptname.log.
Again, use this at your own risk! But I hope it helps! J
NOTES:
- Script only supports Windows Server 2012 and/or Windows Server 2012 R2
- The WSUSDB server also holds the WSUSContent share here as well. You can change that in the script if you’d like J. And it obiously requires IIS on the SUPDB J
- Run this script locally on the box you are working on. You will need to run this on the remote database server first to prep the DB. Then run it on the SUP1, SUP2 SUP3 and so on, following the guideline above.
- Pay attention to the variables that are set above the script. And it is domain aware, so change the variables in there according to domain environments you have. This is really useful for folks that have Lab and production environments. So you only make one script change and it applies to both for consistency.
- Created on .