share point upgrade methodology - white paper

8/3/2019 Share Point Upgrade Methodology - White Paper

http://slidepdf.com/reader/full/share-point-upgrade-methodology-white-paper 1/8

White Paper

SharePoint 2010 Upgrade MethodologyBy: Tom Castiglia & Tony Rockwell

of 8 October 17, 2011

SharePoint Upgrade Methodology

Unlike many software applications, SharePoint is not a product, but rather a sophisticated platform for

building and hosting a variety of different business applications. This makes SharePoint a powerful and

flexible system that organizations rely upon as a mission-critical part of their IT infrastructure.

It also makes the process of upgrading an existing MOSS or WSS farm to SharePoint 2010 more complex

than most applications or other server products from Microsoft.

Purpose

The purpose of this document is to explain the necessity and value of careful planning and testing

before upgrading a MOSS 2007 or WSS 3.0 farm to SharePoint 2010.

The information gathered during the planning and testing stage will help assess the overall time,

complexity and costs associated with performing the upgrade.

SharePoint Upgrade Planning Checklist

The following checklist will help with the upgrade planning and testing process:

Document Farm and Setup accounts & passwords

Document farm architecture & components (include server names & IP address)

o SharePoint Web Front End servers (Qty & services running on each)

o SharePoint Application servers (Qty & services running on each)o SharePoint Index servers (Qty & services running on each)

o SharePoint Database servers (Qty & services running on each)

o Identify server details (for each server listed above)

OS & version

CPU (32-bit/64-bit)

RAM

Identify the IIS version and any special settings

Identify the .NET version

Local disks or SAN

Define any Extranet or External sites or connections

List all solutions installed (free, 3rd party, or Microsoft provided but not default OOTB)

List all custom features or web parts (not installed as solutions)

List any customizations including custom applications or integration with other systems

Identify any custom branding, themes or style sheets

If Reporting Services is being used, list # of reports & details of report servers

Capture configuration details of SSP’s



White Paper



List each SharePoint Web Application & port used

List all SharePoint Site Collections

Document Content Databases – list each by name & include size List any libraries or lists using custom forms

o Identify any InfoPath forms in use

List any Business Data Catalog usage or connections to external data

Identify system criticality, down-time restrictions, and business expectations

Identify key contacts for system/network access, dba, business and project leads

List all Workflows – custom, SPD, 3rd party, and standard SharePoint workflows

Indicate the number of audiences and how they are being used.

Extensibility and Customization

A typical production MOSS 2007 or WSS 3.0 farm contains many customized features and solutions, such

as branding elements (master pages, page layouts, themes and CSS), web parts, workflow, site

definitions, web pages, etc. These customizations are generally developed using SharePoint Designer

and/or Visual Studio and are provided by developers from internal IT staff, outside consultants and 3rd

party components that are purchased off-the-shelf.

The extensibility framework and large ecosystem for custom and 3rd party solutions is what makes

SharePoint such a powerful tool.

Most customizations will work properly in SharePoint 2010; however, some may not be as simple.

Inventory all customizations

In the early planning stages of a SharePoint 2010 upgrade, it is important to inventory all

customizations. There are three main sources of customizations to look out for:

1. 3rd party components

2. Customizations created by the IT staff

3. Customizations created by an outside consultant

For “proper” customizations that were deployed as a “Solution”, some of this information is readily

available in SharePoint’s Central Admin, under Operations>Solution Management (see figure 1 below).

This screen will display a list of all deployed solutions including which web application(s) they are

deployed to. This information can be used to start your inventory of customizations; however,

additional information about each solution is necessary for planning purposes:

Is the solution actually being used?

What type of customization does the solution contain?

What is the installation procedure for the solution?



White Paper



Who created the solution (and who supports it)?

How to regression test the solution.

Typically, research is needed by a SharePoint administrator to properly document this information. The

SharePoint administrator may find only a small percentage of the many solutions deployed are actually

in use. Removing solutions that are not being used, will simplify the upgrade process dramatically.

In addition to the “properly deployed” solutions, many production SharePoint servers have various

ad-hoc customizations created in SharePoint Designer and in some cases unofficial (“rogue”) web parts

or other modules that were deployed without using SharePoint’s solution framework. While these

customizations are more difficult to track down, it is important to identify all customizations for

inclusion in the inventory.

The completed inventory of customizations will help determine the overall complexity of the pending

upgrade.

Create a SharePoint Test Farm

Due to the extensive level of customizations found in most production SharePoint farms, it is highly

recommended that all organizations maintain a SharePoint test farm that mimics the production farm as

close as reasonably possible. A test environment is needed to accurately test the deployment of

