A while ago I created a deep dive article series covering the WSS content deployment and migration API which helped many people to develop their own applications to do export and import in a customized manner.

Today I will start a new article series which will discuss all aspects of Content Deployment – with other words the MOSS feature sitting on top of the WSS API.

Most customers see this feature as a monolithic implementation which does not allow any customization – but that is not the case as you will see in future chapters of this article series

But before we can start with the internals we first have to start with the basics.

Content Deployment – The Idea Behind

MOSS 2007 contains Content Deployment as a new feature which has been added to fulfill the requirements of companies which plan to use SharePoint as a Web server to host public facing Web sites.

The main purpose is to allow authors and reviewers to modify and evaluate on a different farm before the content is finally pushed to the public facing server farm – but also to have a single authoring environment and then push the content to multiple different farms of different departments - potentially on different continents.

A similar concept (site deployment) was already available in Microsoft Content Management Server 2002 but required additional programming for automated deployments. With MOSS 2007 this can now be automated and customized easily through a build in UI.

Content Deployment – The Feature

The Content Deployment section shown on the Operations tab of the Central Administration Website is provided by the "Content Deployment" feature which is shipped with MOSS 2007.

You can find this feature in the following directory: …\12\template\features\DeploymentLinks

This feature is activated on the Root Web of the Central Admin site collection. Be aware that this is a hidden feature so you cannot see it in the site feature list in the UI.

Deactivating this feature will remove the Content Deployment section from the central admin Web site and also disable the underlying functionality of Content Deployment as several methods verify internally if this feature has been enabled on the central admin Web site or not.

Content Deployment – The different flavors

Content Deployment as it is available in MOSS 2007 comes in three different flavors: full deployment, incremental deployment and quick deployment. Here is a short overview about the three different flavors:

Full Deployment

Full Deployment allows all the content of a site to be deployed to the target site collection independent of when the content was created. This is usually done when deploying a site collection to the target farm for the very first time.

Limitations

Full deployment will only deploy the current state of the site. It will not deploy information about historical actions performed on the site (for example, if an item has been moved or has been deleted).

Benefits

Full deployment does not rely on information about what has been previously deployed to the target. It will always export the current state of the source site collection.

Caveats

Full deployment into a database that has already received content through a content deployment job can cause inconsistencies between the source and the target farm as information about historical actions is not deployed. For example, if a list item is deleted on the source farm between the two content deployment runs you will notice that the item will not get deleted on the target farm.

Incremental Deployment

Incremental Deployment deploys all content that has changed since the last successful run of a content deployment job. Only modified content will be deployed to the target farm. Incremental deployment also transports the information about historical actions such as move, delete and rename to the target farm.

Limitations

The complexity of an incremental deployment is higher than the complexity of a full deployment job. This is due to the additional logic included to deploy only the modified content and items directly linked to the modified content. This increases the chance for problems which can cause incremental content deployment to fail. A second limitation is that an incremental deployment will only look at the source system to determine the data that has to be deployed. It will not analyze source and target and based on the difference decide which content to deploy.

Benefits

Due to the fact that only modified content is deployed, the time for an incremental deployment is usually much shorter than the initial full deployment. In addition, the feature to deploy information about historical actions allows the target system and the source system to keep in sync beyond what is possible with full deployment.

Caveats

If an incremental deployment job fails repeatedly it might be required to perform a new full deployment to the target to re-sync the content on the source farm with the target farm. Since a full deployment does not transport information about historical actions, this will only work reliably if this full deployment is performed into an empty database.

Quick Deployment

Quick Deployment allows authors to pick specific pages for content deployment. This is vital for companies which need to quickly update specific pages on their site which need to be independently updated from other content that would be deployed with an incremental deployment.

Limitations

Quick deployment will deploy only the selected publishing pages and resources bound to these pages. In addition, it is not possible to select items in a regular document library or list for quick deployment.

Benefits

Quick Deployment enables authors to register specific items for quick deploy which will be deployed to the target farm independent from any other changes that have been done on the source farm since the last full or incremental deployment.

Caveats

Quick deployment only deploys publishing pages and resources bound to the selected pages. Sites and lists are not deployed through quick deployment. Due to this, all target folders and libraries for all selected an dependent items must already exist on the target farm – otherwise quick deployment will fail. For example, consider the scenario where a new picture library has been created and a picture from this picture library has been bound to a field in a publishing page that needs to be quick deployed. Quick deployment will fail if the picture library has not been previously deployed to the target site collection.

Myths and Facts about Full, Incremental and Quick Deployment

Myth: I need at least one full and one incremental deployment job per path as I have to run at least on full deployment at the beginning before I can run an incremental deployment

Fact: The above statement is not correct. The very first incremental deployment will always be a full deployment. So there should be no need to create a full deployment job.

Myth: Full deployment is more than incremental deployment

Fact: The above statement is not correct. Full deployment only deploys the current state of the site while incremental deployment deploys all changes done to the site since the last deployment. That also includes delete and move operations. An extreme example would be a site collection that contained 100.000 items when it was last deployed. After deleting 90.000 items full deployment would only deploy the 10.000 remaining items and would not deploy the delete operations. So after a full deployment the number of items in the target database would not have changed (assuming that no other operations have been done to the source database as the delete operation). On the other hand an incremental deployment will only deploy the 90.000 deleted items to ensure that these items will also be deleted on the target. With other words: after the full deployment the source and target database will be out of sync while incremental deployment will keep these databases in sync.

Myth: It is best practice to run incremental deployments during the week and a full deployment during weekend to ensure that my content database is in sync

