Udostępnij za pośrednictwem

How other services are affected by upgrade (SharePoint Server 2010)

  • Artykuł

 

Applies to: SharePoint Server 2010

When you upgrade from Microsoft Office SharePoint Server 2007 to Microsoft SharePoint Server 2010, you have the opportunity to take advantage of new features and new configuration options. In SharePoint Server 2010, the services infrastructure has been updated to give you more flexibility in how you configure services, and there are many more services than were available in Office SharePoint Server 2007. Because of this architectural change, upgrading your services data requires planning and thought beforehand. You need to understand the new services infrastructure, how services upgrade works, and the considerations to think about for specific services that you want to upgrade to the new version.

In this article:

  • Updated services infrastructure for SharePoint Server 2010

  • In-place upgrade with services

  • Database attach upgrade with services

  • Considerations for specific services

Updated services infrastructure for SharePoint Server 2010

In SharePoint Server 2010, services are no longer contained in a Shared Services Provider (SSP). Instead, the infrastructure for hosting services moves into Microsoft SharePoint Foundation 2010 and the configuration of service offerings is much more flexible. Individual services can be configured independently, and third-party companies can add services to the platform. Many services that stored data in the SSP database have their own databases — in some cases, several databases. When you enable new services, new databases are also created to store the data for those services. The following table lists services databases in your pre-upgrade and post-upgrade environments. This list is only an example. The list of databases will vary depending on which services are enabled in your environment.

Microsoft Office SharePoint Server 2007 services databases before upgrade SharePoint Server 2010 databases after in-place upgrade

  • Search database

  • SSP database

  • SSP Admin Site content database

  • Application Registry database

  • BDC Service database

  • Search Service Admin database

  • Search Service Crawl Store database

  • Search Service Property Store database

  • Session state service database

  • State service database

  • Taxonomy database

  • User Profile databases

  • WSS Usage database

  • More…

Before you begin the upgrade process for services, review the updated services infrastructure and determine which services you have to upgrade and which new services you want to incorporate into your upgraded environment. Plan the logical and physical architecture you need to support the services and service applications you want to host in your SharePoint Server 2010 environment. For more information, see Logical architecture components (SharePoint Server 2010) and the Services models in Technical diagrams (SharePoint Server 2010).

In-place upgrade with services

When you perform an in-place upgrade, all of your services infrastructure and the settings for the services themselves are upgraded as part of the process. The following sections and diagrams explain what happens to the different services components during the upgrade process.

  • Shared Service Providers (SSPs)

    During an in-place upgrade, any SSPs are converted to service applications and service application proxies, one per service. They are given default names (for example, if the SSP was named SharedServices1, the service applications will be named SharedServices1_service, such as “SharedServices1_Search). All SSPs that are upgraded keep their associations with the Web applications that consumed from that SSP. All SSP administrators are added to the SharePoint Central Administration Web site as delegated administrators.

  • Databases

    The SSP database is upgraded and data is copied into new user profiles and taxonomy databases. Other services information is moved into other service databases or the configuration database.

  • Sites

    The SSP Admin site is upgraded as a mostly blank site except for the Business Data Catalog profile pages. The site can be deleted after upgrade if it is not needed for Business Data Catalog pages.

Before in-place upgrade

  • Collect any settings that must be reapplied, such as scheduled timer job settings.

  • Review your services architecture and determine what, if any, changes to make after upgrade.

For detailed information about steps to perform before you begin an in-place upgrade, see Upgrade in place to SharePoint Server 2010.

During in-place upgrade

If you have a single SSP, all proxies for service applications are added to the default proxy group. The following diagrams show the changes to your farm that are made during in-place upgrade.

Services infrastructure before upgrade:

Upgrading one Shared Services Provider (before)

Services infrastructure after upgrade:

Upgrading one Shared Services Provider (after)

If you have multiple SSPs, they will all be upgraded together, and you will have multiple proxy groups after the upgrade. The following diagrams show the changes to your farm that are made during in-place upgrade.

Services infrastructure before upgrade:

Upgrading multiple SSPs (before)

Services infrastructure after upgrade:

Upgrading multiple SSPs (after)

For more information and detailed steps for performing an in-place upgrade, see Upgrade in place to SharePoint Server 2010.

After in-place upgrade

  • Configure new and upgraded services

    Many new services are available in SharePoint Server 2010. You can enable these new services after you perform an in-place upgrade.

    • You must create service applications to host any new services. You can use the Farm Configuration Wizard to quickly select and enable several new services in your farm, or you can configure the services manually.

    • You can also add proxies for any service applications that you want to use with different Web applications.

  • For Profile Services, upgrade any taxonomy data manually.

  • For Excel Services, provision a new unattended service account for the Secure Store Service.

  • For Business Data Catalog, consider migrating the Business Data Catalog profile pages to a new location.

