Book Excerpt -- Chapter 23: Upgrading from Microsoft Windows SharePoint Services 2.0

Applies To: Windows SharePoint Services 3.0

 

Topic Last Modified: 2008-07-29

This article is an excerpt from Microsoft Office SharePoint Server 2007 Administrator’s Companion by Bill English and the Microsoft SharePoint Community Experts and property of Microsoft Press (ISBN-10: 978-0-7356-2282-1) copyright 2007, all rights reserved. No part of this chapter may be reproduced, stored in a retrieval system, or transmitted in any form or by any means—electronic, electrostatic, mechanical, photocopying, recording, or otherwise—without the prior written permission of the publisher, except in the case of brief quotations embodied in critical articles or reviews.

If you have been using Microsoft Windows SharePoint Services 2.0, you have several Web sites that you might decide to upgrade to Windows SharePoint Services 3.0. This chapter will focus on how to upgrade a Windows SharePoint Services 2.0 installation to Windows SharePoint Services 3.0. If you need to upgrade from Microsoft Office SharePoint Portal Server 2003 to Microsoft Office SharePoint Server 2007, refer to Chapter 24, “Upgrading from Microsoft SharePoint Portal Server 2003.”

Before you upgrade, it’s best to read the relevant material. Fortunately, Microsoft has published a body of good, detailed information concerning the topic of upgrading your Windows SharePoint Services 2.0 installation, which you should read. Here are a few good starting points:

• Microsoft Windows SharePoint Services in Windows Server 2003 TechCenter found at https://www.microsoft.com/technet/windowsserver/sharepoint/default.mspx

• Deployment for Windows SharePoint Services 3.0 Technology found at https://technet.microsoft.com/en-us/library/Cc287737.aspx

Whichever upgrade option you choose, there are four stages that you need to complete for the upgrade to be successful:

• Planning the upgrade

• Pre-upgrade tasks

• The upgrade process

• Post-upgrade tasks

In this chapter, you’ll learn the most significant aspects of each part, which will allow you to formulate the extent of the task you are undertaking and plan for the upgrade process. This chapter focuses on the administrative tasks that you will complete using the SharePoint 3.0 Central Administration Web pages and the tools you can use during the upgrade process.

If you have a highly customized Windows SharePoint Services 2.0 installation, you should read this chapter in conjunction with Chapter 25, “Upgrading Site Customizations and Custom Site Definitions to Microsoft Windows SharePoint Services 3.0.” If you want to automate the upgrade process, refer to Chapter 24, which covers the use of the command-line tool stsadmn.exe in the upgrade process.

Understanding Your Upgrade Options

There are three approaches to upgrading a Windows SharePoint Services 2.0 implementation to Windows SharePoint Services 3.0:

• In-place upgrade

• Gradual upgrade

• Content database migration

An in-place upgrade is used to upgrade all SharePoint sites at once. This approach is the easiest and is best suited for single-server or small-volume deployments. A gradual upgrade installs Windows SharePoint Services 3.0 side by side with Windows SharePoint Services 2.0, and it allows you granular control of the upgrade process by allowing one or more site collections to be upgraded at a time. You also have the ability to revert the upgraded site back to a Windows SharePoint Services 2.0 Web site. Both in-place and gradual upgrades take place on the same hardware used by your Windows SharePoint Services 2.0 installation. A content database migration allows you to move your content to a new farm or onto new hardware, and therefore requires a greater number of servers to implement than the other two approaches. You could also use a database migration approach to gradually upgrade your Web sites to Windows SharePoint Services 3.0, keeping one set of servers—a Web farm—for Windows SharePoint Services 2.0 and a Web farm for Windows SharePoint Services 3.0.

In-Place Upgrade

Using the in-place upgrade option, the Windows SharePoint Services 2.0 implementation is upgraded in place (overwritten) with Windows SharePoint Services 3.0 and the SQL content databases are updated. Because of this, an in-place upgrade is an irreversible process; therefore, you should ensure that you have a tried and tested backup solution that you can use to restore the Windows SharePoint Services 2.0 solution.

The original sites are upgraded in-place, and you cannot view the previous versions of the sites after upgrade. This means you have no easy method of comparing or testing the upgraded Windows SharePoint Services 3.0 with the original Windows SharePoint Services 2.0 sites to verify that the upgrade process was successful. You have only your memory, documentation, or screen shots. If you use either the gradual or data migration approaches, you still have the Windows SharePoint Services 2.0 sites that you can use to verify that the upgrade process was successful.

The SharePoint Web sites are not available to site visitors during the upgrade process. The outage window for all users is the full time it takes to upgrade the entire server or server farm, plus the time required to check the results of the upgrade.

The advantage with this approach is that the site visitors continue to use the same URLs after upgrade. This approach is useful if you do not have another server available on which to install Windows SharePoint Services 3.0.

Gradual Upgrade

Using the gradual upgrade approach, Windows SharePoint Services 2.0 sites coexist with Windows SharePoint Services 3.0 sites on the same hardware until you are ready to uninstall the old version of the software. You can upgrade a site collection or a group of site collections one at a time. The upgrade process copies the data from the original SQL content database to a new SQL content database. The data in the new content database is then upgraded. The original data is maintained in the original database until explicitly deleted by the server administrator. Because of this, upgraded site collections can be easily rolled back to the previous version if necessary.

The gradual upgrade approach is best suited to organizations that want to stage the upgrade over a period of time either because of the time it will take to upgrade the Windows SharePoint Services 2.0 installation, because some feature (such as a language pack) is not yet available, or because they are waiting on some development work, such as a new site definition.

Most Windows SharePoint Services 2.0 sites are available to site visitors during the upgrade. Only site collections that are currently being upgraded to Windows SharePoint Services 3.0 are offline. (Note that the previous version sites are marked as updates only after they have been copied in preparation for upgrade.)

When the upgrade process is completed, the original URLs point to the upgraded version of the sites. This way, users can continue to use the same URLs they used before the upgrade.

Content Database Migration

Content database migration is also known as the advanced upgrade process because it is complex and requires many manual steps, especially if you want to retain the original URLs for the sites. It is like an in-place upgrade, performed on new hardware on a copy of the content, but it doesn’t retain anything from your current installation other than the content itself. If your current hardware is outdated or your current farm has just outgrown the hardware, this might be a scenario to consider. You do not have to migrate all your content databases at the same time. Therefore, it is similar to a gradual upgrade with the unit of upgrade being a content database, which can contain one or more site collections. As with the gradual upgrade approach, you can choose to maintain both Windows SharePoint Services 2.0 and Windows SharePoint Services 3.0 deployments. However, in this approach, the two versions of the software product are on different hardware. In a content database migration, you perform the following tasks:

• Install Windows SharePoint Services 3.0 on a new standalone or server farm installation.

• Make a copy of all databases except for the configuration database to the Windows SharePoint Services 3.0 installation.

• Attach the databases to the Windows SharePoint Services 3.0 installation. This forces an upgrade process, which upgrades the data in place.

As in the gradual upgrade approach, the original data is untouched in the original databases. Because of this, you can quickly reinstate the Windows SharePoint Services 2.0 sites if necessary.

You must use the content database migration approach if you have a scalable hosting mode implementation, you have enabled an Active Directory directory service account creation, or you want to switch between 32-bit and 64-bit hardware.

Planning Your Upgrade

Because of the downtime involved and the risk that the upgrade might take longer than expected or that some sites might need some rework after upgrade, it is critical that the server administrator plan the upgrade process, communicate this plan to site owners and users, and communicate what to expect during the process. Use the following list as a check list:

• Understand each approach.

• Review supported topologies. (See Table 23-1 for a list of the supported topologies.)

• Review system requirements for Windows SharePoint Services 3.0.

  You should refer to other chapters within this book that cover planning and installation. In addition, you will need extra resources for the upgrade process, in particular the space required on the SQL server, because the transaction logs will grow enormously during the upgrade process. The amount of space you require is also dependent on the upgrade option you choose—for example, gradual and content migration will need more resources than the in-place approach.

• Identify the Windows SharePoint Services 2.0 sites and workspaces that are no longer used or are no longer required.

  In large installations, this analysis can reduce the number of sites you must migrate by a considerable amount. You might want to restructure your site hierarchy, sometimes known as the site taxonomy. Do not assume you will just duplicate your old structure. You might find that this is the perfect opportunity to reorganize your Windows SharePoint Services implementation now that you have worked with it for some time. Initial installations of Windows SharePoint Services—especially those that did not go through a structure prototype and pilot stages—resulted in chaotic usage. This could be your chance to add logic to your installation.

• Review that all the settings of your Windows SharePoint Services 2.0 sites are the way you want them to be in Windows SharePoint Services 3.0.

  For example, by default in Windows SharePoint Services 2.0, members of the Local Administrators Group on the server running Windows SharePoint Services 3.0 can access any Windows SharePoint Services site (and all its content). In Windows SharePoint Services 3.0 this does not happen, so if your user ID is placed in the local administrator’s group, and you are not explicitly given access rights to Windows SharePoint Services sites, you might find that you are denied access after the Windows SharePoint Services 2.0 sites are upgraded.

  The security requirements in your organization might dictate that all members of the local Administrators group should not have global access to all Windows SharePoint Services Web site. However, to fulfill your administrative duties, your Active Directory userid might still need access to all Web sites, therefore, ensure you have explicit access to the Windows SharePoint Services 2.0 Web sites, before you upgrade them.

  Table 23-1 Supported Topologies

  Source topology (Windows SharePoint Services 2.0)	Supported destination (Windows SharePoint Services 3.0)	Unsupported destination
  Single server using WMSDE	Single server using Microsoft SQL Express	Farm
  Single server using SQL 2005 or SQL Server 2005	Single server using SQL 2005 or SQL Server 2005	Standalone server using SQL Express, Farm
  Farm	Farm	Single server using SQL Express, SQL Server 2000, or SQL Server 2005.

  If you cannot log on to a site after the upgrade process, log on as the system account, which is usually the Web application’s Internet Information Services (IIS) application pool identity.

  Note

  A fix was included in Windows SharePoint Services 2.0 Service Pack 2 (SP2) that allowed you to remove full access rights for users who are members of the local Administrators group. See Microsoft Knowledge Base article number 892295 found at https://support.microsoft.com/default.aspx/kb/892295 for details of the stsadm.exe command to enable this fix.

• Review your current Windows SharePoint Services 2.0 infrastructure, and decide whether you want to modify it, such as by reducing the size of your content databases, upgrading from SQL 2000 to SQL 2005, or using 64-bit technology.

• Estimate how long the upgrade process will take and the amount of space needed. Microsoft provides worksheets to determine how much disk space you need to perform the upgrade and how long the upgrade process might take.

• Understand how the URL redirects are handled during the gradual upgrade approach. During the upgrade process, each Windows SharePoint Services 2.0 Web site is moved to a new temporary URL. The new Windows SharePoint Services 3.0 Web site uses the old URL. During the upgrade process, users can still use the old URL and are redirected to the Windows SharePoint Services 2.0 Web site. When the site is upgraded, the redirect is deleted. More details of this can be found in the section “The Upgrade Process” later in this chapter.

  Important

  During the gradual upgrade process, certain client software, such as Microsoft Office client applications, cannot use these types of redirects. As part of your communication plan, you need to inform users of this and let them know they need to use the new temporary URL during the upgrade process.

• Perform a trial upgrade to find potential issues. This trial should take place in a non-production environment. If your production implementation contains a great deal of content, so will your trial environment. Performing this task enables you to estimate the amount of additional resources you need for the upgrade and the time it will take. This information is very important for the planning process.

• Test custom Web Parts with ASP.NET 2.0. Most Web Parts will work post upgrade. However, your developer will have to rebuild the custom Web Parts if he or she used ASP.NET 1.1 “obfuscation” tools or used application programming interfaces (APIs) that are removed from Windows SharePoint Services 3.0.

• Develop new and upgraded custom site definitions files. (See Chapter 25.)

• Determine how to handle customizations. (See Chapter 25.)

• Create a communication plan. You do not want your users to learn about the upgrade process while it is occurring.

Microsoft FrontPage Customizations

Although using Microsoft FrontPage 2003 makes it easy to change Windows SharePoint Services site Web Part pages, it does have a significant consequence. Initially, all Windows SharePoint Services Web Part pages are based on ASP.NET Web pages located on the file system in site definition folders; they are not stored in the content database. When these pages are first referenced, they are cached on the Web server. When a page is requested, the content database is searched for specific content, which is incorporated with the cached Web page and rendered to the user. This provides fast response time. The Web Part pages that are based on site definitions and cached in memory are known as ghosted (uncustomized) pages.

