Content deployment overview (SharePoint Server 2010)

  • Article

 

Applies to: SharePoint Server 2010

Content deployment is a feature of Microsoft SharePoint Server 2010 that you can use to deploy content from a source site collection to a destination site collection. This article summarizes the content deployment feature in SharePoint Server 2010. It describes the purpose and function of content deployment, explains content deployment paths and jobs, and explains the security options that are available when you deploy content. This article also explains how the content deployment process works, and it lists important factors and limitations of using content deployment. This article does not describe the steps that are involved in planning to use content deployment or how to set up and configure content deployment. For more information, see Plan content deployment (SharePoint Server 2010).

In this article:

  • What is content deployment?

  • About deployment paths and jobs

  • About content deployment security

  • How content deployment works

  • Important considerations in content deployment

What is content deployment?

Content deployment deploys content from a source SharePoint Server 2010 site collection to a destination site collection. The complete source site collection can be deployed, or a subset of sites can be deployed. Content deployment, which is incremental by default, deploys only changed pages and related assets (such as images). A Quick Deploy feature supports the deployment of a single page by authors.

Note

For the content deployment Quick Deploy feature to work, the source site collection must have been created by using the Publishing Portal template, or it must have the SharePoint Server Publishing Infrastructure feature enabled.

In most content deployment scenarios, the source site collection, from which content is being deployed, is in a server farm that is separate from the destination site collection. Typically, the destination server farm (the "production" farm) has tightened security to minimize the actions that can be done in the production environment. It is not expected that authoring will be done on the production server, because changes to content on the production server might be overwritten by a content deployment job. In most content deployment scenarios, the source server farm and the production server farm are in independent Active Directory domains. For information about content deployment topologies, see Design content deployment topology (SharePoint Server 2010)

It is important to be aware that content deployment is a one-way process: content is deployed from a source site collection to a destination site collection. The content deployment feature does not support round-trip synchronization from source to destination and back again. Creating new content or changing existing content on the destination site collection can cause content deployment jobs to fail. Because of this, you should consider restricting permissions on the destination site collection so that users cannot make changes directly to content that is stored within that site collection.

In content deployment, the base URL of the source site collection can differ from the base URL of the destination site collection. The content deployment feature will fix links in the source content to work correctly in the destination location.

Content deployment deploys only content — Web pages, libraries, lists, and resources that are used by the deployed pages. It does not deploy programs, assemblies, features, or configuration information such as Web.config files. When a Web page is deployed, any items in the content database that the page depends on — such as images, style sheets, or layout pages — will also be deployed.

Content deployment deploys the most recent major and minor versions of a content item. For example, if version 2.7 of a Web page is being deployed, the most recent major version (2.0) of the page, and the most recent minor version (2.7), will be deployed to the destination site.

If an item has an associated publishing schedule, the scheduling information is deployed together with the item so that the schedule is followed in the destination site collection. For example, if an item that is scheduled to be published at 6:00 A.M. is deployed at 3:00 A.M., site users on the destination site cannot view the content until 6:00 A.M. For information about scheduling content, see Plan content approval and scheduling (SharePoint Server 2010).

A new feature of content deployment that was added for SharePoint Server 2010 is the option to use SQL Server database snapshots during export. If the database snapshots option is enabled, a snapshot of the source content database is created before the export phase of the content deployment job starts. The content deployment job then uses the database snapshot to perform the export, instead of exporting directly from the live content database. After the export has successfully completed, the snapshot is deleted. By using the database snapshot option, you eliminate any potential problems with users editing content in the content database while a content deployment job is running.

Note

The SQL Server database snapshot option is only available if Microsoft SQL Server 2008 Enterprise edition is installed. If you are using Remote BLOB Storage (RBS), and the RBS provider that you are using does not support snapshots, you cannot use snapshots for content deployment or backup. For example, the SQL FILESTREAM provider does not support snapshots. For more information about RBS, see Overview of RBS (SharePoint Server 2010).

About deployment paths and jobs

The following section describes content deployment paths and jobs.

Content deployment paths

A content deployment path defines a source site collection from which content deployment can originate and a destination site collection to which content is deployed. A path can be associated with only one site collection. A content deployment path specifies the following information:

  • Authentication information that gives content deployment jobs permission to the destination site collection. To deploy content to the destination site collection, deployment jobs must have Central Administration credentials on the destination server. Jobs can connect by using Integrated Windows authentication or Basic authentication.

  • Information about whether to deploy user names that are associated with the content, such as authors' names.

  • Information about how to deploy permissions on the content. For more information, see About content deployment security.

Content deployment jobs

A content deployment job deploys specified content on a specified schedule by using a specified path. After a path is defined, one or more content deployment jobs can be defined. A deployment job specifies:

  • The path with which the job is associated.

  • Whether the job uses SQL snapshots.

  • The sites within the source site collection to deploy.

  • The frequency at which to run the job and deploy the content.

  • Whether to send e-mail when a job succeeds or fails and the e-mail addresses to use.

