Changes to content deployment in SharePoint Server 2013

Article
07/15/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

Scenario	Alternative solution
Content must be reviewed and staged before it is approved for live publication	Use the built-in security model in SharePoint Server 2013, with either the author-in-place or cross-site publishing method. For more information, see Plan for Internet, intranet, and extranet publishing sites in SharePoint Server 2013.
High availability (including replication in a geographically distributed environment) or disaster recovery	Use SQL Server Log Shipping between the source site and target sites. For more information, see Supported high availability and disaster recovery options for SharePoint databases (SharePoint 2013).
Site relaunch or redesign	Back-up the site to a private site collection in a separate content database, and work on the new site there. To launch the new site, flip the alternate access mapping (AAM) for the site URL. For more information, see Enable Apps in AAM or host-header environments for SharePoint 2013.

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:

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.
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.

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.
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.
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.
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:

On the top-level site of the source site collection, on the Settings menu, choose Site Settings.
On the Site Settings page, in the Site Collection Administration section, choose Site collection features.
On the Site Collection Features page, next to Content Deployment Source Feature, choose Activate.
On the Settings menu, choose Site Settings.
On the Site Settings page, in the Site Collection Administration section, choose Content Deployment Source Status.
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.
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

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.
On the Start menu, choose All Programs > Microsoft SharePoint 2013 Products > SharePoint 2013 Management Shell.
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 
```
Press Enter.
Type Y, and then press Enter.

For more information, see Disable-SPFeature.

Cern McAtee
Technical Writer
SharePoint IT Pro content publishing

Comments

Anonymous
January 01, 2003
One of the more interesting changes to SP13. Thanks for taking the time to post for the community.
Anonymous
January 01, 2003
Hi Moontear, I don't think the updated guidance for content deployment has been mentioned anywhere on MSDN. This is guidance that was shared by members of the product team at the SharePoint Conference last fall. There was so much information relating to changes with content deployment that I felt it was better to aggregate it all in one place (this blog post) rather than spread it across multiple articles on TechNet or MSDN. For the licensing issue, I wasn't sure if you were asking a question or simply citing a problem you've run into. You would need ECAL licenses for any users that need access to the authoring site collection, and any intranet portal solution that leverages both cross-site publishing and the Content Search Web Part. Your best course of action is to discuss licensing needs with your account team to figure exactly what your needs are. Content is not duplicated to the extranet, it's stored in the search index and rendered from there. Unless you're talking about assets, which should be stored in a location that both external & internal users can access. See Plan the logical architecture for cross-site publishing in SharePoint Server 2013 (technet.microsoft.com/.../jj635882.aspx) for more info. Hope this helps. Cern
Anonymous
January 01, 2003
Very insightful post, thank you! Is the recommendation to only use content deployment for the "business, regulatory, or legal requirement" mentioned anywhere on MSDN? Otherwise it would be a great addition. I have been recommending Content deployment to customers with specific scenarios: Wanting to show content (not only pages, but also documents) to external users on a secure extranet. If I would go with Cross-Publishing I would face two problems:

I would need Enterprise CALs, so for a company with 10.000 users I'd need 10.000 Enterprise CALs
The Extranet users would need permission on the Intranet so that they can access the content published by search - or is the content duplicated to the Extranet?

Anonymous
January 01, 2003
Hi Tony, If you're planning to migrate to SharePoint 2013, and are currently using things like ratings that are no longer supported by content deployment, then you should plan to use an alternate publishing method, as described in the table Alternatives to content deployment. You can use whichever suggested method will suit the needs of your solution. I recommend looking into the new cross-site publishing feature. There's a flowchart in Plan for Internet, intranet, and extranet publishing sites in SharePoint Server 2013 (technet.microsoft.com/.../jj635878.aspx) that's designed to help you decide whether to use author-in-place or cross-site publishing. You could also use SQL Server Log Shipping, as mentioned above. But the method you decide to use will be determined by the needs of your site. Thanks, Cern
Anonymous
July 21, 2013
Hi, thanks for writing this article. Can you tell me what the MS stance is for those 2010 deployments that are already using Content Deployment with ratings and the other features which are not supported by the Content Deployment Source Status feature? What do we do with them? Thanks Tony
Anonymous
August 07, 2013
Very Interesting Read...!!!!!!!!!! ...Thanks
Anonymous
January 09, 2014
Pingback from Overview of Cross-Site Publishing in SharePoint 2013 | MIcrosoft Homer
Anonymous
January 09, 2014
Pingback from Overview of Cross-Site Publishing in SharePoint 2013 | Microsoft Homer
Anonymous
January 09, 2014
Pingback from Overview of Cross-Site Publishing in SharePoint 2013 | Microsoft Homer
Anonymous
January 10, 2014
Pingback from Cross-Site Publishing in SharePoint 2013. Consulting solutions
Anonymous
January 10, 2014
Pingback from Cross-Site Publishing in SharePoint 2013. Consulting solutions

Partager via