Wednesday, May 30, 2012

Migration SharePoint 2007 to SharePoint 2010

As we know SharePoint 2010 has significant user experience, performance, and other improvements, most of the organizations with existing SharePoint 2007 applications are planning to upgrade to SharePoint 2010. New hardware and software requirements, architectural changes, and UI changes in the product will require solid migration and testing plans to ensure these upgrades proceed smoothly.

My goal of this migration article is to illustrate step by step migration from SharePoint 2007 to SharePoint 2010.
Here I am going to describe the migration process steps for the below scenario which exists in SharePoint 2007 environment.

Scenario: Migrating Team Site with below content/functionalities/custom solutions
  • Ø  Regular Team Site
  • Ø  Team Site with sub-sites
  • Ø  Team Site with list template
  • Ø  Team Site with sub sites using Site Template
  • Ø  Team Site with sub sites using Site Template + Custom WP solution
  • Ø  Team Site with sub sites using Site Template + Custom WP solution + Custom Content Types
Before you run any process to upgrade from Microsoft Office SharePoint Server 2007 to Microsoft SharePoint Server 2010, you have to determine which upgrade approach to take from the below two major approaches. The Article Upgrade process overview (SharePoint Server 2010) gives the more information possible approaches for migration.
The article Determine upgrade approach (SharePoint Server 2010) helps in comparing the pros and cons for each approach and to review information about special cases that might influence your approach. In addition to this information, be sure to read Review supported and unsupported upgrade paths (SharePoint Server 2010) to understand exactly which upgrade situations are valid and lead to successful upgrades.

Here in my case I am using the Database Attach Approach. The Source and Destination servers are different. The below describes the Step-by-Step Migration Process.

1.      Check Pre-Requisites for upgrading from SharePoint 2007 to 2010

2.       SharePoint 2007 with SP2 environment
3.       A web application with above scenario in SharePoint 2007 environment
5.       A web application with no site collection in SharePoint 2010 environment

2.      Run the pre-upgrade check

Note: To perform an upgrade, you must have installed Office SharePoint Server 2007 with Service Pack 2 (SP2).

The pre-upgrade checker is a STSADM operation that you run in a Microsoft Office SharePoint Server 2007 environment to find any potential issues for upgrade and to review recommendations and best practices.
STSADM -o preupgradecheck

In my environment, I got the following issues after running the preupgradecheck.

Issue 1: This server machine in the farm does not have a 64 bit version of Windows Server 2008 SP2 or higher installed.
Description: This issue is related to hardware, software, pre-requisites of SharePoint 2010 server.

Issue 2: Orphaned site collections
An orphaned site collection is a site collection exists in the content database, but it is not available in the configuration site map(CA/UI). Such site collections are not accessible and will not be upgraded properly. The following orphaned site collections were found.

/sites/MyTest (Data Source=WS2003\OfficeServers; Initial Catalog=WSS_Content_80; Integrated Security=True; Enlist=False; Connect Timeout=15)

Description: This issue is related to MyTest Site is corrupted in SharePoint 2007 server.

Issue 3: Missing server file or server configuration issues
Description: This issue is related to custom web parts, event handlers, and features etc.

Note: The generated report is available in LOG files.  

3.      Clean up the Environment:

Resolution of Issue 1:
Resolve all the environment issues mentioned in Issue 1.

Resolution of Issue 2:
·         Verify whether the reported orphan site collection exists in the specified web application through CA (UI).

Then verify whether the same orphaned site collection exists in content database using the below STSADM command
STSADM -o enumallwebs -databasename  <<name of the content database>>

It gives the count of the site collections in content database and lists all the site collections and webs inside with IDs. The orphaned site collection should be found here.

·         The orphaned site collection Sites/MyTest is deleted in content database using below STSADM command
STSADM -o deletesite -force -siteid <<site guid>> -databaseserver <<database server>> -databasename <<name of the content database>>

·         RECOMMENDATION: After deleting the orphaned site collection, it is recommended to repair the content database for any schema related issues using below STSADM command.
STSADM -o databaserepair -url <<site collection url>> -databasename  <<name of the content database>>

Note: The siteid is copied from the STSADM command prompt after running enumallwebs command.

Resolution of Issue 3:
This issue is related to custom solution. Lists all the missing web parts, features, content types etc., in content database; Make sure all the custom solutions are deployed to the farm.

Note: Run the preupgradecheck command again after resolving all the listed issues to see if there are any issues still.

4.      Backup Content Database -SharePoint 2007 Environment 