services packs and cumulative updates on your MOSS or WSS farm as well as for planning an upgrade to

SharePoint 2010.



White Paper



The test farm should be running the same version of SharePoint and use the same versions of Windows

OS and SQL Server as the production environment. However, it is not critical to match the number of servers in your production farm. For example, if a SharePoint farm contains multiple web front end

(WFE) servers, it is typically fine to create a test farm with only one WFE server. In some cases, a test

farm can be staged on a single server combining multiple roles (WFE, SQL, APP). The most common

scenario is to have a two-server test farm, with one web front end and one database server running, SQL

Server 2008 R2.

When planning an upgrade from SharePoint 2007 to 2010, if a test farm does not exist, the first step is

to plan a test farm. The specific requirements for each test farm will vary depending on the projectbudget, the complexity of the production SharePoint farm and the type of upgrade that is planned (In-

Place vs. Database attach).

In addition to the inventory of customizations, the level of complexity to create a test environment will

depend on numerous factors, including:

1. Number of web applications, site collections and content databases

2. Size of content databases

3. Number of SSPs

4. SSP Content (Audiences, Search rules, Profile mappings and MySites)

Tip: Using a virtual server (VMWare or Hyper-V) is highly recommended for staging a SharePoint test

environment. This reduces hardware acquisition costs and provides the ability to create snapshots of

the test environment throughout the testing process. Should the testing process encounter a problem,

the server can be restored to a previous, known-good snapshot.

Pre-Upgrade Checker

With the release of Service Pack 2 for MOSS and WSS, SharePoint includes a specific utility called the

Pre-Upgrade Checker (technically, this utility is simply a new command available in STSADM).

The Pre-Upgrade Checker will compile a detailed report about the readiness of the SharePoint system tobe upgraded. If your existing SharePoint 2007 farm has SP2 installed, your administrator can run the

Pre-Upgrade Checker command at any time to identify any major issues with the current configuration.

The Pre-Upgrade Checker reports on data that is global to the entire farm as well as unique to the

current server, so this command should be run on every WFE or APP server in your SharePoint farm.



White Paper



The report produced by the Pre-Upgrade Checker identifies major “show stopping issues” that will

prevent the upgrade outright along with warnings of potential issues that may or may not be serious,

depending on any number of factors.

Note: The purpose of the Pre-Upgrade Checker is not to determine that your MOSS or WSS farm is

completely ready for an upgrade, but only that it is ready for detailed upgrade testing.

Preparing for the Pre-Upgrade Checker

Because the Pre-Upgrade Checker requires SP2, many organizations will need to first install this service

pack before they can run this tool on their production SharePoint server. Optionally, it is suggested to

also install the October 2010 Cumulative Update at this time as well. Although SP2 and the October

2010 CU are very reliable, it is suggested to deploy these updates in a test environment first and then

regression test the system to verify that the SP2 did not break or change existing functionality.

Once regression testing is complete, the same updates can be deployed to the production farm,

enabling you to actually run the Pre-Upgrade Checker.

Limitations of the Pre-Upgrade Checker

The Pre-Upgrade Checker however, may not catch every possible pitfall related to the upgrade. For

example, the Pre-Upgrade Checker cannot validate that every custom web part, workflow or other

custom solutions will behave the same way in SharePoint 2010 as it does in MOSS or WSS.

Hence the need for a test farm, where the upgrade process itself can be tested and any customizations

can be methodically regression tested after the upgrade installation is complete.

Resolving Errors and Warnings from the Pre-Upgrade Checker

In a perfect world, the Pre-Upgrade Checker will not report any errors in your production farm.

However, in most cases, at least a few errors are reported that must be addressed before upgrade

testing can begin. In many cases, the reported errors will have straight-forward solutions and can be

resolved quickly. But that may not always be the case.

Common Errors reported by the Pre-Upgrade Checker include:

Unsupported customizations (only those that will prevent the upgrade from completing)

Orphaned Objects

Invalid Configuration Settings

Unsupported Database requirements

Unsupported Hardware/operating system



White Paper



As each error or warning is resolved, you should re-run the Pre-Upgrade Checker to confirm that the

problem is no longer reported. You can run this command as many times as needed.

Depending on which upgrade approach you plan to use, some of the reported errors may not be

relevant. In some cases, you may use the results of the Pre-Upgrade Checker to determine which

upgrade approach to utilize.

Visual Upgrade

With the introduction of the Ribbon Bar, SharePoint 2010 introduces a major change in the fundamental

user interface design compared to MOSS and WSS. As a result, most custom branding elements from

SharePoint 2007, such as master pages, page layouts and CSS will not work as expected in SharePoint

2010.

The good news is that SharePoint 2010 provides an option called Visual Upgrade, which allows web site

