Upgrade Considerations (Windows SharePoint Services 2.0)

This topic contains the following upgrade considerations:

• Upgrading from SharePoint Team Services to Windows SharePoint Services.

  There are two stages in upgrading from SharePoint Team Services from Microsoft or FrontPage 2002 Server Extensions from Microsoft to Microsoft Windows SharePoint Services:

  • First, you back up your existing Web sites using the Microsoft SharePoint Migration Tool and remove SharePoint Team Services or FrontPage 2002 Server Extensions from the virtual servers.

  • Second, you install Windows SharePoint Services on your server computer or to a new server, and restore your Web sites to new locations on the existing server, or to the same locations on a new server.

    There is no "upgrade in place" method for upgrading your server or your sites. Because Windows SharePoint Services requires Internet Information Services (IIS) to be in IIS 6.0 worker process isolation mode and SharePoint Team Services and FrontPage 2002 Server Extensions work in IIS 5.0 isolation mode, you cannot run both the old applications and Windows SharePoint Services at the same time. Your sites are likewise always upgraded by way of migration. For more information, see Considerations for Upgrading a Server from SharePoint Team Services to Windows SharePoint Services.

• Upgrading from WMSDE to SQL Server 2000 or SQL Server 2005.

  You can choose to upgrade your database from Microsoft SQL Server 2000 Desktop Engine (Windows) (WMSDE) to Microsoft SQL Server 2000 or SQL Server 2005, if you find you need more database features or more storage capacity than are provided with WMSDE. For more information, see Considerations for Upgrading from WMSDE to SQL Server.

• Upgrading from SQL Server 2000 to SQL Server 2005.

  If you are using SQL Server 2000 to store your Windows SharePoint Services databases, you can upgrade to SQL Server 2005. For more information, see Considerations for Upgrading from SQL Server 2000 to SQL Server 2005.

Considerations for Upgrading a Server from SharePoint Team Services to Windows SharePoint Services

If you want to upgrade a server from SharePoint Team Services or FrontPage 2002 Server Extensions to Windows SharePoint Services, consider the following changes:

• The architecture has changed considerably. For example, you can now use Windows SharePoint Services in a server farm configuration. Also, all site content is now stored in the content databases instead of on the file system, and configuration data for a server or server farm is stored in the configuration database. For more information about the new architecture, see Windows SharePoint Services 2.0 Architecture.

• The security model has changed. For example, you can now grant Windows SharePoint Services administration rights to a specific domain group, in addition to the server's local administrators group. For more information about the new security model, see Windows SharePoint Services 2.0 Architecture.

• There are many new features, some changed features, and some features that no longer exist in the new version. For more information about features included in Windows SharePoint Services, see Introducing Windows SharePoint Services 2.0.

In addition to these general changes, several specific issues should be considered when you upgrade your server to Windows SharePoint Services. The following sections describe these areas and help you manage the upgrade process.

Upgrading from SharePoint Team Services on Windows 2000 Server to Windows SharePoint Services on Windows Server 2003

Windows SharePoint Services requires that you be running Microsoft Windows Server 2003. If you are running SharePoint Team Services on Windows 2000 Server, you must upgrade your server to Windows Server 2003 and then upgrade to Windows SharePoint Services. To upgrade successfully, you must perform the following steps:

