Part 1 - The BasicsPart 2 - The Basics continuedPart 3 - ConfigurationPart 4 - CommunicationPart 5 - Quick DeploymentPart 6 - LoggingPart 7 - Change Token BasicsPart 8 - Job and Change TokenPart 9 - Job and Timerjob
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.
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.
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.
You can easily try this on your own using the following command:
STSADM -o deactivatefeature -url http://central-admin-url -name DeploymentLinks
After executing this command you will see that the content deployment section is gone from the operations tab. To reenable the functionality use this command:
STSADM -o activatefeature -url http://central-admin-url -name DeploymentLinks
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 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.
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).
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.
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 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.
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.
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.
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 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.
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.
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.
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.
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.
Thanks for another set of great posts about Content Deployment.
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.
that is a common practice and will avoid the inconsistencies between source and target.
If the problem has been caused by authoring activities on the target system (conflicting content) it will also be a way to resolve the problem.
But if not you should consider to open a support case. Because then the problem will show up later again and again and again.
Fixing the underlying issue should then be the preferred way to deal with this.
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...
I have never heard about this myth.
You can have versioning in the pages lib.
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.
Do let me know if u have not done that,then I will ask you here :-)
how can I tell you if I covered your questions in later posts if I don't know the questions. ;-)
Feel free to send the question here.
Is it possible to deploy content from a Sharepoint 2007 source farm to a Sharepoint 2010 target farm?
no this is not possible.
Do you know why?
Do cab files have different format?
2) different schema version.
Thanks for your post, it always gives me benifit after reading.
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?
as I outlined: a full deployment will not fix the issue! It only postpones it to a later date. And it might cause additional trouble due to missing deployments of delete and move operations.
Mixing STSADM export/import with content deployment is unsupported as STSADM export/import does not preserve GUIDs while content deployment does preserve the GUIDs.
After an STSADM export/import further content deployment operations will usually fail.
Thanks for your quick reply.
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.
Then you should open a support case with Microsoft to get this analyzed.
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!