Fix Pre-Upgrade Check errors

So before you upgrade to SharePoint 2010 from SharePoint 2007, it’s a written rule that you need to run Pre-Upgrade Checker which was introduced in SP2 and has been updated in October 09 Cumulative Update. You can read about the Pre-Upgrade Check here

The syntax for it is

STSADM -o preupgradecheck

When you run the Pre Upgrade Checker, you will get a report like this

There is a log file associated with the pre-upgrade check which you find at C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\Logs.

You can run the pre-upgrade check, any number of times and it will not make any changes to your farm. Even if you are not upgrading to SharePoint 2010, you should do this because it will give you nice report of your SharePoint including the size of farm,  any large lists etc. I think this is a great tool.

The report has all links to various KB  articles which will help you in troubleshooting a the various issues in the report.

So now, how to fix the errors shown in the pre-upgrade checker. Here we go

The first issue is the Missing server file or server configuration issue. You can read about this error here.

Part 1: Fixing Missing Web Part Issues

If you look at the first part of this issues, the pre-upgrade check is telling you that some web parts are being referenced but they are installed on the server. It should look something like this

The following web part(s) are referenced by the content, but they are not installed on the web server

• Id = GUID, Type = Unknown, Reference = 2, Status = Missing

How to fix it? You got jump a few hoops to fix this issue.

First run this STSADM Command

stsadm.exe -o enumallwebs -includewebparts > N:\enumwebs.txt

Note: includefeatures, includesetupfiles, includewebparts, includeeventreceivers, and includecustomlistview were the new parameters for enumallwebs command included in the October 09 Cumulative Update

This would give you list of your webs in your farm and all the web parts installed.  Use CTRL F and search for MISSING which should show you the missing web part. It should look like this

The URL parameter next to web ID should lead you the web where this web part is missing.  Now to fix this web part, I followed the steps.

Go to the web part maintainance page, to do this add ?Contents=1 end the url.

For example: http://sitename/sites/site/default.aspx?contents=1

Thank You Shane Young for short cut, you can read more about the Maintenance here

You should see something like this

If you see the error, Select the error web part and delete it, this fixed one of my web part id error in pre upgrade check report.

If you don’t see the error, then you got a follow a longer way.

Consider my scenario, I have two farms; Farm A and Farm B.

We had a custom web part installed in Farm A but we never installed this web part in Farm B. We often move data from Farm A to Farm B using Export/Import, so I assumed that the data was referencing the custom web part in Farm even though we never installed this web part in Farm B. To prove my theory, I used few tricks.

Using the custom web part type name and assembly name we had on the Farm A, I was able to generate the GUID for the web part which matched with web part ID error on pre-upgrade check. To generate GUID I followed this blog.

Then installed the custom web part on the Farm B and this resolved one web part ID issue. To make sure, I ran the pre-upgrade check and this web part error was gone.

Part 2: How to Fix Missing Feature(s) Issue

If your data is referencing a feature and if the feature is not installed on the server, the pre-upgrade check will throw an error like below.

The following feature(s) are referenced by the content, but they are not installed on the web server

Name = Unknown, Feature id = GUID, Reference count = 43, Scope = Web, Status = Missing

These errors occur if you have faulty features in your Farm. You can delete these feature from the farm using Feature Admin Tool found here. This is a very handy tool, make sure you test before you remove these faulty features. Removing these features should fix most of the errors on the pre-upgrade check.

Hopefully this can help someone!

I am working on couple of upgrade projects and I will post any new findings.

Leave a comment if you have question.

SharePoint 2010 database upgrade with Multiple Content Databases

Consider the following scenario

One of my client (SharePoint 2007 Farm) had multiple site collections in a single web application and each site collection had its own database. In other words the web application had multiple content databases.

I wanted to upgrade the SharePoint 2007 farm to SharePoint 2010.

So I installed a SharePoint 2010 test farm and sat down to do the upgrade using database attach upgrade method

1. I restored the content database containing the top-level site collection (http://sitename/).

2. I tested the content database using Test-SPContentDatabase – No Issues

3. I mounted the content database using Mount-SPContentDatabase – No Issues

4. I was able to browse the top-level site collection – No Issues

5. Now, I restored the content database with the second site collection (http://sitename/teams/HR)

6. Tested and Mounted it – No issues

7. When I tried to browse the site, I could not. I was getting a 401 page.

8. After some troubleshooting I noticed the SharePoint has added the managed path as “Teams/HR” instead of just “Teams”. I deleted the managed path (“Teams/HR”)  and added “Teams” as wild card managed path.

This fixed the issue. Turns out that when you have custom managed paths and you are doing a database attach upgrade, you need to add the custom managed path through central admin. If you don’t, you will receive 401 pages just like me.

So, if you are upgrading using database upgrade method and your web application has multiple content databases, follow the steps below:

1. Run pre-upgrade check,

2. Test your content databases using Test-SPContentdatabase powershell commandlet, make sure there are no upgrade blocking issues.

3. Create a new web application on your 2010 farm.

4. Create custom managed paths if you have any in your SharePoint 2010 central admin

5. Mount the content database containing the top-level site collection followed by other site collections.

Make sure to test the upgrade on a test farm before you start playing with a live environment! Happy Upgrading!

Thanks to @ToddKlindt for steering me in the right direction!