1. Use the SharePoint Migration Tool (smigrate.exe) to back up the SharePoint Team Services Web sites. For more information about backing up Web sites, see Migrating and Upgrading Web Sites (Windows SharePoint Services 2.0).

   Note

   Before you can use the SharePoint Migration Tool to migrate sites from SharePoint Team Services to Windows SharePoint Services, you must verify that you are running the update to SharePoint Team Services that updates it to function better with the SharePoint Migration Tool. To download this update, go to Office XP Web Services Security Patch: KB812708 (https://go.microsoft.com/fwlink/?LinkId=73999).

2. Remove SharePoint Team Services. For more information about removing SharePoint Team Services, see the SharePoint Team Services Administrator's Guide on the Microsoft TechNet Web site (https://go.microsoft.com/fwlink/?LinkId=74000).

   Note

   When you uninstall SharePoint Team Services, some content may be left on the file system in the virtual server directory. In Windows SharePoint Services, all content is stored in the content databases, rather than on the file system, and so you no longer need this content. Because you have already backed up the Web sites, you can delete this content from the file system after you uninstall SharePoint Team Services, and before you install Windows SharePoint Services. After you install Windows SharePoint Services you can restore the Web sites, and the content will be added to the content database.

3. Upgrade your server computer to Windows Server 2003, Standard, Enterprise, Datacenter, or Web Edition. For more information about upgrading to Windows Server 2003, see the Windows Server 2003 documentation.

   Note

   When you upgrade from Windows 2000 Server to Windows Server 2003, the FrontPage 2002 Server Extensions are automatically installed. If you do not need FrontPage 2002 Server Extensions, it is recommended that you remove them (from the virtual server, and from your computer) before you install Windows SharePoint Services. If you want to run both FrontPage 2002 Server Extensions and Windows SharePoint Services, you must first remove in FrontPage 2002 Server Extensions from the default Web site before installing Windows SharePoint Services. If the default site contains information that you wish to preserve, use the SharePoint Migration Tool to back up the data before removing FrontPage 2002 Server Extensions. See Migrating and Upgrading Web Sites (Windows SharePoint Services 2.0) for more information.

4. Install and enable ASP.NET. For more information about installing ASP.NET, see the Windows Server 2003 documentation.

5. Enable IIS and set it to run in IIS 6.0 worker process isolation mode, and then install Windows SharePoint Services. For more information, see Installation Considerations for Windows SharePoint Services 2.0 and Preparing Front-End Web Servers for Windows SharePoint Services 2.0.

6. Use the SharePoint Migration Tool to restore the backed up Web sites.

FrontPage 2002 Server Extensions Considerations

You cannot upgrade in place from FrontPage 2002 Server Extensions to Windows SharePoint Services. To upgrade successfully, you must perform the following steps:

1. Use the SharePoint Migration Tool to back up the Web sites based on FrontPage 2002 Server Extensions. For more information about backing up Web sites, see Migrating and Upgrading Web Sites (Windows SharePoint Services 2.0).

2. Remove FrontPage 2002 Server Extensions. For more information, see the SharePoint Team Services Administrator's Guide on the Microsoft TechNet Web site (https://go.microsoft.com/fwlink/?LinkId=74000).

3. Install and enable ASP.NET. For more information about installing ASP.NET, see the Windows Server 2003 documentation.

4. Enable IIS and set it to run in IIS 6.0 worker process isolation mode, and then install Windows SharePoint Services. For more information, see Installation Considerations for Windows SharePoint Services 2.0 and Preparing Front-End Web Servers for Windows SharePoint Services 2.0.

5. Use the SharePoint Migration Tool to restore the backed up Web sites.

Note that certain features from FrontPage 2002 Server Extensions, such as using ASP pages in a Web site and linking to a database file (such as an .MDB file) to display dynamic database content on a Web page, are not supported in Windows SharePoint Services and do not work in any Web sites you migrate to the new technology.

Role and Right Considerations

If you have a custom role that you created in SharePoint Team Services, a site group with the same name is created, and the Windows SharePoint Services rights that correspond to the SharePoint Team Services rights are assigned to the site group when you upgrade. In some cases, because of changes to how Windows SharePoint Services works, there is no corresponding right. The following table lists the rights mapping between SharePoint Team Services and Windows SharePoint Services.

For a complete list of the rights and site groups available in Windows SharePoint Services, see User Rights and Site Groups (Windows SharePoint Services 2.0).

Considerations for Migrating Sites from SharePoint Team Services to Windows SharePoint Services

You use the SharePoint Migration Tool to migrate sites from SharePoint Team Services to Windows SharePoint Services. The site migration process is optimized for use with standard team Web sites. This means that many types of customizations do not migrate properly or do not work in a migrated site. Also, because the feature set and architecture have changed significantly between or FrontPage 2002 Server Extensions and Windows SharePoint Services 2.0, several features that you could use in these environments do not work in Windows SharePoint Services.

The customizations and features that do not migrate include, but are not limited to, the following items:

Type of customization or feature	Explanation of migration issues
Customized home pages	Home pages customized by using a Windows SharePoint Services-compatible Web page editor such as Microsoft Office FrontPage 2003 revert to the standard team Web site home page. Home pages customized in the browser retain their customizations, including views that were added and changes that were made to the Quick Launch bar. Note: When you migrate a site, the default.htm home page is replaced with a new page. The original default.htm page is renamed as default_old.htm.
Customized view and form pages	Most view and form pages customized by using a compatible Web page editor such as Microsoft Office FrontPage 2003 revert to standard view and form pages. However, views created with other applications or that include settings not available in the SharePoint Team Services browser interface will not migrate.
Customized link bars	Link bars, such as the top link bar, that were customized using a Windows SharePoint Services-compatible Web page editor such as Office FrontPage 2003 revert to the standard link bars.
Custom script files executed on the server	By default, the ISAPI filter for Windows SharePoint Services blocks the use of any script files (such as ASP pages) that are executed on the server and are not part of the installation. If you want to use custom script files with your SharePoint sites, you must put the script files in a separate virtual directory, and create an excluded path for the directory in Windows SharePoint Services. This allows IIS to control the directory, rather than Windows SharePoint Services, and allows the ASP pages to run. Note that script files running on the client are not blocked. For more information about creating an excluded path, see Managing Paths (Windows SharePoint Services 2.0). For more information about ASP pages in Windows SharePoint Services, see Windows SharePoint Services 2.0 Architecture. To prevent script files from being included during migration, either add those file extensions to the blocked files list in the destination Windows SharePoint Services site, or remove those files from your SharePoint Team Services site before migrating. See Migrating and Upgrading Web Sites (Windows SharePoint Services 2.0). Caution: Custom script files that are not being executed on the server can be browsed by users with read access to the folder where they are stored on the server. Browsing the files can allow users to discover information such as user names and passwords contained in the script files, as well as network paths.
Custom pages that link to SharePoint lists	The SharePoint Migration Tool does not include an automatic link fixup tool. After migration, any links that you have created to point to specific lists are broken. You can update the links to refer to the current list location after migration. Note: If you have a link to a subsite, that link remains, but any links to parent Web sites or other Web sites at the same level do not work.
Customizations based on CAML	Customizations made to your site by using the Collaborative Application Markup Language (CAML) are not migrated. You must re-create these customizations. For more information about customizing SharePoint sites programmatically, see the Windows SharePoint Services Software Development Kit.
Files or folders with trailing spaces	Trailing spaces at the very end of a filename ("filename.doc ") are not supported in Windows SharePoint Services. You must change the file name and then add the file manually to your site.
Unsupported characters	The following characters are not supported in Windows SharePoint Services: /\:*?"<>|#{}%&~ or tab characters and multiple periods. If a file, folder, or URL name in your original site contains one of these characters, it is replaced with an underscore (_). Multiple periods are replaced with a single period. Additional digits may be appended to the file or folder name if there are conflicting renaming changes.
Files with file extensions that are blocked in Windows SharePoint Services	A new feature allows server administrators to control whether specific file types can be uploaded or downloaded to the server. If a file in your site uses one of these file extensions (for example, .exe), the file is not migrated to the new site. If you know that certain file extensions are in a site you want to migrate, you can temporarily remove those file extensions from the list of blocked file extensions while you migrate the site. For more information about blocked file extensions, see Configuring Blocked File Extensions (Windows SharePoint Services 2.0).
Long file and folder names (more than 255 characters)	File and folder names longer than 255 characters are not supported in Windows SharePoint Services. You can rename files or folders that have long names before migrating a site, or rename them after migration and add them manually to the new site.
Lists with too many fields or columns	Lists in Windows SharePoint Services can only contain a certain number of fields or columns. If a list in your site contains too many fields or columns, it is not migrated. You must manually re-create the list. Note that this includes surveys. The maximum numbers for fields and columns are: 64 text fields, including the following field types: Single line of text, Choice, Hyperlink, or Picture 16 Lookup fields 16 Date and Time fields 16 Yes/No fields 32 Number and Currency fields 32 Multiple lines of text fields
Links with long URLs (more than 255 characters)	URLs longer than 255 characters are not supported in Windows SharePoint Services. Note that this character limit is for the URL and description.
User account limits	User account limits are not supported in Windows SharePoint Services. If you are using Active Directory account creation mode for user accounts, you can limit the number of users per site by using quotas. For more information, see Configuring Site Collection Quotas and Locks (Windows SharePoint Services 2.0).
Local user accounts	Local user accounts are only supported if you are using Active Directory account creation mode with Windows SharePoint Services, and local user accounts from your original site are not automatically created during migration. If you are using local accounts, first be sure that the server you are migrating to is using Active Directory account creation mode, and then add the users to the site manually after migration. For more information, see Installation Considerations for Windows SharePoint Services 2.0 and Managing Users and Cross-Site Groups (Windows SharePoint Services 2.0).
Subscriptions	The subscriptions feature in SharePoint Team Services 1.0 changed to the Alerts feature for Windows SharePoint Services. Users can create alerts in the new site to notify them about changes. To restore subscriptions as alerts, you must be sure that alerts are enabled for the virtual server you are restoring to. Set the number of alerts to unlimited so that the restore does not stop when it reaches a limit. Also note that if a user only set up subscriptions on the original site and hasn't added information to lists or libraries, his or her subscriptions won't get migrated. To resolve this problem, the user should create a new item in a list and then delete it. For more information about alerts, see Managing Alerts (Windows SharePoint Services 2.0).
Remote Web discussions and subscriptions	Windows SharePoint Services does not support using a server running Windows SharePoint Services in an intranet to discuss content on the Internet, nor does it support creating alerts for content on the Internet. For example, you cannot use https://server1 to create discussion items or alerts for https://www.example.com.
Web discussions and subscriptions from unavailable user accounts	If the user account for a Web discussion or subscription cannot be determined at restore time, the Web discussion or alert is restored with the user name of the administrator restoring the site.
Security from a site based on FrontPage 2002 Server Extensions	If the original server is running FrontPage 2002 Server Extensions, the security information (such as user roles) cannot be migrated.
Created By/Modified By fields	If the original user account is not available on the new server when the site is restored, the Created By and Modified By fields are set to the account that performed the restore.
Subsites that have the same name as a wildcard inclusion or exclusion	If you have set up included and excluded paths for the server that hosts the migrated sites, ensure that the names of those paths do not conflict with the names of the sites to be migrated. For example, if you had a subsite named https://server1/sites, and the /sites path on the new server is a wildcard inclusion, the https://server1/sites subsite is not migrated. For more information about included and excluded paths, see Managing Paths (Windows SharePoint Services 2.0).
Theme applied to site	If the original site was based on SharePoint Team Services and had a theme applied, when you restore the site, you may notice formatting issues such as the Search box being sized differently than it was. To fix these issues, apply a new theme in Windows SharePoint Services.
Specific file permissions on the file system	If you set access control lists (ACLs) on specific files or folders in your Web site, those ACLs are not restored, and the files and folders are accessible to any user with access to your restored site.
Currencies	When migrating a site from SharePoint Team Services to Windows SharePoint Services, Windows SharePoint Services converts some obsolete currencies to their modern equivalents. For example, German Deutschmarks are converted to Euros. However, only the format of the currency field is changed. The value for each entry is not altered and must be manually converted using the desired conversion rate.
SharePoint Team Services sites based on customized schemas	SharePoint Team Services sites that are based on customized schema files may not migrate properly to Windows SharePoint Services. Even though the Software Development Kit (SDK) documented how to customize schema files for SharePoint Team Services, the Smigrate.exe utility does not support migrating SharePoint Team Services sites based on customized schema files.

For more information about how to migrate Web sites, see Migrating and Upgrading Web Sites (Windows SharePoint Services 2.0).

Considerations for Upgrading from WMSDE to SQL Server

WMSDE has only a small subset of the capabilities available with SQL Server. For example, WMSDE does not include tools for backing up and restoring the database, and WMSDE doesn't provide full-text searching of site content as SQL Server does. Also, you cannot create a server farm with multiple back-end database servers if you are using WMSDE. If you are running Windows SharePoint Services, and you originally installed with WMSDE but now want to take advantage of these capabilities with SQL Server, you can upgrade your databases from WMSDE to SQL Server. For more information about switching to SQL Server, see Migrating from WMSDE to SQL Server 2000 (Windows SharePoint Services 2.0) and Migrating from WMSDE to SQL Server 2005 (Windows SharePoint Services 2.0).

Considerations for Upgrading from SQL Server 2000 to SQL Server 2005

Starting with Windows SharePoint Services Service Pack 2 (SP2), Microsoft SQL Server 2005 is supported. This section describes considerations for upgrading from SQL Server 2000 to SQL Server 2005, including workarounds that may be needed in some cases.

The following list describes the high level steps for upgrading from SQL Server 2000 to SQL Server 2005 as your database server for Windows SharePoint Services.

1. Back up all databases. This step is optional, but highly recommended. Before you upgrade to SQL Server 2005, it is a good idea to backup your configuration and content databases. If you have the SQL Server 2000 client tools installed on your server, you can use them to back up your databases. For more information about the client tools for SQL Server 2000, see the SQL Server 2000 documentation.

2. Run SQL Server 2005 Upgrade Advisor. Microsoft SQL Server 2005 Upgrade Advisor analyzes instances of SQL Server 2000 in preparation for upgrading to SQL Server 2005. Upgrade Advisor identifies deprecated features and configuration changes that might affect your upgrade, and it provides links to documentation that describes each identified issue and how to resolve it. For more information, and to download the tool, see this page about the SQL Server 2005 Upgrade Advisor (https://go.microsoft.com/fwlink/?LinkId=74001).

   Note

   Keep a copy of the SQL Server 2005 Upgrade Advisor report. You will need it after installing SQL Server 2005 to determine what steps you need to perform to have a successful upgrade.

3. If the SQL Server 2005 Upgrade Advisor report contains the warning description shown in the following table, it is recommended that you verify the hard drive partition you are using to store your database files is of adequate size before you upgrade to SQL Server 2005.

   Warning Description	Increase database size to accommodate DOCID map
   Issue	Because the DOCD map in SQL Server 2005 is stored in the database, the size requirement of the database has increased. Note: If additional space is not available during the upgrade, the full-text index population for the table pauses. If this occurs, check the crawl log to identify the error and increase the space of the file group accordingly.
   Workaround	You must ensure that the file group associated with the base table has enough hard drive space to accommodate the additional space requirement for all databases that contain full-text indexes. Use the following formula to estimate the space required. (2*FTK+ 34 bytes) * RC Where: FTK = Full-Text Key Size RC = Row Count of the Table

4. Install SQL Server 2005 and upgrade the instance used by Windows SharePoint Services. For information about installing SQL Server 2005, see the SQL Server TechCenter (https://go.microsoft.com/fwlink/?LinkId=74002).

5. After you install SQL Server 2005, perform the necessary workarounds to resolve warnings from SQL Server 2005 Upgrade Advisor.

   The following tables describe all known issues and workarounds that are relevant to Windows SharePoint Services, which you must resolve after upgrading from SQL Server 2000 to SQL Server 2005. Note that the "Warning Description" row contains the description of the warning as shown in the SQL Server 2005 Upgrade Advisor report.

   Warning Description	Upgrading will cause Full-Text Search to use instance-level, not global, work breakers and filters by default
   Issue	In SQL Server 2000, new word breakers and filters could be added as global operating system level components only. SQL Server 2005 allows the instance-level registration of new word breakers and filters. This provides functional and security isolation between instances.
   Workaround	After upgrading to SQL Server 2005, use the sp_fulltext_service stored procedure to set the load_os_resources service property, which allows the components to be loaded. To do this, run the following command: sp_fulltext_service 'load_os_resources', 1
   Warning Description	The Microsoft Full-Text Search Engine for SQL Server (MSFTESQL) service will not load third party components by default
   Issue	Third party filters, such as a PDF filter, that are currently installed on the server will not be loaded by the MSFTESQL service by default after upgrading to SQL Server 2005.
   Workaround	To enable an instance of the MSFTESQL service to load a third party filter, you must set the load_os_resources property and turn off the verify_signature property on that instance. To do this, run the following command: sp_fulltext_service 'load_os_resources', 1 sp_fulltext_service 'verify_signature', 0