Many IT professionals are looking toward next year with excitement, anxiously anticipating the release of SharePoint Server 2010 and wondering what they can do now to prepare. Although many details about SharePoint 2010 haven’t yet been revealed, the SharePoint product team has provided guidance on several items to help organizations plan for the upgrade. In addition, SharePoint Server 2007 SP2 includes tools that offer additional insight and configuration information.

Pre-Upgrade
You can take several measures to prepare your environment for SharePoint 2010 before its release.

System requirements. Servers running SharePoint 2010 will require 64-bit Windows Server 2008 R2 or 64-bit Windows Server 2008. (Microsoft announced more than a year ago that SharePoint 2007 and Windows SharePoint Services—WSS—3.0 would be the last versions to support 32-bit Windows.) Although most rack-mounted servers produced in the past few years are 64-bit capable, most current installations run on Windows Server 2003 in 32-bit mode, which is insufficient for SharePoint 2010; you must run 64-bit Server 2008 in your production environment. Environments running 32-bit hardware will require upgrades. In addition, because Microsoft Virtual Server and VMware’s Virtual Desktop Infrastructure (VDI) both support only 32-bit images, you’ll need Windows Server 2008 Hyper-V or alternative virtualization software to host 64-bit images.

SharePoint SP2 or later. One of the first things you can do to prepare for SharePoint 2010 is upgrade your current installation to the latest service pack. Upgrading to SP2 or one of the newer cumulative updates will give you significant features to help prepare for SharePoint 2010. SP2 includes:

  • PreUpgradeCheck—This key STSADM command provides guidance about upgrade requirements and determines whether an upgrade will fail, without making any changes to the current environment. The command is built on the best practices analyzer and is the best free tool available to help you understand the current state of your environment. I discuss the PreUpgradeCheck command in more detail later in the article.
  • Read-only databases—Read-only databases provide uptime flexibility for both build-to-build and version-to-version upgrades. Providing read-only databases to users while other databases are being updated gives users access to data during the upgrade.
  • Parallel upgrades—In the past, databases had to be upgraded serially; only one database per server could be upgraded at a time. Although some companies used more hardware to overcome this limitation, you now can upgrade many databases simultaneously, dramatically increasing the speed of built-to-build or version-to-version upgrades.
  • EnumAllWebs—This command provides the entire site collection and information hierarchy of your environment. The XML output can be used either as a site map or for inventory.
  • DeleteSite and Deleteweb—These two STSADM commands are enhanced in SP2 to include the force command for removing problematic site collections and webs. Orphaned sites and webs can be removed using the stsadm -o deletesite -force command.
  • VariationFixTool—You can use EnumAllWebs to obtain the globally unique identifier (GUID) for sites with variation issues. The VariationFixTool command in STSADM lets you repair sites with variations that are out of sync.

SQL Server. For performance reasons, SharePoint 2010 requires a 64-bit OS and hardware for your web infrastructure, as well as for SQL Server. It also requires SQL Server 2008 or 2005. SQL Express 2008 and 2005 are free alternatives, but their lack of management tools makes issue identification difficult. SQL Server 2008 Standard or Enterprise Edition offers the best scalability, performance, and manageability. The edition you decide to use will likely depend on your high availability, mirroring, and database encryption needs.

Internet browser. SharePoint 2010 won’t support Internet Explorer (IE) 6.0. Instead, you’ll have to use a standards-based browser such as IE 8.0, IE 7.0, or Firefox 3.x to author content. SharePoint 2010 will also offer an increased level of compatibility with Firefox 3.x and Safari 3.x on non-Windows OSs. This move is a big win for corporations with mixed environments; in addition, it means a richer editing and design experience. If you’re planning to upgrade to SharePoint 2010, you’ll want to upgrade to a standards-based browser now, rather than continuing to design pages with IE 6.0.

Client desktops. Before deploying SharePoint 2010, you should evaluate your entire environment’s desktop requirements. Organizations that still run Office 2003 and Windows XP should consider upgrading to Office 2010 and Windows 7. Office 2010 provides the best innovations yet for Office applications, as well as the richest SharePoint integration. Microsoft Worldwide Partner Conference attendees gave Windows 7 a 90-percent approval rating, and I can’t agree more: It’s the best OS ever, offering security, compatibility, and stability. It also has fewer hardware requirements than Windows Vista, so many organizations will be able to squeeze another year or two out of their existing hardware while enjoying increased productivity without additional expense.

You also should seriously consider Office SharePoint Workspace, for its improved user experience and attractive licensing options. Although not all users will need Office SharePoint Designer 2010, its designer standards-based desktop might increase adoption and provide tools for those who do need them.

SharePoint 2010 will include Office Web Applications, which are “light” versions of Office applications that are available directly from the cloud, as a subscription service. Office Web Applications will reduce the cost of upgrading Office applications but still provide users with the features they need to be productive.

Mac desktops. You should update your Macintosh desktops to Office 2008 for Mac SP2. This version of Office provides Mac integration with Office and SharePoint; specifically, it includes the new Document Connection for Mac tool, which lets users save and open documents on SharePoint 2007 and Microsoft Office Live Workspace. This enhancement improves the editing experience and integrates the Mac desktop experience with SharePoint and Live Workspace. In addition, Office Live is now compatible with Apple's Safari 4 web browser.

