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.

Real World 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 http://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 can not use site settings to amend the lefthand 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 affects 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 nonupgraded 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 lefthand 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.

• 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.

Figure 23-20: Finishing the upgrade

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.