Little Known Facts (Issues) of MOSS Content Deployment Jobs (MOSS 2007)

I spend 1.5 years working on a MOSS project (yes, the project was that long…) developing a MOSS web content management platform. Here are some things I could like to share during my 1.5 years of my life (yes, I know a lot about MOSS web content management after 1.5 years of my life spend living with it)… things Microsoft didn’t want anyone to know…  on a side note, some of the problem can be fix using custom code, if you run into any of the problem email me…

I am sure most of you who uses MOSS know there is a thing in SharePoint call “content deployment” features which allow you to deploy approved content from server 1 to server 2. This function is created for web content management and web publishing. Here are some little known fact about this “content deployment”. I will try to update this post as I remember more of things we run into during the project…

  • Microsoft whitepaper say you can have a 3 stage deployment (Develop, Staging, and Production), but this is false!
    • What Microsoft is trying to say on their whitepaper is that you can do the following:
      • Develop to Staging
      • Develop to Production
    • There is no out-of-the-box solution for this one yet… you can have a workaround using custom code by coding a manual timer job
    • Technically you can only do 2 stage content deployment. This doesn’t really work for firm that is regulated by government such as the FDA that “WANTS” to have a 3 stage content deployment process (check your work before having the content go to the public for government regulation purpose).
  • MOSS web content management have a lot of bugs…
    • Content deployment within MOSS’s web content management is nothing close to perfect… Check out some of my other blogs for some of those errors…
    • A lot of those errors are “unexplainable”, and the only way to fix it is to recreate the deployment jobs.
  • Microsoft calls it “content deployment job”, but do you know technically all your content are deploy to the 2nd server?
    • In MOSS when you create a document it is call version 0.1 and when its publish it is then call version 1.0
    • Version 1.0 is then publish to the internet for the rest of the world to view.
    • BUT the way content deployment works is that it copy all version to 2nd server, then uses permission to mask the content from being display on the internet…
    • This means every version you have (even un approved version) are “technically ” on the 2nd server available to the rest of the world, the public just can’t view it because of permission.
  • Versioning
    • Depends on how your content deployment job is setup, the 1st server will copy and overwrite content in 2nd server. Not a big issue until you are trying to figure out the version in server 2 and dealing with the database size…
    • This is how it works:
      • when things is approve, server 1 copies the content to server 2.
      • Server 2’s content is then overwritten and the new content is rename as a new version.
      • Image the server does this every 15 mins (common schedules for MOSS web content management)… by week 2 you have on version 500+!!!
    • Why is this important? What if you are trying to build a report that shows you version in dev and production? You can’t build a report with this type of behavior…

2 Responses

  1. Please explain in more detail what you mean when you say that you cannot have a 3-stage development cycle. I am working on a project where we use content deployment to move content from authoring, to staging then from staging to production. This seems to work ok, but after every 5 or 6 partial deployment to prod, we have to delete the site collection, recreate it and do a full content deployment (obviously this sucks since it means we have to be “down” while this is going on.)

    • Hi Greg,

      Got your comment on my blog. Here is the problem we have during the project I was on:

      – The client wanted 3 stage deployment for a web content management system.
      – They want to do 2 stage approval. 1 approval during dev, and another final approval in staging. So after content is approval in dev, the content is suppose to wait in staging until a 2nd approval is granted.
      – In central admin, we set up the deployment job to do the following:
      — Dev to Stage – auto at every 5 mins
      — Stage to Prod – auto at every 5 mins
      – The problem occur when we approval the content in Dev, instead of waiting for a 2nd approval it go directly to Prod. It turns out that once a content is set to “approve” the first time, the system automatically assume the content is approve and move it out of staging right away.
      — Because the customer wanted to have the end user to control the deployment (getting the deployment out of IT’s responsibility), we end up building a custom solution.
      — So what we did to fix it the problem was to build a custom timer job and insert it into Staging. Instead of setting the Stage to Prod to auto, we have it as manual.
      — When a end user click on a button in Dev, it manually kick off the timer job. This was the work around we created base on the customer’s requirement…
      — The sad thing was other system such as interwroven does allow this features (which was why the customer wanted it to say the same)…

      Was the above similar to what you guys are trying to do?

      As for the 5 or 6 partial deployment issue, the entire content deployment features in sharepoint was buggy, we notice it seem to be a random issue (at least was what we think)… We believe it’s random as we can’t really fine a patent of why the error occur. Our work around was to use a full deployment every time (which result in another problem with versioning, see one of my prior post about versioning in production), which seem to give us less problem.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: