8 Replies Latest reply on Aug 8, 2014 12:01 PM by Lawrence Garvin

    Migrating WSUS Servers

    khiyal

      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.

        • Re: Migrating WSUS Servers
          Lawrence Garvin

          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.

          • Re: Migrating WSUS Servers
            Lawrence Garvin

            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:

            1. Remove the WSUS role *AND* database, but NOT the CONTENT!
            2. Install the WSUS role and NEW database, pointing to the existing content store.
            3. Synchronize with the new upstream server.
            4. 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.
              • Re: Migrating WSUS Servers
                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?

                  • Re: Migrating WSUS Servers
                    Lawrence Garvin

                    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.


                      • Re: Migrating WSUS Servers
                        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:

                         

                        <downstreamserver name="ABCDWSUS01.unicef.org" id="c3b434a4-4d76-4975-9f60-18ffaa1c1bca" port="80" usessl="no" />

                         

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

                          • Re: Migrating WSUS Servers
                            khiyal

                            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.

                             

                            Is it specifically ,Net 3 or could it also be 3.5, 3.51, or higher?

                             

                            From our existing WSUS v3 upstream server, /changeconfiguration gives "Unable to connect to the remote server" The remote server is up, able to replicate, and is PINGable

                             

                            Just a thought ... What if on the remote server, we change the server name (and eventually the port number) from "update source and proxy server" instead of using the wsuschangeuss utility?

                              • Re: Migrating WSUS Servers
                                Lawrence Garvin
                                Is it specifically ,Net 3 or could it also be 3.5, 3.51, or higher?

                                The *tool* only requires .NET2, but inasmuch as Microsoft only supports .NET3.5.1 .... :-)

                                The issue being, there's no .NET2/NET3 on a WS2012/WS2012R2 system, and I doubt installing .NET351 is justifiable just for this task.

                                 

                                What if on the remote server, we change the server name (and eventually the port number) from "update source and proxy server" instead of using the wsuschangeuss utility?

                                 

                                That's always an option. It's the original methdology.

                                The intent of the tool was to eliminate the need to do this on several, or dozens, or hundreds of downstream servers. It was this need of an actual customer that resulted in the creation of the tool.