Quantcast
Channel: TechNet Blogs
Viewing all articles
Browse latest Browse all 36188

Upgrading from SharePoint Portal Server 2003 to SharePoint 2010 Part 3

$
0
0

In previous posts we have covered the upgrade part for SharePoint portal server 2003 to SharePoint 2007 now we need to be clear about how we can upgrade to 2010 by listing some considerations before we start the process.

The only supported platform you can upgrade to SharePoint 2010 is SharePoint 2007  it has to be at least service pack 2 (build 12.0.0.6421) or later.

An in-place upgrade takes place when you install SharePoint 2010 on your existing SharePoint 2007 machines. It functions nearly the same as the in-place upgrade from SharePoint 2003 to SharePoint 2007 but most probably your SharePoint 2003 servers are running on 32 bit environment which limits the validity for this option.

An in-place upgrade runs on your existing SharePoint 2007 hardware and maintains all your URLs.

This is a good fit if you want to upgrade a small environment and use the same machines and URLs.

A database attaches, you take databases from a SharePoint 2007 farm (service pack 2 or later, of course) and you attach them to a fully functional SharePoint 2010 farm. When a database is attached, SharePoint 2010 will upgrade it and render its content. You are allowed to attach content databases, Microsoft Project databases, and SharePoint profile databases to a SharePoint 2010 farm. This method requires SharePoint 2010 be a new installation on new hardware, and this option is the most appropriate in this stage when upgrading from 2003 to 2010.

Both of these methods require some planning and testing to be successful. The most useful tool you can use to discover any upgrade issues you have in SharePoint 2007, and determine how much trouble they will be to upgrade, is SharePoint 2007. In service pack 2, Microsoft introduced a new

STSADM operation, preupgradecheck, which scours your SharePoint 2007 farm looking for problems.

While running preupgradecheck is not required when doing either type of upgrade, it is recommended.

It will do a thorough inventory of your SharePoint 2007 farm and report any problems it finds. Not only can these problems impede your upgrade, it may be beneficial to your existing SharePoint 2007 farm to fix them sooner rather than later. Even if your farm does not have any issues, the report that preupgradecheck creates is a good point-in-time snapshot of your farm that is very easy to create.

This file is where you can get in-depth information about your farm. The following figure shows the first page of this report.

 

image

 

Here is a partial list of the problems preupgradecheck looks for:

  • Farm is at service pack 2 or later
  • Supported operating systems (Windows Server 2008 SP2 64-bit or Windows Server 2008 R2)
  • Database schemas have not been modified
  • Configuration database does not have any site orphans
  • Content database does not have any data orphans
  • Farm is not still in a gradual upgrade from SharePoint 2003
  • Databases are read only
  • Invalid entries in web.config
  • Custom site definitions
  • Large lists
  • Views and content types that use CAML

Now we have SharePoint 2007 site hosted in lab environment , we will proceed by creating web application in SharePoint 2010  we will start by Running the pre-upgrade checker (on Office SharePoint  Server 2007 environment)

Click Start, right-click Command Prompt, and then click Run as administrator.

In the Command Prompt window, navigate to the following directory:

%COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\12\bin

Type the following command and press ENTER:

STSADM.EXE -o preupgradecheck

Create a web application that will host the site using central administration

image

To Verify custom components availability Click Microsoft SharePoint 2010 Products.

Right-Click SharePoint 2010 Management Shell. And select Run as administrator

At the Windows PowerShell command prompt, type the following command:

Test-SPContentDatabase -Name <DatabaseName> -WebApplication <URL>

