none
Migrating WID from Server 2003 to 2012

    Question

  • Hello All,

    We are in the process of decommissioning our Server 2003 boxes, one of which currently houses our WSUS rigging.

    I have a new 2012 box prepped and I see a lot of discussion about migrating WSUS from WID to MS-SQL. However, I haven't noticed much about migrating from 2003 WID to 2012 WID.

    Of course, the file structure looks the same, but is there some tool that must be run to update the 2003 version to 2012 format? Or is it as simple as copying the files from the old server to the new?

    TIA, Tom W.


    JTW

    Friday, November 15, 2013 10:27 PM

Answers

  • The question here really isn't about migrating the database, but really about migrating WSUS.

    There are two methodologies for "migrating" WSUS.

    There's the complex and complicated methodology described in the "Migration Guide", which includes backing up and restoring the database, and a lot of manual steps ...

    And there's the "replicate using the WSUS built-in replication" method.

    1. Ensure the WSUS v3.2 system has KB2734608 installed and is fully functional.
    2. Set synchronization on the WSUS v3.2 server to MANUAL.
    3. Install WSUS v6 on the new WS2012 (or WS2012 R2) system as a replica of the WSUS v3 server.
    4. Replicate. This may take a day or two depending on the number of approved updates and amount of files to transfer). I would strongly suggest performing Approval Maintenance and running the Server Cleanup Wizard on the WSUS v3.2 server before performing this replication. If the Server Cleanup Wizard times out on the WSUS v3.2 server, so will the attempt to replicate.
    5. After replication is complete, reconfigure the WSUS v6 server as an upstream server.
    6. RESET the Product Categories and Update Classifications on the WSUS v6 server to what they should be. (This should match what is configured on the WSUS v3.2 server.) NOTE: There is a **BUG** in the WSUS v6 server (actually it may also exist in a WSUS v3.2 server, but nobody has reported it) that incorrectly resets (or never records at all) the Product Categories and Update Classifications obtained from the upstream server during the replication.
    7. After resetting Product Categories and Update Classifications, perform a synchronization with Microsoft.
    8. After the successful synchronization with Microsoft, update Group Policy to point the WSUS clients to the new WSUS v6 server.
    9. After ALL clients have successfully REPORTED to the new WSUS v6 server, retire the WSUS v3.2 server.


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

    Friday, November 15, 2013 11:37 PM
  • Hi,

    As far as I know, we could first back up WSUS database on the source server and then restore the database on the desitination server, for more details please refer to the below article:

    http://technet.microsoft.com/en-us/library/hh852349.aspx

    The article not only point out how to use SQL to do migration, also talk about when using WID.

    In addition the below blog should be helpful for WSUS migration:

    How to move WSUS from one server to another

    http://blogs.technet.com/b/sus/archive/2009/07/02/how-to-move-wsus-from-one-server-to-another.aspx


    Regards, Yan Li

    Monday, November 18, 2013 7:32 AM