Fact: The above statement is not correct. Every single full deployment has the risk that the target site collection runs out of sync with the source as delete and move operations will not be applied the target which also has the risk of breaking future the content deployment jobs which will fail due to the inconsistencies between source and target.

Myth: If incremental deployment fails I can do a full deployment to fix the problem

Fact: This statement is not correct. Indeed: full deployment often succeeds when incremental deployment failed and indeed future incremental deployments will often work again afterwards but this is caused by the fact that after the full deployment the next incremental will deploy only content changed after the full deployment. The problem is that in this situation you will usually not really resolve the underlying issue. You are just avoiding it by adding all other content that exists in the source site collection to the package so that inconsistencies in the source database which led to the failing incremental deployment will no longer show up. But often the same problem occurs again a couple of days later when incremental deployment again has to deploy the problematic items. And through the full deployment you made things worse as you now have potentially additional inconsistencies between source and target due to the fact that delete and move operations that would have been deployed with the failing incremental deployment will never be deployed again. So now you added additional inconsistencies to the one that caused the earlier failure which can cause additional problems with future content deployments (as well incremental and full).

Myth: Quick deploy is an easy way to ensure that important content can go live easily out of sync with other content.

Fact: The above statement is not fully correct. The quick deployment has to be used very carefully. For every single quick deployed item – and also for all dependent items like referenced images and documents – it has to be guaranteed that the site, the folder the list or library the item is in has been deployed to the target earlier with an incremental deployment. If this is not the case the quick deploy job and all future quick deploy job runs will fail till the next incremental deployment has been performed. That means a single user that quick deploys a page that references a document in a doc lib which has not been previously deployed to the target system can cause a problem that affects the ability of all other users to perform a quick deployment. The main problem is here that quick deployment is done by authors – while incremental deployment is controlled by farm administrators. So it is usually unclear to the authors when the last successful incremental deployment has been done and which sites and lists have been deployed.

Do you think it’s a good idea, when there’s a content deployment error that can’t be resolved quickly (e.g. < 4 hours) to clear the content database of the destination and then performing a full content deployment. Essentially clearing the destination site and starting again.

Currently, I would run a full CD anyway, which I know isn’t good, but it seems to make the problem go away. So my thoughts are that I should clear the database first.

Obviously this will be done out of hours and only applies to sites that don’t necessarily need to be up 24/7.

in the past we have configured a publishing site with only primary versions and not secondary versions in the Pages library settings. We did this because of a content deployment bug. Is this correct or is this also a myth? Or perhaps fixed in a servicepack or hotfix?

Our customer now wants to use approval workflow which only works when secondary versions are turned on…

Great post but after reading this I have lots of questions and thinking of whether MOSS is gud for public facing sites or not.I hope you have explained all answers to these limitations in the later post.

I agree with you that we should do only one full deployment (the first incremental one) when build up the desitination from blank. But i will the most people palying content deployment faced failed increamental deployment, and fixed the issue by a full deployment. I did that serveral times. And with a versioning enabled portal, i finially get a huge content database. 🙂

Sometimes, we have content deployment issue, can not be fixed by a full deployment as well. But the myth is if i run a manual export and import, there is no error at all! What the differece to run it from stsadm or from central admin?

so what should i do now? A incremental failed, a full also failed. I enabled ULS log to catch content deployment and upgrade activity. The only info i got from there is importing list pages. Then an error occured saying system can not find the file specified. not mention which file.

It is the production farm, it is not possible to delete all content and redeploy.

This is a great guide and I’ve found it really useful in getting content deployment up and running. Recently the content deployment job (on MOSS 2007) has started failing and reporting the following exception on the import server:

Failed import operation for Content Deployment job ‘Remote import job for job with sourceID = f50bc18f-e5ef-4e7c-8680-a063be0b1a9d’. Exception was: ‘System.ArgumentOutOfRangeException: The specified indexer value for this collection could not be found or is not unique.

Parameter name: jobId

It looks like all the export files get uploaded and there’s no other errors being raised. Have you ever seen this before or have any suggestions on what I could look at by way of finding the problem? Any suggestions you can provide would be a big help!

Hi, we have content deployment setup and working smoothly from Authoring to QA to Staging. From Staging to Production we are getting the error below whether we do a full or incremental deployment. It always breaks at the same point ZZ1_Black.css – it is the first OOTB css in the Style Library. Any insight on how to fix this is greatly appreciated.

Great series, but we’re still stumped by a particular CD issue. A subsite got deleted from the staging site, and now the incremental CD job fails with a ‘Error deleting Web site "/main site/subsite". You can’t delete a site that has subsites.’ I understand the issue, but I don’t see how to fix it – I can’t undelete the subsite in Staging, as it’s not in the recycle bin. I tried rebuilding the subsite, but I’m not fooling MOSS.

We have a VERY unusual situation here. MOSS 2007, Enterprise edition. All set up, configured, installed, working fine. Except there is no 'Content Deployment' section on the Operations site. We installed from the exact same disk used on oterh servers which have that section, and used the same process. Any idea what would account for the entire section to be missing from Operations tab?

We are finding that alerts are not being transferred to target site on a successful full and incremental deployment. Just curious if the above statement is true for only SP farm that is above a particular SP cumulative update? If so, then do we know what
version?

We have a requirement to run content deployment immediately after content approval. Yes this means not waiting the 30 min interval between deployments. We plan to do this by programatically executing the deployment job via workflow. Is this a supported scenario?

Is there any way we can terminate a stuck CDJ? This is required to resolve the issues identified during an incremental run at the source or target site collections. I tried to restart the SharePoint timer service from all servers of the farm but it did not work. Also I am interested to know how can we find which server is being used for a CDJ instance.