Tuesday, 10 December 2013

Content Deployment Source feature

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:
Screenshot of Content Deployment Source Feature text.
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:
Screenshot showing Content Deployment Source Status link on the Site Settings page
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:
Screenshot of Content Deployment Source Status error list
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.
Content deployment with cross-site publishing logical architecture diagram
  1. Sensitive content is authored on http://source, and then deployed to http://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 http://authoring, enabled as catalogs, crawled and indexed by search, and displayed on the publishing site, http://contoso.com.
  3. On http://target, the lists or libraries that contain the sensitive content from http://source are enabled as catalogs, crawled and indexed by search, and displayed on the publishing site, http://contoso.com.
  4. Assets used by the authoring site collection (http://authoring) and source site collection (http://source) are stored in a separate site collection (http://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.
  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 http://source 
  4. Press Enter.
  5. Type Y, and then press Enter.
 

No comments:

Post a Comment