All replies

  • The question here really isn't about migrating the database, but really about migrating WSUS.

    There are two methodologies for "migrating" WSUS.

    There's the complex and complicated methodology described in the "Migration Guide", which includes backing up and restoring the database, and a lot of manual steps ...

    And there's the "replicate using the WSUS built-in replication" method.

    1. Ensure the WSUS v3.2 system has KB2734608 installed and is fully functional.
    2. Set synchronization on the WSUS v3.2 server to MANUAL.
    3. Install WSUS v6 on the new WS2012 (or WS2012 R2) system as a replica of the WSUS v3 server.
    4. Replicate. This may take a day or two depending on the number of approved updates and amount of files to transfer). I would strongly suggest performing Approval Maintenance and running the Server Cleanup Wizard on the WSUS v3.2 server before performing this replication. If the Server Cleanup Wizard times out on the WSUS v3.2 server, so will the attempt to replicate.
    5. After replication is complete, reconfigure the WSUS v6 server as an upstream server.
    6. RESET the Product Categories and Update Classifications on the WSUS v6 server to what they should be. (This should match what is configured on the WSUS v3.2 server.) NOTE: There is a **BUG** in the WSUS v6 server (actually it may also exist in a WSUS v3.2 server, but nobody has reported it) that incorrectly resets (or never records at all) the Product Categories and Update Classifications obtained from the upstream server during the replication.
    7. After resetting Product Categories and Update Classifications, perform a synchronization with Microsoft.
    8. After the successful synchronization with Microsoft, update Group Policy to point the WSUS clients to the new WSUS v6 server.
    9. After ALL clients have successfully REPORTED to the new WSUS v6 server, retire the WSUS v3.2 server.


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

    Friday, November 15, 2013 11:37 PM
  • Hi,

    As far as I know, we could first back up WSUS database on the source server and then restore the database on the desitination server, for more details please refer to the below article:

    http://technet.microsoft.com/en-us/library/hh852349.aspx

    The article not only point out how to use SQL to do migration, also talk about when using WID.

    In addition the below blog should be helpful for WSUS migration:

    How to move WSUS from one server to another

    http://blogs.technet.com/b/sus/archive/2009/07/02/how-to-move-wsus-from-one-server-to-another.aspx


    Regards, Yan Li

    Monday, November 18, 2013 7:32 AM
  • Thanks Lawrence and Yan Li,

    I have followed the methodology outlined by Lawrence successfully.

    Noteworthy on the database side:

    1a) It is necessary to use the SSMS from SQL Server Express 2012 to reposition the WID SUSDB (instance name \\.\pipe\MICROSOFT##\WID\tsql\query) to a path other than its default in this case. Attempting to install SQL Server Express 2008/R2 prompted me with compatibility concerns in Server 2012.

    1b) It is also necessary to mirror the permissions of the WID default user (MSSQL$MICROSOFT##WID) path on the new target path.

    2) Allowing the new database to populate itself on the new target WSUS server results in a cleaner database than moving the original database, due to whitespace, purged updates, etc. Planning to run a shrink on the original WID SUSDB once I've decommissioned the existing server just for grins and to see how much space is typically recoverable on a box that's been hosting WSUS for (5) years.

    FOLLOWUP QUESTION: When removing the upstream/downstream relationship from the new (and old) servers, I get a warning about "This will remove rollup information." I have already set the old server as a downstream and the new one as updating directly from Microsoft. OK to disregard this dialog or is there a recommended take-down procedure?

    Many Thanks!

    -Tom W.


    JTW

    Thursday, December 26, 2013 4:21 PM
  • Attempting to install SQL Server Express 2008/R2 prompted me with compatibility concerns in Server 2012.

    SQL Server Express Edition is a wholly inappropriate edition to use for WSUS in any case due to its CPU/RAM throttling which will severely impair the performance of a WSUS database when compared with deployment using the Windows Internal Database (which does not have any CPU/RAM throttling).

    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, December 31, 2013 12:53 AM
  • FOLLOWUP QUESTION: When removing the upstream/downstream relationship from the new (and old) servers, I get a warning about "This will remove rollup information." I have already set the old server as a downstream and the new one as updating directly from Microsoft. OK to disregard this dialog or is there a recommended take-down procedure?

    This is a transient condition and you can safely ignore the warning. Once the new server(s) are operational the current client state information will be rolled up to the upstream server and reporting will be fully functional as it was prior to the conversion.

    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, December 31, 2013 12:55 AM
  • Understood. I was only talking about the Management Studio, not using SQL Express itself for WSUS. The Studio is necessary in order to detach the WID database and attach a copy of it on a different volume. This seems to be the way to move WID to a path other than its default. We had limited space on C: and ample on D: was the impetus for this.

    Everything has been working great with no hiccups since all of these procedures.


    JTW

    Monday, April 28, 2014 6:38 PM
  • Understood. I was only talking about the Management Studio, not using SQL Express itself for WSUS.

    Semantics are everything in written communications. :-)

    As for the "compatibility" concerns.... those are raised because the initial installation is not at the correct service pack level and the installer checks the OS version (and Windows v6.2 and newer don't make the grade).

    SQL Server 2008 R2 is supported on Windows Server 2012. Install the product; ignore the compatibility warning; install the appropriate service pack and cumulative update.


    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.


    Thursday, May 01, 2014 3:45 PM