Understanding Publishing and Content Deployment

This topic explains how to deploy content from an authoring farm to a production farm. The Web Content Management features in Microsoft Office SharePoint Server contain publishing features for creating and managing authored content. Authored content provides the text and graphics that make up the content of a site. The Microsoft Office SharePoint Server publishing infrastructure helps companies create, version, and approve content that is typically published to a Web site, such as a public Internet site, a knowledge base, or an extranet portal.

It is easy to confuse publishing with content deployment. They are often spoken of together, but they are actually separate SharePoint capabilities. To better understand content deployment, you should familiarize yourself with the concepts that are explained in Plan content deployment on TechNet.

Content deployment is the ability to copy content from one site collection to another. It relies on the content migration APIs that are exposed by Windows SharePoint Services (WSS). For more information, see Microsoft.SharePoint.Deployment Namespace on MSDN.

The authoring farm is the server farm that hosts content. This is where you use the Microsoft Office SharePoint Server publishing capabilities to create, review, and approve content. The authoring farm exists behind the corporate firewall and it has read/write permissions. After the content is ready, it is published to the production server farm. The production farm is typically located in the perimeter network (also known as demilitarized zone, DMZ, or screened subnet) for Internet-facing sites. The production site has read-only permissions. The perimeter network and the intranet are separated by a fire wall such as an Internet Security and Acceleration (ISA) server.

For the production infrastructure, the Partner Portal application uses the back-to-back perimeter network with content publishing topology. For information about this topology, see Design extranet farm topology on TechNet.

The following diagram shows this topology.

A topology for publishing content to the Internet

You should plan your content deployment strategy before you begin to implement it. For information about how to do this, including a downloadable worksheet, see Plan content deployment on TechNet.

Note

The following are now deployed: workflow state, workflows that are designed with SharePoint Designer, items in the recycle bin, audit trails, and alerts.

Content deployment relies on internal SharePoint change logs that are located in both the source and destination site collections. When a content deployment job runs, it creates and saves a change token in both the source and destination environments. The next time the content deployment job runs, it checks these tokens against the tokens that were saved from the previous run. If the tokens do not match, SharePoint raises errors but still tries to redeploy the content. This commonly results in errors in subsequent content deployment job runs. In other words, changes to the destination site collection can cause deployment jobs to fail. To avoid these issues, treat destination site collections as read-only sites and consider restricting permissions on the destination site collection so that users cannot make changes to the production site content.

The source and destination site collections must exist in different SharePoint Web applications. This is because all of the GUIDs that define sites, Web pages, lists, and list items are preserved and transferred with the site during deployment. Therefore, you cannot deploy one site collection to the same content database as the source site collection.

Deploying Content to the Production Farm

This topic describes the resources and steps that are required to deploy content from an authoring farm to a production farm. Setting up and running content deployment can be complex, and only the basic steps are included here. For greater detail, see Administer content deployment on TechNet and an excellent blog series by Stefan Gobner.

To prepare the destination site collection

1. Create an empty site collection in the production farm. This is where the content will be deployed. An empty site template differs from a blank site template in that it contains no content, libraries, or activated features. A blank site contains some content and has some features that are activated. The only way to create an empty site collection is with the following STSADM command:

   STSADM.EXE -o createsite -url <url-to-site-collection> -ownerlogin domain\user -owneremail <email-address>

2. Add and deploy all the SharePoint Solution Packages (WSP) to the production farm. Typically, deploying the WSP should install all features to the production farm. However, if you are not using WSPs or if you have an exceptional case, ensure that all features are installed but not activated.

3. Make any necessary file system changes. For example, modify the Web.config files and install or place in the global assembly cache any .NET Framework assemblies that were not included in the WSP deployment.

Do not activate any of the features in the empty site collection. The content deployment process handles feature activation.

After you create the production site collections, you can configure the import and export settings for incoming (production) and outgoing (authoring) content. For information about how to configure the authoring and production farms for content deployment, see Configure content deployment settings on TechNet.

After you configure the content deployment settings, you must create the deployment paths and jobs. For more information, see Manage content deployment paths and jobs on TechNet. (The Partner Portal application uses the default settings.) After you create the path and the job, you can deploy content from the authoring farm to the production farm. To run the deployment job manually, click Run Now on the deployment job's shortcut menu. To see the updated status, refresh the page. After you do this, the status should display succeeded.

Guidelines and Recommendations for Content Deployment

This section includes some guidelines and recommendations that you should consider before you begin to deploy content to the production farm. Guidelines are general statements, and recommendations are more specific applications of the guideline. The following describes some guidelines and recommendations for those guidelines:

