Get Ready for SharePoint 2010

With the release of SharePoint 2010 just around the corner, it's a good time to consider the upgrade and migration options, and take action to prepare your environment.
As happens in most upgrade or migration scenarios, there are hundreds if not thousands of details to think about that increase complexity, ranging from network connectivity to third-party applications to business continuity. There are also various frameworks and scenarios you can use for moving to a new version, such as prepare-test-implement-validate, and deciding whether to upgrade in place or migrate.

The good news is that you still have time to plan your migration strategy, and prepare now to mitigate possible issues when you do move to SharePoint 2010.

This article covers some of the actions you can take now to prepare for SharePoint 2010 that will have the greatest impact. If you want to dig deeper, you can look at existing documentation for additional guidance or to help you develop a more comprehensive plan.

For example, Joel Oleson has released presentations and a white paper about upgrade preparedness on his blog at sharepointjoel.com, and Microsoft has published preliminary guidance.

Resolve Hardware and Software Dependencies

The first action you can take to prepare your environment is to audit the existing software and hardware configuration to see if it is adequate for SharePoint 2010, and update your environment if it does not meet requirements. The most significant overall requirement is 64-bit hardware and SharePoint 2007 with at least the SP2 update.

You can do more, of course; consider updating your environment in accordance with the following best practices for front-end and application servers, back-end servers and clients.

For front-end servers, SharePoint 2010 requires 64-bit Windows Server 2008 or Windows Server 2008 R2, which uses the new Windows 7-based user interface. Many installations as of this writing run without major issues on Windows Server 2003, and if you're in that position, a large part of preparing for the transition to SharePoint 2010 entails upgrading the OS.

If you run Windows Server 2003 on 64-bit hardware already, you can reuse the servers and do an in-place upgrade for front-end, application and back-end servers. You can also add new servers to the farm and migrate the Central Administration Web site, front-end roles and application roles. If you plan to move to Windows Server 2008, you should consider the following best practices:

• Grant Windows SharePoint Services Timer (SPTimerV3) permissions. If the farm administrator account is not in the local Administrators group, or if you have a stand-alone installation, grant SPTimerV3 permission to read from IIS 7.0 by running stsadm -o grantiis7permission.
• Stop the Windows SharePoint Services Search (Spsearch) service. If you install Windows Server 2008 and then run the SharePoint Products and Technologies Configuration Wizard while Spsearch is running, the process may corrupt the search index. To re-create a corrupt index, you need to run stsadm -o spsearch -action stop, and then navigate to the Windows SharePoint Services Search service settings page in Central Administration and rename the database. For more information, see tinyurl.com/l6fmkr.
• Check IIS 7 settings. After upgrading to Windows Server 2008 and IIS7, the W3SVC service may be disabled if your IIS 6 installation used incompatible features, such as Front Page Server Extensions. Another issue you may encounter is kernel-mode authentication, which IIS 7 uses by default. If you get a 401.1 error, kernel-mode authentication may be the cause. You can disable it in the IIS Advanced Settings for Windows Authentication. Click here for more details.

For back-end servers, SharePoint 2010 requires 64-bit SQL Server 2005 or later. SQL Express is supported, but moving to SharePoint 2010 provides an opportunity to re-examine the back-end infrastructure and optimize it.

The Standard and Enterprise editions of SQL Server provide management tools and high-availability features such as clustering.

In terms of client browser support, SharePoint 2010 discontinues support for Internet Explorer 6 and only supports standards-based browsers, such as IE7 or later. SharePoint 2010 also supports Firefox 3.x and Safari.

Run the Upgrade Checker Tool

The next step after ensuring that front-end servers run Windows Server 2008 on 64-bit hardware, back-end servers run SQL Server 2005 or later, and that clients are using a standards-based browser, is to run stsadm -o preupgradecheck. PreUpgradeCheck is included with SP2 for SharePoint 2007 and uses rule files -- OssPreUpgradeCheck.xml for Microsoft Office SharePoint Server (MOSS) and WssPreUpgradeCheck.xml for Windows SharePoint Services (WSS) -- to check for configuration details and create a report.

Of course, before you can run PreUpgradeCheck, you must install SP2. The installation wizard is relatively straightforward, but there are several things to keep in mind. First, provide notice to users of planned downtime because you should stop the front-end IIS services on each server and back up and detach the content databases before proceeding. It's a good idea to back up front-end and application server files, too, especially if you have customizations.

Second, install the WSS SP2, cancel the configuration wizard, and then install MOSS SP2.

Finally, after the update processes complete, check for errors in upgrade.log, located in the version 12 hive logs directory. Look for instances of fail or error. If installation completes successfully, upgrade.log should include the strings shown in Figure 1. Click here for more information about updates..

After running PreUpgradeCheck, the detailed report it generates contains useful information about the details of your environment and includes specifics about farm topology, server configuration, Alternate Access Mappings (AAMs), databases, features, site definitions and so on. The immediate output in the command prompt also indicates if any categories do not pass; that is, they require you to make changes before moving to SharePoint 2010. The detailed .HTM file is helpful for finding out more about what you need to do to resolve the underlying condition. Look for the following details in the file that may need to be addressed:

