Microsoft Press: Upgrading from Microsoft SharePoint Portal Server 2003

This book excerpt is from Microsoft Office SharePoint Server 2007 Administrator’s Companion, Microsoft Press, January 2007.

Buy this book

Microsoft Office SharePoint Server 2007 Administrator’s Companion is a comprehensive reference that details features and capabilities of Microsoft Office SharePoint Server 2007. It delivers the easy-to-follow procedures, practical workarounds, and key troubleshooting tactics that you need for on-the-job results.

Authors

Bill English, MCSE, MCT, CTT+, GSEC certified, is a Microsoft MVP for Microsoft Office SharePoint Server. He is president of MindSharp, a leading training and consulting company for SharePoint Products and Technologies, and the author of several books on SharePoint Portal Server.

The Microsoft SharePoint Community Experts include Microsoft MVPs, real-world practitioners, and members of the Microsoft teams that develop and support SharePoint Products and Technologies.

Book excerpt -- Chapter 24: Upgrading from Microsoft SharePoint Portal Server 2003

This chapter is designed for those of you who are planning to upgrade an existing Microsoft Office SharePoint Portal Server 2003 implementation. Office SharePoint Portal Server 2003 is built on Windows SharePoint Services 2.0. Microsoft Office SharePoint Server 2007 is built on top of Windows SharePoint Services 3.0, and therefore much of Chapter 23, “Upgrading from Microsoft Windows SharePoint Services 2.0,” is relevant to the discussions in this chapter, as is Chapter 25, “Upgrading Site Customizations and Custom Site Definitions to Windows SharePoint Services 3.0.” You should also refer to documents published by Microsoft. Good starting points are “Office Online Chapter Overview: Plan and prepare for upgrade available” on Microsoft TechNet, located at http://technet2.microsoft.com/Office/en-us/library/53b8a28b-43c4-43aa-8854-d72d9b7b59c41033.mspx, and “Migration and Upgrade Information for SharePoint Developers,” a Microsoft Office Developer Center article located at https://msdn.microsoft.com/office/server/moss/2007/migration/.

The SharePoint Portal Server 2003 upgrade process is similar to the Windows SharePoint Services 2.0 upgrade process that was documented in Chapter 23. We will not repeat the detailed step-by-step procedures included in that chapter. However, in this chapter, we’ll explore the use of the stsadm.exe command-line tool in the upgrade process and the effect of the upgrade process on a SharePoint Portal Server 2003 installation.

Nota

If you took part in the beta program and want to upgrade pilot environments to Release To Manufacturing (RTM) Office SharePoint Server 2007, you must first upgrade to Beta2 Technical Refresh (B2TR). For help doing this, refer to the Microsoft TechNet article “Installing Microsoft Office SharePoint Server 2007 for Beta 2 Technical Refresh,” which is located at http://technet2.microsoft.com/Office/en-us/library/f49862ab-e067-4723-bb90-7eb1182c65ce1033.mspx?mfr=true. If your pilot environment included the Knowledge Network (KN) components, there is no straight upgrade path from Beta 2 to Knowledge Network Beta Technical Refresh. For more information on this issue, see https://blogs.msdn.com/kn/archive/2006/09/22/Getting_Ready_for_KN_Technical_Refresh.aspx.

There are not any tools provided to upgrade from SharePoint Portal Server 2001 to SharePoint Server 2007. If you have a SharePoint Portal Server 2001 deployment, you must migrate first to SharePoint Portal Server 2003 and then migrate again to SharePoint Server 2007.

The upgrade path from SharePoint Team Services is to upgrade to Windows SharePoint Services 2.0 and then to Windows SharePoint Services 3.0.

Nota

To upgrade from Microsoft Content Management Server 2002, see Chapter 22, “Upgrading from Content Management Server 2002 to Microsoft Office SharePoint Server 2007.”

Understanding Upgrade Options

You learned in Chapter 23, "Upgrading from Microsoft Windows SharePoint Services 2.0," that there are three options for upgrading a SharePoint Portal Server 2003 implementation to SharePoint Server 2007:

• In-place upgrade

• Gradual upgrade

• Content database migration

The Table 24-1 reconsiders these different approaches to help you find the one that works best for your implementation.

Table 24-1_ Upgrade Alternatives and Tradeoffs

Upgrade option	Pros	Cons
In-Place	Simple. Uses existing hardware.	Entire farm is offline during the upgrade. No ability to easily revert.
Gradual	Allows you granular control of the upgrade process at the site-collection level. Reduces the time a user is affected. You can revert to the original SharePoint Portal Server 2003 Web sites if needed. Uses existing hardware.	Requires SharePoint Server 2007 installation on the SharePoint Portal Server 2003 farm servers. Domain Name System (DNS) redirects for SharePoint Portal Server 2003 URLs during upgrade need to be created. Performance impact on SharePoint Portal Server 2003 servers can be significant because you’re running two platforms side by side. This option is hardware intensive, requiring additional memory and extra Microsoft SQL Server storage.
Content database migration	Allows moving to a new farm or new hardware while retaining farm content. Allows “Web application by Web application” migration to new farm. The SharePoint Portal Server 2003 farm is not affected by the upgrade process. Better performance than the gradual upgrade method.	Much more complex migration design. Granularity is at the content-database level. Involves many manual steps, with a high level of administrative and developer effort. Requires a new farm and double the SQL Server storage capacity. Some features are not upgraded, such as Search and all customizations.

Whichever upgrade option you choose, you need to complete the following four stages for your upgrade to be successful:

• Planning the upgrade

• Pre-upgrade tasks

• The upgrade process

• Post-upgrade tasks

Planning the Upgrade

Because of the length of time your SharePoint Portal Server Web sites will be unavailable and the risk that the upgrade process might take longer than expected or that some portal sites might need some rework after upgrade, it is critical that the your organization plan the upgrade process and communicate this plan with site owners and users so that they know what to expect during the process. In a large organization, you will be only one of a team of people involved in this project.

Planning is important to any upgrade or migration scenario, and you can use the following list as a checklist to assist you during the planning process.

• Understand each upgrade approach.

• Understand the updated features and how the changes in the architecture affect your existing Windows SharePoint Services 2.0 and SharePoint Portal Server Web sites, and review the supported topologies. SharePoint Server 2007 has carried over a large number of features from SharePoint Portal Server 2003, such as user profiles, audience targeting, and personal sites. The sections following this checklist cover the effect of the upgrade on your SharePoint Portal Server 2003 environment, including the effects on areas, listings, search, shared services, My Site, and customizations.

  Nota

  There is a spreadsheet available on the Microsoft download site that compares Windows SharePoint Services 2.0, SharePoint Portal Server 2003, Windows SharePoint Server 3.0, and SharePoint Server 2007. This spreadsheet can be found at the following link: https://download.microsoft.com/download/1/d/c/1dc632e8-71e1-466f-8a2f-c940f1438e0a/SharePointProductsComparison.xls.

• Review the system requirements for SharePoint Server 2007. (See Chapter 5, “Installing Microsoft Office SharePoint Server 2007.”)

• Identify portal Web applications that are actively used and need to be upgraded. You can back up and retire portal Web applications that you do not want to upgrade.

• Review all your portal areas and Windows SharePoint Services sites and workspaces that were created under any managed paths beneath your portal Web application, such as http://portal/sites/department. Doing so will help you know where your content is so that if you want to restructure the areas within your portal Web site, you can do so in advance of the migration. Or, if you are using the gradual migration method, you will know the location to which each site collection should be migrated. This review can be completed either before or after the upgrade process and will not affect the time taken to upgrade your portal Web sites.

• Understand your current SharePoint Portal Server installation. Review and document your current environment, including all configuration settings—such as search scopes, audiences, content sources, and the Lightweight Directory Access Protocol (LDAP) query you used to import user profiles from Active Directory. Ensure you have up-to-date copies of files that you have used during the lifetime of the deployment, such as assemblies, Web Parts, site definitions, and image files. Be sure to include files you installed on the search and index servers, such as IFilters and file extension icons. Document any alterations that were made to web.config or any other files you might have altered for each virtual server, particularly those in the %SystemDrive%\Program Files\Common Files\Microsoft Shared\Web server extensions\60 directory. Review how the portal Web site is used and how content is added—in particular, the use of areas and listings. This list might seem excessive, especially if you are considering an in-place upgrade, but it will lead to a well-thought-out project plan and knowledge of the people who should be involved in the upgrade process. You should also ensure that users who administer the SharePoint Portal Server 2003 environment are configured explicitly with the correct level of access rights in your SharePoint Server 2007 deployment. Remember, SharePoint Server 2007 will not give access to members of the Local Administrators group by default.

  Importante

  You need to contact software vendors whose products you have installed on your SharePoint Portal Server 2003 environment to see whether they have upgraded versions for SharePoint Server 2007. You might need to update these products for the new version. If you will be running the two environments side by side, as is the case in the gradual and in-place upgrade options, ensure you investigate the ability to run different versions of the products on the same server.

• Review your current SharePoint Portal Server 2003 infrastructure and decide if you want to modify it, such as reducing the size of your content databases, upgrading from SQL Server 2000 to SQL Server 2005, or using 64-bit technology. Do not upgrade your SQL Server as part of the upgrade process. Either complete this exercise well before you start the migration process or well after you have finished the upgrade process. As part of this task, create a diagram of your existing and post-upgrade architectures.

• Determine the order in which you plan to upgrade your servers in a Web farm implementation.

• Estimate the length of time the upgrade process will take and additional resources you might need, such as memory, storage, and backup media.

• Understand the URL redirection process in the gradual upgrade approach, and decide on your temporary domain names.

  Importante

  When you create Web applications using either the SharePoint 3.0 Central Administration Web pages or the Internet Information Services (IIS) Manager, ensure you use different Web application pools than the SharePoint Portal Server 2003 Web sites. Use the same account for the identity of both sets of application pools.

• Use a test environment to perform a test upgrade of your production environment, with a view to finding the potential issues that you’ll encounter during the production upgrade process.

• Identify the length of time the upgrade process will take and the amount of resources you will need. During the upgrade process you will run the prescan tool, which will help you identify issues you need to resolve before performing the upgrade process in production. The upgrade process also creates logs, and each entry is date and time stamped, allowing you to calculate the length of time the upgrade took. If you take note of the size of the content database—that is, the <portalname>_site database—prior to the upgrade and then obtain the time from the prescan.log, the calculation size_MB / time will provide you with an upgrade rate that you can use in your estimations. This upgrade rate will depend on your hardware resources and the available bandwidth between your SQL Server and your farm servers.

• Test custom Web Parts with ASP.Net 2.0.

• Determine how to handle customizations, including those made as the result of using Microsoft FrontPage 2003, custom site templates (.stp files), and custom site definitions. (See Chapter 25.)

• Create a communication plan for your organization so that everyone knows when their most important information will be upgraded to the new platform.

• Be sure that your users are trained and educated on the SharePoint Server 2007 software. Nothing will kill a great deployment like giving users a technology that they don’t know how to use.

Real World

Microsoft Office Web Components

