SharePoint 2007 - Setting up Content Deployment Jobs

Wednesday, 27 February 2008 22:38 by RanjanBanerji

In my previous post on content deployment  I talk about how content deployment jobs are not as smart as they are made out to be.  A little more testing helped me determine when jobs can be smart and when they are not.

Let's start by defining smart.  When doing an incremental deployment Microsoft claims that for a path when content is deployed SharePoint will remember that fact and will only deploy new, edited, or deleted content from this point on.  This is not exactly true.  My previous post shows that.  But here is a recap and some additional information.

Let's start with creating a site collection with a structure like as follows.

Root

--------S1

--------S2

--------S3

--------S4

--------S5

--------S6

----------------S6.1

------------------------S6.1.1

------------------------S6.1.2

------------------------S6.1.3

----------------S6.2

----------------S6.3

 

Content Deployment Scenarios (Please note, all content deployments in this case are incremental, i.e., only new, edited, or deleted content is deployed).

Scenario 1

  1. Deploy S6.1.1 (Branch) as job 1
  2. Now deploy S6.1 (Branch) as job 2.  SharePoint will redeploy all content from S6.1.1 in job 2 even though you just deployed it under job 1, i.e., not that smart.

Scenario 2

  1. Deploy S6.1(Branch) job 1.
  2. Now deploy S6.1.1 as job 2.  SharePoint will only deploy content from S6.1.1 that has been edited, added, or deleted, i.e., smart, it remembers everything pushed under job 1.

Scenario 3

  1. Deploy S6.1 (Branch) as job 1
  2. Deploy S6.2 (Branch) as job 2
  3. Deploy S6.1 (Branch), S6.2 (Branch), and S6.3 (Branch) as job 3.  Job 3 will deploy S6.3 and only edits, additions and deletions to S6.1 and S6.2, i.e., smart.

So it appears SharePoint's content deployment is smart as long as a job contains sites that children of a site that is already deployed or siblings.  But deploy a site and then its parent site and the smartness is gone.

Why is this important?

Deploying content for a very large site collection under bad network conditions may require that your first deployment for each site is done as a separate job.  This will result in 10s or 20s or 100s of jobs to get your initial content across.  From this point on you want to reduce the total number of jobs running since now you are only deploying new content, changes, and deletions. 

Why reduce the number of jobs for new content?  Well SharePoint often issues a nasty error (save conflict) if two jobs complete at the same time.  Its not easy to schedule a large number of jobs in a manner that there will never be a save conflict error.  SharePoint offers no way to trigger a job based on the termination of another job.  So your best bet for reliable deployments is to reduce the number of jobs.

Ahaa! and the moment you try to reduce the number of jobs by creating consolidated jobs after your initial deployment you may find that SharePoint is redeploying everything if your consolidation followed the pattern of scenario 1 above.  And why is redeplying bad?  Well that will be addressed in my next post.

So plan how you create your smaller jobs and how you consolidate them later.

 

Comments

January 26. 2014 02:46

pingback

Pingback from camera-site.com

Axis Communications | Digital SLR Camea Site

camera-site.com

Add comment


(Will show your Gravatar icon)

  Country flag

biuquote
  • Comment
  • Preview
Loading