When a Windows SharePoint Services site is modified in FrontPage, these modified and now unique Web Part pages are stored in the content database. When a modified page is requested, it is not cached in memory and is known as unghosted (customized) pages. There are many disadvantages with unghosted pages—for example, unghosted pages are slower to render, and they are forced through the SafeMode parser and therefore cannot contain inline code. Additionally, changes to the underlying site definition Web Part pages do not percolate through to Web Part pages modified by FrontPage 2003.

If your Windows SharePoint Services 2.0 implementation contains no customized Web Part pages, or includes only small customizations of features—such as navigation bars, images outside Web Part zones, and Data View Web Part (DVWP)—your upgrade process might be relatively straightforward. However, if your Windows SharePoint Services 2.0 implementation has included more than a light degree of customization—such as drastically changing the look and feel, making changes to the default site definitions (which is not supported), or the heavy use of site definitions—you need to refer to Chapter 25, because you’ll have some re-customization work to perform before upgrading to version 3.0.

Organizing and Resizing Content Databases

Many organizations might not have considered the size of their site hierarchy when they designed their Windows SharePoint Services 2.0 implementation; so, before you upgrade to Windows SharePoint Services 3.0, you should review your storage and database sizes. Although there is no hard-coded limit to the size of the databases, SQL Server best practices recommend that databases be no larger than 30 GB. Beyond that limit, performance can slowly degrade. Windows SharePoint Services 2.0 documentation recommends a size of less than 50 GB. However, a properly configured Windows SharePoint Services 3.0 and SharePoint Server 2007 installation should be able to handle terabyte-sized content databases. So the issue is not what SharePoint can support, but instead comes down to backup and restore, high availability and disaster recovery solutions. Many organizations have limited the sizes of their Windows SharePoint Services database, so that they can achieve their service level agreements. Databases will grow over time and therefore the time taken to back up and restore, which is dependent on the infrastructure in use, can increase to the point where it can endanger an organization’s service level agreements.

As part of the upgrade planning process, ensure that your databases are smaller than 50 GB. This will make your upgrade easier to manage no matter which of the three upgrade approaches you choose. In fact, it is recommended that you not use the in-place upgrade approach if your database is larger than 30 GB. By not keeping to these size recommendations, the upgrade process can fail.

To reduce the size of your databases, you need to move Web sites or site collections to new content databases, either using smigrate.exe or stsadm.exe. There are also third-party tools such as SPSiteManager, found at https://www.microsoft.com/sharepoint/downloads/components/detail.asp?a1=724, that can help you divide your databases and can automate the process. This tool can also help to identify the site collection owners, which is really useful when you formulate your communication plan. Note that SPSiteManager is an unsupported tool from Microsoft.

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 https://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 https://www.microsoft.com/technet/prodtechnol/office/office2003/maintain/bureswss.mspx.

3. Install Windows SharePoint Services 2.0 SP2.

   Note

   For more information about installing Windows SharePoint Services 2.0 SP2, see https://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 https://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.

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

      

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 https://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 https://www.codeplex.com/Release/ProjectReleases.aspx?ProjectName=SPUS on the Releases tab) and SPReport (https://www.gotdotnet.com/workspaces/workspace.aspx?id=8eb2bfa3-aac8-4b5a-b3a2-5accb29970eb). 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 https://technet2.microsoft.com/Office/en-us/library/3479e99e-0734-4237-a412-9fc42bf8bd251033.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.

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”: https://blogs.msdn.com/krichie/archive/2005/10/25/484889.aspx, https://blogs.msdn.com/krichie/archive/2005/10/31/487365.aspx, and https://blogs.msdn.com/krichie/archive/2006/06/30/652453.aspx “SharePoint Orphans and Twins – Gotta love the little guys”: https://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!” https://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”: https://support.microsoft.com/kb/918744/

The Upgrade Process

This section provides additional details on the three upgrade approaches. The first stage in the upgrade process is to install Windows SharePoint Services 3.0. Then you can upgrade or migrate your Windows SharePoint Services 2.0 Web sites. The upgrade process is broken into four tasks, as follows:

• Task 1: Install Windows SharePoint Services 3.0 binaries

• Task 2: Run the prescan tool

• Task 3: Run the SharePoint Products And Technologies Configuration Wizard

• Task 4: Upgrade and migrate your Windows SharePoint Services 2.0 Web sites