Developer desktops. The ultimate SharePoint developer desktop is 64-bit with 8GB of RAM running Visual Studio 2010 with solid state disks (SSDs). Sound like a dream? Although it might take some serious planning to get your developers running with the latest and greatest technologies, SharePoint 2010’s 64-bit requirements will help you justify this expenditure in your development budget. If your remote development includes virtual environments, you’ll also need to consider Server 2008 Hyper-V (with a host that supports 64-bit).

Even if you can’t upgrade to the ultimate SharePoint development environment immediately, you can specify that future developer desktop purchases include 64-bit hardware, as well as additional RAM to support virtual images and to provide the necessary overhead to run the server. Additional RAM means speed—which leads to faster development and better productivity. SSDs likewise provide the necessary speed and performance for increased developer productivity.

PreUpgradeCheck
Running the PreUpgradeCheck STSADM command runs rules that will help you determine how to prepare to upgrade.

Running the command. The old prescan.exe tool is different because it makes changes in the content database to show that a site is checked and ready for upgrading. The upgrade itself will fail if the command hasn’t been run. Microsoft paid attention to users’ feedback about this issue, and PreUpgradeCheck doesn’t perform any write operations—it’s strictly read-only.

Running the stsadm -o preupgradecheck command with the default settings uses the rules and definitions in either WssPreUpgradeCheck.xml (for WSS 3.0) or both WssPreUpgradeCheck.xml and OssPreUpgradeCheck.xml (for SharePoint 2007 environments). These XML files provide their products’ rules for out-of-the-box configuration. Settings include options for processing alternative rules files.

Understanding the output. When you run the PreUpgradeCheck command, you’ll notice the word “Passed” in green text for processed rules such as OSPrerequisite; these items receive a pass or fail based on the version of Windows Server installed. The yellow “Information Only” sections call your attention to information you need to be aware of during an upgrade, such as LargeList, where configuration and complexity information about the farm are detailed.

If you run PreUpgradeCheck and see “Failed” in bright red text next to items that need to be corrected before upgrade, this result means the farm contains a custom site definition but SiteDefinition is missing from the XML configuration file. You’ll need to address the identified issues, upgrade to 64-bit Server 2008, and rerun the check with the new configuration file.

The output of PreUpgradeCheck isn’t just what you see in the simple command output. An Extensible Style Language (XML) file lets you create custom reports for comparison/analysis. An additional web-based HTM report includes a full log of detailed information about each check performed. You can open this report in IE or Firefox. The rich HTM file includes the real meat of PreUpgradeCheck. Two main categories of content are provided: information and configuration, and customizations and dependencies.

Examples of PreUpgradeCheck information and configuration content include:

  • Content sources and start addresses
  • Topology +(SSPs), WSS search topology
  • Servers (not including SQL Server)
  • Upgrade types
  • List of alternative access mappings
  • Large lists
  • Language packs

Examples of PreUpgradeCheck customization and dependency content include:

  • Sites based on custom site definitions
  • Sites based on site template
  • Features in use (including missing features)
  • Installed language packs
  • Features
  • Custom list views and custom field types, web.config entries
  • Content and site orphans
  • Custom web parts
  • Custom XML-based Collaborative Application Markup Language (CAML) views
  • Custom XML CAML content types

Local server mode. In addition to running PreUpgradeCheck in the default mode to determine farm customizations, you can also run the check in local server mode, which runs a smaller set of rules from the given server. In large server farms, you can run the command in local mode for each server, as well as for the whole farm. You can then compare the reports and identify any differences in configuration and customizations.

I recommend running PreUpgradeCheck early and often because the insight it provides is useful not only for upgrades but also as a best practice and for configuration analysis. PreUpgradeCheck doesn’t stop running when it finds an issue, so you can run the command even if you know you have custom site definitions that will generate a failure notice. Because the command is read-only, it provides information without making changes.

Information Architecture and Data Cleanup
The more optimized your environment, the smoother and faster your upgrade will be. To improve the upgrade process, trim the following content that is simply taking up space and would slow down the upgrade:

  • Remove unused sites and site collections
  • Remove orphaned sites, lists, and objects identified by PreUpgradeCheck
  • Remove locks and increase the quotas for sites that are at or near maximum capacity
  • Remove or add missing features and web part assemblies (check dependencies) identified by PreUpgradeCheck

Cleanup also can involve working through and resetting pages and sites back to the site definition, or finalizing previous upgrades. Also be sure to consider the supportability of your customizations and address any improper development, testing environments, or resources. Now is the time to package up the various assemblies and features and build them into solutions that can be deployed easily and consistently. This cleanup can take the form of simply packaging up the code and some of the configuration, or writing scripts for some of it and documenting the rest. When it comes time to actually upgrade, you’ll be glad you took the time to perform this cleanup.

Get Started
You can take several steps now to optimize your environment for upgrading to SharePoint 2010. First, ensure that you have 64-bit hardware capable of hosting your production sites on Server 2008 Hyper-V. As soon as possible, upgrade to SharePoint 2007 SP2 or later. Discuss Office 2010 with your desktop team, including the possibility of using Office Web Applications. Run the PreUpgradeCheck tool, and assess any issues that might hinder an upgrade. Finally, reevaluate and clean up your information architecture. If you communicate about and plan ahead for an upgrade to SharePoint 2010, the process will go much more quickly and smoothly.