Pre-Upgrade Tasks

Whichever upgrade approach you decide to use, you must perform a number of pre-upgrade steps or your upgrade process might fail. Once you have completed the pre-upgrade tasks, you can commence your chosen upgrade approach. The pre-upgrade tasks are as follows:

1. Ensure your Windows SharePoint Services 2.0 deployment is working correctly.

   Note 

   The upgrade process will not resolve any problems you might have with your implementation. However, any outstanding problems might cause the upgrade process to fail, and depending on the point where it fails, it might leave your Windows SharePoint Services 2.0 implementation in an unusable state. This is particularly true if you are using the in-place upgrade approach. You will then have to restore your Windows SharePoint Services 2.0 environment before you can attempt the upgrade process again. The SharePoint Configuration Analyzer can analyze your Windows SharePoint Services 2.0 implementation and report a wide range of configuration errors. You can download the tool from http://go.microsoft.com/fwlink/?LinkId=25438&clcid=0x409.

2. Run and test a full backup of your SQL databases, and make sure you have copies of any customizations (such as site definitions), Web Parts and other files you would need to re-create your Windows SharePoint Services 2.0 environment. See the Microsoft TechNet article, "Backing Up and Restoring Web Sites Created with Windows SharePoint Services," at http://www.microsoft.com/technet/prodtechnol/office/office2003/maintain/bureswss.mspx.

3. Install Windows SharePoint Services 2.0 SP2.

   More Info 

   For more information about installing Windows SharePoint Services 2.0 SP2, see http://office.microsoft.com/en-us/assistance/HA011607881033.aspx and Microsoft Knowledge Base article number 875358, "You must update all the Web servers that are running Windows SharePoint Services in a Web farm," found at http://support.microsoft.com/default.aspx/kb/875358. This Knowledge Base article lists the version numbers of Windows SharePoint Services 2.0 and how to check and update a virtual server if the service pack did not update them correctly.

4. Ensure all Internet Information Services (IIS) virtual servers on each Web front-end server are at the same service pack and that all servers in the farm have the same security updates installed.

   You can check the version number of your virtual servers by completing the following procedure:

   1. From the Administrative Tools start menu, click SharePoint Central Administration.

   2. On the Windows SharePoint Services Central Administration Web page, under the Virtual Server Configuration section, click Configure Virtual Server Settings.

   3. The Virtual Server List is displayed. Check that each virtual server is at version 6.0.2.6568 or above, as shown in Figure 23-1.

5. Check again that your Windows SharePoint Services 2.0 installation is working as normal. Resolve any problems that the service pack or security updates might have introduced.

6. Perform a backup of your environment.

   Note 

   Windows SharePoint Services 2.0 SP2 changes the database schema. Therefore, any backups that you made when the server was running the original release version of Windows SharePoint Services 2.0 or Windows SharePoint Services 2.0 SP1 cannot be restored to a server that has Windows SharePoint Services 2.0 SP2 installed.

7. Install Microsoft .NET Framework 2.0 plus any security updates. This allows the use of ASP.NET 2.0 Web service extensions in IIS. That is, both ASP.NET version 1.1 and version 2.0 will execute side by side, but it does not automatically upgrade your existing IIS virtual servers to use ASP.Net 2.0. You can run your Windows SharePoint Services 2.0 Web sites on .NET Framework 2.0 after you have installed Windows SharePoint Services 2.0 SP2. This will allow you to test your custom Web Part on .NET Framework 2.0 prior to running them on Windows SharePoint Services 2.0.

8. Increase the ASP.NET runtime executionTimeout. You can specify this at the machine, site, application, and subdirectory levels-that is, alter the <httpRuntime> element in your machine.config or the web.config. For more information, refer to http://msdn.microsoft.com/library/en-us/cpgenref/html/gngrfHttpRuntimeSection.asp.

9. Install Windows .NET Framework 3.0 (formerly known as WinFX). There are separate versions for x86-based computers and x64-based computers. Ensure you use the correct version for your server.