If your environment included the Microsoft Office Web Components (OWC), which are available at https://www.microsoft.com/downloads/details.aspx?displaylang=en&familyid=38BE67A5-2056-46A1-84B1-337FFB549C5C, you should note that Microsoft has announced that these will be the discontinued. (see https://blogs.msdn.com/excel/archive/2006/07/17/668544.aspx.) However, these components will continue to work in Windows SharePoint Services 3.0 and SharePoint Server 2007 if you use the in-place or gradual upgrade approaches. If you choose the content migration option and therefore have a new server environment, they will not install by running ststpkpl.exe. To install OWC in your new environment, follow these steps. Copy the following three cab files from %SystemDrive%/program files\common files\Microsoft Shared\Web server extensions\6.0\wppacks in your Windows SharePoint Services 2.0 environment to a neutral directory, such as C:\temp, on each Web front-end in your new environment: microsoft.sharepoint.solutions.greatplains.cab microsoft.sharepoint.webparts.quickquote.cab microsoft.office.dataparts.cab On each Web front-end server, open a command prompt, navigate to *%SystemDrive%*\Program Files\Common Files\Microsoft Shared\Web server extensions \12.0\BIN and then type the following command for each cab file: stsadm.exe –o addwppack –filename c:\temp\*name_of_cab_file*.cab -globalinstall

Deprecated Features

You need to be aware of a number of deprecated features in SharePoint Server 2007. First, there is no longer a Topics Assistant that helps you categorize content in SharePoint Server 2007. Second, spsbackup.exe has been replaced by the Windows SharePoint Services 3.0 backup command-line tool, stsadm.exe. Third, unlike SharePoint Portal Server 2003, where each server in the farm hosted the Central Administration Web site, there is only one SharePoint Server 2007 Central Administration Web site, and it is hosted, by default, on the first server in the farm.

Similarly, the SharePoint Portal Server 2003 administrative object model has been deprecated in SharePoint Server 2007; therefore, any custom applications that rely on the administrative object model have to be rewritten to use the new object model in SharePoint Server 2007.

Other major features in SharePoint Portal Server 2003 that have been changed or deprecated are discussed in the following sections.

Areas

Once your SharePoint Portal Server 2003 portal Web site is upgraded, you will notice a different look and feel because your portal will be based on the Collaboration Portal site template. Figure 24-1 shows a portal before and Figure 24-2 shows a portal after the upgrade process.

Figure 24-1_ Portal prior to upgrade

The areas and their content are retained; however, the order on the top navigation bar has been altered. The Portal Owner QuickStart Guide Web Part is one of the depreciated Web Parts that you have to remove if it is on your home page.

Figure 24-2_ Portal upgraded to Collaboration Portal Web site

The portal no longer contains any application services, such as search and My Site. However, you still access these services (search and My Site) from the portal site, but they are now the responsibility of the Shared Services Provider (SSP)—that is, you cannot administer the application services using the portal administration pages; you must use the SharePoint 3.0 Central Administration pages.

In SharePoint Portal Server 2003, the area hierarchy that is visible through the browser on the top and left navigation bars and the Portal Site map is not reflected in the URLs of the areas. Each area is a heavily customized Windows SharePoint Services 2.0 subsite off the portal home Web page, and SharePoint Portal Server 2003 allows only 20 areas to appear under the portal root (home). When the root has 20 subsites, any new subsites are created in a Web directory, such as C1, C2, and so on. These Web directories are called buckets. This mechanism allowed you to reorganize your area taxonomy without breaking links. In Windows SharePoint Services 2.0, if you wanted to reorganize your site hierarchy, you needed to back up and delete the site from its current location and then restore it under a new parent site in the site hierarchy, using the smigrate.exe tool or FrontPage 2003. The need to dynamically reorganize the site hierarchy in SharePoint Portal Server 2003 was seen to be important. As a result, the need for buckets also caused some limitations. Not only did areas not inherit some of the basic Windows SharePoint Services 2.0 features, but there was some loss of usability. Many organizations like to manage the naming conventions of their URLs, especially on intranet-facing Web sites.

Windows SharePoint Services 3.0 includes the ability to dynamically re-arrange a hierarchy of SharePoint sites, known as re-parenting, and SharePoint Server 2007 has removed the “buckets” concept. If any areas have a bucket URL, then, the bucket Web directory is removed in the upgrade process. The area is given a new URL using the logical site structure as a guideline. For example, http://portal.contoso.msft/C1/departments is upgraded to http://portal.contoso.msft/departments if departments is a top-level area. If departments is a subarea, say, of the topics area, then the URL is upgraded to http://portal.contoso.msft/topics/departments. The upgrade process checks for URL naming conflicts, and a number is appended to the URL, starting with zero, for URLs where duplicate names are found.

Listings

In SharePoint Portal Server 2003, whenever an area, subarea, or topic is created, a specialized link list, called Portal Listings, is created. The Group Listings Web Part allows you to display these links on pages throughout a portal Web site. The Group Listings Web Part also provides a roll up of links from areas below a specific branch of your area taxonomy and can be used with audiences. Both Portal Listings and the Group Listings Web Part are not included in SharePoint Server 2007. Web Parts based on the Group Listings Web Part—such as “News for You,” “Latest News,” and “Links for You”—are therefore not available. During the upgrade process, a new list (named Listings) is created and the upgrade moves listings in this list and the Group Listings Web Part to the Content Query Web Part.

Through a portal site, there were many links in the browser that allowed you to add link items to Portal Listings, such as Add Listing, Add Person, Submit To Portal Area, Select A Portal Area For This List, Select A Portal Area For This Document Library, and Add A Listing For This Document. These are all removed during the upgrade.

Although Portal Listings are a specialized link list and therefore you can point to data held elsewhere, they can also contain content. During an upgrade process, the area is converted to a Windows SharePoint Services Web site, a document library named Pages is created, and a page layout .aspx file is created in that document library for each listing that contains content. The page created is based on the page layout Article page, with an image of the page shown on the left side of the screen, as you can see in Figure 24-3.

Figure 24-3_ Page layout files for each upgraded Portal Listings that contains content

