Migrate an existing server farm to a 64-bit environment (Project Server 2007)

Artículo
01/10/2017

This Office product will reach end of support on October 10, 2017. To stay supported, you will need to upgrade. For more information, see , Resources to help you upgrade your Office 2007 servers and clients.

Topic Last Modified: 2016-11-14

To upgrade Microsoft Office Project Server 2007 to a 64-bit environment, you must migrate existing servers to a new farm. You cannot upgrade Office Project Server 2007 directly from the 32-bit edition of Office Project Server 2007 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 Project Server 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 (Project Server 2007).

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 Office Project Server 2007 in a 64-bit environment.

Project Server and Windows SharePoint Services software updates and service packs

Since Windows SharePoint Services 3.0 is installed with Office Project Server 2007, update both 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 Project Server 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 (front-end Web Servers, Project application servers, Project database servers).

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 (Project Server). 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 Office Project Server 2007 on a computer running Windows Server 2008, you must install Office Project Server 2007 with SP1 or later.

For Office Project Server 2007 you can create a slipstream installation that contains SP1 or later. For more information, see:

Create an installation source that includes software updates (Project Server 2007)
Dan Winter's article, How to create a SharePoint slipstream using the latest updates (https://go.microsoft.com/fwlink/?LinkID=139512\&clcid=0x409) also provides information about creating a slipstream version of Microsoft Office SharePoint Server.

Important

When planning to migrate your Office Project Server 2007 farm to a 64-bit environment, we highly recommend migrating to Windows Server 2008 64-bit (as opposed to Windows Server 2003 64-bit). By migrating to the newer version of Windows server, you are in a better position to make an easier transition to any upgrade to Office Project Server 2007. Future versions of Project Server and other Office Server applications may require operating systems that are newer than Windows Server 2003.

Windows SharePoint Services 3.0 installed on Windows Server 2008

There is a known issue in 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. Since Windows SharePoint Services 3.0 installs Office Project Server 2007, you should take this into consideration. 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\&clcid=0x409)
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\&clcid=0x409)

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. For ease of reference, the servers in each farm are grouped as tiers, based on their tier.

Farm topology for migration

Migration to 64-bit topology

In the previous figure, note the following:

Tiers 1-A and 1-B consist of two load-balanced front-end Web servers (WebA-32 and WebB-32, WebA-64 and WebB-64).
Tiers 2-A and 2-B consist of a single Project application server (AppA-32 and AppA-64).
Tiers 3-A and 3-B consist 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

Software	Farm A (32-bit)	Farm B (64-bit)
Operating system	Windows Server 2003, SP2	Windows Server 2008
Database	SQL Server 2005, SP2	SQL Server 2008
Office Server applications	Office Project Server 2007 with the latest service pack and cumulative update installed	Windows SharePoint Services 3.0 with the latest service pack and cumulative update installed

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 Office Project Server 2007 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 Office Project Server 2007 and Windows SharePoint Services 3.0 at least to the level of the latest service pack.

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:

Tier 3-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. 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.
Tier 2-A: Test the new database server and then migrate the existing application server to the new farm.
Tier 1-A: Test the application 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), Phase 2 (application servers), and Phase 3 (front-end servers) of the migration.

Important

