Skip to main content

Deploying contents between server.

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.

NoteNote

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.


    To configure Content Deployment between the two server farms complete the following steps:

    1. Create an empty site on the Production server farm by using the Blank Site Template.
    2.     Configure the Production server farm to accept incoming deployment jobs. This includes configuring the import server and connection security.
    3.     Configure a Web-Front-End server on the Staging server farm as the export server.
    4.     Configure the deployment path(s) between the farms on the Staging server farm. That path defines the source farm, the destination farm, the authentication information and security details.
    5.     Create the deployment job(s) on the Staging server farm. The job is where you select the content to deploy, the frequency, and so on.



Labels:

Comments

Post a Comment

Popular posts from this blog

How to get SPUser or SPGroup from Person or Group field

You have person or group field in SharePoint list and you want to programmatically get the user or person. The below code to gets SPUser from User or Group field in the list when multiple choice and Groups are not allowed in the field: //get SPUser SPFieldUser userField = (SPFieldUser)item.Fields.GetField("Users"); SPFieldUserValue userFieldValue = (SPFieldUserValue)userField.GetFieldValue(item["Users"].ToString()); SPUser user = userFieldValue.User; This part of code would help you to get SPUser when multiple choice is allowed and groups are not allowed: //Multiple choices are allowed SPFieldUser userField = (SPFieldUser)item.Fields.GetField("Users"); SPFieldUserValueCollection userFieldValueCollection = (SPFieldUserValueCollection)userField.GetFieldValue(item["Users"].ToString()); foreach (SPFieldUserValue userFieldValue in userFieldValueCollection) {     Console.WriteLine("     " + userFieldValue.User.LoginName); } And when group
1 comment
Read more

SharePoint publishing page scheduling

In SharePoint 2010 publishing enabled team site collection is not showing schedule button in publish ribbon. Solution: Here is how to enable it  though the UI: Locate the SharePoint Server Web site on which you want to enable content approval and item scheduling. Click  Site Actions , click  Site Settings , and then click  Modify Pages Library Settings . Under  General Settings , click  Versioning Settings . Click  Yes  next to  Content Approval , and then click  OK . Click  Manage item scheduling .   Click to enable the  Enable scheduling of items in this list  check box, and then click  OK .
2 comments
Read more

Changing Content Type Hub URL

Change the Hub URL through powershell by using: Set-SPMetadataServiceApplication -Identity " " -HubURI " " For Ex: Set-SPMetadataServiceApplication -Identity "Managed Metadata Service" -HubURI "http://contenttype.Domain.Com" When you try to do this you get this rather scary message: This is SharePoint telling you that this is a major thing so be careful! Essentially all your content types that you have published out will be removed if they can, and you have to republish all of your content types out again which can cause some issue.
2 comments
Read more