Explained: Deploying Content to a Production Farm
This topic explains the process of deploying content from an authoring farm to a production farm. The Web Content Management pillar of MOSS contains publishing features for creating and managing authored content. Authored content, provides the text and graphics
that makes up the content of a site and is created by content authors. The publishing infrastructure helps companies build, version, and approve content that is typically published to a tightly governed site such as a public internet site, a knowledge base,
or an extranet portal at a large company.
It is easy to confuse publishing and content deployment. They are often used in tandem but they are actually separate SharePoint capabilities. In order to understand content deployment, you should familiarize yourself with the concepts that are explained in
Plan content deployment
Content deployment is the capability to replicate content from one site to another and is built on top of the content migration APIs exposed by WSS. The authoring farm is the server farm that hosts this content and where the content creation, review, and approval
processes take place using the publishing capabilities. The authoring farm exists behind the corporate firewall and it has read/write permissions. Once 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 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 chose one of the recommended topologies named “back to back perimeter network with content publishing,” . igure xx illustrates the topology. It does not show the firewalls but the networks are segmented.
See Design extranet farm topology
for for additional details and other choices for SharePoint farm topologies. There is also a downloadable
. Our testing of the Partner Portal application eliminated the ISA Servers the ISA servers but was otherwise equivalent to this topology.
Figure xx illustrates an example of this topology.
A topology for publishing content to the Internet
The Plan content deployment
article describes the types of content that are deployed when content deployment occurs. Three items that are not deployed are workflow state, workflows designed
with SharePoint Designer and items in the recycle bin. If changes are made to the destination site collection after deployment, they are either overwritten (if they are modifications of existing items) or deleted (if they are new items) the next time the content
deployment job runs. To avoid losing information, treat destination sites as read only 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 content databases. This is because all of the GUIDs that are used to define sites, Web pages, lists and list items are transferred with the site when it is deployed. This means that you cannot
deploy a site to the same database as the source site.
Configuring the Production Farm
The following walkthrough 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 this walkthrough only covers the basics. For greater detail,
see Cannot resolve macro, invalid parameter 'input'.
and an excellent
by Stefan Gobner.
To prepare the destination site collection
- 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. A blank site actually does have some features activated. The only way to create an empty site
collection is by using the following STSADM command:
- Add and deploy all of the SharePoint Solution Packages (WSP) to the production farm that will be used on the product site. 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, then ensure that all features are installed.
- 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 handled by the WSP deployment.DO not directly activate any features in the empty
site collection. The content deployment process handles feature activation.
After creating the production site collections, you can configure import and export settings for incoming (production) and outgoing (authoring) content. See
Cannot resolve macro, invalid parameter 'input'.
for steps to configure the authoring and production farms for content deployment.
After configuring content deployment settings need to create your deployment paths and jobs. See
Manage content deployment paths and jobs
information on how to create a content deployment path and job. The reference implementation uses the default settings. Once you
have created the path and the job, you can deploy content from the authoring farm to the production farm. To run the deployment job manually, select
from the deployment job’s context menu. See the updated status by refreshing the page. Once completed, the status should display
The following articles contain more information about deploying content.