There are two kinds of standard content deployment jobs: full and incremental. These jobs are managed by a server farm administrator, and they enable you to specify whether to deploy all content, including any content that might have been deployed previously, or only content that was added, updated, or deleted since the last successful deployment. These jobs are run on a schedule that the server farm administrator specifies.

A third kind of content deployment job, Quick Deploy, is a special job that enables users to quickly publish content without waiting for the next standard content deployment job to run. This job runs automatically, at a specified interval.

The following table describes the kinds of content deployment jobs:

Job Type Description

Incremental

An incremental deployment job deploys all new, changed, or deleted content from the source to the destination. The first time that an incremental deployment job runs, it performs a full deployment. For each subsequent run of an incremental deployment job, new content is added to the destination, whereas updated content replaces content that has the same GUID but has older modification dates. Content that is deleted on the source is flagged so that it will also be deleted from the destination server. This is an important difference between full and incremental deployments.

Full

A full content deployment job deploys all content from the source to the destination, regardless of whether that content was previously deployed. Also, full deployment jobs do not check whether content that exists on the destination was deleted from the source. If you delete content on the source server and then perform a full deployment, that content will not be removed on the destination server. You should avoid using full deployment jobs except in specific cases where you know content has not been deleted on the source server.

Quick Deploy

A Quick Deploy job enables users, such as authors and editors, to quickly deploy a Web page. By default, a Quick Deploy job is created automatically when a new content deployment path is created, and it is set to run automatically every 15 minutes. When a user flags a page for inclusion in a Quick Deploy job, that page will be included in the next automatically scheduled Quick Deploy job. Only pages that are flagged by a user as Quick Deploy pages are included in the job. Alternatively, a farm administrator can manually run or cancel a Quick Deploy job at any time by using the Manage Content Deployment Paths and Jobs page. Any member of the Quick Deploy users group (which is created in sites that have the SharePoint Server Publishing Infrastructure feature enabled) can mark a Web page for deployment by using the Quick Deploy command.

Note

It is possible to have a path that is defined in sites that do not have the Office SharePoint Server Publishing Infrastructure feature enabled. However, paths that are created in this manner will not have associated Quick Deploy jobs. If you want to add a Quick Deploy job to a path that was defined in a site that does not have the SharePoint Server Publishing Infrastructure feature enabled, first enable the SharePoint Server Publishing Infrastructure feature on the source site collection, and then edit and save the path again. The path will then have a Quick Deploy job associated with it.

About content deployment security

Permissions to content on the destination server farm will usually differ from permissions to content on the source server farm. In many publishing solutions, the destination server farm authenticates users by using a different Active Directory domain than the one used in an authoring or staging environment, and there might not be a trust relationship between the two domains.

When you configure a content deployment path, you can select from the following security options:

  • All   Deploys all security-related information together with the content. This includes role definitions, access control lists (which map users and roles to the content they have permissions to view or edit), and users. This option is useful if the same set of users has the same permissions on the source and destination server farms. For example, when you deploy from an authoring server farm to a staging server farm, this option might be best because the same users need access to both sets of content. All is the default option.

  • Role Definitions Only   Deploys role definitions and access control lists that map the roles to the content but do not deploy users. In this option, the same roles apply in the source and destination server farms, but different users can be assigned to those roles in each server farm.

  • None   Deploys no security information. Security on the destination security farm must be managed by the administrators of that server farm by assigning users and roles to the farm's sites and content. For example, when you deploy from a staging server farm to a corporate Internet presence site, this option helps ensure that the security of the two server farms is managed separately.

For more information about security, see Security planning for sites and content (SharePoint Server 2010).

How content deployment works

Content deployment settings for both incoming and outgoing deployment jobs are configured on the Content Deployment Settings page, which is accessed from the General Application Settings page on the Central Administration Web site. You use the Content Deployment Settings page to accept or reject incoming content deployment jobs for a whole server farm. You can also set specific servers within your server farm to be used for receiving incoming content deployment jobs or for sending outgoing content deployment jobs. This enables you to spread the load for content deployment jobs across multiple servers in your server farm, based on the available server resources and the needs of your server farm.

Note

Depending on the kind of server farm you are using, you might not have to enable support for both incoming and outgoing deployment jobs. If your server farm is an authoring server farm, you do not have to configure incoming (import) settings. If your server farm is a production server farm, you do not have to configure outgoing (export) settings. However, if your server farm is a staging server farm, you must configure both incoming (import) and outgoing (export) settings.

