Problem
Your Boss tells you that the budget has been freed up and new capital for upgrades will be available next year. Thus we will be purchasing SQL 2008R2 and SharePoint 2010. He wants you to determine an upgrade plan and any initial tips on performing the upgrade. He wants you to confirm what versions need to be purchased and see if we can run through a test upgrade over the next few weeks on a test box that is currently not being used.
Solutions
Step 1
The first step you must perform is to determine what version of SQL Server and SharePoint 2007 you are using. Within most organizations except the very largest, who will likely be running Microsoft Office SharePoint Server (MOSS) - Enterprise Edition, Windows SharePoint Services 3.0 (Foundation) or MOSS 2007 Standard edition will be the most commonly used versions. The main reason for determining your current version is to assist you in determining what edition to which you can upgrade. Generally speaking, you can upgrade to a higher edition (at a cost of course), but cannot downgrade to a lower edition without a great deal of additional effort. As such, you can not easily move from MOSS 2007 Enterprise Edition to SharePoint Foundation 2010, but you can upgrade in the other direction. Thus, the ultimate point of step 1 is to determine what version and edition of SharePoint you are running. To find out, open up Central Administration, and then navigate to Operation and then Servers in Farm. This screen will tell you the exact version you are running, such as 12.0.0.6545.
You can compare that to the various build lists found online. Surprisingly, I always find it a challenge to find the build lists; such a consolidated list would seem to be on top of Microsoft's list of MSDN articles.
Next you would want to determine your edition in Central Administration -> Operations -> Convert License Type.
Now that you have your version and edition in hand, you can use the supported upgrade paths document to determine your target version and edition. In our problem statement above, if we are using Standard Edition, you would want to tell your supervisor, yes we can get a Trial Edition of the Standard Edition. However, a second issue exists which must be addressed; you must upgrade to a 64 bit server for SQL 2008R2. Unless your test machine is 64 bit, you will be out of luck. With so many organizations utilizing virtualization, coming up with 64 bit test server may be easier than in the past. Also, if your supervisor would like to just give SharePoint 2010 a test run without a full upgrade, you could also install SharePoint Foundation 2010.
Step 2
To further our example though, say you have a 64 bit test machine with specs that meet the system requirements, and have downloaded the trial editions SharePoint 2010 Standard Edition and SQL 2008 R2 Standard Edition. What is the next step?
First, I would recommend utilizing a third party tool called SPAutoInstaller from CodePlex to assist with the install process. This tools serves two essential purposes: First it prevents what I call the SharePoint Database name bloat; the default database names used by the normal SharePoint install are a combination of very long descriptions plus a GUID. SPAutoInstaller allows you to customize these names using your own naming conventions.
Second, since your settings are saved in an XML configuration file, SPAutoInstaller allows you to quickly reinstall SharePoint in a consistent way each time you run through a SharePoint install. The SPAutoInstaller PowerShell scripts allowed our organization to very quickly initiate the same install multiple times with the same consistent inputs which in turn let us run through several test upgrades. Once SPAutoInstaller has completed, you will have a base SharePoint site with no content. You can run through some tests on this blank site, or you could move to step 3.
Step 3
Now you are ready to see if you can upgrade your current content database(s) to SharePoint 2010; first you will need to run the SharePoint 2010 pre upgrade checker via the STSADM.EXE tool. SharePoint SP2 and the October 2009 Cumulative Update are required to run the checker. The checker will provide you with a list of installed features, webparts, solutions, and other objects. Any customized objects will need to be installed on the SharePoint 2010 machine before proceeding with the Upgrade. You will want to clean up these objects on the old server or install them on the new server in order to avoid issues during the upgrade. Another great tool on codeplex to assist with this clean up is the SharePoint Feature Administration and CleanUp Tool. Additionally, Robert Bogue's blog has an substantial list of GUID's matched to Feature names.
Once you have cleaned up your current environment including deleting old sites, documents, document versions, solutions, and have installed any additional features, webparts, solutions on your test upgrade machine, you are ready for the big move. In our example, we are moving from a 32bit server to a 64bit server, so you will need to use a database Detach/Attach method to "copy" the actual database from old server to new server, and then restore the database on the SQL2008R2 server. Now, the SharePoint PowerShell cmdlet test-spcontentdatabase can be used to determine the actual invalid and missing objects, such as features and solutions, which exist in your copied database using your newly installed SharePoint 2010 specifications. When we completed this check, we were primarily missing the "Fab 40" solutions and a publishing feature plus a few custom solutions that were being used on the old SharePoint site. You will want to use the SharePoint PowerShell tools to install these features before proceeding. Once the test-spcontentdatabase no longer returns data, you are ready to run actual upgrade which will be covered in our next tip.
At this point, you are ready for the actual test upgrade. Your Boss is excited that you have gotten this far and is happy with the progress made.. Thus what are your next steps to get your test upgrade complete and a site available for some quick testing and user previews?
Step 4
Once the PowerShell test-spcontentdatabase command no longer returns data, you are ready to run the actual upgrade.
However before we begin the upgrade, one issue that many upgrades have encountered is with the Fabulous 40 Application Templates. Microsoft decided to not produce a new set of templates for SharePoint 2010 as noted by Samantha Robertson's Blog To the SharePoint.
Although many of these applications will upgrade without issue, Mrs. Robertson's blog does offer a work around for getting these templates into SharePoint 2010. Furthermore, TechSol, has created 2010 versions of some of the templates.
The actual upgrade may take some time depending on the size of your content database. At this point you should have deleted any unused sites, webparts, and other customizations. Also, you should have added any customizations, webparts, and solutions to the new site. It is important at this point to recheck your position and specifically document the process you have followed so far. My methodology is very low tech in that I document each command in a text document or spreadsheet ( not always the best option as Excel, OpenOffice, or other spreadsheet applications are not normally installed on a server). I also customarily number my steps in tens or hundreds to allow for easy insert.
During our most recent upgrade we actually used one of the SharePoint Project solutions to keep track of the steps to be performed; this method was definitely easier to keep organized, but I also kept all my commands in a text file matching the step in SharePoint.
Documenting the upgrade process is extremely important and necessary. Furthermore, Microsoft provides a wealth of Planning Spreadsheets to help you deploy SharePoint 2010.
Now that the lecture on documentation is complete, we can actually run the upgrade. If you had to make changes to your existing site, such as removing a defunct webpart, you will want to backup the existing site again, and then move and restore it. You will want to perform one last check using the PowerShell test-spcontentdatabase to make sure all the changes, upgrades, deletes and such produce no warnings or errors.
Finally, the actual upgrade can start; you will first need to remove the existing default content database. You remove it in Central Administration > Application Management>Manage Content Database...
Next you mount the restored database using the PowerShell Mount-SPContentDatabase database command. An example of the command is:
Mount-SPContentDatabase -Name [database name] -DatabaseServer [database server] -WebApplication [SharePoint URL]
SharePoint recognizes that the database is a SharePoint 2007 version and institutes an upgrade routine. You expect everything to run without a hitch, since you tested the upgrade multiple times using the test-spcontentdatabase command. Unfortunately, normally you will encounter one of several errors and, as such, the upgrade will fail. The upgrade creates two log files that we can use to troubleshoot any errors.
The Upgrade Log contains all the upgrade details and is much longer than the error log. The error log contains the first level details you need to help solve any issues with the upgrade process, so this log should be the first place to start researching an upgrade failure. One common issue pertains to the Publishing features in SharePoint, which generally results in an error similar to the follow:
[PowerShell] [SPSiteWssSequence2] [ERROR] [7/16/2011 6:23:21 AM]: Feature upgrade incomplete for Feature 'PublishingSite' (Id: 'f6924d36-2fa8-4f0b-b16d-06b7250180fa') in Site 'http://xxxxxxxxxxx'. Exception: A duplicate content type name "Resource" was found.'
You will need to research your exact issue, but for this error, you can start by reviewing the data in the dbo.ContentTypes table within the Content database. In anotherMSSharePointTips article Matt Takar provides an excellent solution to address one variation of this issue in Publishing Feature Activation Error After SharePoint 2007 to 2010 Migration .
Of course other issues could surface that you will need to address before you restart the upgrade, but when you are ready, you can restart the upgrade by issuing the Upgrade-SPContentDatabase -Identity [Content Database Name] PowerShell command. The upgrade should begin again, and hopefully no additional errors will result. Again recheck your logs.
Once the upgrade is complete you will want to navigate to your site and verify it is accessible. Additionally, you can perform the Visual Upgrade to the site and any sub sites to bring the visual aesthetics of the sites to SharePoint 2010 standards.
During our test upgrades, an additional issue was encountered; the server name changed which caused Alerts to stop working. Be sure to verify in the dbo.ImmedSubscriptions and dbo.SchedSubscriptions tables, that the server name was updated in the Properties field.
At this point, you should have a working SharePoint 2010 Test site. Any additional content databases will need to be attached, Search Services will need to be created, and the User Profile Service will need to be setup. Take a look at Database Attach method to migrate MOSS 2007 User Profile and My Site to SharePoint 2010 by Udaya Kumar for details on the User Profiles Service. Since you have documented exactly what steps were required, including any upgrade restart and alert fixes, when the time comes for the production upgrade, an upgrade plan can be in place to have the upgrade run smoothly.