SharePoint 2010 Deployment: Get Ready to Upgrade to SharePoint 2010

It may be tempting to jump right into a SharePoint 2010 upgrade, but it requires a substantial amount of planning. This will guide you through the upgrade planning process.

Brien Posey

Upgrading to SharePoint 2010 will be like no other upgrade you’ve ever done. Before you even start the planning process for your upgrade, you need to familiarize yourself with the system requirements for SharePoint 2010. Unlike previous versions of SharePoint, SharePoint 2010 is 64-bit only. As such, you’ll have to install SharePoint 2010 on top of a 64-bit version of either Windows Server 2008 or Windows Server 2008 R2.

SharePoint requires a SQL Server database, but that database doesn’t have to reside on the same server as SharePoint. SharePoint 2010 still requires SQL Server, but Microsoft has made some important changes. SharePoint 2010 requires the database to be running a 64-bit edition of SQL Server 2005 or 2008. This is true whether or not the database is installed locally on the SharePoint server.

Although not technically a system requirement, you may want to consider the Web browsers you use. SharePoint2010 is designed to make better use of Web standards. This means that users should be able to get a consistent experience regardless of whether they’re using Internet Explorer or Firefox (3.x or later). One caveat to this is that SharePoint 2010 has limited support for Internet Explorer 6. IE6 users shouldn’t have any trouble viewing SharePoint content, but content authoring requires IE7 or later (or Firefox 3.x or later).

In-Place Upgrades

As you may have heard, SharePoint 2010 allows for in-place upgrades from Microsoft Office SharePoint Server (MOSS) 2007. But because SharePoint 2010 is 64-bit, you can only perform an in-place upgrade if your existing MOSS 2007 is running on top of a 64-bit version of Windows Server 2008. If your existing SharePoint servers meet the necessary system requirements, you can perform an in-place upgrade on every server in your SharePoint farm.

Although SharePoint fully supports these upgrades, I would only recommend an in-place upgrade if you have a simple SharePoint deployment and haven’t made any customizations. Full migrations are recommended in more complex environments because doing so gives you a higher degree of control over the upgrade process. They’re also advisable for environments in which you’ve made customizations so you don’t accidentally overwrite those customizations.

A migration usually involves building an entirely new SharePoint farm running SharePoint 2010. After doing so, you can attach your existing SharePoint databases to the new farm. You can also use a hybrid migration strategy, which combines in-place upgrades and brand new SharePoint 2010 servers.

Pre-Upgrade Check

Regardless of whether you’re doing an in-place upgrade or a migration, you’re going to need to do some planning and preparation before you actually begin the process. Running the pre-upgrade checker is one of the most important steps in preparing to upgrade to SharePoint 2010. Before releasing MOSS 2007, Microsoft came out with the Prescan.exe utility that helped you ensure your SharePoint deployment was in a healthy state prior to upgrading to MOSS 2007.

While Prescan.exe was a good tool in its day, it isn’t really suitable for a pre-deployment analysis for SharePoint 2010. That being the case, Microsoft has provided a new tool called the Pre-Upgrade Checker. The Pre-Upgrade Checker is a huge improvement over Prescan.exe. For starters, the Pre-Upgrade Checker is read-only, so you don’t have to worry about it making any changes to your SharePoint servers.

What really makes the Pre-Upgrade Checker useful is that it does a much more thorough job of detecting problems than its predecessor Prescan.exe. It’s also extensible. The Pre-Upgrade Checker comes with a set of rules that it uses when it analyzes your SharePoint servers. These rules are in XML format, which means that you can create your own custom rules should the need ever arise. Using XML-based rules also makes it easy for Microsoft to update the Pre-Upgrade Checker should their recommended best practices ever change.

Arguably the best thing about the Pre-Upgrade Checker, though, is the information it compiles. Even though Microsoft designed the Pre-Upgrade Checker as a tool for preparing for an upgrade to SharePoint 2010, some organizations are using it for other purposes. One company actually uses the Pre-Upgrade Checker as a part of its disaster recovery plan. The utility doesn’t actually do anything to help salvage a failed SharePoint server, but the information it collects can be invaluable if you should ever find yourself having to rebuild a SharePoint deployment (just make sure you run the tool before the failure happens).

Similarly, another organization has used the Pre-Upgrade Checker as a tool for making sure its SharePoint servers are configured in a consistent manner. By running the Pre-Upgrade Checker on each of its SharePoint servers, it’s able to compare the reports from each server and look for any individual configuration elements that don’t adhere to the corporate policy.

So where can you get the Pre-Upgrade Checker? Chances are, you probably already have it. Microsoft included the Pre-Upgrade Checker in MOSS 2007 SP2. But contrary to what you might expect, the Pre-Upgrade Checker is not a standalone tool. Instead, Microsoft built it into the STSADM.EXE utility. Incidentally, after applying SP2, I had to reboot my test server a couple of times before Windows would allow me to access the new STSADM.EXE functionality.

With that said, I want to show you how the Pre-Upgrade Checker works. As I mentioned earlier, the Pre-Upgrade Checker works by parsing an XML-based rule file, and then using those rules as a basis for analyzing your SharePoint deployment. The Pre-Upgrade Checker comes with a built-in set of rules. These rules, which are based on the Best Practice Analyzer, exist within a file called OssPreUpgradeCheck.xml. You can get a feel for what this file looks like in Figure 1.