The tasks that are involved in content deployment are controlled by the timer process on the server that hosts the Central Administration Web site, which is used to administer the content deployment jobs. This server could be the source server in the deployment server farm, or it could be a separate server in the farm. The content deployment job uses the service account information that is provided in the content deployment path settings to authenticate with a Web service on the destination server. This Web service acts as the pathway for all communication between the source and destination servers while the content deployment job runs.

The following illustration shows the process that the content deployment job undergoes from start to finish:

Content deployment process flowchart

Callout Description

1

When a content deployment job starts, it checks the change token to determine when the last successful content deployment job was run. If the length of time between the last successful content deployment job and the current one is so long that the stored change token is no longer valid, it will run as a full content deployment job, not an incremental content deployment job.

After the change token has been verified, the export process is started on the source server. If SQL snapshots are enabled for the content deployment job, a snapshot is taken before the export process starts.

Note

In preparation for the export, settings such as the file location, base file name, and other values are specified for the deployment job.

2

Next, the content to be included is exported to a temporary directory on the source server, where it is packaged into .cab files for transport. If the deployment job has been configured to use SQL Server database snapshots, it will use a database snapshot as the source for the export; otherwise, it will export directly from the content database.

Alternatively, you can use the Microsoft.SharePoint.Deployment.SPExport namespace from the SharePoint Server 2010 API to export content.

After the source server has authenticated with the Web service on the destination server, it calls the Web service to prepare the import on the destination server.

3

After the files have been packaged into .cab files on the source server, the files are transported to a local temporary directory on the destination server via HttpPost.

The content deployment job then calls the Web service to start the import process on the destination server.

Note

In preparation for the import, settings such as file location, base file name and other values are set by using the information that was stored in the content deployment job when the files were prepared on the source server.

4

While the import is in progress, the content deployment job calls the Web service to get the status of the import process. If the destination server does not respond with updated status within a certain amount of time, the content deployment job will contain a warning message that the job might have timed out. The content deployment job will continue to request updated status from the destination server, but might eventually fail and need to be re-run if the destination server repeatedly fails to respond.

5

During import, the .cab files are extracted to a temporary directory on the destination server, and then they are imported into the database. Any site collection features that are required by items that were included in the import are activated, and scheduling is then configured for the imported items.

Alternatively, you can use the Microsoft.SharePoint.Deployment.SPImport namespace from the SharePoint Server 2010 API to import content.

6

After the import has finished, it returns either a Success or Failure status to the Central Administration server. If the import status is Success, the change token is saved. If the import status is Failure, the change token is discarded.

Important considerations in content deployment

The following list contains important considerations to be aware of when you use content deployment:

  1. Always deploy to an empty site collection for the initial content deployment job.   If the site collection already contains content, the initial content deployment job will fail. When you create the site collection on the destination server, use the < Select template later > option on the Custom tab of the Create Site Collection page in Central Administration to create an empty site collection. The first time that the content deployment job runs, the correct template and all associated configuration settings will be applied to the destination server.

    Note

    Do not use the Blank Site template to create a destination site collection. The Blank Site template does not create an empty site collection and can cause the content deployment job to fail.

  2. The export and import servers must each host an instance of the Central Administration Web site.   When you configure content deployment settings for your server farm, you select the servers in your server farm to designate as export and import servers for content deployment. If you attempt to configure an export or import server that does not host the Central Administration Web site, no error message will be displayed. The content deployment export or import phase will not start. Be sure to deploy the Central Administration Web site on the export and import servers.

  3. Each server in your source and destination server farms must have identical updates.   Be sure that all SharePoint Server 2010 and Windows Server 2008 R2 and Windows Server 2008 with Service Pack 2 (SP2) updates have been applied and that any language packs, if they are needed, have been installed.

  4. The source and destination servers must have enough hard disk space for storing the files that are used during export and import.   During export, all files to be included in the content deployment job are stored in a temporary directory in the export server farm. Likewise, during import, files to be imported into the database are stored in a temporary directory on the destination server farm. Be sure that the location of the temporary directory for each server farm has sufficient disk space to accommodate the files that are included in the deployment job.

  5. If jobs will run infrequently, the time for keeping changes in the change log must be adjusted.   By default, the change log is configured to keep a record of any changes for 60 days. If the time between two incremental deployment jobs exceeds this time—for example, if it was 70 days since the last content deployment job was run—then the change log will not contain entries from before the last change token. If the time between jobs will be more than 60 days, you must change the number of days specified for the Web application in the Central Administration Web site.

  6. Do not run content deployment jobs in parallel if the same path is used by both jobs.   Changes made by one job might conflict with changes made by another job that is running along the same path at the same time. If this happens, the content deployment job might fail.

See Also

Concepts

Plan content deployment (SharePoint Server 2010)
Design content deployment topology (SharePoint Server 2010)

Other Resources

Resource Center: Enterprise Content Management in SharePoint Server 2010
Resource Center: Web Content Management in SharePoint Server 2010