• Language packs. If your configuration requires language packs, you need to plan to update the language packs to the latest versions after moving to SharePoint 2010.
• AAMs. If you plan to migrate to SharePoint 2010 and use new servers (or new server names), there's a good chance you will need to make URL-related changes such as updating AAMs and DNS entries.
• Site definitions. Sites that use custom site definitions require a definition file that SharePoint 2010 uses to upgrade the site. You need to create this file to fit your custom definition. For more information, see tinyurl.com/mulfcb.
• Features. Examine the report for missing features, and install any that are missing.
• Lists. Check for size and the number of lists because both influence migration speed. Microsoft has published guidance for performance sizing recommendations at tinyurl.com/kueoov. If your lists have more than 2,000 to 5,000 items or if the environment has grown to exceed other recommended performance guidelines, bring it back in line with best practices.
• Configuration DB and Content DB orphans. In the course of performing administrative tasks or user operations, the situation may arise where SharePoint schema or database items exist with no parent or child relationships. These items include lists without parent sites, documents with no parent document library, list items with no parent list, Web pages with no parent site, timer jobs and so on. The PreUpgradeCheck tool does not always find orphans and they may not appear in the Central Administration site, so you should manually check for orphaned objects. There are two types of orphans, configuration orphans and content orphans. Configuration orphans are items that exist in the configuration DB, but have no child component in the content DB. Content orphans exist in two cases: either a blank site is mapped in the configuration DB but does not have the existing content DB associated with it, or the correct content DB is associated with the site in the configuration DB, but there are stray items in other content DBs.

Figure 1: Succesful SP2 instalation entries from upgrade.log

It is relatively straightforward to resolve configuration orphans; detach the content DB and reattach it (stsadm -o deletecontentdb and stsadm -o addcontentdb).

Don't forget to run stsadm -o preparetomove beforehand in MOSS 2007 environments.

To resolve a content orphan where the site is mapped to the incorrect, empty content DB, back up and delete the incorrect content DB and attach the appropriate one.

To resolve a content orphan where orphaned content DBs exist, back up your production site, delete it, attach the orphaned content DB to make it accessible, and delete it. Then you can restore the backed-up site.

Check out KB articles 918742, 918744 and the STSADM commands -o databaserepair, -o deletecorruption, -o repairorphans and -deleteconfigurationobject -id <objectId> for more information.

Keep in mind that configuration details may differ among front-end servers, so run PreUpgradeCheck on each server and check for any configuration differences.

By running stsadm -o preupgradecheck -localonly, you can check an individual server, then compare the resulting .HTM reports using a tool such as WinDiff.

Find here more information about PreUpgradeCheck.

Clean and Standardize

Customizations are one of the more time-intensive issues to address before moving to SharePoint 2010 because even in the simpler scenarios of minor site customizations, transitioning entails recording specifics, migrating, and then verifying and fixing issues.

For larger customizations, or for those using third-party tools, the increased complexity can turn migration of customizations into a full software development project.

From the IT pro perspective, standardizing where possible, documenting customizations, and cleaning up data and configuration details all help to mitigate issues for developers.

Figure 2: Customization Migration Best Practices

I covered some cleanup possibilities earlier. Checking for orphans, resolving feature and Web Part dependencies, optimizing lists, setting a hard database limit of 100GB and performing other optimizations will make the move easier.

Deleting unused sites, increasing quotas and starting a user-driven site cleanup initiative are additional opportunities to trim the migration size. You should also standardize solutions and features wherever possible, and consider if the best choice is to delete, reinstall or re-create customizations. Figure 2 shows some general best practices and options for customizations.

Because SharePoint 2010 is not released yet, there are limits to how much preparation and testing you can do for customizations.

The best approach for most environments is to plan to not upgrade in place, but to create a new farm, migrate content databases and then apply customizations.

With this approach, you could do a gradual upgrade and decommission previous servers as you migrate sites.

Leverage Virtualization Possibilities

The convenience of virtualization and related management tools has made it possible to validate and verify migration plans before updating the production environment.

Perhaps the most obvious possibility with virtualization is to re-create the production environment on a much smaller scale as virtual computers, and validate the migration or upgrade strategy before implementing it in the production environment.

Virtualization provides features such as taking a snapshot of the OS and restoring it on demand. This makes it possible to document the full migration steps in detail, so that when you update the production environment, it becomes a matter of following the steps

Looking Forward

I've covered readiness from a practical point of view and offered suggestions for actions you can take to prepare your environment for SharePoint 2010.

If you follow the key suggestions of moving to 64-bit, running the PreUpgradeCheck tool, resolving the discovered issues, and validating your plan in a virtual environment, you'll be in good shape for SharePoint 2010.

Pav Cherny is an IT expert and author specializing in Microsoft technologies for collaboration and unified communication. His publications include white papers, product manuals, and books with a focus on IT operations and system administration. Pav is President of Biblioso Corp., a company that specializes in managed documentation and localization services.