Home > SharePoint > Content Deployment

Content Deployment

December 30, 2011 10:51 am Leave a comment Go to comments

What is content deployment

Content deployment is a subset of the Enterprise Content Management feature of Microsoft SharePoint Server 2010 that you can use to copy content from a source site collection to a destination site collection. Most content deployment topologies include two or more server farms, to separate the authoring environment from the production environment. 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.

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 job copies 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.There are two kinds of standard content deployment jobs: full and incremental. These jobs are managed by a server farm administrator and 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.

When to use Content Deployment?

Although content deployment can be useful for copying content from one site collection to another, it is not a requirement for every scenario. The following list contains reasons for why you might want to use content deployment for your solution:

The farm topologies are completely different. A common scenario is one in which there are authors publishing content from an internal server farm to an external server farm. The topologies of the server farms can be completely different. However, the content of the sites to be published is the? same.

The servers require specific performance tuning to optimize performance. If you have a server environment in which both authors and readers are viewing content, you can separately configure the object and output caches on the different site collections based on the purpose of the site or the user role.

There are security concerns about content that is deployed to the destination farm. If you do not want users to have separate accounts on the production server, and you do not want to publish by using only approval policies, content deployment lets you restrict access to the production server.

Alternatives to Content Deployment

Before you implement a content deployment solution, you should carefully consider whether content deployment is really necessary. The following list contains alternatives to using content deployment:

· One alternative is to author on the production farm and use an extended Web application. If you have a single-farm environment, you can choose to allow users to author content directly on the production farm and use the publishing process to make content available to readers. This option lets you have a separate IIS Web site that uses a shared content database to expose the same content to different sets of users. This is typically used for extranet deployments in which different users access content by using different domains.

· A second alternative is to use the Microsoft.SharePoint.Deployment.SPExport and Microsoft.SharePoint.Deployment.SPImport namespaces from the SharePoint Server 2010 API to develop a custom solution to meet your needs.

· A third alternative is to use backup and restore to back up a site collection from one location and restore it to another location.

The two-farm topology is a standard Internet site topology, and it is typical of topologies that are used to publish an Internet site. It includes two server farms: one to host the authoring site collection along with other sites that are used by the authoring team, and the other to host the production site collection. Users of the production server farm belong to a separate Active Directory® domain, and some production farm users might be anonymous.

· A front-end Web server in the authoring farm must be configured to export content from the authoring site collection to the production farm.

· One front-end Web server in the production farm must be configured to import content from the authoring farm.

On production farm central administration configure to accept incoming deployment jobs


On production server designate a WFE as import server


On production server determine if encryption is needed and temporary files directory


On authoring farm select a server as export server


Configure Content Deployment Path


Creating a Path automatically creates a quick deploy job, create a deployment job




Process of running a Path job or quick deploy

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.

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.

Categories: SharePoint Tags:
  1. Richard Walsh
    March 21, 2012 5:43 am at 5:43 am

    Your comment above is interesting, talking about considerations for using content deployment:

    “The servers require specific performance tuning to optimize performance. If you have a server environment in which both authors and readers are viewing content, you can separately configure the object and output caches on the different site collections based on the purpose of the site or the user role”

    We have found an issue with this, and I wonder if you also have encountered it? Basically – we have the standard 2 farm topology (separate authoring and public sites) and we have done exactly that, setup and enabled separate caching profiles for each site (one for read/write use and one for read only use) This all works fone, however if the authoring site makes a change to its site admin settings (i.e. if you amend the timeout for the read/write cache profile) – the next time you do a content deployment the public site has its cache settings overwritten with the authoring site profile. This is most annoying as I’m sure you can imagine. So where did you get your information that content deployment supports the scenario you described?

  2. March 21, 2012 7:06 am at 7:06 am

    Can you check your content deployment settings? We have similar settings but don’t see the issue or have not configured same as your settings. Most of this information is from technet or based on how we configured in our SharePoint farms for content deployment.

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: