Planning for SharePoint 2010 – Upgrade Planning Part 4 – Using preupgradecheck
Please refer to my previous three posts on Upgrade Planning for SharePoint 2010 – These previous posts outline some important scenarios for your upgrade planning process. SharePoint 2010 Upgrade Planning Part 1, SharePoint 2010 Upgrade Planning Part 2, SharePoint 2010 Upgrade Planning Part 3.
In this post I’ll outline the supported scenarios for your SharePoint 2010 upgrade from SharePoint 2007 and how to determine a best approach for your upgrade. I have been working with a few clients who are currently on SharePoint 2007 and are looking to upgrade to SharePoint 2010. So I will try and provide some real world data as part of this post.
If you’ve been following my post series I outlined the steps and the approach to move your SharePoint 32bit farm to 64bit since SharePoint 2010 is only available and supported in 64 bit Windows Server 2008 deployments. Also with the release of SharePoint 2010 there are some significant architectural changes. I will cover these in a later post. The focus of this post is about using the “preupgradecheck” command available with SharePoint 2007 Service Pack 2 and post SP2 Cumulative updates. For guidance on updating your server deployment to Service Pack 2 please visit the following article Deploying Software Updates for SharePoint Server 2007 .
The first important aspect of doing an upgrade project is to learn as much as you can about the existing deployment. This can be achieved by using the methods outlined below. Once you have gathered this information you can then determine the best approach for the upgrade process.
In your existing SharePoint 2007 or Windows SharePoint Services 3.0 deployment you can run the following command to identify if your deployment can be upgraded using one of the supported scenarios. Running preupgradecheck does not do any changes to your existing deployment environment or underlying data.
STSADM.exe –o preupgradecheck
](https://www.chandima.net/Blog/Lists/Posts/Attachments/229/1.UpgradeChecker_2_52C9B54C.png)
By running the command you can get a report that will provide you with information on the state of your deployment. Let’s look at the report that is created and how to determine issues which needs to be addressed.
The report is located in : “%commonserverfiles%/Program Files/Common Files/Microsoft Shared/web server extensions/12/LOGS
](https://www.chandima.net/Blog/Lists/Posts/Attachments/229/2.UpgradeCheckerLogs_2_52C9B54C.png)
This report contains information that will assist in the upgrade planning process. Basically when you run the preupgradecheck the command proccess checks a rule files located in “%commonserverfiles%/Microsoft Shared/web server extenstions/12/config/PreUpgradeCheck”. To run local level checks you can run this command using the –localonly parameter.
STSADM.exe –o preupgradecheck –localonly
Let’s have a look at a sample report generated by this command. (I am only including some truncated info here while highlighting info that should be considered).
Information Only : Search content sources and start addresses
The following is a list of the content sources and start addresses for each shared service provider in the farm. SSP Name = LocalSharedServices Content Sources = Content source “Local Office SharePoint Server sites” contains a total of 660 items from the following start addresses
Information Only : The components from this farm
This sharepoint software currently running on this farm is 12.0.0.6510. The farm contains the following components:
Information Only : Supported upgrade types
The current farm supports the following upgrade types:
Information Only : Informational rule to list the Windows SharePoint Services Search topology information
The Windows SharePoint Services Search topology in this farm consists of the following components: 1 search service instances Search server: Name = moss-vm Index Size = 36483146 bytes WSS Search DB Name = moss-vm \ MOSSSPSearch WSS Search DB Size = 83165184 bytes Content Databases:
The above was generated in a VM test server and only contains a subset of the report. Also as part of the report is this warning message to highlight that this server farm requires to be moved to 64bit hardware and also to Windows Server 2008.
**Failed : This server machine in the farm does not have Windows Server 2008 or higher 64 bit edition installed. **
Upgrading to Windows SharePoint Services 4.0 requires Windows Server 2008 or higher 64 bit edition. Please upgrade the server machines in your farm to Windows Server 2008 64 bit edition, or create a new farm and attach the content from this farm
The report also contains important information on any custom site definitions and also currently installed site definitions and how often these are used within your farm. For example if a customised site definition is used across a large number of sites you will need to ensure that your site definition conforms to upgrade compatibility and the site definition exists in the target SP2010 farm at upgrade time. (I’ll talk about upgrade methods in my next post).
](https://www.chandima.net/Blog/Lists/Posts/Attachments/229/4.SiteDefUsage_2_58A458E5.png)
For a complete list of the output and the report parameters please refer to this TechNet article which outlines the preupgradecheck output.
This command is handy to do an audit of all sites and webs. This command outputs information about all webs in a particular content database. It can be useful for troubleshooting orphaned sites as it lists the webid and siteid for each web and whether or not the site exists in the sitemap table of the configuration database. The important output to watch out from this report is
Site collections typically become orphaned when they are in a content database that is being attached to a Web application, but the Web application already contains a site collection with the same URL path. Because site collections cannot share the same URL path in a Web application, only the first site collection registered in the site map will be accessible. All other site collections that use the same URL path cannot be registered in the site map and are considered orphans. The orphaned site collection data still exists, but you can only access it by detaching its content database from the current Web application, and then attaching it to a Web application that does not have a site collection registered at that URL path.
](https://www.chandima.net/Blog/Lists/Posts/Attachments/229/3.EnumAllWebs_2_58A458E5.png)
With the release of the October Cumulative Updates this command will provide you with additional information such as feature id’s and assembly information. This extra information will assist with your upgrade planning.
You can download the October Cumulative Updates for WSS and SharePoint from the following links which will give you access to the updated commands.
October CU Downloads
http://support.microsoft.com/kb/974989 > WSS 3.0 http://support.microsoft.com/kb/974988 > SharePoint 2007
By using the options mentioned above you’ll be able to get a good insight to your current SharePoint 2007 deployment and get prepared for SharePoint 2010. In my next post in the series I’ll outline the available upgrade options for SharePoint 2010 and some of the new enhancements for administrators.