In any type of database attach upgrade, you can set the database to read-only temporarily to ensure that you capture all the data in the backup so that you are restoring and upgrading the current state of the environment. If the database are set to read-only, users can continue to view content, but they will be unable to add or change content.

5.      Restore Content Database - SharePoint 2010 Environment 

After you configure the new server farm (SharePoint 2010), you can restore the backup copies of the database new environment.

You must also set the database back to read-write before you attach and upgrade them.

6.      Verify Custom Components 

Before you attach the content database to the Web application, use the 
Test –SPContentDatabase Windows PowerShell cmdlet to verify that you have all the custom components that you need for that database against the web application.
Test-SPContentDatabase -Name <<restored content database name>> -WebApplication <URL>

7.      Attach a Content Database to a Web application 

You can use either the Mount -SPContentDatabase cmdlet in Windows PowerShell or the addcontentdb Stsadm command to attach a content database to a Web application.

Note: Using the SharePoint Central Administration pages to attach a content database is not supported for upgrading.

PowerShell Cmdlet
Mount-SPContentDatabase -Name <<restored content database name>> -DatabaseServer <<database server>> -WebApplication <<URL>> [-Updateuserexperience]

 STSADM command
STSADM -o addcontentdb -url <<web application url>> -databasename <<content database name>> [-preserveolduserexperience]

Note: Updateuserexperience & preserveolduserexperience are optional and used for visual upgrade respectively, which applies the 2010 look and feel for 2007 pages.
After you have attached a database, you can use the Upgrade Status page in Central Administration to check the status of upgrade on your site collections. After the upgrade process is complete, you can review the upgrade log file to see whether there were any issues during upgrade. Also, you can review each upgraded site to find and address any issues with how the content is displayed. For more information, see Verify upgrade and review upgraded sites (SharePoint Server 2010).

To view the Upgrade Status page:
In Central Administration, click Upgrade and Migration, and then click Check upgrade status.

8.      Visual Upgrade 

Once the content database is restored, attached to a web application and the site is accessed through browser, the site holds the 2007 look and feel if user experience operation is not used in PowerShell/STSADM while attaching content database.
To apply the 2010 look and feel to the restored sites follow the below simple approach.
Logon to SharePoint 2010 team site; click on Site Settings->Visual Upgrade, select the update the user interface radio button, which will update the SharePoint 2010 interface.

9.      Verify Successful Upgrade 

Run the below PowerShell command to check whether the upgrade/migration is successful
Test-SPContentDatabase –Name <name of the content database > -WebApplication <web application url>

It generates a report of missing custom features, web parts and event receivers….etc.

10. Deploy Custom Solution 

1.      Add & deploy the custom solution to SharePoint 2010 restored site using PowerShell or STSADM.
2.      Activate the content type and webpart features in SharePoint 2010 restored site.

11. Again Verify Successful Upgrade 

Run the PowerShell command as follows to check for successful upgrade
Test-SPContentDatabase –Name <database name> -WebApplication <URL>

      This time it should be successful, no warning/errors.

I hope this post is useful in manual migration.

Wednesday, May 9, 2012

SharePoint Registering Event Handlers to Content Type

Recently i have a requirement to registering the event handler to multiple lists having the same content type. Actually the event handler has ItemAdded/ItemUpdated events.

The complexity has been increased when new lists keep-on added at different places/sites. So i keep registering the same event handler with each newly created list which has same content type. I felt this is not a good approach to registering the event handler for each and every list.

When i investigated for the better solution, i found that event handlers can be registered for a specific content type. So as soon as the content type is added to the list, the same event handler is available on the list for a specific content type items. With this no need to register event handler for each list with same content type.

Binding Event Handlers to Content Type can be done by using SharePoint content type feature/elements xml.
Feature - XML
<?xml version="1.0" encoding="utf-8"?>
<Feature Scope="Web" 
  Title="Sample Event Handler Registration" 
    <ElementManifest Location="elements.xml"/>
ConteType with Event Handler Binding - XML
<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<Elements xmlns="">
  <ContentType Name="ContentType Name"
   Description="ContentType Description"
   Group="ContentType Group Name" >  
    <XmlDocument NamespaceURI="">
      <spe:Receivers xmlns:spe="">
          <Name>List Item Updated Event Receiver</Name>
          <Assembly>Sample.Solution, Version=, Culture=neutral, Public                    KeyToken=285bf69c25gca888</Assembly>
Hope this helps in reducing the development efforts and increases the efficiency.