owners to choose between two options:

1. Switch to the new SharePoint 2010 user interface

2. Retain the “look and feel” from SharePoint 2007

The Visual Upgrade option can be enabled for each Site Collection. When enabled, site owners can

choose either option for each site and SharePoint 2010 allows them to test the look and feel of the siteunder both options and then choose whichever one is preferred.

Retain the “look and feel” from SharePoint 2007

This will enable custom branding elements to continue to work as they did in MOSS or WSS. The benefit

of this approach is that no functionality available in SharePoint 2007 is lost. The downside is that some

SharePoint 2010 functionality will not be available in this mode (such as, the ribbon UI, in-place editing

for Wiki pages, interactive calendars, and list relationships).

Therefore, this option is intended only as a short term solution until the branding is updated or replaced

with branding that is compatible with SharePoint 2010 and this can be assessed during the overalltesting process.

Switch to the new SharePoint 2010 user interface

If the MOSS or WSS system has little or no custom branding, the Visual Upgrade option will not be used,

or if it is used then the new SharePoint 2010 UI will be selected soon after the upgrade.



White Paper



Additionally, sites with custom branding can still be briefly tested in this mode, and if the results are

acceptable then the new UI can be enabled permanently without any changes to the branding.

Select the Right Upgrade Approach

SharePoint 2010 supports two upgrade approaches: In-Place and Database Attach

In-Place

The In-Place approach is used when you want to upgrade the existing SharePoint servers to SharePoint

2010. This approach is only valid if the hardware and operating system meet SharePoint 2010’s

minimum requirements (64-bit, typically with Windows 2008 R2).

With the In-Place upgrade, the SharePoint 2010 installation is run on each WFE and APP server in the

farm. The installer detects that MOSS or WSS is previously installed and presents the user with the

appropriate options to upgrade.

This approach absolutely requires a greater level of up front planning and testing, because if the

upgrade process does not go smoothly the production server could be unavailable for an extended

period of time. However, once thorough planning and testing is complete, the In-Place upgrade is the

easier of two upgrade options.

For the In-Place upgrade, the test environment is used to stage a replica of the production MOSS or WSS

farm, with Service Pack 2 and the October 2010 CU is installed. After resolving any issues reported by

the Pre-Upgrade Checker, an actual test of the In-Place upgrade can proceed on the test server. The

purpose of this test process is as follows:

1. Verify that the core upgrade completed successfully

2. Verify that the content databases upgraded successfully

3. Test the Visual Upgrade

4. Regression test the upgraded SharePoint 2010 environment to identify any components that do

not function as expected.

Database Attach

The Database attach option is used when you need to install SharePoint 2010 on a new server(s) that do

not already have MOSS or WSS installed. In this scenario, a new SharePoint 2010 farm is created with

clean installation of SharePoint 2010 on at least one WFE server.

Once the new SharePoint 2010 farm is created and the existing SharePoint 2007 system has been

updated with SP2, any custom solutions that need to be used in SharePoint 2010 should then be

installed.



White Paper



At this point, the existing content databases can be backed up from the production SQL Server and

restored to the test SQL Server. After the content database(s) are restored to the test database server,they can be attached to the SharePoint 2010 farm one at a time. When each content database is

attached, it will be automatically upgraded to be compatible with SharePoint 2010. If the SharePoint

2007 farm makes use of SSPs, Audiences and/or MySites, the SSP database(s) can also be backed up,

restored and upgraded to SharePoint 2010.

The actual upgrade process for the Database Attach option contains a few additional steps compared to

the In-Place upgrade. Compared to the In-Place upgrade, the benefits of this approach are:

1. The ability to leave the production MOSS or WSS farm operational (in read-only mode) during

the upgrade process.

2. Lower risk because you can resume use of the MOSS or WSS farm should the SharePoint 2010upgrade not work as expected.

With the Database Attach approach, you should expect to test a complete upgrade at least one time and

then assess the results:

1. Verify that the content databases upgraded successfully

2. Test Visual Upgrade

3. Regression test the upgraded SharePoint 2010 environment to identify any components that do

not function as expected.

With the Database Attach approach, often the “test farm” will become the production farm once the

upgrade process is complete. In this case, there is no difference between the “testing process” and the

“upgrade process” – if the upgrade test process works perfectly the first time, then the upgrade may be

considered “complete”.

In reality, there are likely to be some issues uncovered during the testing process that will need to be

remediated and re-tested in order to complete the Database Attach upgrade process. With careful

analysis and regression testing, this process should only be repeated once. But the benefit of the

Database Attach option is that the process can be repeated as many times as necessary.

share point upgrade methodology - white paper

Documents