Changes to content deployment in SharePoint Server 2013

If you're familiar with the content deployment feature in previous versions of SharePoint Server, then you've probably heard that there have been a few changes to make it easier in SharePoint Server 2013. In this blog post, I'll explain those changes, including:

• When to use content deployment
• Alternatives to content deployment
• What's new for content deployment in SharePoint Server 2013
• Using content deployment with cross-site publishing
• New procedures for content deployment

When to use content deployment

In previous versions of SharePoint Server, content deployment was used to separate the source farm from the target (also referred to as destination, or production) farm. The target farm had more security, and only the content deployment feature could write to the content database on the target farm. If your website consisted of static content, this model worked okay. But web sites are changing, and in SharePoint Server 2013, we introduced a cross-site publishing feature, which enables you to use search to find and publish content to dynamic web sites.

Starting with SharePoint Server 2013, content deployment is best-suited only for scenarios in which you have a business, regulatory, or legal requirement that a separate farm must host content until it is supposed to be published. In most cases, this applies only to a portion of a site, such as an area for investor relations or earnings reports.

So, if your site does not have such a requirement, what should you use in place of content deployment? There are several options. But for starters, you should consider the new cross-site publishing feature.

Alternatives to content deployment

SharePoint Server 2013 introduced a new feature called Cross-Site Collection Publishing (we usually just refer to it as cross-site publishing). In a nutshell, cross-site publishing separates the authoring site collection, where you create and manage content, from the publishing site collection, where users see content. Now, at first blush, this may sound rather similar to content deployment. Here's the difference: cross-site publishing uses search to crawl and index content from catalogs on the authoring site collection, and displays content from the search index in Content Search Web Parts on the publishing site collection. I'm not going to go into detail about it here, but cross-site publishing has a lot of other cool functionality, which you can read about in Overview of cross-site publishing in SharePoint Server 2013.

The following table lists other scenarios, and alternative solutions you should consider instead of content deployment in SharePoint Server 2013.

Table: Alternatives to content deployment

If you're not currently using content deployment, don't start now. Use one of the alternatives described in the preceding table. It's that simple.

If you currently use content deployment, carefully evaluate whether you need to continue using it after you upgrade to SharePoint Server 2013.

If you find that you must use content deployment because of business, regulatory, or legal requirements, then continue reading, as I explain the changes you'll need to be aware of in SharePoint Server 2013.

What's new for content deployment in SharePoint Server 2013

In SharePoint Server 2013, content deployment only deploys content – webpages, document libraries, lists, and associated resources such as images and style sheets. It does not deploy things like content types or custom workflows. Also, the content deployment feature in SharePoint Server 2013 does not work with many features, such as ratings, managed navigation, blog sites, slide libraries, and social sites, to name a few. If you have been using customized publishing sites together with content deployment in a previous version of SharePoint Server, you can’t continue doing this in SharePoint Server 2013. You will have to switch to a different publishing method.

Introducing the Content Deployment Source feature

It would be nice to know whether content deployment will be able to deploy content from your source site collection. SharePoint Server 2013 has a new Content Deployment Source feature that checks the source site collection,
and helps ensure compatibility with other features.

Important   By default, the Content Deployment Source feature is not activated. The feature must be activated on the source site collection before you can configure a content deployment path.

The following image shows the feature as it is displayed on the Site Collection Features page:

When this feature is activated, a list of incompatible features is created. A link to the list is added on the Site Settings page, in the Site Collection Administration section, as shown in the following image:

The Content Deployment Source Status page displays a list of incompatible features, along with information about how to fix the issues. The following image shows the list of incompatible features that was generated after I activated the Content Deployment Source feature on a site collection that was created with the Publishing Portal site collection template:

After you deactivate the incompatible features, you'll be able to create a new content deployment path in Central Administration. I'll explain how to deactivate these features later in this post.

Changes to checks made when a content deployment job starts

SharePoint Server 2013 has new checks that it makes when a content deployment job starts. When a job starts, two things happen:

1. SharePoint Server 2013 checks to see if the Content Deployment Source feature is active on the source site collection. If it’s not, the job is cancelled, and an error message is written to the ULS log.
2. If the feature is active on the source site collection, another check determines what active features on the source site collection might cause the job to fail. If any conflicts are found, the job is cancelled, and an error message is written to the ULS log.

This means that if you deactivate features that were listed on the Content Deployment Source Status page, create a content deployment path and job, and then reactivate any of those features on the source site collection, the deployment job will fail.

To find the error messages in the ULS log, open the log and search for "Content Deployment."

Note   Because of the checks that verify that the Content Deployment Source feature is active on the source site collection, the user account that is used to create a content deployment path (the Farm administrator) must have read permissions to the source site collection.

Using content deployment with cross-site publishing

As I said earlier, with SharePoint Server 2013, you should only use content deployment if you have a business, regulatory, or legal requirement that you must host content on a separate farm until it’s supposed to be published. In those cases, you should use a separate site collection for sensitive content, and use either author-in-place, or cross-site publishing for all other content. The following diagram shows the logical architecture for content deployment with cross-site publishing.

