Migrate an existing server farm to a 64-bit environment (Windows SharePoint Services 3.0)

Applies To: Windows SharePoint Services 3.0

Topic Last Modified: 2009-05-08

To upgrade Windows SharePoint Services 3.0 to a 64-bit environment, you must migrate existing servers to a new farm. You cannot upgrade Windows SharePoint Services 3.0 directly from the 32-bit edition of Windows SharePoint Services 3.0 to the 64-bit edition.

You must determine which migration strategy is appropriate for your environment. This article provides instructions for a clean migration — in phases — of a SharePoint farm to servers in a 64-bit environment. For information about the advantages of a 64-bit environment, see Advantages of 64-bit hardware and software (Windows SharePoint Services 3.0).

You can migrate an existing farm to a 64-bit environment in several ways; for example, by adding 64-bit servers to an existing farm and then removing the 32-bit servers. The phased approach described in this article is designed to mitigate possible performance issues. A phased approach also spreads out the periods of downtime required for a migration and enables you to perform the appropriate level of testing after farm servers are migrated.

Service is disrupted during the migration so you must plan the migration and conduct the migration during a time that has the least impact on users.

This article contains the following sections:

• Constraints and known issues

• Before you migrate your farm

• Migrate servers to a 64-bit environment

Constraints and known issues

Prerequisites, constraints, and known issues in the following areas apply to the deployment of Windows SharePoint Services 3.0 in a 64-bit environment.

SharePoint software updates and service packs

Update Windows SharePoint Services 3.0 to the same service pack or software update level on all computers in both the source and destination farms. This is necessary to prevent potential post-migration errors that can occur if software versions are not the same on all the servers.

If your migration goal also includes crossing operating system or database versions, we recommend that you identify and install any public updates released and installed on Windows Server 2003 and Microsoft SQL Server 2005 that also apply to Windows Server 2008 and Microsoft SQL Server 2008.

Existing applications

You must recompile existing 32-bit applications and custom assemblies (for example, Web Parts and event receivers) to run on the 64-bit architecture because the 64-bit edition of SharePoint cannot load a 32-bit assembly. Before you recompile existing applications or custom assemblies, verify that they are compiled to run on both architectures. If this is the case, do not compile them for a single architecture. (In Microsoft Visual Studio this build option is AnyCPU.)

If the existing applications are third-party applications, check with the third-party vendor regarding 64-bit versions and compatibility. In the case of custom contracted solutions for which you do not have the source, verify the solutions in a test 64-bit environment to ensure compatibility.

Maintaining homogenous servers on each tier in the farm

As a best practice, we recommend that you maintain homogenous servers on each tier during migration. A tier is a grouping of servers that provide similar services that cannot be broken apart from the perspective of end-user serviceability. For example, load-balanced front-end Web servers that service user requests constitute a tier, but a SharePoint index server on which the Web application service runs is not considered a part of that tier.

If you follow the procedures in this document, each tier will contain servers that have the same architecture.

If you choose to migrate your servers to a 64-bit environment by simply adding 64-bit servers to an existing farm, you cannot always maintain homogenous servers on each tier and thus might experience poor or inconsistent performance. These issues are identified in Determine hardware and software requirements (Windows SharePoint Services). This approach (migration by adding 64-bit servers to an existing farm) is supported, but we do not recommend it for farm migration because of the potential performance risks associated with mixing architectures in a tier.

Windows Server 2008

To install Windows SharePoint Services 3.0 on a computer running Windows Server 2008, you must install Windows SharePoint Services 3.0 with SP1 or a subsequent update.

