locked
WSUS 3.0 SP2 master server cross-forest migration impacts RRS feed

  • Question

  •     Hello to all, I'm preparing a cross-forest migration and have one WSUS 3.0 SP2 master on source forest placed in root domain. This master has 16 replicas scattered among child source domains. As I plan do migrate member servers using MS tool named ADMT 3.2 and considering that I will firstly migrate just root domain member servers to target forest, I need to know:

       1- Will WSUS 3.0 SP2 master server work after it's migrated from source to target forest? I mean: can all its replicas still access and donwload the necessary patches from it? Will its configuration be in place (groups, schedules, etc) ?

       2- Should I need to change source domain clients WSUS GPOs to point to the just migrated master server (new FQDN name)?

       3- Is possible to change my just migrated WSUS 3.0 SP2 to be replica from a master server already present on target forest? How this move could affect its existing replicas still present on source forest?

       Suggestion and attention points will be appreciated.

       Regards, EEOC.

    Tuesday, April 29, 2014 8:17 PM

Answers

  • the plan is to run ADMT on it so it will be migrated to target forest with all its already instaled services - WSUS is the main one.

    Perhaps there is some confusion over the purpose of the ADMT tool.

    ADMT will move the *objects* from the database of one domain to the database of another domain, but it doesn't actually reconfigure the domain member systems.

    If this is simply a question of taking a WSUS Server from an existing Domain 'A' and moving it to an existing Domain 'B', the simple solution is to:

    1. Disjoin the existing domain.
    2. Rename/Readdress the server (if necessary, e.g. if physically moving to another IP Subnet).
    3. Join the new domain.

    Generally speaking, WSUS is NOT AD-aware, so WSUS doesn't care if, or what, forest or domain the server it runs on might be located. The only real issue of relevance is that a client can resolve the hostname to the correct IP Address and make the necessary HTTP connection to the WSUS server.

    So after joining the new domain, all that's really necessary is to change the URL configured in the DSS for the USS, and change the URL in the GPO(s) for the clients of the USS.


    Lawrence Garvin, M.S., MCSA, MCITP:EA, MCDBA
    SolarWinds Head Geek
    Microsoft MVP - Software Packaging, Deployment & Servicing (2005-2014)
    My MVP Profile: http://mvp.microsoft.com/en-us/mvp/Lawrence%20R%20Garvin-32101
    http://www.solarwinds.com/gotmicrosoft
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

    • Marked as answer by EEOC Friday, May 2, 2014 11:19 AM
    Wednesday, April 30, 2014 10:20 PM

All replies

  • 1- Will WSUS 3.0 SP2 master server work after it's migrated from source to target forest? I mean: can all its replicas still access and donwload the necessary patches from it? Will its configuration be in place (groups, schedules, etc) ?

    Fundamentally yes, as long as the downstream servers are updated to use the new hostname and DNS properly resolves that hostname. NOTE: You cannot "migrate" the WSUS role using ADMT. What is your plan for "migrating" the WSUS upstream server?

    2- Should I need to change source domain clients WSUS GPOs to point to the just migrated master server (new FQDN name)?

    Probably. Presumably the hostname and IP Address of the server are going to change.

    3- Is possible to change my just migrated WSUS 3.0 SP2 to be replica from a master server already present on target forest?

    Yes, but that's kind of a cart-before-the-horse move... which brings us back to the original question: How do you plan to "migrate" the upstream server?

    How this move could affect its existing replicas still present on source forest?

    Well.. it will introduce a three-tier replication hierarchy for starters, which will slow everything down by one or two days. But, really, I wouldn't worry about that because there's no real need to do this.

    Suggestion and attention points will be appreciated.

    1. Install a *NEW* WSUS server in the target forest.
    2. Configure it as a replica of the existing master in the source forest.
    3. Replicate.
    4. When the replication is complete, reconfigure it as an Upstream Server and RESET the Product Category and Update Classifications to what they should be.
    5. Synchronize with Microsoft.
    6. When that sync is successful, enabled regular synchronizations.
    7. Configure clients and downstream servers to sync from the new upstream server in the target forest.
    8. When all clients and downstream servers are working with the new server, turn off the old one.

    Lawrence Garvin, M.S., MCSA, MCITP:EA, MCDBA
    SolarWinds Head Geek
    Microsoft MVP - Software Packaging, Deployment & Servicing (2005-2014)
    My MVP Profile: http://mvp.microsoft.com/en-us/mvp/Lawrence%20R%20Garvin-32101
    http://www.solarwinds.com/gotmicrosoft
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

    Tuesday, April 29, 2014 11:34 PM
  •    Hello Lawrence, thanks for you useful reply. Below you can find what I mean by migrating the master WSUS from source to target forest:

       the plan is to run ADMT on it so it will be migrated to target forest with all its already instaled services - WSUS is the main one. I didn't consider to install a new OS and turn off the original master server. I just thought to migrate it to target forest using ADMT and ,as you said, reassign the replicas servers (left on source forest) to it and change GPOs to reconfigure patch to clients. Extra info.: on near future all other child domains and its members servers will be migrated to target forest so the replicas servers will be migrated too. What do you think from this approach? I think that it works but would like to hear your eventual comments about it.

       About question # 3, I was considering it an option but now I understand that it does not woth the effort.

       Regards, EEOC.

      

      

      

    Wednesday, April 30, 2014 12:38 PM
  • the plan is to run ADMT on it so it will be migrated to target forest with all its already instaled services - WSUS is the main one.

    Perhaps there is some confusion over the purpose of the ADMT tool.

    ADMT will move the *objects* from the database of one domain to the database of another domain, but it doesn't actually reconfigure the domain member systems.

    If this is simply a question of taking a WSUS Server from an existing Domain 'A' and moving it to an existing Domain 'B', the simple solution is to:

    1. Disjoin the existing domain.
    2. Rename/Readdress the server (if necessary, e.g. if physically moving to another IP Subnet).
    3. Join the new domain.

    Generally speaking, WSUS is NOT AD-aware, so WSUS doesn't care if, or what, forest or domain the server it runs on might be located. The only real issue of relevance is that a client can resolve the hostname to the correct IP Address and make the necessary HTTP connection to the WSUS server.

    So after joining the new domain, all that's really necessary is to change the URL configured in the DSS for the USS, and change the URL in the GPO(s) for the clients of the USS.


    Lawrence Garvin, M.S., MCSA, MCITP:EA, MCDBA
    SolarWinds Head Geek
    Microsoft MVP - Software Packaging, Deployment & Servicing (2005-2014)
    My MVP Profile: http://mvp.microsoft.com/en-us/mvp/Lawrence%20R%20Garvin-32101
    http://www.solarwinds.com/gotmicrosoft
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

    • Marked as answer by EEOC Friday, May 2, 2014 11:19 AM
    Wednesday, April 30, 2014 10:20 PM
  •    Hello Lawrence, thanks again.

       Regards, EEOC.

    Friday, May 2, 2014 11:19 AM