Changing WSUS server used to update SCCM

Question

I'm very new to WSUS and SCCM. -- After reading duct_tape_coder message, I edited the text-- Thanks Coder!

Currently there is an old setup using a SCCM 2012 server to update internal systems, without internet connection. An exporting WSUS server with internet access is used to download the patches, then the contents in \WSUScontents\wsusconent are robocopy to an external harddisk. Using WSUSutil to export the metadata to .xml.gz format, also copied to the external harddisk. The contents are then robocopy into the SCCM's server WSUScontents folder, WSUSutil to import the metadata.

The WSUS server is owned by another group, which I have no access.

I need to takeover the update of this SCCM server, and hence need to setup another WSUS server.

Idea I have is, setup a new exporting WSUS, download all the content and export meta. On the current SCCM server, remove all file in the WSUScontent folder. And replace with contents from the new WSUS and import.

Another is, requesting the owner of the current exporting WSUS server to give me a copy of their WSUS contents and metadata export. Or, I got the WSUS contents and metadata export from the SCCM server. Then using these to copy into a exporting new WSUS server plus import the metadata.

What I don't know is, will the old SCCM get messed up, corrupted, update error, etc... if all its WSUScontents are replaced from the new WSUS. Or the second option is a safer bet? I would also need to mirror the current MS products and classifications to download.

Is the Windows version between the new and old WSUS server important? How about the WSUS version and any patches required?

Thanks!

Answer 1

Well you have two different issues going on here that probably need to be handled separately:

1. Migrating SCCM's WSUS
2. Performing an offline update of WSUS

I'm not too familiar with the SCCM setup but from here (https://social.technet.microsoft.com/Forums/windows/en-US/a58cf433-0804-45e1-a137-20c002c4b647/wsus-to-be-migrated-from-sccm-primary-server-to-new-server?forum=configmanagersecurity) it seems relatively simple:

• Build the new WSUS
• Use ConfigMgr to update the WSUS
• Clients will use SCCM agent data to point to the new WSUS

As for the new WSUS, this is where it gets a little tricky: If your Offline WSUS already has good data, you can use it as an upstream source for the new WSUS server. Odds are however that it's out of date and there's a monthly process to get it resynchronized.

Performing an offline update of WSUS involves five basic steps and the order MATTERS A LOT. Here is the MS guide: https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd939873(v=ws.10)?redirectedfrom=MSDN

1. Install a WSUS server on the disconnected network segment. This server is known as the WSUS import server.

2. Synchronize updates and metadata to a WSUS server that is connected to the Internet. This server is known as the WSUS export server.

3. Transfer the required updates and metadata from the WSUS export server to removable media.

4. Transport the removable media to the WSUS import server.

5. Import the updates and metadata to the WSUS import server.

6. Manage and download updates to client computers on the disconnected network segment by using the WSUS import server.

Gotchas!

NUMBER ONE BY HOLY JEEBUS: DO NOT IMPORT METADATA BEFORE COPYING OVER ALL THE CONTENT

You must always import the update files to the WSUS import server before you import the update metadata. If WSUS finds metadata for an update that does not have corresponding update files, WSUS considers the update to be a failed download. To resolve this issue, copy the update to a directory on the WSUS import server and redeploy the update.

They make it sound easy to recover from, but I've always had to completely wipe WSUS and start over when I've screwed this up. One option is to use two WSUS and import to a "sacrificial WSUS" and synchronize your real WSUS to the sacrificial one. The sacrificial will act like content is not downloaded but the real WSUS can pull it just fine.

Number Two: Versions of OS and WSUS matter.

It may seem like they don't but they do.

Number Three: Your Database matters.

Windows Internal Database works well, until it doesn't. SQL works okay, until it doesn't. Everything sucks, but in different ways

Number Four: IIS settings matter.

Review the Microsoft documentation on how to tune IIS for WSUS

Number Five: Export your metadata as .xml.gz rather than .cab. CAB files can't handle size larger than 2GB (32bit issue) and WSUS data long ago exceeded that size.

Number Six: WSUS sucks

No really. I have NEVER encountered a worse piece of software and one so critical to every environment. WSUS constantly corrupts itself, doesn't tune itself, doesn't perform automatic database cleanup. It will randomly fail for no apparent reason and doesn't provide useful errors or logging.

Good luck!