Condividi tramite

Deploying Content Between Servers in SharePoint Server 2010 (ECM)

  • Articolo

Applies to: SharePoint Server 2010

Microsoft SharePoint Server 2010 provides a rich deployment user interface. Most deployment scenarios can be accomplished by an IT professional through the user interface (UI), without the need for scripts. However, you can still use the object model to handle other scenarios, such as deploying content between servers that are not on the same network or writing scripts to automate common tasks. This topic provides an overview of the SharePoint Server 2010 content deployment feature and gives developers the background and resources necessary to build and implement custom deployment solutions.

Before considering content deployment concepts and scope, let's consider a basic scenario for which content deployment is a solution. In a typical IT scenario for an Internet-facing site, content is authored by people on your internal network, and some network separation exists. For example, the network may have one or more firewalls between the intranet and the Internet-facing network. In this scenario, internal content providers need access to the SharePoint Server 2010 site so they can author, edit, and approve content, but for security reasons the system needs a way to shield the intranet from incoming Internet traffic. Clearly, Internet users need to access the SharePoint Server 2010 site, which is one reason why IT departments frequently separate servers into two farms: one server farm for internal content and the intranet, and another server farm for the Internet-facing network that hosts a production site. Authors work on the internal farm, while Internet customers view content on your production farm. With this server farm separation, a need arises for a consistent and easy way to move authored content from the source authoring farm to the destination production farm. That solution is content deployment.

You can use content deployment to push content from a source server farm to a destination server farm. Content deployment supports two-tier (authoring to production), three-tier (authoring to staging to production), and n-tier topologies. Content deployment can flexibly support many different topological arrangements in part because the basic steps for successfully deploying content in SharePoint Server 2010 are consistent regardless of topology:

  1. Export content from the source farm.

  2. Transport content from the source farm to the destination farm.

  3. Import content into the destination farm.

Note

Content deployment is always one-way. It is a "single master" system that always moves from a source farm or site collection to a destination farm or site collection.

You can write code that uses the object model to complete these steps. You can deploy content in code exactly the same way you can in the UI, or you can set custom properties for export and import that tailor the deployment to meet needs that you cannot meet when setting up a deployment through the SharePoint Central Administration site. You can also create code that exports and imports a content package in situations where connectivity between a source farm and a destination farm may be limited or unavailable.

In a typical content deployment, the feature automatically transports the content from the source farm to the destination farm, and then instantiates the remote import. Content deployment manages these steps by using paths and jobs.

  • A path is a connection between a source farm and a destination farm. It contains information about the source Web application and site collection being deployed, authentication for the destination farm, and the Web application and site collection on the destination farm. The path represents the mapping between the authoring and production site collections. The path does not deploy content.

  • A job is associated with a path, and it determines exactly which sites in the source site collection are deployed and on what schedule. You can associate many jobs with a single path, and each can run on a different schedule and deploy specific sections of your site. A job can deploy content updates regularly without needing a manual restart every time.

For example, AdventureWorks has several Office SharePoint Server 2007 site collections. They include a Press Releases site that requires hourly updates and an About Employees site that requires monthly updates. By creating two jobs--one that runs every hour and deploys the Press Releases site, and another runs monthly and deploys the About Employees site--you can ensure that both sites are updated on their respective schedules.

In This Section

See Also

Reference

ContentDeploymentConfiguration

ContentDeploymentJob

ContentDeploymentNotificationSettings

ContentDeploymentPath

ContentMigration

ContentMigrationSettings

ContentMigrationType

DeploymentStatus

DeploymentStatusDictionary

JobReportType