10. Deploy upgraded definition files and new site definitions. Existing sites created from a custom Windows SharePoint Services 2.0 site definition should work in Windows SharePoint Services 3.0. However, to take advantage of much of the new functionality and to create new sites from your Windows SharePoint Services 2.0 custom site definitions, these must be upgraded. For more information, see Chapter 25 and the Windows SharePoint Services 3.0 SDK.

11. Communicate outage details to your site owners and users. To help your planning process and to find who to target your communications to, you need to analyze your current Windows SharePoint Services implementation. You can use SPSiteManager (found at http://www.codeplex.com/Release/ProjectReleases.aspx?ProjectName=SPUS on the Releases tab) and SPReport (http://www.gotdotnet.com/workspaces/workspace.aspx?id=). Once the product is released to manufacturing, the features from the SharePoint Configuration Analyzer, SPSiteManager, and SPReport may be merged depending on customer needs.

12. If you are planning a gradual upgrade approach, decide on your temporary domain names for your Web applications. For example, if the pre-upgrade URL for a Windows SharePoint Services 2.0 Web site is http://departments.contoso.msft, the new URL could be http://departmentsold.contoso.msft. Post upgrade, the new URL will be used for the Windows SharePoint Services 2.0 Web site and http://departments.contoso.msft will be used for the upgraded Windows SharePoint Services 3.0 Web site. You could use a new port number with the same host name for the new URL, such as http://departments.contoso.msft:8080, but usual practice is to create a new domain name.

13. Run the pre-upgrade scan tool, prescan.exe. To use this tool, you must be logged on as a member of the Administrators group on the local server. This tool is available as a separate download, the URL of which can be found at http://technet2.microsoft.com/Office/en-us/library/1033.mspx?mfr=true, and is part of the Windows SharePoint Services 3.0 setup program. It should be run prior to the upgrade process and again during the upgrade process, but before the SharePoint Products And Technologies Wizard is run. (See the "Task 2: Run the Prescan Tool" section later in this chapter.) Prescan.exe has two purposes:

    1. Parses and saves list definitions with the associated lists. After you apply Windows SharePoint Services 2.0 SP2, whenever a list is created it contains its list definition. Prescan calls the Windows SharePoint Services 2.0 SP2 method to complete this process for all lists.

    2. Reports common issues that will result in a failed upgrade.

    Such issues reported by this tool are as follows:

    1. The presence of customized site templates. You can then verify the customizations after the upgrade.

    2. The presence of orphaned objects.

    3. The presence of custom Web Parts. These need to be identified prior to the upgrade process so that a decision can be made whether they are needed when the site is migrated to Windows SharePoint Services 3.0. Such custom Web Parts will need to be investigated because they might need to be rebuilt or redeployed after the upgrade. Most custom Web Parts will continue to work after the upgrade, but they need to be tested on an ASP.NET 2.0 Windows SharePoint Services Web site.

Figure 23-1: Windows SharePoint Services 2.0 Virtual Server List

Orphan Objects

An orphan object is an entry in one SQL database table that points to a nonexistent entry in another SQL database table. The most common orphan is where there is an entry for a site in the sites table of the configuration database but no corresponding site entry in the content database sites table. Windows SharePoint Services 2.0 SP2 contained two fixes to prevent orphans, and it also contained an update to stsadm.exe that could be used to clean orphans from the database. You might notice that you have orphans if stsadm -o restore fails to restore the site, even with the -overwrite option when you know the URL exists, or stsadm -o deletesite fails to delete the site. Information on orphans can be found at the following locations:

• "Orphaned Sites - Part 1, Part 2, and Part 3": http://blogs.msdn.com/krichie/archive/2005/10/25/484889.aspx, http://blogs.msdn.com/krichie/archive/2005/10/31/487365.aspx, and http://blogs.msdn.com/krichie/archive/2006/06/30/652453.aspx

• "SharePoint Orphans and Twins - Gotta love the little guys": http://blogs.msdn.com/joelo/archive/2006/06/23/644954.aspx

• "Orphan KBs! How to remove your Windows SharePoint Services and SPS 2003 orphans in a supported way!" http://blogs.msdn.com/joelo/archive/2006/07/12/663629.aspx

• "Description of a new command-line operation that you can use to repair content databases in Windows SharePoint Services": http://support.microsoft.com/kb/918744/