For detailed information about post-upgrade steps for services, see Perform post-upgrade steps for an in-place upgrade (SharePoint Server 2010).

Database attach upgrade with services

Most services settings will need to be reconfigured when you upgrade via database attach. When you move your databases to a new farm and upgrade the content, you must create your services infrastracture in the new farm, and configure the services appropriately for your new farm and new version. You can attach the SSP databases from your old farm, but only the profile information in that database will be upgraded — any search information or other services settings will not be upgraded. You cannot upgrade Search databases by using the database attach upgrade approach.

If you are using the database attach approach for upgrading to SharePoint Server 2010, there are several steps to perform before, during, and after the upgrade to successfully reconfigure the services infrastructure.

Before database attach upgrade

  • When you configure the new farm, you must also configure the new service applications and service application proxies for the farm, and configure the settings for all services that you want to use.

  • If you are using Profile Services, and you have taxonomy data in your database, configure the Managed Metadata service before you upgrade. That way, you can upgrade any taxonomy data from the shared services database when you attach that database.

  • For InfoPath Forms Services, export any administrator-deployed form templates (.xsn files) and data connection files (.udcx files) from your Office SharePoint Server 2007 farm by using the following command:
    Stsadm.exe -o exportipfsadminobjects -filename <path to export CAB>

  • For InfoPath Forms Services, import any administrator-deployed form templates and data connection files to your new farm before you attach the content databases. Use the Import-SPIPAdministrationFiles Windows PowerShell cmdlet to import the forms.

For more information about how to configure your new environment before you perform a database attach upgrade, see Prepare the new SharePoint Server 2010 environment for a database attach upgrade.

During database attach upgrade

When you attach and upgrade the content databases, you also attach and upgrade the SSP database, which upgrades the profile information in the database. The following table provides an example of the services databases that exist before and after upgrade.

Microsoft Office SharePoint Server 2007 services databases that can be upgraded by using the database attach approach SharePoint Server 2010 databases after a database attach upgrade

  • SSP database

  • SSP database

    Only contains user profile data, no search or other services data. Note that the name does not change during a database attach upgrade.

  • Taxonomy database

    If the Managed Metadata service was configured before upgrading, and if taxonomy data existed in the SSP database, this database contains that data.

For more information and procedures for performing a database attach upgrade, see Attach databases and upgrade to SharePoint Server 2010.

After database attach upgrade

  • Reapply administrator permissions for services. By default, farm administrators have permissions to all services when you perform a database attach upgrade.

  • For Excel Services, you must provision a new unattended service account that uses the Secure Store Service to interact with Excel Services.

  • For InfoPath Forms Services, update any links that are used in the upgraded form templates by using the Update-SPInfoPathAdminFileURL Windows PowerShell cmdlet.

  • For Profile Services, upgrade any taxonomy data. You use the Move-SPProfileManagedMetadataProperty Windows PowerShell cmdlet to upgrade profile taxonomy data manually to the Taxonomy database and reconnect the data to the Managed Metadata and User Profiles service applications. The User Profiles service and Managed Metadata service must be in the same proxy group to upgrade and use the data.

  • For Business Data Catalog, consider migrating the Business Data Catalog profile pages to a new location.

For detailed information about post-upgrade steps for services, see Perform post-upgrade steps for a database attach upgrade (SharePoint Server 2010).

Considerations for specific services

The following services were available in Office SharePoint Server 2007 and can be upgraded to SharePoint Server 2010. Changes in the services infrastructure mean that there are additional things to consider when planning and performing an upgrade for an environment where these services are present.

User profiles

  • Services

    Two services are now used for user profiles and taxonomy information: the User Profile service and the Managed Metadata service. During in-place upgrade, these two services are automatically enabled and configured. If you are using the database attach upgrade approach, you can enable and configure the Managed Matadata service before you upgrade the User Profile service to upgrade the taxonomy data as part of the upgrade.

  • Databases

    • During in-place upgrade, user profile data from Office SharePoint Server 2007 is upgraded from the SSP database into a new user profile database. Any taxonomy data is upgraded, and you can copy the taxonomy data into a Taxonomy database for use by the Managed Metadata service after upgrade is complete by using the Move-SPProfileManagedMetadataProperty Windows PowerShell cmdlet.

    • During a database attach upgrade, user profile and taxonomy data from the SSP database is upgraded when the SSP database is attached, but the database is not copied and renamed. You can copy the taxonomy data into a Taxonomy database for use by the Managed Metadata service after upgrade is complete by using the Move-SPProfileManagedMetadataProperty Windows PowerShell cmdlet.

  • Any scheduled timer jobs will need to be reconfigured after upgrade. During upgrade, they are set back to their default times. Be sure to record your timer job schedules before upgrade so you can reapply the times.

  • Persisted properties that relate to the profiles (such as the MySite Host URL) are preserved during an in-place upgrade, but are not upgraded when you use database attach because they are stored in the configuration database, not the services database.

    The following properties are preserved during in-place upgrade, but not during a database attach upgrade:

    • MySiteHostURL

    • SearchCenterURL

    • EnablePersonalFeaturesforMultipleDeployments

    • ProfileStoreLanguage

    • ProfileStoreLanguagePacksApplied

    • ProfileStoreCollationID

    • DaysWorthOfEventsToKeep