You can download a slipstream version of Windows SharePoint Services 3.0 that includes SP1. See Windows SharePoint Services 3.0 Service Pack 1 (SP1) (https://go.microsoft.com/fwlink/?LinkID=105655) for more information.

Windows SharePoint Services 3.0 installed on Windows Server 2008

There is a known issue Windows SharePoint Services 3.0 where sites that are running on Windows Server 2008 time out when you try to upload a large file to a SharePoint site. For more information, see:

• MVP Shane Young's blog post, Windows Server 2008 WFE will not allow large file uploads (https://go.microsoft.com/fwlink/?LinkId=145881)

• KB article 925083, Error message when you try to upload a large file to a document library on a Windows SharePoint Services 3.0 site: "Request timed out" (https://go.microsoft.com/fwlink/?LinkId=145916)

IFilters and extensions

Most, but not all, IFilter components and extensions support 64-bit. Verify that your 32-bit iFilters and extensions work in a 64-bit environment. If you are using a third-party filter that does not support 64-bit, follow up with the vendor and obtain a compatible filter and instructions on how to install it.

To avoid a known issue with the Visio filter in a 64-bit environment if you are using the Microsoft Filter Pack, you must install the December cumulative update (or a subsequent update) for Windows SharePoint Services 3.0.

Before you migrate the farm

Before you migrate the farm, review the example farm topology model and the strategy that we recommend for migrating a multiple tier farm from one environment to another. This migration strategy is designed to provide the cleanest possible migration for this type of farm topology.

Farm topology

The following figure shows the farm topology used for the source (Farm A) and destination (Farm B) farms. This topology is representative of farms that have SharePoint roles installed on several servers. For ease of reference, the servers in each farm are grouped as tiers, based on their tier.

Farm topology for migration

In the previous figure, note the following:

• Tier 1-A and 1-B consists of two load-balanced front-end Web servers (WebA-32 and WebB-32, WebA-64 and WebB-64).

• Tier 2-A and 2-B consists of one database server (DB-32, DB-64).

The following table lists the software installed on the servers in each farm.

Software installed on farm servers

Referring to the preceding table, note the following:

• As a best practice, we recommend that you update the operating system on the destination servers with any hotfixes that are common to Windows Server 2003 and Windows Server 2008.

• You cannot install Windows SharePoint Services 3.0 on a server core installation of Windows Server 2008.

• The migration described in this document supports any version and patch level of SharePoint (RTM to the latest service pack or software update). We recommend that you consider patching SharePoint at least to the level of the latest service pack or Infrastructure Update, whichever is the most recent. The Infrastructure Update includes several updates for SharePoint Products and Technologies. For more information about this specific update, see the following Knowledge Base articles:

  • Description of the Infrastructure Update for Windows SharePoint Services 3.0: July 15, 2008 (https://go.microsoft.com/fwlink/?LinkID=133362)

Migration strategy

The strategy is to migrate and test the farm servers in separate phases for each tier in the farm in the following sequence: Begin WSS only

1. Tier 2-A: Migrate the existing database server to the new database server. This tier is done first to mitigate any potential performance issues that might occur if a 64-bit system is querying or writing to a 32-bit database server. The following options are available:

   • Keep the same host server name on the destination server that you have on the source server.

   • Change the host server name on the destination server. This is the database migration option used in this article.

2. Tier 1-A: Test the migrated database server and then add the 64-bit front-end Web servers to the new farm.

The preceding systematic approach is not mandatory, but we strongly recommend it because it provides an environment for migration and testing that ensures the cleanest possible migration. The benefits are minimization of unexpected results, such as missing files and corrupt data, and the ability to effectively manage service downtime during migration.

Migrating servers to 64-bit environment

You can use the steps in this section to migrate to a farm that has any of the following operating systems and databases installed:

• The 64-bit version of Windows Server 2003

• The 64-bit edition Windows Server 2008

• The 64-bit version of SQL Server 2005

• The 64-bit version of SQL Server 2008

From a migration perspective, the notable differences between these operating systems and databases lies in the preparation of the destination servers.

Read the following section before conducting Phase 1 (back-end databases), and Phase 2 (front-end servers) of the migration.

Before you begin

Before you start a farm migration you must complete the following tasks:

• Obtain updated reference material

• Document your farm configuration

• Identify and document required accounts and permissions

• Prepare the destination farm

Obtain updated reference material

Obtain a copy of Move all databases (Windows SharePoint Services 3.0). This topic contains comprehensive instructions, including SQL Server and Stsadm commands for moving a SharePoint database server. These instructions cover the following scenarios:

• Moving a database to a new database server that has the same name

• Moving a database to a new database server that has a different name

Document your farm configuration

Some elements of a farm must be migrated manually. Ensure that you have documented the following:

• The Web applications associated with SSPs

• Customized master pages and other pages

• Other customized content

• Features

• Custom applications and compiled DLLs

• Any other customized farm elements

Identify and document required accounts and permissions

In order to work on the source and destination servers, refer to Move all databases (Windows SharePoint Services 3.0) to ensure that you have the correct permissions for using Windows SharePoint Services 3.0 tools, Microsoft SQL Server database tools, and operating system commands.

Prepare the destination farm

The following preparation work is required for the application and database servers on the destination farm:

• Apply the appropriate operating system updates to the servers.

• Use Deploy a simple farm on the Windows Server 2008 operating system (Windows SharePoint Services) as a reference for configuring SQL Server and deploying SharePoint on Windows Server 2008.

• Install either SQL Server 2005 or SQL Server 2008 on the database server.

• Use the SharePoint Products and Technologies Configuration Wizard to complete a basic installation of SharePoint on AppA-64. When you finish, you will have a new farm with two application servers (AppA-64 and AppB-64) and a database server (DB-64).

  Important

  Do not give the new content databases the same name as the content databases on the source farm. You cannot share content databases between two SharePoint farms.

Phase 1: Migrate the back-end databases

During this phase, you migrate the back-end databases by using one of the following procedures:

• Move the database to a host server that has the same name.

• Move the database to a host server that has a different name.

  Note

  You change the name of a SharePoint database server, but you cannot change the instance name. For example, DB-32\sharepoint can be renamed to DB-64\sharepoint, but DB-32\sharepoint cannot be renamed to DB-32\sharepoint2.

The following procedure requires a full backup of the content databases.

Move the database to a host server that has the same name

1. Completely stop Farm A by stopping the services associated with Windows SharePoint Services 3.0 and by stopping Internet Information Services (IIS).

2. Use SQL Server 2005 (SP2) tools to back up all the SharePoint databases on the source database server (DB-32).

3. Shut down the source database server (DB-32).

4. Copy all the backup files to a server share folder that is not part of Farm A or Farm B. This share folder provides a restoration point for all the critical SharePoint files.

5. Copy the database backup files to the destination database server.

6. Restore the databases from DB-32 to DB-64 by using SQL Server 2008 tools.

7. Copy all the SQL Server logins, fixed server roles, fixed database roles, and permissions for the databases to the destination server (DB-64).

8. Restart the AppA-32 application server to ensure that the services, Web sites, and application pools associated with Windows SharePoint Services 3.0 are started.

9. Verify that all the servers on Farm A are correctly configured to point to DB-64 and can connect to the new database.

10. Restart Farm A.

11. Conduct the appropriate tests for your environment to ensure that Farm A is working with the new database.

Move the database to a host server that has a different name

1. Completely stop Farm A by stopping the services associated with Windows SharePoint Services 3.0 and by stopping Internet Information Services (IIS).

2. Use SQL Server 2005 tools to back up the following SharePoint databases on the source database server (DB-32):

   • All content databases

   • The configuration database

   • Central Administration content database

   • Windows SharePoint Service Help search database

3. Copy all the backup files to a server share folder that is not part of Farm A or Farm B. This share folder provides a restoration point for all the critical SharePoint files.

4. Copy the database backup files to the destination database server.

5. Restore the databases from DB-32 to DB-64 by using SQL Server 2008 tools.

6. Copy all the SQL Server logins, fixed server roles, fixed database roles, and permissions for the databases to the destination server (DB-64).

7. Run the Stsadm renameserver operation on WebA-32 to rename the database server in Farm B. This operation notifies SharePoint that the databases that were on DB-32 are now on DB-4.

8. Restart the WebA-32 application server and verify that the services, Web sites, and application pools associated with Windows SharePoint Services 3.0 are started.

9. Run the Stsadm renameserver operation on the rest of the farm servers and verify that they are correctly configured and connecting to DB-64.

10. Restart Farm A.

11. Conduct the appropriate tests for your environment to ensure that Farm A is working with the new database.

When you complete this phase your active farm has the following topology:

• Front-end Web servers: WebA-32, WebB-32

• Database server: DB-64

Phase 2: Migrate the front-end Web servers

During this phase, you complete the migration by adding 64-bit front-end Web servers to the farm. Use the following procedure to migrate the front-end Web servers.

Migrate the front-end Web servers.

1. Completely stop Farm A by stopping the services associated with Windows SharePoint Services 3.0 and by stopping Internet Information Services (IIS).

2. Start Farm B.

3. Add WebA-64 and WebB-64 to Farm B and configure them so that they are pointing to DB-64.

4. Conduct the appropriate tests for your environment to ensure that the destination farm is working.

When you complete this phase, the migration to a 64-bit environment is complete and your active farm has the following topology:

• Front-end Web servers: WebA-64, WebB-64

• Database server: DB-64