As mentioned previously, when planning to migrate your Office Project Server 2007 farm to a 64-bit environment, we highly recommend migrating to Windows Server 2008 64-bit (as opposed to Windows Server 2003 64-bit).

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 Migrate Project Server data from one farm to another. 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 (Project Server 2007) to ensure that you have the correct permissions for using Office Project Server 2007 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 Install Project Server 2007 in Windows Server 2008 (single-server installation) as a reference for configuring SQL Server and deploying Project Server on Windows Server 2008.
Install SQL Server 2008 on the database server.
Complete a farm installation of Project Server on AppA-64. When you finish, you will have a new farm with one Project application servers (AppA-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 Project Server 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 Project Server database server, but you cannot change the instance name. For example, DB-32\projserv can be renamed to DB-64\projserv, but DB-32\projserv cannot be renamed to DB-32\projserv2.

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

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

Completely stop Farm A by stopping the services associated with Office Project Server 2007 (Microsoft Office Project Server Queuing and Events services) and by stopping Internet Information Services (IIS).
Use SQL Server 2005 tools to back up all the SharePoint databases on the source database server (DB-32).
Shut down the source database server (DB-32).
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 Project Server files.
Copy the database backup files to the destination database server.
Restore the databases from DB-32 to DB-64 by using SQL Server 2008 tools.
Copy all the SQL Server logins, fixed server roles, fixed database roles, and permissions for the databases to the destination server (DB-64).
Reattach the databases to the new database server.
Restart the AppA-32 application server to apply the changes and ensure that the services, Web sites, and application pools associated with Office Project Server 2007 are started.
Configure all the servers on Farm A to point to DB-64.
Restart Farm A.
Conduct the appropriate tests for your environment to ensure that Farm A is working with the new database.

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

Note

Backing up and restoring SSPs is not required if a farm is using a SQL Server alias to connect to the SQL Server database.

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

Use the Stsadm operation to do a full backup of all the SSPs on AppA-32.
Delete all the SSPs from Farm A.
Completely stop Farm A by stopping the services associated with Office Project Server 2007 (Microsoft Office Project Server Queuing and Events services) and by stopping Internet Information Services (IIS).
Use SQL Server 2005 tools to back up the following databases on the source database server (DB-32):
- All content databases
- Central Administration content database
- Project Server databases (Archived, Draft, Published, and Reporting)
- Windows SharePoint Service Help search database (if you are using Windows SharePoint Services Search)
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 files.
Copy the database backup files to the destination database server.
Restore the databases from DB-32 to DB-64 by using SQL Server 2008 tools.
Copy all the SQL Server logins, fixed server roles, fixed database roles, and permissions for the databases to the destination server (DB-64).
Run the Stsadm renameserver operation on AppA-32 to rename the database server in Farm B.
Restart the AppA-32 application server to apply the changes and ensure that the services, Web sites, and application pools associated with Office Project Server 2007 are started.
Restore the SSPs on AppA-32 using Stsadm –restore with the [keepindex] option.
Add all of the restored SSPs to Farm A.
Set the new default SSP and then delete the original default SSP.
Configure all the servers on Farm A to point to DB-64.
Restart Farm A.
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
Application servers: AppA-32
Database server: DB-64

Phase 2: Migrate the application servers

During this phase you backup and restore SSPs. During this phase you can copy the farm elements that you documented in Document your farm configuration to a location on the server share you created in Phase 1. Use the following procedure to migrate the application servers.

Migrate the application servers

Prepare the front-end Web Servers for Farm B, but do not add them to the farm.
Use the Stsadm operation to perform a full backup of all the SSPs on AppA-32.
Delete all the SSPs from Farm A by issuing the following command:

stsadm -o deletessp -title SharedServices -force
Completely stop Farm A by stopping the services associated with Office Project Server 2007 and by stopping Internet Information Services (IIS).
Copy farm elements that need to be moved manually from the server share to locations on Farm B (WebA-64, WebB-64, and AppA-64) that correspond to their locations on Farm A.
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.
Copy all the backup files to AppA-64.
Start AppA-64 to apply the changes and ensure that the services, Web sites, and application pools associated with Office Project Server 2007 are started.
Configure AppA-64 to point to the content databases restored from Farm A and use SQL Server 2008 tools to delete the original content databases that were created when you built Farm B, from DB-64.
Restore the SSPs on AppA-64 using Stsadm –restore with the [keepindex] option.
Add all of the restored SSPs to Farm B.
Set the new default SSP and then delete the original default SSP.
Restart Farm A.
Conduct the appropriate tests for your environment to ensure that the source farm is working with the new application servers and the database.

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

Front-end Web servers: WebA-32, WebB-32
Application servers: AppA-64
Database server: DB-64

Phase 3: 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.

Completely stop Farm A by stopping the services associated with Office Project Server 2007 and by stopping Internet Information Services (IIS).
Start Farm B.
Add WebA-64 and WebB-64 to Farm B and configure them so they are pointing to DB-64.
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
Application servers: AppA-64
Database server: DB-64

Compartir a través de