As a post-upgrade task, you should review the newly created list i.e. Listings, and the pages created during the upgrade process. Other features of SharePoint Server 2007 might suit your needs, for example, if the original listings are only referenced on one area and you do not need to use audiencing for displaying, sorting, and grouping links on a page, then consider using the Summary Link Web Part.

Sites Directory

The site directory has changed between the two versions and can be seen in Figure 24-4 and Figure 24-5. The site directory search box is removed, as the default search box now can search the site directory site and its subsites.

Figure 24-4_ Site directory prior to the upgrade

Figure 24-5_ Upgraded site directory

By default, creating a site from the site directory does not create a new site collection, but creates subsites under the site directory. The default action can be changed by navigating to the top-level site settings for the portal Web site. Then, under Site Collection Administration, click Site Directory Settings. (This assumes you have enabled Self-Service Site Management for this Web application in Central Administration of your SharePoint Server 2007 deployment.) During the upgrade, any existing sites under the site directory remain as site collections and list items in the site directory list are migrated. For more information on the site directory, see Chapter 6, “Performing Central Administration and Operations Configuration,” and Chapter 7, “Application Management and Configuration.”

Search

During an in-place or gradual upgrade to SharePoint Server 2007, some search settings are upgraded. However, some elements are not upgraded, including the following ones:

• Index files

• Search scopes

• Search IFilters

• Word breakers

• Thesaurus files that you have installed

If you choose a database migration approach to upgrading, none of the search elements are upgraded, so you need to manually reconfigure these elements in the new environment.

Nota

If you have shared services, when you upgrade the parent portal, the settings from the parent portal’s servers are added to the upgraded Search database.

A number of changes have been made to how SharePoint Server 2007 searches content compared to SharePoint Portal Server 2003. For example, there is no automatic propagation of indexes. There is no Advanced Search Administration mode, which allowed you to create multiple indexes. In SharePoint Server 2007, there is only one index, and the management of that index is very limited in the SSP interface.

There are changes to crawl rules and schedules. Crawl rules are no longer hierarchical; instead, they are a flat list. Crawl schedules are now completely tied in with content sources—that is, you cannot define a crawl schedule outside of a content source. The Query object model has been replaced, and the entire Search object model has been changed. Be sure to reference the new SharePoint Server 2007 Software Development Kit (SDK) found at https://www.microsoft.com/downloads/details.aspx?FamilyId=6D94E307-67D9-41AC-B2D6-0074D6286FA9&displaylang=en for specific information on how the object models have changed.

Shared Services

Shared services in SharePoint Portal Server 2003 was an optional feature that you could enable. In SharePoint Server 2007, it is mandatory to have an SSP. In SharePoint Portal Server 2003, you had to affiliate shared services with a portal in an environment where you had multiple portals and possibly over a number of farms. You had to have a specific parent/child style of portal topology to run shared services effectively.

If you use shared services in SharePoint Portal Server 2003, your upgrade process requires additional steps, unless you have one SharePoint Portal Server 2003 Web farm and are using the in-place upgrade option. Otherwise, you should upgrade the shared services portal first and then any child portals you want to upgrade. The upgrade process for shared services will result in the shared services portal being replaced by a new SSP Web application.

Nota

If you need to upgrade a child portal first, for example, if you only want to upgrade a single child portal and not any others or the parent portal, create a temporary Shared Services Provider (SSP) in a new SharePoint Server 2007 environment and then upgrade the child portal and associate it with the temporary SSP for services.

In a gradual upgrade option, as long as the SharePoint Portal Server 2003 shared services portal has not been upgraded, this portal will continue to provide shared services to sites that have not been upgraded. The SSP in SharePoint Server 2007 will crawl everything that was crawled by SharePoint Portal Server 2003, and the SharePoint Portal Server 2003 shared services portal will continue to crawl the SharePoint Portal Server 2003 farm. This means that some content in your SharePoint Portal Server 2003 implementation will be crawled twice during the gradual upgrade process.

Therefore, you will see an increase in network bandwidth usage for crawling processes during a gradual upgrade process when shared services are involved in the overall upgrade process. To minimize the impact, you can reduce the scope of either the SharePoint Portal Server 2003 or SharePoint Server 2007 crawls, and as SharePoint Portal Server 2003 sites are upgraded, you can delete their start addresses from the SharePoint Portal Server 2003 search settings.

To ensure that you don’t introduce duplicate user profile and audience data in your environment, be sure to first upgrade the Job Server in your SharePoint Portal Server 2003 farm to the SharePoint Server 2007 platform. This ensures that user profile and audience data is managed by the upgraded server. This also ensures that the data is pushed from SharePoint Server 2007 to a SharePoint Portal Server 2003 environment by way of a scheduled job run by the SharePoint timer service. Until the migration is completed, some of your SharePoint Portal Server 2003 portals will use the profile and audience data that is generated by the SharePoint Server 2007 server.

My Site

The in-place upgrade process takes the SharePoint Portal Server 2003 My Site and upgrades it to the improved SharePoint Server 2007 My Site, which is a Windows SharePoint Services 3.0 site from an architectural viewpoint. My Site is still a personal site that allows a user the opportunity to aggregate information “for me,” “by me,” and “about me.” Significant enhancements include social networking, privacy controls, and Colleagues and Memberships Web Parts. Figure 24-6 and Figure 24-7 shows a My Site before and after the upgrade process.

Figure 24-6_ SharePoint Portal Server 2003 My Site

Figure 24-7_ Upgraded My Site

