locked
Migrating WSS 3.0 to new server and upgrading to 64-bit Windows Server 2008 R2 and SQL server 2008 RRS feed

  • Question

  • Hi All,

    I have the following type of sharepoint:

    1. WSS 3.0 with Windows server 2003, SQL Server 2005 on Server A. 

    In this server, I have all user documents stored in user's document libraries (~ 11K libraries).  

    2.  WSS 3.0 SP2 with Language pack German with Windows Server 2003 on Server B and Content DB on Server C where it has  SQL Server 2005 with Windows Server 2003. 

         In Server B, I allow users to create their own sites, blogs, forums and with all customized lists. 

     

    Now we want to move our servers and optimize all Sharepoints into a single server and one SQL server. The new environment has the following: 

    1. Windows Server 2008 R2 with SQL Server 2008 R2  (Server E)

    2. Windows Server 2008 R2 with WSS 3.0 SP2 with Language pack German (Server D)

    When we move migrate to the new environment I got several questions. 

    a) When I move WSS 3.0 from Server A to Server D, do I need Admin_Content DB and WSS_Content DB backups to be restored on new server. As I have all documents in the document libraries, do I still need WSS_Content DB restore on new server.

    b) When I move WSS 3.0 from Server B to Server D, here also I will have Admin_Content DB and WSS_Content DB backups. Here I need the WSS_Content DB as all blog, forums related stuff stored in WSS_Content. Do I need the Admin_Content DB restored on new server.

    Do we need Central Admin Content DB restored on new server? If we need the Central Admin Content DB only for Configuration reasons, I will do the configurations manually. Still are there any other reasons that the central admin DB to restore?

    Any ideas and experiences, please share!

     

    Thanks in advance.

     

     

     

     

     

    Monday, December 5, 2011 11:23 AM

Answers

  • The Admin_Content DBs contain farm configuration information. This would be the type of configuration that you would perform through Central Administration or using the stsadm command line tool. You would only need to move this to the new environment if you had complex configuration done through Central Administration or stsadm, but 99.99% of the time, it's far easier to just perform this configuration again manually in the new environment. Configuration items such as server names, database locations etc are stored in these databases, so migrating them to the new environment would be a lot of effort for very little gain.

    The WSS_Content DBs are the databases that will hold all the content from your two web applications, including all of the site collections, sites, lists, libraries and their contents. These are the important things to move across.

    The easiest thing to do is to just back up both content databases and restore them both onto the new SQL Server, note that if they both currently have the same name, you'll need to restore one with a different name so that they can both coexist on the new server. Then for each of your current applications use Central Administration to create a new web application on the new environment, and connect it to the relevant content database that you restored onto the new SQL Server. If you want your sites to keep the same URLs you can specify the correct port and host header when creating the web application to have that URL (you can also do it later via IIS bindings and AAM, but much easier to do it when you create the web app), and then use DNS to point people to the new server when you're reasy to go live.

    Because this method gets you running on the new environment without taking down the old one, it lets you do a trial run to make sure it all works ok before doing a "go live" change over. So I always recommend to do this first and do plenty of testing to make sure everything works. Then when you're happy with everything set your current live environements to read-only (to ensure that nobody changes anything while you migrate), do the backup/restore of your Content DBs again, then change DNS to get everybody working on the new environment. I'd also recomend taking your old environment offline as soon as the new environment is available to everyone, there will always be someone with some funny DNS issue who ends up getting pointed at the old server, you don't want to have them editing out of date content on the wrong environment.

     

    • Marked as answer by rockthis Tuesday, December 6, 2011 2:27 PM
    Monday, December 5, 2011 12:01 PM