Part 1 – The Basics
Part 2 – The Basics continued
Part 3 – Configuration
Part 4 – Communication
Part 5 – Quick Deployment
Part 6 – Logging
Part 7 – Change Token Basics
Part 8 – Job and Change Token
Part 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.
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.
Permalink
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.
Permalink
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
Permalink
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
Permalink
Hi Harold,
I have never heard about this myth.
You can have versioning in the pages lib.
Cheers,
Stefan
Permalink
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
Permalink
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
Permalink
Hi Stefan,
Is it possible to deploy content from a Sharepoint 2007 source farm to a Sharepoint 2010 target farm?
Thanks
Angel.
Permalink
Hi Angel,
no this is not possible.
Cheers,
Stefan
Permalink
Do you know why?
Do cab files have different format?
Thanks,
Angel.
Permalink
1) unsupported
2) different schema version.
Permalink
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?
Permalink
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
Permalink
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.
Permalink
Then you should open a support case with Microsoft to get this analyzed.
Permalink
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
Permalink
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
Permalink
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.
Permalink
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
Permalink
Is it possible to deploy content between two different Farms?
Permalink
Hi Sami,
yes. This is actually the most common use of Content Deployment.
Cheers,
Stefan
Permalink
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()
Permalink
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
Permalink
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
Permalink
Hi Kurt,
the simplest method would be to delete the site on the target.
Cheers,
Stefan
Permalink
Hi Stefan;
Thank you very much! We had been nervous about touching the target site, but that worked perfectly.
Kurt
Permalink
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,
Permalink
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
Permalink
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
Permalink
Hi Nishan,
this is an error in the article. "Now" should read "Not": "The following are not deployed…"
Cheers,
Stefan
Permalink
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
Permalink
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
Permalink
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.
Permalink
Enterprise experience with Content Deployment jobs in SharePoint 2010 (and 2013)
Permalink
Enterprise experience with Content Deployment jobs in SharePoint 2010 (and 2013)