My Sites

Upgrade the My Sites host at the same time that you upgrade the profile services. You do not need to upgrade the My Sites at the same time. For best results, upgrade My Sites (or at least the My Sites host) at the same time as your main intranet site.

Before you perform an in-place upgrade, you should review and adjust your Search topology after upgrade to suit the new recommendations and requirements. For more information, see Plan search (Office SharePoint Server) and the Search models in Technical diagrams (SharePoint Server 2010).

You cannot upgrade search data by using the database attach method for upgrading. If you are using database attach upgrade, you must configure Search in your new farm separately from (either before or after) you upgrade your other content.

  • Service applications

    During upgrade, for each SSP that hosts the Search service in your Office SharePoint Server 2007 farm, a new service application is created in your SharePoint Server 2010 farm.

    The application server that was serving as the index server becomes the crawl component on the same server.

    Any query servers become query components on the same servers, all in the same index partition.

  • Databases

    In SharePoint Server 2010, the Search service uses three databases:

    • Search administration database (new): contains Search administration settings that were stored in the SSP database in Office SharePoint Server 2007.

    • Search Service Crawl Store database (new): contains crawl history information that was stored in the SSP database in Office SharePoint Server 2007.

    • Search Service Property Store database (reused Search database): contains the metadata for search.

  • Index files

    Before upgrade, index files are stored on the index server and the query servers. After upgrade, only servers that have query components will store index files.

Tip

Upgrade will be faster if you scale down to one query server before you upgrade. With only one server, there is less data to copy. You can scale out again after upgrade to multiple mirrored query components.

The Windows SharePoint Services Search service has been re-architected in SharePoint Server 2010. During an in-place upgrade, the Windows SharePoint Services Search service is stopped and reprovisioned. Windows SharePoint Services Search stores index files on the application server in Office SharePoint Server 2007 and also has a database (WSS_Search, one per server in your farm). During an in-place upgrade, the database is restructured and reused. The old data is not kept and is not upgraded.

InfoPath Forms Services

When you upgrade by using the database attach upgrade approach, you must export any administrator-deployed form templates (.xsn files) and data connection files (.udcx files) before you perform the database attach, and then import them to the new farm by using the Export-SPInfoPathAdministrationFiles Windows PowerShell cmdlet. If the URL of the new server differs from the URL of the previous server, you can run the Update-SPInfoPathAdminFileUrl Windows PowerShell cmdlet to update links that are used in the upgraded form templates.

For more information about how to upgrade forms and form templates, see Plan to upgrade form templates during an upgrade to SharePoint Server 2010.

Excel Services

  • Excel Services remains a local service for SharePoint Server 2010 — this means that you need to run the service in the same farm that consumes it.

  • For in-place upgrade, any configuration information stored in the SSP database for Excel Services is upgraded and moved into the configuration database. For the database attach upgrade approach, you must reconfigure Excel Services in your new farm.

  • After upgrade (either in-place or database attach), you must provision a new unattended service account that uses the Secure Store Service to interact with Excel Services.

Business Data Catalog

During an in-place upgrade, data that was stored in the SSP database is moved and upgraded to a separate database. New service applications are created for the SharePoint Server 2010 service. A new service, the Application Registry Backwards-compatible service, is used to manage the old Business Data Catalog connections.

The Business Data Catalog is not upgraded when you use the database attach upgrade method.

For more information, see Plan to upgrade to Business Connectivity Services (SharePoint Server 2010).

Single sign-on

The Single Sign-On (SSO) service is being replaced with the Secure Store Service in SharePoint Server 2010. You can use Windows PowerShell cmdlets to upgrade application definitions from SSO to the Secure Store Service. Note that passwords are not upgraded. After you upgrade the application definitions, you can make the Secure Store Service the default SSO provider. For more information, see Perform post-upgrade steps for an in-place upgrade (SharePoint Server 2010).

See Also

Other Resources

Downloadable book: Upgrading to SharePoint Server 2010
Resource Center: Upgrade and Migration for SharePoint Server 2010