• Guideline: Never directly modify the destination site collection's content database, either before or after deployment. Consider the following recommendations:

  • Recommendation: Do not use the blank site template or any other site template to create a site collection in the destination farm.

    The blank site template is not empty. A non-empty template populates the content database. This is contrary to the guideline. You should use STSADM to create a site collection and not specify a site template. This is also named an empty site template.

  • Recommendation: Do not directly activate any features in the destination site collection.

    The content deployment process activates features that are already activated in the authoring farm. If you directly activate features in the destination site collection, there will be duplicate activations. Directly activating features can also add content to the content database. This is contrary to the guideline.

  • Recommendation: Do not add Web Parts to a Web Part zone during feature activation if the feature is going to be activated when the content is deployed. More generally, do not add or change data to the content database during feature activation.

    If you add Web Parts to a Web Part zone during feature activation, the Web Parts might be duplicated in the destination site collection. This is because the Web Part will be added twice, during content deployment when the content is copied from the authoring farm to the production farm) and during feature activation.

• Guideline: Make all the required changes to the file system before content deployment. Consider the following recommendations:

  • Recommendation: Deploy all the required WSPs to the destination Web application before you run the content deployment job.

    The WSP deployment adds the required files to the 12 hives of all the Web front-end servers and installs the included assemblies in the global assembly cache.

  • Recommendation: Make all the required changes to the Web applications IIS folder \Inetpub\wwwroot\wss \VirtualDirectories\yourport in all Web front-end servers before you run the content deployment job.

    For example, if you need to modify the Web.config file, do it before you run the content deployment job.

  • Recommendation: Make sure that all the required assemblies are installed in the global assembly cache of all the Web front-end servers before you run the content deployment job.

    The WSP might not include all the required assemblies. In this situation, you must install the additional assemblies in the global assembly cache before you run the content deployment job.

Techniques for Securing Published Information

You should secure published information so that only the appropriate users can see it. For example, in the Partner Portal application, promotion pages must be secured so that only certain partners can see them. To accomplish this, an access control list (ACL) is attached to each promotion page is. The general process for creating and securing promotions is as follows:

• There is a dedicated site collection for promotions. This means that the content in this site collection can be deployed independently of any other content.
• The root Web of the Promotions site collection hosts the pages library for all promotion pages.
• Each promotion page is attached to an ACL. The ACL gives access to specific partners. A promotion page is assigned an ACL in the authoring farm after the page is authored.
• The ACL, together with the promotion page, is deployed from the authoring farm to the production farm by the content deployment job.

This approach is straightforward because there is only one site collection, one site, and one page library to manage. It is flexible because any promotion page can be assigned to any partner.

If the number of pages becomes large, it can be difficult to manage the individual ACLs. For example, if you want to change the ACLs for all the pages, you may need to do it one page at a time. You should also consider the impact on performance. The Partner Portal application did not have any performance problems with up to 2,000 promotion pages. However, more pages or a more complex use of ACLs might present performance issues.

One way to solve the manageability and performance issues is to have more than one pages library and to group the promotions according to some criteria, such as the discounts they offer. The ACL is attached at the page library level. All the pages in the pages library then have the same ACL. For example, you could set up three page libraries, such as the Gold library, the Silver library, and the Bronze library. You the assign partners to the appropriate group. This means that they only see the promotions that are meant for them. The drawback to this approach is that you lose some flexibility.

Content Deployment with the Partner Portal Application

You can use the Partner Portal application as a way to familiarize yourself with the content deployment process. This requires two stand-alone SharePoint servers. One server is for the authoring farm and should be located in the intranet. The other server is for the production farm and should be located in the extranet.

To set up the authoring server, run the ContosoSetup.bat file that is located in the Setup\PartnerPortal folder. To set up the production server, you must first make the following change to the 00_Parameters.bat file that is located in the Setup\PartnerPortal\SupportingFiles folder before you run the ContosoSetup.bat file.

Change the following code:

Set ContentDeployment=Authoring

Change the preceding code to the following:

Set ContentDeployment=Targeting

The 05A_CreatePublishingPortal.bat file that is located in the Setup\PartnerPortal\SupportingFiles folder specifies a site template for the authoring server. This creates the Promotions site collection and activates the features. There is no template specified for the destination server. This is in accordance with the guidelines that are discussed in Guidelines and Recommendations for Content Deployment.

After you set up the authoring and destination servers, you can create the promotion pages on the authoring server and then deploy the promotions site collection from the authoring server to the production server. After you run the deployment job, verify that the features on the production server's Promotions site collection are activated and that the site collection is populated with the promotion pages.

The following illustration shows the structure of the Partner Portal authoring and productions servers.

Structure of Partner Portal servers

More Information

The following articles discuss content deployment in more depth:

• Content Deployment on TechNet.
• Content Deployment on the Microsoft SharePoint Team Blog.
• Content Deployment – Step by Step Tutorial on Jack Bodine: SharePoint Blog.
• White Paper: End-to-End Content Deployment Walkthrough on TechNet.
• Content Deployment in WCM on Sharing...SharePoint.
• Best Practices for publishing portals on TechNet.
• Deep Dive into the SharePoint Content Deployment and Migration API blog series by Stephan Gobner

Home page on MSDN | Community site