Migrating WSUS Servers

From online discussions, I understand that Solarwinds has WSUSChangeUSS utility that, "....is designed to be used in conjunction with any WSUS upstream server migration involving a URL change to the location of the upstream server." In my current environment, we do not use SSL and in the new envoironment, we plan to use SSL.

For my environment, let's say I have:

Existing Upstream server OLDWSUS01

Replica Servers DOWNWSUS01, DOWNWSUS02, DOWNWSUS03

New Upstream Server NEWWSUS01

To use the utility, I will perform the following:

On OLDWSUS01, run WSUSChangeUSS /command export /dssxmlfile c:\temp\oldwsus.xml /sourcewsusname oldwsus01.abc.org /sourcewsusport 8530 /sourcewsususessl no

Then copy c:\temp\oldwsus.xml from OLDWSUS01 to NEWWSUS01 and run

WSUSChangeUSS /command changeconfig /dssxmlfile c:\temp\oldwsus.xml /sourcewsusname newwsus01.abc.org /sourcewsusport 8531 /sourcewsususessl yes

Is this all or am I missing something in this routine? Is there anything required on the replica server? Would the existing patches/approvals be automatically deleted on the replica server?

If I only need to do this on one of the replica servers, can the xml file be edited, and the names of other servers removed?

Alternatively, if I uncheck the "this is a replica server" setting on the replica server, delete all patches and then change the name of the source server and the port number and recheck the "replica" setting, would that also do the job?

Looking forward to some additional information.

Thanks.

Find more posts tagged with

wsus_change_upstream_server

wsus

change

replica

Accepted answers

All comments

LGarvin

There's a couple of things going on here that I'd offer comment on.

First, my suggestion would be to complete the migration of the upstream server WITHOUT invoking SSL, and ensure that all downstream servers are properly communicating with the new upstream server WITHOUT SSL.

THEN.... go through the process of implementing SSL (keeping in mind you'll also have to deploy SSL certificates to the downstream servers, and change the URLs from http://xxx:8530 to https://xxx:8531).

You can still do the URL changes using the WSUSChangeUSS utility, but you eliminate the implementation of TWO changes, simultaneously, either of which can be a source of complications.

And either way, you're still going to have to distribute the SSL certificate of the new upstream server to the downstream servers before you can point the downstream servers to the new upstream server.

And, you may also have similar considerations with any *clients* of that upstream server... those clients will also need SSL certificates and to be reconfigured.

Better, IMHO, to get the configuration changes all done and verified working without SSL complicating the situation.

And then invoke SSL, and if something goes sideways you KNOW it's an SSL issue, because everything else WAS working perfectly prior to invoking the SSL.

LGarvin

If I only need to do this on one of the replica servers, can the xml file be edited, and the names of other servers removed?

Yes, if you don't want to invoke the configuration change on one or more downstream servers, you can delete those elements from the exported XML file before running the /command changeconfig.

Alternatively, if I uncheck the "this is a replica server" setting on the replica server, delete all patches and then change the name of the source server and the port number and recheck the "replica" setting, would that also do the job?

No, that will screw things up bigtime, and just create gigabytes of content that needs to be downloaded against across your WAN connection.

Of course, it also depends on how you're invoking the migration to the new server.

If you're using the built-in WSUS replication to create the new upstream server, then the new upstream server and the existing replicas will already be "in sync", and there's no need to do anything on the replicas except just point them to the new server.
If you're creating a *NEW* upstream WSUS server, and only retaining some (one?) replica server, then I would suggest building a new replica server from scratch.

If you're using the Migration Guide from Microsoft, I would highly encourage you to NOT do that, and instead consider one of the above two methodologies.

Here's the most effective way to rebuild the replica from a NEW upstream server:

Remove the WSUS role *AND* database, but NOT the CONTENT!
Install the WSUS role and NEW database, pointing to the existing content store.
Synchronize with the new upstream server.
Run the Server Cleanup Wizard "Delete unneeded FILES.." option only on the replica server(s), to clean up the content store of any files no longer needed.

khiyal

Thanks for the suggestion. Our SSL certificate is signed with our internal CA so no requirement to send the SSL certificate everywhere. However, I will begin without SSL and then add it later.

khiyal

Thanks for your detailed responses, Lawrence.

We plan to create a new upstream server and use the existing replica servers.

I will do my test based on the four steps that you mentioned.

Since we will be retaining most of our 200+ replica servers, I will do extensive testing on a couple of replica servers before making a final determination on how to proceed.

I am still not sure about the WSUSChangeUSS utility. This is how I mentioned to use it:

On existing upstream WSUS, run WSUSChangeUSS /command export /dssxmlfile c:\temp\oldwsus.xml /sourcewsusname oldwsus01.abc.org /sourcewsusport 8530 /sourcewsususessl no

Then copy c:\temp\oldwsus.xml from existing upstream WSUS to NEWWSUS01 and run

WSUSChangeUSS /command changeconfig /dssxmlfile c:\temp\oldwsus.xml /sourcewsusname newwsus01.abc.org /sourcewsusport 8531 /sourcewsususessl yes

or would the utility with /changeconfig be run on the existing WSUS upstream server?

LGarvin

The only requirement for any of the functionality in the WSUSChangeUSS utility is that it be run from a machine with .NET3 and the WSUS API.

Functionally you can run it from any WSUS v3 server or any machine with a WSUS v3 console.

You could also run it from a WSUS v6 system, but this would require you to install the .NET3 which would not otherwise be present.

For the /command export, the utility makes a remote API call to the upstream server and extracts the list of registered downstream servers.

For the /command changeconfig, the utility uses the local API to make a remote API call to each of the downstream servers (based on the list contained in the XML file),

and then pushes the configuration change based on the declared command line parameters (/sourcewsusname, /sourcewsusport, and /sourcewsususessl).

Since everything is defined in the command line parameters, or contained in the XML export file, the actual location of execution of the utility doesn't matter.

khiyal

The output file of

WSUSChangeUSS /command export /dssxmlfile c:\temp\oldwsus.xml /sourcewsusname oldwsus01.abc.org /sourcewsusport 8530 /sourcewsususessl no

Provides the file oldwsus.xml where downstreamserver is listed as follows:

However, our downstream servers use port 8530. Is this port 80 referring to something else?