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.
|More Info|| |
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: http://download.microsoft.com/download/1/d/c//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.
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.
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 http://www.microsoft.com/downloads/details.aspx?displaylang=en&familyid=, you should note that Microsoft has announced that these will be the discontinued. (see http://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:
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
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.
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
Figure 24-2: Portal upgraded to Collaboration Portal Web site
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.
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.
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.
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."
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:
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.
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 http://www.microsoft.com/downloads/details.aspx?FamilyId=&displaylang=en for specific information on how the object models have changed.
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.
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.
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.
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.
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.
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.
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.
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 any references to cascading style sheets is lost during any of the upgrade options. You need to review and re-engineer your CSS solutions.