The home page of My Site is now called My Home, which is your private page. Your public view is called My Profile, which you can use to share information with other users. Your new My Site will contain all content that your old My Site contained, including any details from the profiles database and any links you might have added, both private and shared. However, any modifications made to the SharePoint Portal Server 2003 private page will not appear on My Home. In SharePoint Portal Server 2003, the My Site functionality is based on one My Site area, plus a personal site collection for each user. The My Site area provides the private and profile pages, but all content and any subsites you create are part of your personal site collection, created under the personal managed path. During the upgrade, a managed path named personal is created and the personal site collections and the My Site area are upgraded. However, in SharePoint Server 2007 your private page is truly the home or default page of your personal site collection and not a redirection to a page in the My Site area. This is another reason why the private page is called “My Home” page. The old My Site area is still available, but it does not appear as a tab on your My Site. If you append MySite to the upgraded portal site’s URL, such as http://portal.contoso.msft/MySite, the old My Site area is temporarily displayed (unpinned) as a tab, as shown in Figure 24-8.

Figure 24-8_ My Site (old)

The old My Site will contain Web Parts that will fail to render, as in the case of My Alerts Summary, which is not available in SharePoint Server 2007.

In a gradual upgrade, users continue to use the SharePoint Portal 2003 My Site until the user’s personal site is upgraded. Also, once the SharePoint Portal Server 2003 shared services is upgraded, if a user makes changes to her user profile, those changes will not be reflected on the SharePoint Server 2007 environment until the user has upgraded her My Site to the SharePoint Server 2007 platform.

With a content database migration, where the SharePoint Portal Server 2003 and SharePoint Server 2007 environments are available at the same time, users are provided with two sets of profiles and My Sites. This can confuse users, so be sure to communicate clearly when the database that contains their SharePoint Portal Server 2003 My Site has been upgraded to the SharePoint Portal Server 2007 platform.

SharePoint Portal Server Alerts

In SharePoint Portal Server 2003, you could manage alerts through My Site and the My Alerts Summary Web Part. Now in SharePoint Server 2007, alerts are managed at the site level. To obtain a global view of your alerts, you must use the Microsoft Outlook 2007 client.

Some of the alerts a user has configured will be upgraded; however, the alerts mechanism in SharePoint Server 2007 will now revert to the Windows SharePoint Services 3.0 alerts. You can no longer add an alert on what was an area, which are now Windows SharePoint Services 3.0 sites. Alerts on people are replaced by the e-mail option for a colleague alert. If a user created an alert on keywords in search, these will need to be re-created.

User Profiles and Audiences

The in-place and gradual upgrade option retains user profiles and audiences. However, you need to reconfigure content database migration options. You should review both the managed properties list and the audiences you use. You might find that now you can target information based on SharePoint groups. You might no longer need all the audiences you have created.

Permissions

SharePoint Portal Server 2003 security model objects, such as SPRole and SPList.PermissionsMask, have been replaced by a new role-based security model. As a result, the user interface for permissions is different. The upgrade process will migrate the existing security settings to the new security model. If any custom applications use the old security model objects, on recompilation you will get warnings. Be sure to investigate these warnings and take appropriate action to ensure your users have access to all the information they need.

Single Sign-On

There are no schema changes to Single Sign-On (SSO) for SharePoint Server 2007. For a gradual upgrade, configure SharePoint Server 2007 to point to the SharePoint Portal Server 2003 SSO database. For the content database migration option, copy the SharePoint Portal Server 2003 SSO database to the SharePoint Server 2007 SQL Server and then configure the SharePoint Server 2007 servers to use this database.

E-Mail Enabled Document Libraries

In SharePoint Portal Server 2003, you could link a document library with a Microsoft Exchange 2000 or 2003 public folder so that files attached to messages posted to that public folder were automatically down-stepped into the e-mail-enabled document library. In SharePoint Server 2007, this functionality has been replaced with the incoming e-mail feature. Therefore, you need to configure incoming e-mail at the farm level to restore the ability to archive documents from e-mail messages. Document libraries, discussion boards, calendars, and announcements can be enabled to receive new postings via e-mail. In addition, extensible support is provided for custom e-mail handlers in Windows SharePoint Services 3.0.

Custom Branding and Cascading Style Sheets (CSS)

Custom branding and any references to cascading style sheets is lost during any of the upgrade options. You need to review and re-engineer your CSS solutions.

Performing 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. When you have completed these pre-upgrade tasks, you can commence your chosen upgrade approach. The pre-upgrade tasks that were detailed in Chapter 23 should be read in conjunction with the following list of tasks:

1. Ensure your SharePoint Portal Server 2003 installation is working correctly, and in a Web farm environment, ensure that all Web servers are configured identically. This requirement also includes drive letter names. The upgrade process will notice any inconsistencies and will fail if any inconsistencies exist. Use the following tools to check your installation:

   1. The SharePoint Configuration Analyzer can be used to check your SharePoint Portal Server 2003 server topology by using the SharePoint Portal Server Central Administration Web pages. Under the Server Configuration section, click Configure Server Topology. At the bottom of the Configure Server Topology Web page, check that it states, “There are no issues at this time. Your farm is fine.”, as shown Figure 24-9. This does not indicate you do not have any issues, but it does state that you have a supported SharePoint Portal Server 2003 configuration.

      Figure 24-9_ SharePoint Portal Server 2003 server topology

      

   2. The prescan.exe tool, which you will run during the upgrade process, also indicates any issues it finds in your SharePoint Server 2007 installation, but again it might not find them all.

      Importante

      Prescan.exe cannot update locked, “over quota” sites or database orphans.

2. Run and test a full backup of your environment.

3. Install Windows SharePoint Services 2.0 Service Pack 2 (SP2), followed by SharePoint Portal Server 2003 SP2 whose features are described at https://office.microsoft.com/en-gb/assistance/HA100806971033.aspx. Be sure also to read Microsoft Knowledge Base article KB 887623 found at https://support.microsoft.com/default.aspx/kb/887623. If you are updating a Web farm, update all Web servers to both service packs at the same time. Check that all IIS virtual servers are at the same service pack level. See Chapter 23 for details on how to check this.

