Upgrade | The White Pages

Upgrading to SharePoint 2010 from 2007 is well worthwhile, and is significantly easier than the upgrade from 2003 to 2007 was. With that said, there are a number of things to look out for, and a number of bumps along the way. Running the stsadm –o preupgradecheck on your SharePoint 2007 farm identifies a number of the potential pitfalls and alerts you to their dangers.

Recently, I was at a client site doing a database attach upgrade, and we ran into a warning about orphaned objects. Orphaned objects will cause the upgrade to fail, so it needs to be remedied prior to the upgrade.

Orphaned objects are items that exist in the database, but aren’t properly connected to anything in the site collection. Orphaned objects are typically sites or lists. Joel Oleson has a good article on deleting orphaned sites, Orphaned lists are trickier with much of the guidance pointing to removing and then re-adding the content database. Also there is an stsadm command that should repair orphaned objects. The syntax is:

stsadm –o databaserepair –url yoururl –databasename contentDB –deletecorruption

Using the –deletecorruption directive goes ahead and fixes the problem, without it, it just tells you where the problem lies.

Unfortunately, nothing worked in my case. Running databaserepair simply resulted in a return that looked like the following:

<OrphanedObjects Count="1">
  <Orphan Type="SPList" Id="{787A6375-ABA3-4475-AE64-230853EB4448}" SiteId="{13AB0F9E-386B-4128-916C-E70BFC6A45F3}" />
</OrphanedObjects>

This discussion (in which the response marked as an answer isn’t the answer) got me pointed in the right direction. I am loathe to do anything directly in the content database, but if I had an orphan, I could at least find it there. I therefore opened up the AllLists table in the content database and did a SQL search for my list, like:

select * from AllLists Where tp_ID=’787A6375-ABA3-4475-AE64-230853EB4448’

Unfortunately, I got no results. This was baffling.

I had the GUID of the offending list, but it didn’t exist in the list table. I started rooting around elsewhere. It wasn’t too long before I found a reference to it in the AllDocs table, in the ListId column. To me, that meant that I didn’t have an orphaned list, but an orphaned document that was referring to a non-existent list..

After determining that the document was in fact disposable, I deleted its record with some simple SQL

DELETE FROM AllDocs Where ListID = ‘787A6375-ABA3-4475-AE64-230853EB4448’

Once that was done, I ran the preupgrade check, and all was clear – no more orphaned objects. We could proceed to the next roadblock… (more on that later).

This solution worked in my case, but as it involves monkeying with the content database, use at your own risk, and whatever you do – have a backup of the database available!

When You install SharePoint 2010 on a server that already has SharePoint 2007 installed on it, it will install all of the 2010 bits on that server in a side-by-side fashion with the 2007 bits. This is a good thing, for all sorts of reasons. However, it can be the source of some confusion, and at least once already in my case, an opportunity for slip ups.

After you run the new SharePoint Products Configuration Wizard (note the new lack of “And Technologies” in the name), you will have converted your farm, which is all of your databases. However, you still have access to all of the code from the 2007 install. This includes the SharePoint Products and Technologies Configuration wizard from the 2007 install.

This can be a real problem, particularly if you have always used a shortcut to run it, and you expect the shortcut to be upgraded. It won’t be… Take care that you’re running the right tool. It’s now installed off the start menu in the “Microsoft SharePoint 2010 Products” folder, and its name is slightly different,“SharePoint 2010 Products Configuration Wizard”. The chrome around it is slightly different,but not enough to tell, but one visual clue that you’ll get while inside the wizard is that the prompt that warns you about services restarting has “v4” in most of the Service names.

April 30, 2010
Posted by John White at 4:31 pm
No Responses
SharePoint
SharePoint 2010, Upgrade

Microsoft has been very clear about the requirements for installing SharePoint 2010. The biggest thing in this release is that it’s 64 bit only, not just on the Operating System side, but also in the SQL Server requirements. In addition, it’s also quite fussy about which versions it supports.

On the operating system side, a complete list can be found here. On the SQL Server side, it’s generally thought that it supports only SQL Server 2008 and above. However, this isn’t true – it supports SQL Server 2005 – provided that it’s 64 bit mode. However, the devil is in the details. It’s very specific about the patch level that you’re running. Glenn Berry has a list of the supported versions, with patch levels, and the SQL script for determining your precise version levels. There are only 3, so I’ll repeat them below:

SQL Server 2005 SP3 CU3 (Build 4220) or greater
SQL Server 2008 SP1 CU2 (Build 2714) or greater
SQL Server 2008 R2

The kicker is that neither the SP3 level of 2005, nor the SP1 level of 2008 will cut it,and you will have a failure if you do not conform to these versions. This failure will not appear until you run the SharePoint Products configuration wizard,which is pretty much past the point of commitment. In addition, the stsam.exe –o preupgradecheck command on a 2007 farm does not appear to detect this deficiency (at least it hasn’t yet in my experience).

Do yourself a favour, and patch up your SQL servers before you start your install/upgrade. The most recent cumulative update packages, as of this writing are:

I’ve used CU7 for 2008 on my installs thus far, and can attest that it works. I’m still waiting, hopefully not long now, for 2008 R2…