Content Deployment – The complete Guide – Part 1 – The Basics

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.

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 – 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.

34 Comments


  1. Hi Stefan,

    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.

    Reply

  2. Hi Bryon,

    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.

    Cheers,

    Stefan

    Reply

  3. Hi Stefan,

    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…

    Kind Regards,

    Harold

    Reply

  4. Hi Harold,

    I have never heard about this myth.

    You can have versioning in the pages lib.

    Cheers,

    Stefan

    Reply

  5. Hi Stefan,

    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 🙂

    Thanks,

    PS

    Reply

  6. Hi PS,

    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.

    Cheers,

    Stefan

    Reply

  7. Hi Stefan,

    Is it possible to deploy content from a Sharepoint 2007 source farm to a Sharepoint 2010 target farm?

    Thanks

    Angel.

    Reply

  8. Hi Angel,

    no this is not possible.

    Cheers,

    Stefan

    Reply

  9. Do you know why?

    Do cab files have different format?

    Thanks,

    Angel.

    Reply

  10. 1) unsupported

    2) different schema version.

    Reply

  11. Hi Stefan,

    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?

    Reply

  12. Hi Weina,

    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.

    Cheers,

    Stefan

    Reply

  13. Hi Stefan,

    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.

    Reply

  14. Then you should open a support case with Microsoft to get this analyzed.

    Reply

  15. Hi Stefan,

      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!  

    Thanks

    Reply

  16. Hi Adam,

    sorry I cannot pinpoint this with just the info you provided. You should open a support case with Microsoft to get this investigated.

    Cheers,

    Stefan

    Reply

  17. I need to migrate one SPWeb (subsite) as one site collection in the target site. So, the source subsite is a SPWeb. But the destination is a SPSite. Appreciate any help.

    Reply

  18. Hi Biyut,

    what you really mean is that you need to migrate an SPWeb which is not a root SPWeb into a root SPWeb in a different site collection.

    SPSite is just a collection of SPWeb objects.

    What you need is possible – as long as you are talking about WSS sites.

    Sites based on the publishing feature cannot be migrated from subsite to root site in a supported manner.

    The reason is that in the rootsite there are the page layouts and several properties which do not exist in the sub site.

    If you migrate the sub site from the root site then the link between the publishing pages and the page layout will get broken.

    Cheers,

    Stefan

    Reply

  19. Is it possible to deploy content between two different Farms?

    Reply

  20. Hi Sami,

    yes. This is actually the most common use of Content Deployment.

    Cheers,

    Stefan

    Reply

  21. 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.

    [3/29/2010 2:54:41 PM]: Progress: Importing ListItem /Style Library?id=54.

    [3/29/2010 2:54:43 PM]: FatalError: Exception occurred. (Exception from HRESULT: 0x80020009 (DISP_E_EXCEPTION))

      at Microsoft.SharePoint.Library.SPRequest.GetFileAndFolderProperties(String bstrUrl, String bstrStartUrl, ListDocsFlags ListDocsFlags, Boolean bThrowException, Int32& phrStatus, Object& pvarFiles, Object& pvarDirs, UInt32& pdwNumberOfFiles, UInt32& pdwNumberOfDirs)

      at Microsoft.SharePoint.SPWeb.GetFileOrFolderProperties(String strUrl, ListDocsFlags listDocsFlags, Boolean throwException)

      at Microsoft.SharePoint.SPFile.PropertiesCore(Boolean throwException)

      at Microsoft.SharePoint.SPFile.get_Properties()

      at Microsoft.SharePoint.SPFile.get_Level()

      at Microsoft.SharePoint.Deployment.FileSerializer.CheckInFile(SPFile file, Guid fileId, String fileUrl, SPUser editor, SPImportSettings settings)

      at Microsoft.SharePoint.Deployment.ListItemSerializer.SetObjectData(Object obj, SerializationInfo info, StreamingContext context, ISurrogateSelector selector)

      at Microsoft.SharePoint.Deployment.XmlFormatter.ParseObject(Type objectType, Boolean isChildObject)

      at Microsoft.SharePoint.Deployment.XmlFormatter.DeserializeObject(Type objectType, Boolean isChildObject, DeploymentObject envelope)

      at Microsoft.SharePoint.Deployment.XmlFormatter.Deserialize(Stream serializationStream)

      at Microsoft.SharePoint.Deployment.ObjectSerializer.Deserialize(Stream serializationStream)

      at Microsoft.SharePoint.Deployment.ImportObjectManager.ProcessObject(XmlReader xmlReader)

      at Microsoft.SharePoint.Deployment.SPImport.DeserializeObjects()

      at Microsoft.SharePoint.Deployment.SPImport.Run()

    Reply

  22. Hi carL,

    I haven’t seen this. This is not a known issue.

    I would suggest to open a support case with Microsoft.

    Cheers,

    Stefan

    Reply

  23. Hi Stefan;

    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.

    Any suggestions?

    Kurt

    Reply

  24. Hi Kurt,

    the simplest method would be to delete the site on the target.

    Cheers,

    Stefan

    Reply

  25. Hi Stefan;

    Thank you very much!  We had been nervous about touching the target site, but that worked perfectly.

    Kurt

    Reply

  26. Stephan,

    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?

    Thanks,

    Reply

  27. Hi Keith,

    this will happen if the "DeploymentLinks" feature is not activated on the central admin website:

    You can activate it using stsadm -o activatefeature. that should resolve the problem.

    Cheers,

    Stefan

    Reply

  28. Hi Stefan,

    This articles states "The following are now deployed: workflow state, workflows that are designed with SharePoint Designer, items in the recycle bin, audit trails, and alerts." for MOSS 2007.

    msdn.microsoft.com/…/ff649641.aspx

    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?

    Thanks,

    Nishan

    Reply

  29. Hi Nishan,

    this is an error in the article. "Now" should read "Not": "The following are not deployed…"

    Cheers,

    Stefan

    Reply

  30. Hi

    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?

    Thanks

    Reply

  31. Hi Dave,

    not sure how you plan to start the job. the workflow is running in the app pool of the web app while the Job would have to be started with the farm account.

    As we advice against using the farm account as application pool account for the web applications you would have to impersonate the farm account within the workflow.

    Also be aware that it is unsupported to run more than one Content deployment Job for the same web app at any given time. So you might have to implement a sync method.

    btw: why do you use Content deployment at all? Your requirement sounds as if authoring and approval on the production farm is more what you should plan to do.

    Cheers,

    Stefan

    Reply

  32. Hi Stefan,

    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.

    Reply

  33. Enterprise experience with Content Deployment jobs in SharePoint 2010 (and 2013)

    Reply

  34. Enterprise experience with Content Deployment jobs in SharePoint 2010 (and 2013)

    Reply

Leave a Reply to Stefan Goßner Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.