4. Perform a backup of your updated environment. You cannot use the backups from step 1 to restore your environment because applying the service pack made database schema changes.

5. Install the Microsoft.Net Framework 3.0. When you do this, you will have side-by-side installations of .Net Framework 1.1 and 3.0. ASP.NET Web server extensions must be enabled in Internet Information Services (IIS). To do this, use IIS Manager or the aspnet_regiis –ir command from the .NET Framework directory (%WinDir%\Microsoft.NET\Framework\v2.0.50727).

   Nota

   Although you can leverage ASP.NET 2.0 on Windows SharePoint Services 2.0 Web applications after you have installed SP2, SharePoint Portal Server 2003 Web applications do not support ASP.NET 2.0. This does pose a quandary for you on how you intend to check that custom Web Parts you have deployed on portal Web sites work correctly in an ASP.NET 2.0 environment. We suggest that, in a test environment, you change your portal Web site to ASP.NET 2.0 using IIS Manager to view the properties of the Web site. Then on the ASP.NET tab, choose 2.0.xxxx from the ASP.NET version drop-down list, as shown in Figure 24-10. However, if you do find issues, the real test will be in a SharePoint Server 2007 environment.

   Figure 24-10_ Web site properties—ASP.NET tab

   

6. Increase the ASP.NET runtime time out as detailed in Chapter 23, and use the IIS Manager to increase the Web sites’ Connection time out on the Web Site tab to 65000 seconds.

7. Although you should have communicated and worked with site owners and users prior to this point in the process, you should once more detail the outage schedule to them.

Performing the Upgrade Process

This section provides additional details on the three upgrade approaches described previously in Chapter 23. The upgrade process can be divided into the following four tasks:

• Task 1: Install SharePoint Server 2007 binaries.

• Task 2: Run the prescan tool.

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

• Task 4: Upgrade/Migrate your SharePoint Portal Server 2003 Web sites using one of the three approaches described previously.

We will detail, in this section, how these tasks are different than they were described in Chapter 23. In addition, we will detail the use of the stsadm.exe command line tool in the upgrade process. If you plan to use the content database migration approach, you should install the new hardware with SharePoint Server 2007 as detailed in Chapter 5, and then return to this chapter for details on the database migration task.

Task 1: Installing SharePoint Server 2007 Binaries—In-place/ Gradual Upgrade Approach

To install the SharePoint Server 2007 binaries, complete the following steps:

1. On the front-end Web server running Central Administration, install SharePoint Server 2007 from the CD by double-clicking on Setup.exe if the installation process does not automatically start. Setup will notice that you have an existing installation, and it will present you with a screen of choices to select your upgrade approach.

   1. Gradual Upgrade: Choose Yes, Perform A Gradual Upgrade.

   2. In-Place Upgrade: Choose Yes, Perform An Automated In-Place Upgrade (selected by default).

   3. Content Database Migration: No, Do Not Upgrade At This Time.

2. If you are upgrading a farm installation and this is the first server in the farm that you’re upgrading, change the default server type on the Server Type tab from Stand-alone to Complete. Use Standalone only if your installation of SharePoint Portal Server 2003 uses the Microsoft SQL Server 2000 Database Engine (MSDE).

   Nota

   The recommended upgrade option for a SharePoint Portal Server 2003 installation that uses MSDE is the in-place upgrade.

3. The remaining two tabs 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.

4. When Setup is complete, remember to clear the check box for starting the Post-Setup Configuration Wizard before you close the Microsoft Office SharePoint Server 2007 window.

   If you get a dialog box with the message, “In order to complete setup, a system reboot is necessary. Would you like to reboot now", click Yes and restart your computer.

Task 2: Running the Prescan.exe Tool

This should be the second time you have run this tool. The first execution of the prescan.exe tool should have been during the planning stage. (The syntax of the prescan.exe tool was described previously in Chapter 23.) Run the prescan.exe tool on one of your SharePoint Portal Server 2003 servers as explained in the following steps:

1. Open a command prompt, navigate to the Windows SharePoint Services 3.0 directory: %SystemDrive%\Program Files\Common Files\Microsoft Shared\Web server extensions\12\BIN, and type the following command:

   Prescan /c preupgradescanconfig.xml /all

   Nota

   In Chapter 23, you had to specify a configuration file only if your installation contained custom site definitions. SharePoint Portal Server 2003 depends on a number of site definitions that are used as templates to create areas within a portal Web site, such as Topics, News, Sites Directory, and My Site. If you do not specify the preupgradescanconfig.xml configuration file, the upgrade process will incorrectly identify these site definitions as custom templates, with the result that the upgrade process may not know how to handle area pages, which in turn may lead you to wrongly identify post upgrade tasks that need to be completed by your developer. The templates identified by the configuration file are those identified in the WEBTEMPSPS.XML located in the Windows SharePoint Services 2.0 directory *%SystemDrive%*\Program Files\Common Files\Microsoft Shared\Web server extensions\60\BIN, except for the STS template entry.

2. After the scan has completed, the names of the summary report and log files are displayed in the command-line window. These files should be reviewed for any outstanding issues, such as customized site definitions (templates) or customized Web Parts, as well as broken sites.

Task 3: Running the SharePoint Products And Technologies Configuration Wizard

Before running the configuration wizard, be sure to perform these actions:

1. Disable all antivirus software before trying to upgrade.

2. Deploy upgraded definition files and site definitions.

3. Upgrade custom Web Part packages. If you are using the content database migration upgrade option, redeploy all custom Web Parts to the new Web front-end servers. Similarly, if you are using the gradual upgrade option, you must redeploy your Web Parts to the \BIN folder of the new Web applications.

4. If you need language packs, install them now.

5. Ensure that all your SharePoint Portal Server 2003 Web applications are started on all Web front-end servers.

After performing these steps, it is time to run the configuration wizard. To successfully do this, follow these steps:

1. Run the SharePoint Products And Technologies Configuration Wizard on the first server in your farm. Choose the install type that matches the upgrade option you have chosen, and select a server type of Complete.

2. Progress through the rest of this task as detailed in Chapter 23, Task 3, steps 2 to 12.

   Nota

   Your SQL Server will now include a new database named SharePoint_AdminContent_*<GUID>*. For a gradual upgrade, it will include a new configuration database, which if you accepted the default, is named SharePoint_Config.

   In a Web farm environment, once SharePoint Server 2007 is successfully installed, either run the SharePoint Products And Technologies Configuration Wizard on the other servers or run the SharePoint Products And Technologies Configuration command-line tool (psconfig.exe) to upgrade the other servers to the SharePoint Server 2007 platform. To use the psconfig.exe command-line tool, follow these steps:

   1. Open a command prompt, and navigate to %SystemDrive%\Program Files\Common Files\Microsoft Shared\Web server extensions\12\BIN.

   2. For an in-place upgrade, use the following command:

   PSCONFIG -CMD configdb -CONNECT -SERVER <SQLServerName> -DATABASE <configDBname> -USER <Domain\username> -PASSWORD <pw> -CMD installfeatures -CMD services -INSTALL -CMD secureresources -CMD upgrade –INPLACE

   3. For a gradual upgrade, use the following command:

   PSCONFIG -CMD configdb -CONNECT –SERVER <DBSERVERNAME> -DATABASE <configDBname> -USER <user acct> -PASSWORD <pwd> -CMD installfeatures -CMD services -INSTALL -CMD secureresources -CMD upgrade –SIDEBYSIDE

   Here is an explanation of the elements contained within the preceding commands:

   • <SQLServrName> is the SQL Server that hosts your configuration database.

   • <configDBname> is the name of your configuration database, which for an in-place upgrade is the name of the configuration database that you created for your SharePoint Portal Server 2003 installation. For a gradual upgrade, it is the name of the configuration database you created when you ran the SharePoint Products And Technologies Configuration Wizard on the first server of your farm. The default name for SharePoint Server 2007 is SharePoint_Config. The name of the configuration database can be found on the Configuration Successful screen as shown in Figure 24-11.

   • <Domain\username> is the Server Farm administrator account. If you do not specify a valid username, psconfig returns an error message.

   Figure 24-11 - The Configuration Successful screen showing the name of the configuration database.

   

   Nota

   The psconfig command-line tool is a useful tool, and it has more parameters than those mentioned. For more information on the psconfig command-line tool, open a command prompt and type psconfig -?. To find more information on the configdb command, type psconfig –help configdb. If you have to repeat this process on multiple servers, I recommend you create a batch file that contains this command.

   Importante

   If you use the SharePoint Products And Technologies Configuration Wizard to upgrade other servers in the farm, select to join an existing farm. Then on the Advanced Settings page, if the server is an application server, select Do Not Use This Machine To Host The Web Site or if the server is a Web front-end server, select Use This Machine To Host The Web Site.

Task 4a: Performing In-Place Upgrade of SharePoint Portal Server 2003 Web Sites

To complete the in-place upgrade process, complete the following steps:

1. After you have completed the steps detailed in task 3, the SharePoint Products And Technologies Configuration Wizard closes and the Upgrade Running page opens, as shown in Figure 24-12.

   Figure 24-12 - Upgrade Running page

   

   If this is not a standalone implementation, in the left navigation pane you will see the words “Server Farm Configuration Not Complete” in red and a link to the administrator’s task list below it. When you click the link, you are redirected to the home page of the Central Administration Web application, as shown in Figure 24-13.

   Figure 24-13_ Central Administration—server farm configuration not complete

   

2. Once the upgrade process is complete on the first server in the SharePoint Server 2007 farm and the Upgrade Running page displays “No job pending,” click the Continue Gradual Upgrade link, and complete the upgrade process on the other servers.

3. If the upgrade fails or reports issues, check the event logs on the server and the 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. An example of an event log entry is shown in Figure 24-14. This particular entry warns of internal name changes.

   Figure 24-14_ Application event log—List schema changes

   

   Nota

   You should review these resources even if the upgrade is a success, as they will inform you of changes made and the timing of the upgrade process. During the test pre-upgrade task, this information can be used in the planning stage of the upgrade process.

Task 4b: Performing a Gradual Upgrade

If your SharePoint Portal Server 2003 environment enabled shared services, you should upgrade the parent portal first. Once you have decided which portal to upgrade, you must upgrade the root of the portal—that is, http://portal.contoso.msft. Once the root is upgraded, you can then choose to upgrade other site collections. A SharePoint Portal Server 2003 portal Web site will consist of a number of site collections: the root, such as http://portal.contoso.msft; a site collection for each personal site, such as http://portal.contoso.msft/personal/*\<username>; and sites under the managed path, such as http://portal.contoso.msft/sites/*\<sitename>. You might have other managed paths with other site collections. Because areas are just Web sites under the root, you will upgrade all areas under a given portal. The granularity of the gradual upgrade process is the site collection.

Gradually upgrading your site collections, including the root, is similar to the gradual upgrade task detailed in Chapter 23. There will be slight differences. For example, on the Set Target Web Application Web page, you will be asked for the SSP and Search database names. However, the two processes are basically the same. This section summarizes the tasks you should complete.

1. Ensure you have a healthy SharePoint Server 2007 environment by completing the following tasks:

   1. Navigate to the SharePoint 3.0 Central Administration Web site, and complete the administrative tasks listed there. Ensure all services that are applicable for the servers in the Web farm are started. An SSP will be created when you upgrade your first portal site.

   2. Review the log files.

   3. Review the event logs.

   4. Resolve any issues.

