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
Open table as spreadsheet

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 http://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 dependant 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 http://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.