If you want to use the content database migration upgrade approach, you should install Windows SharePoint Services 3.0 on your new server or servers. (The process is detailed in Chapter 5, “Installing Microsoft Office SharePoint Server 2007.” If you want to use the in-place or gradual upgrade approach, tasks 1 through 3 are detailed in this chapter. The first three tasks are similar for both upgrade approaches, and therefore, the details for these three tasks will detail both the in-place and upgrade approaches. Task 4 is upgrade/migration-specific and will be detailed separately.

You can also use the stsadm.exe tool to upgrade and migrate a Windows SharePoint Services 2.0 Web site.

Task 1: Installing Windows SharePoint Services 3.0 Binaries— In-Place/Gradual Upgrade Approach

To install the Windows SharePoint Services 3.0 binaries, complete the following steps:

1. Download Windows SharePoint Services 3.0 from the Microsoft download site, and run SharePoint_setup.exe.

2. If an Open File – Security Warning dialog box is displayed, click Run.

3. A Microsoft Windows SharePoint Services dialog box appears, asking if you want to proceed with the installation. Click Yes.

4. A dialog box displays the progress of the installation. This dialog box might disappear, but the installation is still progressing, so be patient.

5. When the Read The Microsoft Software License Terms page is displayed, review the terms. Select the I Accept The Terms Of This Agreement check box, and then click Continue.

6. If the setup program found an upgradeable product installed on the server, there will be an Upgrade tab with a title of Upgrade Earlier Versions, as shown in Figure 23-2. Choose one of the three following options:

   1. Select the Yes, Perform A Gradual Upgrade option button to initiate a gradual upgrade.

   2. Select the Yes, Perform An Automated In-Place Upgrade option button to initiate the in-place upgrade.

   3. Select the No, Do Not Upgrade At This Time option button to install Windows SharePoint Services 3.0 alongside the Windows SharePoint Services 2.0 implementation.

      Note

      If your Windows SharePoint Services 2.0 implementation does not support one of the upgrade approaches, the appropriate option button will be unavailable. You can see this in Figure 23-2, where the Windows SharePoint Services 3.0 setup program was run on a Windows SharePoint Services 2.0 standalone implementation that used Microsoft SQL Server 2000 Desktop Engine (Windows) (WMSDE).

      Figure 23-2 - The Upgrade tab: Upgrade Earlier Versions

      

7. Click the Server Type tab, shown in Figure 23-3. Your choice here is dictated by your current Windows SharePoint Services 2.0 installation. Select the Web Front End option button if you have a Web farm or you use SQL Server 2000 or SQL Server 2005. Otherwise, select the Stand-Alone option button, which should be used only if your Windows SharePoint Services 2.0 implementation is a standalone installation that uses WMSDE—that is, you are not using SQL Server 2000 or SQL Server 2005. Using the Stand-Alone option installs Microsoft SQL Server 2005 Express Edition, also known as SQL Express.

   Figure 23-3 - The Server Type tab showing the Web Front End and Stand-Alone options

   

   Important

   This is an important step, which is very easy missed. Make sure this does not happen to you. Otherwise, you will need to uninstall Windows SharePoint Services 3.0 and reinstall it.

8. The remaining two tabs, Data Location and Feedback, can be used to customize your installation as described in Chapter 5. If you plan to use the server for search, you should choose a location with plenty of disk space available.

9. Click Upgrade. Setup runs and installs Windows SharePoint Services 3.0 binaries in the C:\Program Files\Common Files\Microsoft Shared\Web server extensions\12 directory—unless you changed the default location—and the following two links are added to the Administrative Tools menu:

   1. SharePoint 3.0 Central Administration

   2. SharePoint Products And Technologies Configuration Wizard

   During this portion of the upgrade process, no databases are created or upgraded and no modifications are made to IIS.

10. When the installation has completed, the completion Web page is displayed, as shown in Figure 23-4. Clear the Run The SharePoint Products And Technologies Configuration Wizard Now check box, and then click Close.

    Figure 23-4 - Windows SharePoint Services 3.0 binary installation complete

    

Task 2: Running the Prescan Tool

This should be the second time you have run this tool. The first execution of the prescan tool should be at the planning stage. The syntax of the prescan tool is as follows:

prescan [/c file] /All | [/v] urls

If you have your own custom site definitions (custom templates), you can use the prescan /C parameter to specify a file path to the configuration files for custom templates. By adding custom templates to the configuration file, you tell prescan to mark them as custom templates. See Chapter 25 for more information on using this option. Other switches with this tool include the following:

• /All scans the entire farm.

• /v specifies Virtual Server scan mode; the default is SPSite scan mode.

• urls specifies a list of one or more SPSite or virtual server URLs to scan.

To run the prescan tool, complete the following steps:

1. Run the pre-upgrade scan tool at this stage to be sure that you have identified and addressed any issues. To do this, open a command prompt and type the following commands:

   CD C:\Program Files\Common Files\Microsoft Shared\Web server extensions\12\B IN prescan /All
   

2. Depending on the size of the installation, the pre-scan process can take some time. A percentage value will display showing progress. When complete, an “operation successful” message is displayed, followed by the names of two files—a log file and a summary file. The output looks similar to Figure 23-5.

   Figure 23-5 - Prescan output

   

3. The _Log.txt file contains a list of all Web sites scanned, files that are unghosted, and any custom templates. A portion of the file can be seen in Figure 23-6.

   Figure 23-6 - Preupgrade report _Log.txt file

   

   The _Summary.xml file contains similar information, as shown in Figure 23-7.

   Figure 23-7 - Preupgrade report _Summary.xml file

   

   Important

   Do not add any servers to your server farm after this point in the upgrade process, otherwise you could corrupt your installation. Wait until the upgrade process is complete.

Task 3: Running the SharePoint Products And Technologies Configuration Wizard

The SharePoint Products And Technologies Configuration Wizard creates a Windows SharePoint Services 3.0 Web application to host the SharePoint 3.0 Central Administration Web site. It creates a new configuration database to store configuration data for Windows SharePoint Services 3.0 and copies configuration data into this new database, from the Windows SharePoint Services 2.0 configuration database.

If you need language packs, install them now. In an in-place upgrade, if a particular Windows SharePoint Services 2.0 language pack is installed but its corresponding Windows SharePoint Services 3.0 language pack is not installed, at this point—that is, before the upgrade—the upgrade log records errors. However, the upgrade operation will still complete.

Run the SharePoint Products and Technologies Configuration Wizard using the following steps:

1. Click Start, point to All Programs, point to Administrative Tools, and then click SharePoint Products And Technologies Configuration Wizard.

2. In the SharePoint Products And Technologies Configuration Wizard, on the Welcome To SharePoint Products And Technologies page, click Next.

3. A message appears, notifying you that Internet Information Services (IIS), the SharePoint Administration Service, and the SharePoint Timer Service might need to be restarted or reset during configuration.

4. Click Yes to continue with the wizard.

   • A message appears, as shown in the Figure 23-8, notifying you that you should download and install new language template packs for the new version. Click OK to confirm the message and continue with the wizard.

     Figure 23-8 - Installing Windows SharePoint Services Language Template Packs

     

5. If this is a gradual upgrade, perform the following steps:

   1. The Connect To A Server Farm page is displayed, as shown in Figure 23-9. Select the No, I Want To Create A New Server Farm option.

      Figure 23-9 - Connecting to a server farm

      

   2. On the Specify Configuration Database Settings page, perform the following actions:

      • In the Database Server text box, type the name of the server running SQL Server 2000 or SQL Server 2005.

      • In the Database Name text box, either except the default database name, SharePoint_Config, or type a database name.

      • In the Specify Database Access Account section, type the username and password that will be used to connect to the SQL server. The username should be entered in the format domain\username.

      • Click Next.

6. If you did not choose the Stand-Alone server type, you are presented with configuration screens for the SharePoint Central Administration Web application. Complete these screens as follows:

   1. On the Configure SharePoint Central Administration Web Application page, if you want to use a specific port number for SharePoint Central Administration, select the Specify Port Number check box and then type the port number to use.

   2. In the Configure Security Settings section, select either NTLM or Negotiate (Kerberos) as your authentication provider, depending on your environment, and then click Next.

      Important

      To enable Kerberos authentication, you must perform additional configuration. For more information about authentication methods, see Chapter 5.

   3. The Completing The SharePoint Products And Technologies Configuration Wizard page is displayed, as shown in Figure 23-10.

      Figure 23-10 - Completing the SharePoint Products And Technologies Configuration Wizard

      

   4. If this is a gradual upgrade, the Advanced Settings button will be active. Use this to enable Active Directory Account Creation Mode. This feature is unchanged in Windows SharePoint Services 3.0.

   5. Verify the settings, and then click Next.

7. The SharePoint Products And Technologies Configuration Wizard will now perform 10 configurations tasks for an in-place upgrade or 11 configuration tasks for a gradual upgrade approach. A clean Windows SharePoint Services 3.0 install usually consists of 9 configuration tasks. Task 1 commences, which initializes the upgrade and checks whether the pre-upgrade scan tool has been run.

8. If this is an in-place upgrade, a message appears notifying you that if you have a server farm with multiple servers, you must run setup on each server to install the new Windows SharePoint Services 3.0 binary files before running the configuration wizard and starting the upgrade process. Depending on your server farm configuration, and where you are in the process of installing and configuring Windows SharePoint Services 3.0, you have three choices:

   1. If this is the only server in your farm, no other actions are necessary. Click OK to continue with the wizard.

   2. If you have other servers in your farm, and you have not yet run setup and the configuration wizard on the other servers, leave this message open on this server—the designated server—and then run setup and the configuration wizard on the other servers in the farm. When all the other servers are at this same stage, you can return to this, the designated, server and click OK to continue with the SharePoint Products And Technologies Configuration Wizard. You can also run the SharePoint Products And Technologies Configuration Wizard from the command line. See Chapter 24 for more details on how to do this.

   3. If you have already run setup and the configuration wizard on all servers, the SharePoint Products And Technologies Configuration Wizard has completed on the designated server, and the Windows SharePoint Services 3.0 farm has no pending jobs, click OK to continue with the configuration wizard.

9. The upgrade process then continues with task 2, initiating the upgrade sequence. This task can take some time, after which the other tasks run.

10. The Configuration Successful page is displayed, as shown in Figure 23-11. Review the settings that have been configured, and then click Finish.

    Figure 23-11 - The Configuration Successful page

    

Task 4a: Upgrading and Migrating Windows SharePoint Services 2.0 Web Sites—In-Place Upgrade Approach

To complete an in-place upgrade process, following these steps:

1. The SharePoint Products And Technologies Configuration Wizard closes and the Upgrade Running page opens, as shown in Figure 23-12. You might be prompted to enter your username and password before the Upgrade Running page will open.

   Figure 23-12 - The Upgrade Running page

   

   Important

   If the Upgrade Running page does not display or you get an error that the service is unavailable, this might be due to the excessive work that the server is undertaking, resulting in a timing issue. It does not mean that you have a failure. Do not reboot. Wait a while, and then click your browser’s refresh icon. You can also check for error messages in the Upgrade.log and the trace log files, which are located at %SystemDrive%\Program Files\Common Files\Microsoft Shared\Web server extensions\12\LOGS. The trace log is named in the following format: Machine_name-YYYYMMDD-HHMM.log, where YYYYMMDD is the date and HHMM is the time.

2. The process of upgrading the Windows SharePoint Services 2.0 Web site is automatically started and consists of a number of scheduled timer jobs, which are started sequentially. These might take a while to complete. To check on the status of the upgrade process, click the browser refresh icon. You can monitor each timer job by opening the new SharePoint 3.0 Central Administration Web page. Then on the Operations tab, under Global Configuration, click Timer Job Status. The progress column shows the percentage complete for the current timer job, as shown in Figure 23-13. This is not the progress for the whole upgrade progress— only for this particular timer job.

   Figure 23-13 - The Timer Job Status page

   

3. The upgrade is complete when the Status changes to No Job Pending, as shown in Figure 23-14.

   Figure 23-14 – Status showing No Job Pending

   

   Note

   If the upgrade fails or reports issues, refer to the Upgrade.log and Trace.log files.

4. On the Upgrade Running Web page, in the left navigation pane, under Actions, click Finalize Upgrade. The Finalize Upgrade Web page is displayed, as shown in Figure 23-15. This page shows an overview of known upgrade actions that you need to complete. Do not click Complete Upgrade until you have completed these actions and updated other servers in your farm.

   Figure 23-15 - The Finalize Upgrade page

   

5. If there are any other servers in the farm, then on each server complete the SharePoint Products And Technologies Configuration Wizard as described in task 3.

6. When the configuration wizard has completed running on all servers on the farm, return to the SharePoint 3.0 Central Administration Web page. At the bottom of the home page in the Farm Topology Web Part, all servers should be listed together with the services they are running.

Task 4b: Upgrading and Migrating Windows SharePoint Services 2.0 Web Sites—Gradual Upgrade Approach

Unlike the in-place upgrade, the gradual upgrade does not automatically upgrade any Windows SharePoint Services 2.0 Web sites. You have to manually start this process, either using the Central Administration Web pages or using stsadm.exe. The following procedure details the Central Administration method. Details on using the command-line tool stsadm.exe to upgrade sites is covered in Chapter 24.

As a pre-upgrade task, you should have decided the names for the temporary URL domains for your Windows SharePoint Services 2.0 Web sites. 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 host header. If this is your decision, at this point in the procedure create a CNAME entry on your DNS server if you haven’t already done so.

If Kerberos is enabled for the Windows SharePoint Services 2.0 Web site, ensure that you have registered your service principal names (SPN) for the new URL. End-user applications ask for a Kerberos service ticket based on the URL of the Web service. Therefore, you need two SPNs—one for the Windows SharePoint Services 2.0 new URL (http://departmentsold.contoso.msft) and another for the Windows SharePoint Services 3.0 Web site (http://departments.contoso.msft). To register the SPN for the new URL, use the following command, where contoso\Windows SharePoint ServicesAppPool is the IIS application pool identity for the IIS Web site http://departmentsold.contoso.msft:

setspn -A http://departmentsold.contoso.msft contoso\Windows SharePoint ServicesAppPool

Use the following steps to migrate Windows SharePoint Services 2.0 Web Sites using the gradual upgrade approach.

1. Open the SharePoint 3.0 Central Administration Web page if the SharePoint Products And Technologies Configuration Wizard did not automatically open it. Then on the Operations tab, under Upgrade And Migration, click Site Content Upgrade Status.

2. The Site Content Upgrade Status Web page is displayed, as shown in Figure 23-16. In the Next Action column, click Begin Upgrade for the Web site you want to upgrade.

   Figure 23-16 - Site Content Upgrade Status page

   

3. The Set Target Web Application Web page is displayed, as shown in Figure 23-17. First, check that the Web application you want to upgrade appears in the Web Application To Upgrade section.

4. In the New URL For Original Content section, type a port number or host header name. This should match the new URL you created in step 1.

   Figure 23-17 - Set Target Web Application page

   

5. In the Application Pool For New Web Application section, either use an existing application pool or create a new application pool. If you do create a new application pool, it is recommended that you use the same IIS application pool identity (account) for the new URL as you used for the pre-upgraded URL. If the existing application pool used the IUSR_ComputerName or IWAM_ComputerName accounts, then to change or obtain the passwords for these accounts, refer to Microsoft Knowledge Based article 297989, found at https://support.microsoft.com/kb/297989.

6. In the Reset Internet Information Services section, select either Restart IIS Automatically or Restart IIS Manually depending on how you want to restart IIS on other farm servers.

7. In the Security Configuration section, select either Negotiate (Kerberos) or NTLM, depending on your environment.

8. In the Content Databases section, select either Automatic Database Name Selection or Manually Set Database Names. If you choose the Automatic database name option, a new database will be created using the naming convention <old_database_name>_DB_Pair.

9. Click OK. The Operations In Progress Web page is displayed while the following actions occur:

   1. The new host header or port is added to the existing Web application.

   2. The IIS application pool is created, if chosen.

   3. A new Web application is created. It is named <original_web_application_name>_Pair, whose home directory location is: c:\Inetpub\wwwroot\wss\VirtualDirectories\GUID, with the host header or port of the original Web application. The new Web application is created using the new application pool.

      Note

      You must redeploy Web Parts in the bin directory of c:\Inetpub\wwwroot\wss\VirtualDirectories\GUID. You may need to create the bin directory if one does not already exist.

   4. A new database is created.

      When the Web application and database are created, the Site Collection Upgrade Web page is displayed, as shown in Figure 23-18.

      Figure 23-18 - Site Collection Upgrade page

      

10. Open a new browser window, and type in the Address text box the original URL for your Windows SharePoint Service 2.0 Web site—for example, http://departments.contoso.msft. You should be automatically redirected to http://departmentsold.contoso.msft, and your original Windows SharePoint Services 2.0 Web site should be displayed. If it is not, check that your DNS entry is set correctly. Do not progress further until you are able to successfully browse to your Windows SharePoint Service 2.0 Web site. If you need to administer the Windows SharePoint Services 2.0 Web site using the Windows SharePoint Services Central Administration Web pages, you need to use the new URL—that is, http://departmentsold.contoso.msft.

11. On the Site Collection Upgrade Web page, in the left navigation pane under Actions, click Upgrade settings.

12. The Upgrade Settings Web page is displayed. Select the check box if you want to reset your Web sites during the upgrade process, and then click Save.

    Note

    The default behavior is to keep your customizations during the upgrade process. This is the same default behavior as the in-place upgrade process. You can choose after the upgrade process to reset Web sites and pages to site definitions using the browser at a per-site level. However, with this setting, you can bulk reset all your Web sites within a content database, but only during the upgrade process.

13. On the Site Collection Upgrade Web page, select the check boxes next to the site collections you want to upgrade and then click Upgrade Sites.

14. The Sites Selected For Upgrade Web page is displayed, detailing the number of site collections, storage used originally, and the originating and target database names. Check that these details are correct by using the Web site analysis results obtained during the pre-upgrade tasks.

15. Click Continue. The Upgrade Running Web page is displayed, which is similar to the in-place upgrade process. A number of timer jobs are created. However, the mode is now Side-By-Side. Initially, the first job might be in a pending status. Once the job is in progress, it might take a while to complete.

16. The upgrade is complete when the Status has changed to No Job Pending. If the upgrade fails or reports issues, refer to the Upgrade.log and Trace.log files.

    Note

    Information on troubleshooting configuration wizard failures and how to resume an upgrade can be found at https://technet2.microsoft.com/Office/en-us/library/8c676788-f2bc-412b-b14e-6e13bee3e1301033.mspx?mfr=true.

17. Open a new browser window, and type in the address text box the original URL for your Windows SharePoint Service 2.0 Web site—for example, http://departments.contoso.msft. You completed a similar exercise in step 10, where you were automatically redirected to http://departmentsold.contoso.msft. However, now that the upgrade is complete, you will not be redirected. Instead, you should now see the upgraded Web site. You can still browse to your original Windows SharePoint Services 2.0 Web site by using the new URL—that is, http://departmentsold.contoso.msft.

Task 4c: Performing a Content Database Migration

A content database can contain one or more site collections. Using the content database migration approach, you can gradually migrate the content databases you have created in your Windows SharePoint Services 2.0 installation. After you have installed and configured Windows SharePoint Services 3.0 on a new farm, complete the following steps:

1. Configure your new farm to match the settings of your old farm. There are no automatic method available that will take a Windows SharePoint Services 2.0 farm and create a similar Windows SharePoint Services 3.0 farm. You have to manually complete this task, which might include the following steps:

   1. Create IIS Web sites for each IIS Web site in your Windows SharePoint Services 2.0 installation. For each IIS Web site, use the properties dialog box to increase the connection timeout value on the Web Site tab and, using the Configuration button on the Home Directory tab, increase the ASP script timeout on the Options tab. Although you could leave the creation of the IIS Web site to the Application Management Web page in step 4 of this procedure, by creating it now you can create the bin and resource directories for custom code and assemblies. Ensure you do this on all Web front-end servers if you have a farm implementation.

   2. Copy customizations, such as custom Web Parts and site definitions, from your old farm to all Web front-end servers. It is important that these customizations be deployed prior to upgrading the content database so that they will be available during upgrade. Custom Web Parts must be deployed to the bin folder of the Web application or to the global assembly cache (GAC) of the server. Site definitions should be deployed either during the Windows SharePoint Services 3.0 setup or after setup using the command line. See Chapter 25 for more information on this.

   3. Re-apply farm configurations, such as outgoing e-mail server, security and permissions, quota templates using the SharePoint 3.0 Central Administration Web pages. This is a manually intensive and error-prone task, so take extra care during this task.

   4. Ensure that all necessary services are started, by using the Services On Server link on the Operations Web page, as shown in Figure 23-19.

      Figure 23-19 - Services On Server page

      

2. Run prescan.exe on your Windows SharePoint Services 2.0 installation for content databases you plan to migrate.

3. Set the relevant Windows SharePoint Services 2.0 SQL content database as read-only. This will avoid the need to merge any updates post upgrade. Create a copy of the content databases on the SQL server that your Windows SharePoint Services 3.0 farm is configured to use. There are several options available, such as creating a backup of the SQL content database and then restoring it, using a different name if the SQL service is used by both the Windows SharePoint Services 2.0 and 3.0 farms, or copying the content database file and log file to the default database location on your SQL server and attaching it. The locations for a default SQL Server installation are as follows:

   • SQL Server 2000: C:\Program Files\Microsoft SQL Server\MSSQL\Data

   • SQL Server 2005: c:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data

   To attach the database, you can use one of the following tools:

   • SQL 2000: Enterprise Manager

   • SQL 2005: SQL Server Management Studio

   Or you can use the SQL command-line tool, osql.exe. For more information, refer to SQL Server 2005 Books Online, which can be found at https://technet.microsoft.com/en-us/sqlserver/bb428874.aspx.

   Note

   Users will see warning messages when the content databases are set to read-only. You must inform your users of this in your communications plan.

4. You can attach the content database that contains the root Windows SharePoint Services 2.0 Web site using either the SharePoint 3.0 Central Administration Web pages or stsadm.exe command, Use stsadm.exe to attach the content databases for large sites. The stsadm.exe command is detailed in step 9 of this procedure, and in Chapter 24. Otherwise, in the SharePoint 3.0 Central Administration, click the Application Management tab. Then in the SharePoint Web Application Management section, click Create Or Extend Web Application.

5. On the Create Or Extend Web Application Web page, click Create A New Web Application.

6. On the Create New Web Application Web page, complete the following actions:

   1. In the IIS Web Site section, click the Use An Existing IIS Web Site option button and select the IIS Web site you created in step 1.

   2. Alter the Security Configuration, Load Balanced URL, Application Pool, and Reset Internet Information Services sections, if appropriate. See Chapter 5 for more information on these options.

   3. In the Database Name And Authentication section, in the Database Name text box, enter the name of the content database you attached in step 3.

   4. In the Search Server section, select the appropriate Windows SharePoint Services search server and then click OK.

7. If you change the IIS Web site from Kerberos to NTLM authentication, a message is displayed. Click OK.

8. An Operation In Process Web page is displayed, after which the Application Created Web page is displayed. This states that there is no new SharePoint site collection created, which might lead you to believe that your content database was overwritten. This is not the case. Open a new browser, and type the address you created in step 1a.

   Note

   If you did not complete step 2 before copying the Windows SharePoint Services 2.0 content database, you will get an error Web page stating that prescan.exe also was not run on this content database and the upgrade process will fail.

9. If the Web application contains more than one content database, you can use the stsadm.exe command-line tool to add the other content databases similar to the following command:

   stsadm -o addcontentdb -url http://departments -databasename Departments_DB -databaseserver SQLServer

   The content database for the root site must be added in step 4 and is the first to be upgraded. However, once the root content database is upgraded, there is no particular order for subsequent content databases.

   Note

   If you try to use the Add A Content Database On The Manage Content Databases Web page, an error Web page is displayed stating that the database you are trying to attach requires an upgrade, which could time out the browser, and that you must use the stsadm.exe command. Using the command line allows you to batch the upgrade task and schedule it to run out of hours.

Post-Upgrade Tasks

After you have upgraded or migrated your Windows SharePoint Service 2.0 Web site, you should complete a number of post-upgrade tasks. One of these tasks is to review the log files, as previously mentioned, for any upgrade issues. The rest of this section details other tasks you should perform after the upgrade process is complete. You’ll likely think of other ones to add to the list.

Completing the Windows SharePoint Services 3.0 Installation

The upgrade process might not have started all the services you require, and the installation might not be completely configured. For example, items such as the outgoing e-mail server, security, permissions, and quota templates might not have been configured.

You might also like to take advantage of some of the new features available in Windows SharePoint Services 3.0. You should review the installation and complete any outstanding tasks.

Confirming Upgraded Sites

You should check each Windows SharePoint Services 2.0 Web site that was migrated or upgraded. Address any discrepancies between the old site and the new site. Also, ensure that sites using custom Web Parts, site templates, and site definitions are functioning correctly, and redeploy them if necessary.

You should also check sites where you used the Content Editor Web Part (CEWP) to run JavaScript to alter the page layer or to add functionality, such as adding a tree view to the left navigation area to list subsites. Not only might such scripts not work after the upgrade, resulting in an error icon in the status bar of your browser, but they might not be necessary.

Review the upgraded versions of your customized sites—that is, those based on .stp files or sites customized using FrontPage. Determine whether they are acceptable to your users. You might need to reset them to the site definitions and then customize them with SharePoint Designer.

Windows SharePoint Services 3.0 manages permissions through role definitions, not site groups. This allows a consistent experience at the list, folder, and item level. After an upgrade, the Windows SharePoint Services 2.0 site groups are mapped to role definitions. For users or groups who were assigned specific list rights, the upgrade creates new roles with the appropriate list rights and assigns them to the new role. Familiarize yourself with these new settings, and change any operational procedures and end-user documentation to reflect the new environment.

Resetting Site Definitions    Microsoft released a number of application templates for Windows SharePoint Services 2.0 that were tailored to address requirements for specific business processes or sets of tasks for organizations of any size. (See https://www.microsoft.com/technet /windowsserver/sharepoint/wssapps/default.mspx.) These were site template files (.stp) and consisted mostly of ghosted pages. If you used them, you will be pleased to hear that they are mostly unaffected by the upgrade process. The content of these sites will usually migrate with no issues, but the look and feel is slightly altered and new functionality does not appear—for example, you cannot use site settings to amend the left-hand navigation pane for the home page of the site, nor are the links on the home page security-trimmed. Most of the templates were provided in two formats: basic and custom. Custom templates not only include the additional lists and libraries, but the home page is customized. To reset a site, navigate to the Site Settings Web page, and in the Look And Feel column, click Reset To Site Definition. You can also reset using SharePoint Designer.

Deprecated Features

Windows SharePoint Services 3.0 has a number of new features, as well as ones that are significantly changed, deprecated, or removed. For example, the Calendar view type existed in Windows SharePoint Services 2.0 but has been upgraded for Windows SharePoint Services 3.0. It now includes a Year view in the left navigation pane that allows for easier navigation between months and also displays the current date.

Microsoft has aimed to make the upgrade as painless as possible, and most of your sites and the code you might have written for Windows SharePoint Services 2.0 will work in Windows SharePoint Services 3.0. However, there are differences, and you might not realize the effects of an upgrade until you have completed the upgrade process, which is why it is necessary for you to complete a trial upgrade as one of the pre-upgrade tasks. This section briefly covers the deprecated features but does not detail items in the object model that have been deprecated. You must refer to the Windows SharePoint Services 3.0 SDK for features that are still supported in Windows SharePoint Services 3.0. The three areas of particular interest are as follows:

• Branding

  The methods to use for branding your site have changed in the new version. For example, because Windows SharePoint Services 3.0 is based on ASP.NET 2.0, you can now use Master Pages to control the layout and structure of your pages. You should get your developer to reapply branding using the new methods. For more information, see the Windows SharePoint Services 3.0 SDK.

• Themes

  Themes have been reworked and redesigned based on ASP.NET 2.0 and are not kept during the upgrade process. Therefore, you need to either use the ones that come with Windows SharePoint Service 3.0 or create new themes. You can also design and apply themes using SharePoint Designer.

• Form Libraries

  Form libraries are now form document libraries. Therefore, if you created your own custom form libraries, you need to rework your form library definitions, create a new form library, and reapply the forms to the form libraries.

Revert Web Site

If you used the gradual upgrade approach, you have the ability to revert a Web site to the non-upgraded version 2.0 site. To do this, follow these steps:

1. Using SharePoint 3.0 Central Administration, on the Operations tab, under Upgrade And Migration, click Site Content Upgrade Status.

2. On the Site Content Upgrade Status Web page, on the same line as the URL that contains the site that you want to revert, click Continue Upgrade.

3. On the Site Collection Upgrade Web page, in the left-hand navigation pane, under Actions, click Revert Site.

4. On the Revert To Non-Upgraded Site Web page, ensure that the correct site collection is selected and then click Continue.

5. A message is displayed, warning you that all changes made to the upgraded site will be lost. Click OK.

6. The Operations In Progress page is displayed, after which the Site Collection Upgrade Web page is displayed (shown earlier in Figure 23-18), showing the reverted site collection as available to be upgraded.

   Note

   You can also use stsadm.exe to revert the site. For information on how to do this, see Chapter 24.

Finishing the Upgrade Process

After you have completed all the upgrade actions and are satisfied with the upgrade process, complete the upgrade process as follows:

• If you used the gradual or content migration upgrade approach, delete upgraded Windows SharePoint Services 2.0 Web sites.

• Remove Windows SharePoint Services 2.0 language packs.

• Return to the Finalize Upgrade Web page (shown earlier in Figure 23-15), and click Complete Upgrade. A message appears, as shown in Figure 23-20. If you are certain that you have finished the upgrade process, click OK. When the Finish Upgrade process is complete, the Operations Web page is displayed. There is no longer an Upgrade And Migration section on this page. All temporary data that was used during the upgrade process is removed.

  Figure 23-20 - Finishing the upgrade

  

• For each Web front-end server, uninstall Windows SharePoint Services 2.0, uninstall WMSDE if appropriate, remove the Web sites from IIS, and delete the associated Web site files and any assemblies used by the Windows SharePoint Services 2.0 implementation from the GAC for each Web front–end server.

  Important

  For an in-place or gradual upgrade, Windows SharePoint Services 3.0 tracks whether a Web site was created through Windows SharePoint Services 2.0 (\Web server extensions\60) or Windows SharePoint Services 3.0 (\Web server extensions\12) site definitions. After the upgrade process, any references to uncustomized (ghosted) front-end files are mapped from the \Web server extensions\60 directory to \Web server extensions\12. However, not every Web site is upgraded from \60 to \12. Any existing site definitions that do not have upgrade paths will still function but continue to point to their \60 pages. Before you uninstall Windows SharePoint Services 2.0, ensure you have checked all your customized site definitions. (See Chapter 25.)

• Delete the Windows SharePoint Services 2.0 configuration and content databases.

• If you used the content migration upgrade approach, decommission and reassign the Windows SharePoint Services 2.0 Web front-end servers.

Redistributing Content or Sites As Needed

After you have completed the upgrade process, you might want to redistribute content and sites. You might have completed some of this exercise as part of the pre-upgrade tasks. Windows SharePoint Services 3.0 provides additional options. Not only can you use stsadm.exe to redistribute site collections using the backup and restore options, you can also use the export and import options in stsadm.exe. These replace the use of smigrate.exe and use the new content migration application programming interfaces (APIs). For more information on the new APIs and stsadm.exe, see the Windows SharePoint Services 3.0 SDK and Administration Guide. After you have completed all the post-upgrade tasks, you cannot allow access to the Windows SharePoint Services 2.0 sites.

Summary

This chapter detailed how you might plan and implement an upgrade from Windows SharePoint Services 2.0 to Windows SharePoint Services 3.0. Both of these products have similar functionality, as well as a similar look and feel and, therefore, you may find that you and your users may need little or no training to use the new version, however they will need to be involved in the upgrade process. There are differences, Windows SharePoint Services 3.0 is based on ASP.NET 2.0, branding and customization is different; there is no longer an ISAPI filter; search uses SharePoint search and not SQL Server Full Text Search. You can upgrade your Windows SharePoint Services 2.0 Web sites to Windows SharePoint Services 3.0 Web sites using one of three upgrade approaches: in-place, gradual, or content database migration. Before you upgrade your environment, you must select the upgrade approach that best meets the needs of your organization and create a recovery plan for use if the upgrade process does not go as planned. For best results, follow these best practices:

• Back up your data before, during, and after the upgrade process.

• Determine the upgrade approach and how you will manage customizations.

• Design you Windows SharePoint Services 3.0 installation.

• Plan for additional storage, particularly on your SQL server.

• Test the upgrade in a non-production environment.

• Estimate the length of time the upgrade will take, and ensure you have a tested backout plan.

• Communicate your plan to managers, users, site owners, Web designers, and developers.