2. Check that the site collection’s SharePoint Portal Server 2003 Web application and the Windows SharePoint Services Web Application service are started on all Web front-end servers. This is required so that the Windows SharePoint Services 3.0 Timer service can create all the Web application pairs on all the required Web front-end servers. You can start this service using the following command line:

   stsadm -o provisionservice -action start -servicetype SPWeb

3. If this is your second attempt at upgrading a root Web application or a site collection that results in the addition of a content database, ensure that the databases created from the previous attempt no longer exist.

4. To upgrade your site collection, either use the SharePoint 3.0 Central Administration Web pages or use the stsadm.exe command-line tool. Use the following command as a model if you choose to use the stsadm.exe command-line tool:

   stsadm –o upgrade –sidebyside –url http://portal.contoso.msft –sitelistpath c:\sites.xml

   In this command, sites.xml is a file that contains a list of site collections to upgrade. The xml file should contain text similar to the following for each site collection:

   <WebApplication URL="http://portal.contoso.msft">
     <Database name=”portal1_site”>
       <sitecollection URL="http://portal.contoso.msft/personal/peter"/> 
       <sitecollection URL="http://portal.contoso.msft/sites/team" /> 
       (more as needed)
     </Database>
   </WebApplication>
   

   Nota

   To reduce the amount of typing and to ensure you don’t miss any site collections when creating this XML file, open a command prompt, navigate to the Windows SharePoint Service 2.0 directory *%SystemDrive%*:\Program Files\Common Files\Microsoft Shared\Web server extensions\60\BIN, type stsadm –o enumsites –url http://*<name of your portal>*, and redirect the output to a text file. This will provide a URL to each site collection in the virtual server. You need to run this command for each virtual server in your SharePoint Portal Server 2003 farm.

   Other parameters that you can use with the upgrade option are as follows:

   • -forceupgrade

   • -quite

   • -farmuser<Domain\userid>, which specifies the userid to use during the upgrade

   • -farmPassword<password>

The upgrade process will create one target database for each original content database, plus a single temporary database used during the upgrade process. You can change the names of these databases, but the default names are <Portalname>_SITE_Pair and WSSUP_TEMP_<GUID>. These databases will be created on the same SQL server as the original content database. You should check the settings of these databases and include them in your maintenance and backup procedures.

To revert a site collection to SharePoint Portal Server 2003, use the SharePoint 3.0 Central Administration pages, as detailed in Chapter 23. Before you revert a site, ensure that the site still exists in your SharePoint Portal Server 2003 environment. We recommend you take a copy of the site collection before you revert it by using the stsadm –o export command. See Chapter 30, “Microsoft Office SharePoint Server 2007 Disaster Recovery.”

Task 4c: Performing the Content Database Migration

Once you have installed and configured SharePoint Server 2007 on a new farm, complete the following steps:

1. On one of the servers on your SharePoint Portal Server 2003 Web farm, open a command prompt and navigate to the Windows SharePoint Services 3.0 directory %SystemDrive%\Program Files\Common Files\Microsoft Shared\Web server extensions\12\BIN. Then type the following command:

   prescan /c preupgradescanconfig.xml /all

2. Set the relevant SharePoint Portal Server 2003 SQL content databases as read-only.

3. Copy the content databases to the SQL server that the SharePoint Server 2007 uses.

4. Migrate the content database by using the SharePoint 3.0 Central Administration pages or the stsadm –o addcontentdb command, as detailed in Chapter 23.

Performing Post-Upgrade Tasks

After you have upgraded your SharePoint Portal Server 2003 Web site, you should complete a number of post-upgrade tasks as described in this section. You’ll likely think of other ones to add to this list.

• Verify that all Web front-end servers render the upgraded sites successfully.

• Perform a full crawl of any content you want to index.

• Re-create search scopes.

• For gradual upgrades, configure the profile, user profiles, and audiences.

• Install any IFilters, word breakers, and thesaurus files you required.

• Configure SharePoint Portal Server 2003 so that it does not crawl the same content as SharePoint Server 2007.

• Manually reconfigure all search settings in the new environment.

• Configure incoming e-mail to reinstate any e-mail-enabled document libraries you had in SharePoint Portal Server 2003 or Windows SharePoint Services 2.0.

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

• Update your SQL Server operational procedures to include the new database, and remove those no longer in use. Shrink the transaction logs to reclaim disk space.

• In the gradual and in-place upgrade approach, where you no longer require SharePoint Portal Server 2003 to run side by side with SharePoint Server 2007, perform the following tasks:

  • Remove Windows SharePoint Services 2.0 language packs.

  • Uninstall SharePoint Portal Server 2003.

  • Uninstall MSDE if appropriate.

  • Remove the Web sites from IIS, and delete the associated Web site files and any assemblies used by the SharePoint Portal Server 2003 implementation from the global assembly cache (GAC) for each Web front-end.

  • Decommission index servers that are no longer in use. In SharePoint Server 2007, you need only one index per farm. When you upgrade, the indexes are stored on the job server and the configuration settings from other indexes in the farm are copied into the SSP database.

Nota

Along with Chapter 23, this chapter identified the extent of the task in front of you. Use the checklist at the end of Chapter 23 to review the major points. We cannot stress enough the importance of performing and testing your backup and restore procedures. It is strongly recommended that you read the SharePoint Server 2007 Installation Release Notes. Check the Office 2007 Web site frequently for the most current information on the upgrade process.

Summary

In this chapter and the previous one, you learned about the upgrade process. The implementation and installation of SharePoint Server 2007 and Windows SharePoint Services 3.0 requires significant forethought and planning to be successful, and the same amount of thought and planning is needed when upgrading your existing SharePoint Portal Server 2003 and Windows SharePoint Services 2.0 Web sites. The more effort and thought you expend in creating your upgrade strategy, the greater the likelihood that the upgrade will be a success—and with less stress.