SharePoint 2010 Upgrade
So I’ve attended Sean Livingston’s two upgrade sessions at the SharePoint conference today (SharePoint 2010 Upgrade Part 1: Fundamentals and SharePoint 2010 Upgrade Part 2: Advanced Scenarios) and I figure I’m ready to try upgrading a MOSS 2007 site. What better one to start with than our public web site from www.envisionit.com.
For those of you that don’t want to read all the sordid details, the site did upgrade quite cleanly, and is now available on http://www2010.envisionit.com/Products, running under SharePoint 2010. It still has the old user experience, but in this case that just affects authors, and not the general public. I’ll be working through that quite soon I’m sure. The top level site is currently broken though, as I flipped the user experience over and I can get it back just yet.
We need to start off with a few prerequisites here. First and foremost there are only two versions of SharePoint you can upgrade from. They are WSS v3 SP2 and MOSS 2007 SP2. You have to be current on SP2, and if you’re skipping versions, you still need to migrate through 2007. That’s fine, our site is built as a publishing site on MOSS 2007, and we’ve installed SP2, so we’re good on that side. Next is that you have to be running 64-bit servers for BOTH SharePoint and SQL. You can use either SQL 2005 or SQL 2008, but it has to be 64-bit.
Next step is to decide what type of upgrade you are going to do. Both in place and content database migration are supported. In place is where you have 2007 running on a 64-bit server farm, and you upgrade SharePoint to 2010 right on the farm. Everything in the farm gets upgraded as part of this process. Content database migration is where you build a net new 2010 farm, and move the content databases over one at a time (or a few in parallel to speed things up).
We had the same options back in the 2003 to 2007 days (seems forever ago doesn’t it) and I was a much bigger fan of the content database migration then. You build a new environment, test your migration right through to the end result, and when you’ve got it right you lock users out of the old environment and move it through to the new one. You get to check everything first, and if anything goes wrong you have an easy fallback position. For 2010 all the same arguments apply. Microsoft even added support for read-only content databases in 2007 SP2, so you can allow users to continue to browse the old content while you are upgrading.
Okay, so we’ve got our source environment together, and we’re ready to start the upgrade, right? Not so fast. Again just like 2007, there is a pre-upgrade check to run. However this time Microsoft made it no touch (no updates to the databases are done), rendering it optional. Nevertheless it is strongly recommended that you use it. Its output is a nicely formatted HTML report, complete with KB links to help with issues that it turns up. So how do you run it? Stsadm of course. If you’re not familiar with this command line admin tool, you should be. You’ll find it in the 12 hive on your server (typically C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\bin). You run it with the following arguments:
Stsadm –o preupgradecheck
So what did I see coming out of the check? Well first it’s not that I don’t trust Microsoft beta software, but I’m running it against a development server with a backup of our live production site. That server has lots of sites on it, and there is no way to target just the one I want to upgrade. As a result I’m getting lots of warnings about missing features, customized list views, customized fields types, and modified authorized types for workflow. It probably doesn’t help that we have Nintex Workflows and a number of other third party tools installed on this server.
My next step was to get the content database over to the new SharePoint 2010 environment. This turned out to be tougher than it should have been. We don’t have SQL 2008 up and running in our environment yet (I know, we’re behind on that) and it was just the SQL Express version that installed with SharePoint on the 2010 server (no management console). After fighting on a few machines to get the Management Console installed (conflicts with VS2008 and service packs) I was ready to connect. Then there is the challenge of lighting up SQL Express to allow remote connections. I’ll save that for another post, but eventually I did get the database restored there.
In Sean Livingston’s talk on upgrades at SPC2009, he mentioned a Test-SPContentDatabase PowerShell cmdlet. The idea here is you can test your content database before you attach it, and see what problems may come up. It is intended for both version upgrades (V2V) and upgrades within releases (B2B, such as Beta2 to RTM). Sounds great, right? Except I’m not a PowerShell expert, and for the life of me I couldn’t find the cmdlet. I found a great blog at http://stsadm.blogspot.com/2009/10/sharepoint-2010-stsadm-and-powershell.html that talks about PowerShell and SharePoint 2010. I even tried the suggested command: “gcm -pssnapin microsoft.sharepoint.powershell | select Name, Definition | fl > .\sp2010cmdlets.txt”. Lots of commands, but no sign of Test-SPContentDatabase PowerShell.
Well, this is why you play in a sandbox server, right? I figured I had nothing to lose, so I might as well go ahead with the upgrade. So away I went, using the following command:
Stsadm -o addcontentdb -url http://www2010.envisionit.com -databasename WSS_Content_www2010.envisionit.com
This chugged through the upgrade, and gave me back an error file. Didn’t take more than a few minutes, as the content database is only about 200 Mb. After it was done I had a look at the error file, and only one error was reported! I had a missing feature.
Even with the missing feature, the upgrade had completed, and I now had our public web site collection loaded up in SharePoint 2010. Now for the moment of trust, I tried surfing to it. Well it responded, but some of our earlier SharePoint work isn`t deployed with features, so they require manually copying the binaries and updating the web.config. Just another reason to go back and build proper deployments around those. Turns out it was just one for this. We have a small page layout control that will spit out different CSS depending on whether you are logged in or not. Makes it handy for switching between a Login and Logout type prompt if you don`t want to use the standard Welcome menu on a public facing site, or hiding it altogether for anonymous users.
I`ve fixed up the missing control, and refreshed the browser. I had to add it to the safe controls in the web.config as well, so of course the server was taking a while to respond since the change had caused it to recycle. Finally it came back, and I was looking at our old web site running in SharePoint 2010. Turns out I had backed up the wrong content database, and this was a previous version of our site built (also built on MOSS 2007, but a completely different look). I couldn`t resist looking deeper, so I started playing with the site editing, and everything looked the same as before. I then went into the Site Settings -> Title, Description, and Appearance, and switched the new User Experience Version setting to use the new SharePoint user experience. This is a very cool upgrade feature where you can keep your site running with a MOSS 2007 user experience (this is the default), and then switch to the 2010 user experience once you’ve addressed any issues that your master page or CSS may have with 2010. The site didn’t quite look right, but now I had things like the ribbon when editing a page. Very cool.
Before going further, I wanted to get the right site loaded up. Delete the site collection, remove the content database and then delete it in SQL, and restore the right one in. Do the content database upgrade again, and once again errors and warnings are just related to missing features. I ignored those for now, and charged ahead to find the site was up and running, and looking just like before. All in all pretty painless, and pretty awesome. Of course when I tried to switch to the new user experience, things started to break, but it’s getting on to the wee hours, so this is probably a good place to break for the night. The good news is that the setting is at the site level, so the subsites kept working fine, and I thought it would be easy to go into Site Settings, modify the URL to get back to the settings for the top-level site, and switch it back to use the version 3 user experience. Turns out I chose to not just run in Preview mode, and now the option to go out of that is not there anymore. I know there was something in Sean Livingston’s talk on upgrades, but I can’t find it tonight.