Where:

    • <DatabaseName> is the name of the database you want to test.
    • <URL> is the URL for the Web application that will host the sites.

    F-Attach a content database to a Web application by using Powershell

    1. On the Start menu, click All Programs.
    2. Click Microsoft SharePoint 2010 Products.
    3. Right-Click SharePoint 2010 Management Shell. And select Run as administrator
    4. At the Windows PowerShell command prompt, type the following command:

    Mount-SPContentDatabase -Name <DatabaseName> -DatabaseServer <ServerName> -WebApplication <URL> -Updateuserexperience

    Where:

      • <DatabaseName> is the name of the database you want to upgrade.
      • <ServerName> is server on which the database is stored.
      • <URL> is the URL for the Web application that will host the sites.
      • Updateuserexperience is the choice to update to the new user experience or stay in the old user experience (part of Visual Upgrade). When you include this parameter, the site is set to preview the new user experience. Omit this parameter if you want the site to remain in the old user experience after upgrade.

      To view the Upgrade Status page

      • In Central Administration, click Upgrade and Migration, and then click Check upgrade status.

      To open the upgrade log file

      • The upgrade error log file and the upgrade log file are located at %COMMONPROGRAMFILES%\Microsoft Shared\web server extensions\14\LOGS. The logs are named in the following format: Upgrade-YYYYMMDD-HHMMSS-SSS-error.log and Upgrade-YYYYMMDD-HHMMSS-SSS.log, where YYYYMMDD is the date and HHMMSS-SSS is the time (hours in 24-hour clock format, minutes, seconds, and milliseconds).

      I need to highlight addition Areas that will affect the upgrade process that you need to plan for

      Dependencies

      • Hardware order – The SharePoint Server 2010 may require new hardware (64bit) for web front end (WFE), application and database.
      • The testing environment, which should be a close mirror of the targeted production environment, needs to be available if all of the content will not be upgraded at the same time.
      • Sufficient project resource availability.
      • Representative data can be extracted to manageable sizes for customizations migration.
      • Downtime mitigation planning will depend on the upgrade testing

      Constraints

      • To mitigate downtime, the production upgrade might only be done on weekends. This might stretch the upgrade timeline that is acceptable to the customer.
      • When the upgrade process starts, the corresponding content databases on Microsoft Office SharePoint Server farm will be set to read-only/Offline.]

      Upgrade Risks and Mitigation Strategies

      Key upgrade risks and possible mitigation strategies to consider during the migration:

      Visual Upgrade

      SharePoint 2010 offers an upgrade risk mitigation feature called visual upgrade, which allows backward compatibility with the 2007 user interface (UI) and therefore enables a gradual transition for migrated sites to the new 2010 user interface experience. Visual upgrade is essentially an upgrade option that separates content database data upgrade from 2010 user interface upgrade

      Both site collection owners and site owners can preview the new user interface. They can also switch between the previous and new user interface to verify that everything works correctly.

      To preview the new UI:

      1. Go to the Site Actions menu.
      2. Select Preview New Visuals.

      However, if a site has a custom master page, the administrator should:

      1. Go to the Site Actions menu.
      2. Select Site Settings.
      3. Under the Look and Feel category, select the Title, Description, and Icon page.

      NOTE - Be aware that when the site admin makes the switch to preview the new UI, the change appears for all users and not just the administrator. In order to avoid end user confusion, administrators should consider making the change during non-business hours.

      Downtime Mitigation

      Since it is challenging to avoid downtime during an upgrade, an assessment needs to be done beforehand and after the staging iteration to find the most effective approach to avoid downtime.

      There are a few steps available that can be taken to substantially reduce the time taken to upgrade content databases. Also, these steps need to be carried out on the SharePoint farm and requires separate approval from the customer. The steps to reduce the upgrade time are as follows:

      • Remove extraneous versions of documents
      • Address lists with more than 2000 items
      • Address large ACLs
      • Limit the size of the content databases to 100 GB.
      • Re-evaluate any breaks in hierarchical permissions
      • The various approaches to minimize downtime effect on users are as follows:
        • Weekend only upgrade. The farm is set to read on Friday-night and content databases are upgraded during the weekend.
        • The alternate access mapping (AAM) Redirection approach.

      Web Application URLs

      An important upgrade decision that will need to be made is whether the SharePoint farm will persist the existing web application URLs or if the new SharePoint 2010 farm web applications should get new URLs. Reusing the existing URLs will reduce the complexity of the upgrade, as hardcoded links will continue to work, reduce end user confusion, and reduce the end user training required.

      Based on this , if old SharePoint farm is to remain, then the old SharePoint web application URLs will change

      Increase Upgrade Confidence

      In order to reduce upgrade risks and build confidence in the ability to execute the upgrade process successfully it is recommended that “Upgrade Testing” performed prior to the production upgrade. Upgrade testing is a cycle of test upgrades in a SharePoint 2010 test environment used to remediate upgrade issues and is specified at a high level below:

      STEP 1 – Prepare a SharePoint 2010 upgrade test environment

      STEP 2 – Perform a database attach upgrade in the test environment

      STEP 3 – Review upgrade log files for upgrade errors

      STEP 4 – Remediate upgrade errors

      STEP 5 – Restart the upgrade of the content database

      STEP 6 – Go to STEP 3

      Continue this upgrade testing until an appropriate level of confidence is built for the production SharePoint 2010 upgrade transition.

      Now it worth's to mention here the upgrade option to SharePoint 2013 that it does not support in-place upgrade for an existing environment,You must use the database-attach upgrade method to upgrade your databases to a new environment ; the upgrade process has changed to separate upgrade of the software and databases from upgrade of the sites. for more information about SharePoint 2013 upgrade please check the links http://technet.microsoft.com/en-us/library/cc262483(v=office.15)  and http://technet.microsoft.com/en-us/library/ee617150(v=office.15)


      Viewing all articles
      Browse latest Browse all 36188

      Trending Articles