Thanks to everyone who attended the event last night. As promised here is a copy of the presentation:
I’ll be presenting in the upcoming Houston SharePoint User Group event taking place January 20th. The topic will be SharePoint 2010 Upgrade and Motivators, during this session I will provide an overview of the SharePoint 2010 Infrastructure Upgrade Cycle, discuss pros and cons of the various upgrade paths; in place, database migration, hybrid; and cover some of the intricacies on planning how to upgrade a branded WCM site. Should be a fun event, I hope to see you there.
There are some very welcome improvements with the upgrade process that don’t just apply to 2010 but SharePoint 2007 patch management as well. Unfortunately there is a bit of bad news (at least for some), so we’ll get started there to get it out of the way:
Requirements and Unsupported Scenarios
- SharePoint 2010 will only support upgrading from WSS v3 and MOSS SP2. There will be no direct upgrade path for WSS 2.0 or SharePoint Portal Server.
- SharePoint 2010 will only run on 64 bit environments (nothing new here, this has been known for quite some time)
- No side by side installations. In other words you will not be able to run SharePoint 2007 or WSS 3.0 and SharePoint 2010 on the same hardware at the same time.
- No gradual upgrade. This comes as a result of not being able to run both products side by side.
- In place upgrade
- DB Attach
A couple of tools worth mentioning (discovery and diagnostics)
- Pre Upgrade Checker: SharePoint 2010 equivalent of prescan, but unlike prescan.exe in 2007, you are not required to run it before performing the upgrade. I cant really see why you wouldn’t though as it provides tons of useful information, and does not modify the databases on the farm.
- Worth noting that this already comes with SharePoint 2007 SP2 and a newer version is being released with the October Cummulative Update.
- SP Diagnostics Utility: Already in SharePoint 2007 (at least in SP2), give some very useful information regarding the farm’s overall health
- Test-SPContentDatabase: PowerShell commandlet which reports data from server and database pairing; this is where the database may include references to certain features which may not be on the server ( You can run this against both 2007 and 2010 databases). report data includes:
- Custom Site Definitions
- Template ID
- Count (how often its being used)
- Installed or missing
- Used and missing assemblies
- Missing ghosted(ghostable) files
- Custom Receiver Assemblies
- In use
- Installed or missing
- Where are they being used
- In use
- installed or missing
- Feature Upgrade Capabilities: This allows you to create new versions of your features and indicate whether you want to upgraded these features, where they are being used, to their newer respective versions. I suspect this can be a bit tricky… but if it works well, its a fantastic improvement.
- Visual Upgrade: I mentioned this in one of my earlier posts.. fantastic idea. The product ships with 2007 versions of most of the site definitions (that’s right… most) that run on 2010. This means that you can upgrade now, and worry about the impact changing the look and feel will have later. Of course its important to note that this may not work with custom site definitions (although I hope its supported if we create their 2010 equivalents.)
- By default, sites are upgraded with the 2007 look and feel
- Can force to the new look and feel when performing the upgrade with the addcontentdb command or PowerShell mount command
- Web owners can upgrade to the 2010 look and feel on their own when they are ready.
- The following site definitions do not support Visual Upgrades:
- My Site Core Site
- PWA Core Site
Additional things worth noting
- Central Administration provides great interfaces to help track the status of the upgrade. Giving us a look into the log information including current upgrade step and any errors.
- Can run multiple upgrade sessions simultaneously and track via central admin.
- One log per upgrade session
- Upgrade errors only log
- Fixed upgrade log schema (easier to report against)
- Current DB Schema displayed in Central Admin
- Easily re-run an upgrade that failed in the past.. this is useful if you know what caused the error and were able to fix it.
This is one of those things that you’ll hardly ever run into. But if the stars are aligned just right, and you are running into this error perhaps this posting will help.
First of all, I’m assuming you’ve already checked the permissions of the account you are using to run this command, and as far as you can tell all the necessary permissions are in place both on the DB Server and the WFE server.
So when are the stars aligned just right?…… If you are running SharePoint 2003 and MOSS 2007 on the same server, each version is configured to use a different database server, and the account you are using to run the command does not have necessary permissions on the SharePoint 2003 database server. Why would you need permissions on the SharePoint 2003 database server, if you are trying to add a content database to your MOSS 2007 Server Farm? Perhaps is a bug, perhaps is a feature, perhaps is by design; I wont pretend to know. But we can make an educated guess by looking at the logs.
Open the logs and look for any errors generated around the same time you ran the command. If you carefully follow the trail of the error you should see some references to the following methods; get_CanUpgrade and ReflexiveCanUpgrade. These will be shortly followed by a connection string to the SharePoint 2003 Database Server, specifically the configuration database. Based on this information we can assume that MOSS wants to check if the content database being added is being upgraded from the SharePoint 2003 configuration. But why does the error occur even when the database is new? Well, MOSS doesn’t yet know that the database is new. Whatever the case may be, the fix is easy; make sure you have the necessary permissions on the SharePoint 2003 database server, or get someone who does to run the command.
BTW, a similar error will occur if adding a content database from Central Administration under the same circumstances.
Just recently, I ran into a problem running the prescan utility where a series of sites reported the following errors:
Error: Exception scanning web: http://intraneturl/sites/samplesite
System.IO.FileNotFoundException: The system cannot find the file specified.
Error: The following site has not been scanned. Id = f3b05792-52a4-4a85-9b26-19905f23cf46 and Url = /sites/samplesite
Error: Prescan has encountered sites or lists that were not updated because they cannot be accessed using the SharePoint Products and Technologies object model. The most likely reasons for Prescan to skip a list are covered in the Knowledge Base article at: http://go.microsoft.com/fwlink/?linkid=69958&clcid=0x409.
The recommended Knowledge Base article indicates that the problem may be caused by database corruption which can be solved using the databaserepair command line operation of stsadm. Running the command should produce a list of orphaned objects. Calling the command again with the “deletecorruption” parameter would delete the orphaned objects.
But what if the command doesn’t find any orphaned objects? This was the problem I ran into. Running the databaserepair command would always produce the following response.
First I decided to take a look at the sites that where reporting the “Exception scanning web” error; opening these sites in the browser returned the following “list does not exist” error.
This led me to believe there might be something wrong with the site definition. With a little more research, I found that all of the sites reporting this error were in fact based on the same site definition.
Cause: As it turns out, the Site Definition used had been commented out in the “WebTemp.xml” file (I’ve seen many people do this to prevent certain site definitions from showing up in the list of available templates.)
Note: None of the sites identified by the error “The following site has not been scanned. Id = SOMEGUID and Url …..” were the cause of the problem; it was always a sub-site, specifically the ones that generated the “Exception Scanning Web” and “FileNotFoundException” errors.
Solution: Make sure any site definitions used are included in one of the “WebTemp.xml” files (they must not be commented out.) After correcting (or updating) the WebTemp.xml files, you’ll need to run an IISReset. You should then be able to browse the sites without receiving an error and re-run the prescan.exe utility (hopefully you wont run into something else).