By: Scott Murray | Comments | Related: > SharePoint Administration
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.
Solution
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. This site provides details on supported and unsupported upgrade paths (http://technet.microsoft.com/en-us/library/cc262747.aspx ), but 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 including: http://blogs.technet.com/b/steve_chen/archive/2009/11/11/build-numbers-cube-sheet-for-moss-wss.aspx or http://koenvosters.wordpress.com/2010/03/29/moss-2007-wss-3-0-version-build-numbers/. 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 by downloading from http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=16631. 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 (see http://www.mssharepointtips.com/3745/installing-sharepoint-foundation-2010-on-a-single-server--part-1/--Installing SharePoint Foundation 2010 on a Single Server - Part 1).
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, http://autospinstaller.codeplex.com/ 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. The screen shots below, taken directly from the SPAutoInstaller CodePlex site, shows the positive results gained by using this PowerShell Script.
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, http://featureadmin.codeplex.com/. Additionally, Robert Bogue's blog has an substantial list of GUID's matched to Feature names at http://www.thorprojects.com/blog/archive/2007/05/16/list-of-features-with-guids.aspx.
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.
Next Steps
- Microsoft offers full length documents to assist with your upgrade including the following:Upgrading to Microsoft SharePoint Server 2010--http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=3837
- Determine upgrade approach (SharePoint Server 2010)--http://technet.microsoft.com/en-us/library/cc263447.aspx
- Microsoft SharePoint 2010 Products — Test Your Upgrade Process--http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=16831
- Planning guide for sites and solutions for Microsoft SharePoint Server 2010, Part 1 --http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=7028
- Check these other articles:
About the author
Scott Murray has a passion for crafting BI Solutions with SharePoint, SSAS, OLAP and SSRS.This author pledges the content of this article is based on professional experience and not AI generated.
View all my tips