1. Sensitive content is authored on https://source, and then deployed to https://target along a content deployment path at a time determined by the content deployment job.
2. Non-sensitive content is authored in lists or libraries on https://authoring, enabled as catalogs, crawled and indexed by search, and displayed on the publishing site, https://contoso.com.
3. On https://target, the lists or libraries that contain the sensitive content from https://source are enabled as catalogs, crawled and indexed by search, and displayed on the publishing site, https://contoso.com.
4. Assets used by the authoring site collection (https://authoring) and source site collection (https://source) are stored in a separate site collection (https://assets.contoso.com) so that users on the publishing site have read access to those assets. For more information, see the "Plan asset library content" section in Plan authoring sites for cross-site publishing in SharePoint Server 2013.

For more information about cross-site publishing architectures, see Plan the logical architecture for cross-site publishing in SharePoint Server 2013.

Previously, when content deployment deployed all content between authoring and production, there was a latency period during the export and import stages of a job, before content was available on the production server. With cross-site publishing, you now have to wait for the export and import stages to run, and then wait for the next incremental search crawl to complete before the content is available on the production server. While this may increase the time before sensitive content is published, the remaining, non-sensitive content will be crawled and indexed independently of the sensitive content. The non-sensitive content will be published on the publishing site according to your incremental search crawl schedule.

The important thing to understand is that in SharePoint Server 2013, content deployment is a means to deploy content into a source catalog for a cross-site publishing architecture. The search crawler indexes content from that source catalog instead of from the highly-secured site collection where the sensitive content is initially authored. This means that only the target content deployment site collection can have cross-site publishing activated, and all catalog-related configurations must be made in that target environment. However, this breaks one of the previous rules of content deployment – do not make changes on the target site collection. When you use content deployment with cross-site publishing, you must have a small, trusted group of users to whom you grant permission to make changes to the catalog configuration on the target site collection.

New procedures for content deployment

The addition of the Content Deployment Source feature means that there are now a few new procedures for content deployment in SharePoint Server 2013. In this section, I'll tell you how to complete the following tasks:

• Activate the Content Deployment Source feature
• Use Windows PowerShell to deactivate conflicting features

Activate the Content Deployment Source feature on a source site collection

As I mentioned earlier, the new Content Deployment Source feature must be activated on the source site collection before you can create a content deployment job. Use the following procedure to activate the feature.

To activate the Content Deployment Source feature on the source site collection:

1. On the top-level site of the source site collection, on the Settings menu, choose Site Settings.

2. On the Site Settings page, in the Site Collection Administration section, choose Site collection features.

3. On the Site Collection Features page, next to Content Deployment Source Feature, choose Activate.

4. On the Settings menu, choose Site Settings.

5. On the Site Settings page, in the Site Collection Administration section, choose Content Deployment Source Status.

6. On the Content Deployment Source Status page, for each error listed, deactivate the feature.

   • If the How to fix it column contains a hyperlink, to deactivate the feature, follow the link.
   • If the How to fix it column says that the feature must be deactivated by using Windows PowerShell, use the To disable a SharePoint feature by using Windows PowerShell procedure.

7. When all issues have been resolved, the following text will display:

   "There are no errors and this Site Collection is ready for Content Deployment."

Disable a SharePoint feature by using Windows PowerShell

After you activate the Content Deployment Source feature on the source site collection, you'll have to deactivate features that are not compatible with content deployment. Some of the items in the list include a link you can use to deactivate the associated feature through the user interface. Use the following Windows PowerShell procedure to deactivate features that can't be deactivated through the user interface.

To disable a SharePoint feature by using Windows PowerShell

1. Verify that you have the following memberships:

   • securityadmin fixed server role on the SQL Server instance.
   • db_owner fixed database role on all databases that are to be updated.
   • Administrators group on the server on which you are running the Windows PowerShell cmdlets.

   An administrator can use the Add-SPShellAdmin cmdlet to grant permissions to use SharePoint 2013 cmdlets.

   Note   If you do not have permissions, contact your Setup administrator or SQL Server administrator to request permissions. For additional information about Windows PowerShell permissions, see Add-SPShellAdmin.

2. On the Start menu, choose All Programs > Microsoft SharePoint 2013 Products > SharePoint 2013 Management Shell.

3. At the Windows PowerShell command prompt, type the following command:

    Disable-SPFeature -Identity "<FeatureName>" -URL <SiteCollectionURL>
   

   Where:

   • <FeatureName> is the name of the feature listed in the Error column on the Content Deployment Source Status page.
   • <SiteCollectionURL> is the URL of the source site collection.

   Example

    Disable-SPFeature –Identity "RollupPages" –URL https://source 
   

4. Press Enter.

5. Type Y, and then press Enter.

For more information, see Disable-SPFeature.

Cern McAtee
Technical Writer
SharePoint IT Pro content publishing