MOSS – 32 bit and 64 bit servers Upgrade to SharePoint 2010

TechNet article here     Upgrade Center here

You must have same server level (32bit or 64bit) in all tiers, (A tier is a grouping of servers that provide similar services that cannot be broken apart from the perspective of end-user serviceability)  you cannot have 1 WFE in 32bit and the other one 64bit. But you could have a separate search server in 64 bit. That has prompted many people to move to a new farm with a fresh windows/sql/sharepoint install.

Switching SQL Server boxes is easy if you use TCP/IP. If your SQL box is in 32 bit mode, build a new 64 bit box and use a DNS Alias. It basically just involves installing the SQL Server 64 bit, 2005, 2008 or 2008 R2 version and configuring a DNS Alias to point to your old name new SQL Server and shut off your old box. Microsoft now recognizes this as a supported configuration for SharePoint.

To move the WFE to a new server, add the new server into the existing farm, transfer per tenant roles to that server and then remove the existing server from the farm. There are other approaches (such as building out a new farm and migrating the content databases over) but this involves a lot more configuration. 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 (Office SharePoint Server) (http://go.microsoft.com/fwlink/?LinkID=119403&clcid=0x409). 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.

If you have Win 2003 R2 64 Bit, Upgrade to Microsoft Office SharePoint Server 2007 Service Pack 2. Then, install Windows Server 2008 R2.

Preferred method to migrate a 32-bit SharePoint environment to 64 bit SharePoint 2010

Since you are running on 32-bit environment you will have to use the "Database Attach" upgrade method to migrate to a new farm. A database attach upgrade enables you to move your content to a new farm or new hardware i.e. you can move your MOSS 2007 sites from a 32-bit environment to a 64-bit environment. Once you attach the database into MOSS 2010 environment the database gets updated for the 64-bit environment and you are good to go

The Whole Article from Technet is below

DCSIMG

<a href="http://www.omniture.com&quot; title="Web Analytics"> <img src="//msstonojstechnet.112.2o7.net/b/ss/msstonojstechnet/1/H.20.2–NS/0" height="1" width="1" border="0" alt="" /></a>

HomeLibraryWikiLearnDownloadsSupportForumsBlogs

Sign out |United States – English ||

Microsoft TechNet

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

Updated: 2010-10-14

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

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

Prerequisites, constraints, and known issues in the following areas apply to the deployment of Microsoft Office SharePoint Server in a 64-bit environment.

SharePoint software updates and service packs

Update Office SharePoint Server 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 (Office SharePoint Server)2 (http://go.microsoft.com/fwlink/?LinkID=119403&clcid=0x409). 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 SharePoint Server on a computer running Windows Server 2008, you must install Office SharePoint Server with SP1.

For Office SharePoint Server you can create a slipstream installation that contains SP1. For more information, see:

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:

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.

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 later) for Windows SharePoint Services 3.0 and Office SharePoint Server 2007.

NoteNote:

The Microsoft Filter Pack works with a variety of search products, including Office SharePoint Server 2007. The filter pack provides IFilters that enable search to crawl files that are in Microsoft Office formats such as .pptx and .docx into the index.

Indexing IBM Lotus Notes

You cannot crawl an IBM Lotus Notes database in a 64-bit Office SharePoint Server 2007 environment because IBM does not provide a 64-bit version of the Lotus Notes APIs.

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

Office SharePoint Server farms 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 two application servers. One server is for site administration and search querying (AppA-32, AppA-64); the second server is for search indexing (AppB-32, AppB-64).

  • Tier 3-A and 3-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

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 SharePoint Server

Office SharePoint Server 2007 with latest cumulative update installed

Office SharePoint Server 2007 with latest cumulative update installed.

Referring to the preceding table, note the following:

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:

  1. 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.

  2. Tier 2-A: Test the new database server and then migrate the existing application servers to the new farm.

  3. Tier 1-A: Test the application servers 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.

Before you begin

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

Obtain updated reference material

Obtain a copy of Move all databases (Office SharePoint Server 2007)9 (http://go.microsoft.com/fwlink/?LinkID=118325&clcid=0x409). 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 (Office SharePoint Server 2007)9 (http://go.microsoft.com/fwlink/?LinkID=118325&clcid=0x409) to ensure that you have the correct permissions for using Office SharePoint 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 Deploy a simple farm on the Windows Server 2008 operating system (Office SharePoint Server)10 (http://go.microsoft.com/fwlink/?LinkId=145932&clcid=0x409) 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).

    ImportantImportant:

    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.

    NoteNote:

    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 Office SharePoint Server 2007 and by stopping Internet Information Services (IIS).

  2. Use SQL Server 2005 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. Reattach the databases to the new database server.

  9. Restart the AppA-32 application server to apply the changes and ensure that the services, Web sites, and application pools associated with Office SharePoint Server 2007 are started.

  10. Configure all the servers on Farm A to point to DB-64.

  11. Restart Farm A.

  12. 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.

NoteNote:

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
  1. Use the Stsadm operation to do a full backup of all the SSPs on AppA-32.

  2. Delete all the SSPs from Farm A.

  3. Completely stop Farm A by stopping the services associated with Office SharePoint Server 2007 and by stopping Internet Information Services (IIS).

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

    • All content databases

    • Central Administration content database

    • Windows SharePoint Service Help search database

  5. 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.

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

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

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

  9. Run the Stsadm renameserver operation on AppA-32 to rename the database server in Farm B.

  10. Restart the AppA-32 application server to apply the changes and ensure that the services, Web sites, and application pools associated with Office SharePoint Server 2007 are started.

  11. Restore the SSPs on AppA-32 using Stsadm restoressp. For more information, see Backup and restore: Stsadm operations (Office SharePoint Server)11.

  12. Add all of the restored SSPs to Farm A.

  13. Set the new default SSP and then delete the original default SSP.

  14. Configure all the servers on Farm A to point to DB-64.

  15. Restart Farm A.

  16. 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, AppB-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
  1. Prepare the front-end Web Servers for Farm B, but do not add them to the farm.

  2. Use the Stsadm operation to perform a full backup of all the SSPs on AppA-32.

  3. Delete all the SSPs from Farm A by issuing the following command:

    stsadm -o deletessp -title SharedServices -force

  4. Completely stop Farm A by stopping the services associated with Office SharePoint Server 2007 and by stopping Internet Information Services (IIS).

  5. 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.

  6. 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.

  7. Copy all the backup files to AppA-64.

  8. Start AppA-64 to apply the changes and ensure that the services, Web sites, and application pools associated with Office SharePoint Server 2007 are started.

  9. 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.

  10. Restore the SSPs on AppA-64 using Stsadm –o restoressp with the [keepindex] option.

  11. Add all of the restored SSPs to Farm B.

  12. Set the new default SSP and then delete the original default SSP.

  13. Restart Farm A.

  14. 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, AppB-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.
  1. Completely stop Farm A by stopping the services associated with Office SharePoint Server 2007 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 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

  • Application servers: AppA-64, AppB-64

  • Database server: DB-64

Links Table

1http://technet.microsoft.com/en-us/library/dd630764(v=office.12).aspx

2http://technet.microsoft.com/en-us/library/cc262485(v=office.12).aspx

3http://technet.microsoft.com/en-us/library/cc261890(v=office.12).aspx

4http://go.microsoft.com/fwlink/?LinkID=139512&clcid=0x409

5http://go.microsoft.com/fwlink/?LinkId=145881&clcid=0x409

6http://go.microsoft.com/fwlink/?LinkId=145916&clcid=0x409

7http://go.microsoft.com/fwlink/?LinkID=133362&clcid=0x409

8http://go.microsoft.com/fwlink/?LinkID=121886&clcid=0x409

9http://technet.microsoft.com/en-us/library/cc512725(v=office.12).aspx

10http://go.microsoft.com/fwlink/?LinkId=145932&clcid=0x409

11http://technet.microsoft.com/en-us/library/cc263431(v=office.12).aspx

Community ContentAdd

AnnotationsFAQ

Step by Step Migration Edit

In the real world moving the whole tier and hoping that everything goes well may never happen. So the more practical way would be introducing 64 Bit Servers making sure everything works fine and than retiring 32 bit servers.
Though as per comment above it is supported but not recommended due to some performance risks. But I haven’t found the details regarding those risks and what can be done to mitigate the risks because realistically I am left with step by step aproach but it seems like it is not the recommended aproach.
So please suggest what should be a plan for upgrade in the real world scenario.
Thanks,
Preet