Deep Dive into the SharePoint Content Deployment and Migration API - Part 6
[Part 1 - Part 2 - Part 3 - Part 4 - Part 5 - Part 6]
Requirements for a successful content deployment
Be aware that this article cannot provide a complete list of all requirements. I will update it from time to time if required. Today I will list all the requirements I have seen in the past which - when missed - can cause content deployment jobs to fail.
1) The servers configured as export and import server need to host an instance of the Central Administration website
When configuring the "Content Deployment Settings" for your farm you have the chance to select different servers in your farm to work as export and import servers for the content deployment. This allows to offload this task to a dedictated server to reduce the load on your web frontend servers.
The comments of this configuration options look as follows (here shown for the Import server):
Import Server
Specify the server you want to receive incoming content deployment jobs. This server must have enough available disk space to store the incoming jobs, and it must be running an administration Web application for the farm.
So this requirement is actually listed but a little bit hidden in the second half of a sentence.
In case you configure a server that does not host the Central Admin website then you will not get a warning here!
Impact: The effect you will see is that the content deployment export or import phase will not start.
How to resolve:
1) Provision the Central Administration website on the desired server
2) Change the configuration of the export and/or import server
2) Ensure that sufficient disk space is available
This sounds like a simple prerequesit but it isn't. Content deployment uses different places to store the extracted and compressed files. The compressed files are stored in the location you can configure on the "Content Deployment Settings" page in the "Temporary Files" row.
But before export creates the compressed files it first exports everything into a temporary directory. And this directory is placed inside the directory which is configured in the TMP environment variable of the user the Windows SharePoint Services Timer service (OWSTIMER.EXE) runs on (usually refered to as farm credentials). Per default this variable has the following value: "%USERPROFILE%\Local Settings\Temp" which is usually on your system drive.
Impact: So per default MOSS content deployment requires the disk space for the uncompressed exported files on your system drive!
How to resolve: The easiest way to resolve this is to logon to the machine with the farm credentials and adjust the TMP variable to point to a different location. Afterwards you would need to restart the OWSTIMER service.
3) Use an empty site collection as the destination of your content deployment job
As already discussed in Part 5 content deployment will fail if the destination database contains conflicting content. To avoid this it is required that the initial deployment is done into an empty site collection.
Be aware that the only way to create an empty site collection is to use the following STSADM command:
STSADM.EXE -o createsite -url <url-to-site-collection> -ownerlogin domain\user -owneremail <email-address>
Using the "Blank Site" template will NOT create an empty site collection! It will actually create a site collection with content. You can see the difference if you create a site collection using both methods and then inspect the content of the created sites using SharePoint designer.
I personally recommed to always use the STSADM command with the syntax above to ensure that you really have an empty site collection as destination.
Impact: If the site collection has been created using a different method or already contains data the content deployment job will fail.
How to resolve: Deploy into an empty site collection
4) Install all required features for your site on the destination server
If your site requires custom features ensure that the features are installed on the destination server before running content deployment.
Impact: If the are missing the import phase will fail.
How to identify this: I have written the tool WssAnalyzeFeatures which allows you to identify such problems.
How to resolve: Copy the features to the destination server and install them using STSADM -o installfeature.
5) Do not activate custom features for your site collection on the destination server manually
You should not activate custom features on the destination server if this activation creates content in the destination database as this can cause conflicts as outlined in "Problem 1" of Part 5 of this article series. Instead you should run content deployment and let the import process activate the features on your destination server as this will ensure that all items get created using the same ids as on the source server which is otherwise not guaranteed.
Impact: If the features have been activated and the content deployment import can fail with similar error messages in as "Problem 1" of Part 5.
How to resolve: Deactivate the feature in the destination site and ensure that all items created by the feature are removed. Alternatively do a full deployment into an empty site collection instead.
6) Do not expect that incremental deployment will deactivate features in the destination server site collection
The content deployment and migration API was not designed to deactivate features on the destination server. If a feature needs to be deactivated on the destination server you need to manually perform this deactivation.
7) Ensure that all feature definitions of features activated on the site collection exist on the source server
This is actually a high call generated for Microsoft Support Services: in the development a feature becomes obsolete and is removed or replaced with a different version with a different Guid but on some sites or site collection the old feature is still activated.
Impact: The affected sites can no longer be exported. You will get the errors listed in this article.
How to identify this: I have written the tool WssAnalyzeFeatures which allows you to identify such problems.
How to resolve: Either copy the missing feature files to the required location or uninstall the feature using STSADM -o deactivatefeature/uninstallfeature. In case that STSADM -o deactivatefeature fails to deactivate the feature you can use my tool WssRemoveFeatureFromSite.
8) Configure the retention period of the change log to be long enough for incremental deployment
See here for details.
9) Ensure that content deployment jobs do not run in parallel
The current implementation of the content deployment and migration API does not allow parallel execution. There are plans to change this behavior in the near future but as is you need to ensure that only one deployment is running at a time.
So if you have multiple deployment paths and jobs for the same site collection you need to ensure to schedule them in a way that they don't overlap.
But this is not the only place to look at! Sometimes it is nearly impossible to prevent parallel execution. Just think that the content deployment and migration API is not only used to deploy content between different webfarms. The same API is used in the copy/move implementation inside site manager and in the variation feature.
With other words: you can experience problems with content deployment if an author copies a page at the same time or creates a new page in the source variation label which is then replicated to the destination. And also vice versa a copy operation can fail because a quick deploy job was running at the same time.
Impact: parallel execution of deployment jobs can lead to failing content deployment.
How to resolve: you need to restart the failed deployment job
10) Ensure that the patch level on source and destination farm is identical
Content deployment is only supported if the WSS and MOSS patch level is identical on source and destination. Some hotfixes have changed the schema of the export packages slightly which can cause deployments between different patch levels to fail.
Impact: content deployment and STSADM -o export/import can fail if the patch level is not identical
How to resolve: ensure that both farms are on the same WSS and MOSS patch level
11) Required Language Packs need to be available
Language Packs used in the source site collection have to be installed on the target farm as well.
Impact: if a required language is missing content deployment will fail
How to resolve: install the required language packs on the target farm
12) Avoid the problems listed in Part 5 of this article series.
