Configuring Multiple Software Update Points (SUP) in SCCM

I was working on a SCCM deployment where there was already one existing Software Update Point (SUP). Due to new firewall restrictions, a few new SUPs were required. Microsoft has changed their best practices with SCCM in regards to using multiple SUPs. The best practice is to share the WSUS Database (SUSDB) and the WSUS content directory. This cuts down on a lot of space, replication and administrative issues. Fortunately the WSUS database was installed using standard edition Microsoft SQL Server and not the Windows Internal Database (WID). If you’re using the WID, you cannot share the database as it does not allow for remote connections. You’ll have to migrate it from there.

A great overview and process of using a shared database and content directory are quite well documented in a Microsoft blog which you can read here:

https://blogs.technet.microsoft.com/configurationmgr/2016/10/12/how-to-implement-a-shared-susdb-for-configuration-manager-software-update-points/

But, I’m going to add a little prep work to aid in the success of deploying multiple SUPs sharing the database and content location. This will probably make you go, oh yeah, I need to think about doing this and that in my infrastructure. Knowledge is power!

Preparing the SUP Infrastructure

First off, let’s start from the beginning so we’re all on the same page. In most WSUS deployments I do, I’ll put the WSUS Content location at D:\WSUS. This is the same directory I used when I ran the POSTINSTALL command and used with the CONTENT_DIR parameter.

To share the content location and use the content, we’ll need to share it, but we’ll also need to set security on the share and NTFS folder. As the primary SUP was installed on Pri01, this is where I ran the code. You should only need to do this on that server.

$SUPs = @("Pri01$", "Sup02$", "Sup03")
$WsusPath = "D:\WSUS"
$WsusShareName = "WSUS"
$WsusFolder = New-Item -ItemType Directory -Path $WsusPath -ErrorAction SilentlyContinue

# Set NTFS Permissions to Full Control for SUP Servers
$acl = Get-Acl -Path $WsusPath
foreach ($SUP in $SUPs) {
    $rule = New-Object System.Security.AccessControl.FileSystemAccessRule($SUP, ”FullControl”, “ContainerInherit, ObjectInherit”, “None”, “Allow”)
    $acl.AddAccessRule($rule)
}
Set-Acl -AclObject $acl -Path $WsusPath

# Create SMB Share and Grant Full Permission to SUP
New-SMBShare -Path $WsusPath -Name $WsusShareName -FullAccess $SUPs

Installing the WSUS Components on the new SUP Servers

This is a fairly straight forward process, but it does have a few headaches if you’re already up and running.

To ensure that the WSUS install for this purpose and that the SUP role is installed, run the following:

Install-WindowsFeature Net-Framework-Features, RDC, UpdateServices-Services,UpdateServices-UI, UpdateServices-DB -Restart 

Nothing new there. The next command of running the post install should be familiar, but we’re going to change it up a bit so that we can use the share above.

1. First off, we’re going to point to the SQL Server instance that already has the SUSDB
2. Secondly, we’re going to tell the CONTENT_DIR to use the share on Pri01

cd C:\Program Files\Update Services\Tools 

wsusUtil.exe postinstall SQL_INSTANCE_NAME=pri01.corp.local CONTENT_DIR=\\pri01.corp.local\WSUS

Log file is located at C:\Users\allan\AppData\Local\Temp\3\tmpDFB6.tmp
Post install is starting
Post install has successfully completed 

The problem I’ve run into before and see quite often is, is that the SUSDB is already in use. In this case when you run the POSTINSTALL command above you’ll see the following error:

Fatal Error: Database ‘SUSDB’ is already open and can only have one user at a time.

ALTER DATABASE statement failed.

Now this is where I find a lot of blogs fall down and do various things to “fix” the issue. As WSUS is generally used by one server, the database is installed in Single User mode. Well that just means that we cannot do anything to the database while it’s in use. Instead of killing things, and changing the database ourselves, let’s shut them down properly. All we had to do to find this information was to check your logs.

2017-01-24 16:16:25 Swtching DB to multi-user mode……

2017-01-24 16:16:26 System.Data.SqlClient.SqlException (0x80131904): Database ‘SUSDB’ is already open and can only have one user at a time.

ALTER DATABASE statement failed.

On Pri01 where we originally have SUPs server, I have found the stopping the following 2 processes allows the POSTINSTALL command to complete successfully.

Stop-Website "WSUS Administration"
Stop-Service WsusService -Force

Now rerun the POSTINSTALL command and voila, it should successfully complete. Once it completes successfully, remember to start the update service and WSUS Admin website.

Start-Service WsusService
Start-Website "WSUS Administration"