Figure 1  The Pre-Upgrade Checker uses an XML-based rules file.

When you invoke the Pre-Upgrade Check, you don’t have to explicitly call this rule file. The Pre-Upgrade Checker will call it by default. You do have the option of using custom rule files. The full syntax for the Pre-Upgrade Checker is as follows:

STSADM.EXE –O PreUpgradeCheck
[[-RuleFiles “<rule file name>”] [-ListRuleFiles]] [-LocalOnly]

As you can see in the previous syntax, the only required parameters are the –O and the words PreUpgradeCheck. The –RuleFiles parameter is optional and is only used if you want to manually specify a rules file to be used. Likewise, you can use the –ListRuleFiles parameter to display the rules files that are available to you. Finally, you can use the –LocalOnly parameter to run the rules against only the local SharePoint server.

To give you a better idea of how the Pre-Upgrade Checker works, take a look at Figure 2. As you can see in the figure, I began by opening a Command Prompt window and navigating through the directory structure to C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\BIN. From there, I ran the following command:

STSADMIN.EXE –O PreUpgradeCheck]

Figure 2  The Pre-Upgrade Checker tests your SharePoint deployment.

As you can see in Figure 2, the Pre-Upgrade Checker performs a number of different tests against the SharePoint deployment. The results of each test are color-coded. Red indicates a failed test and green indicates your server has passed a test. Informational items are designated in yellow.

Obviously, the Pre-Upgrade Checker output isn’t exactly verbose. The screen capture in Figure 2 only tells you if a test has passed or failed; you don’t get any detailed information. If you look at the bottom of the screen capture, though, you’ll notice there’s a message indicating that you can review the results by looking at an HTML file that’s located in the C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\Logs folder.

Each time you run the Pre-Upgrade Checker, it creates three separate log files. One of these logs is the HTML file referred to at the end of the upgrade check, but there’s also a LOG file and an XML file. You can use any of these log files, but the HTML file is the easiest to read.

As mentioned earlier, the Pre-Upgrade Checker compiles a lot of information. Therefore, it should be no surprise that the resulting logs are far too lengthy to include in their entirety. However, you can get some idea of what the HTML logs look like in Figure 3.

Figure 3  The Pre-Upgrade Check results can be viewed using a Web browser.

Identify Your Customizations

Another critical step in the upgrade planning process is to identify any customizations you’ve made to your SharePoint servers. Regardless of whether you’re performing an in-place upgrade or a migration, it’s easy to accidentally overwrite your customizations. Therefore, you should document your customizations and make a backup of just those files so they can be easily reapplied after the upgrade, should the need arise.

Hopefully, you’ve thoroughly documented all of your customizations as your SharePoint environment has evolved. Realistically, it can be tough to keep track of all the changes. Therefore, take some time to review your customization log even if you think that all of your customizations have been well-documented. Unfortunately, SharePoint doesn’t contain any built-in tools for identifying customizations. But this doesn’t mean you’ll have to manually review every file on your SharePoint servers.

One way you can find out about customizations is to use a technique called diffing. The idea behind this technique is that you can set up a stock MOSS 2007 server (make sure it’s running the same patches as your production servers) and then use a differencing program to see which files on your production servers are different from a pristine SharePoint server.

Microsoft recommends using WinDiff, but there are a number of differencing utilities available, many of which have a more extensive feature set than WinDiff.

Test the Upgrade Process

As you prepare to make the transition to SharePoint 2010, there will eventually come a point in which you develop a plan for how to perform the upgrade. Assuming you’ve addressed any issues that were reported by the Pre-Upgrade Checker, then the upgrade process should go relatively smoothly. You really shouldn’t leave anything to chance, though.

Deploy MOSS 2007 in an isolated lab environment and try out your upgrade plan in the lab before you attempt to upgrade any of your production servers. Using a lab can help you to become familiar with the upgrade process, as well as to identify issues that may present problems when it comes time for the real upgrade.

The best approach in small to midsize businesses (SMBs) is to set up some virtual servers, and then actually restore backups of your production servers to the lab servers. This will allow you to try out your upgrade plan in an environment that’s nearly identical to your production environment.

In larger organizations, creating an exact duplicate of the production SharePoint deployment is probably impractical. In these types of situations, you might set up a small-scale environment that’s configured in a manner similar to your production deployment. You might also try restoring backups from some—but not all—of your SharePoint servers, to a lab environment. While this approach may seem as though it leaves a lot to chance, remember that you’re probably not going to convert the entire deployment to SharePoint 2010 in one sitting; you’ll want to focus your deployment on one area at a time.

Verify Your Backups

The last step before you begin an upgrade to SharePoint 2010 is to verify that your backups are functioning correctly. Just this week, I had to help someone who thought that he had been diligently backing up his servers, but found out the hard way that his backups were inadequate. Don’t let this happen to you. Test your backups, and make sure that they can be restored.

Brien Posey,*** MVP, is a freelance technical author with thousands of articles and dozens of books to his credit. You can visit his Web site at brienposey.com.*

Related Content

• STSADMIN Pre-Upgrade Check Syntax
• SharePoint 2010 System Requirements
• SharePoint 2010 Upgrade Planning Poster