Content Deployment is a powerful part of Microsoft Office SharePoint Server (MOSS). It can also be a bit of a challenge in highly customised environments. Recently I had the task of enabling Content Deployment in an Internet-facing situation.
The situation was pretty typical. An Internet-facing site that contains content authored by people on an internal network separated by a firewall. The internal authors need to have the ability to author, edit, and approve content, but also ensure that this environment is shielded from incoming Internet traffic for security purposes.
The brief was to enable content deployment between a site on the client's internal authoring environment and a publicly accessible site in their external DMZ publishing environment. Content deployment needed to run an incremental deployment every hour and a full deployment nightly.
We had some initial problems but managed to overcome these. This is a record of what happened and how we solved these issues.
A little disclaimer: It is very important that any custom developed components are created in-line with SharePoint best practice. Shortcuts in this area will lead to a lot of extra effort further down the track.
Content deployment does not deploy any custom code or file system artifacts. These components have to be present in both the Internet-facing and internal authoring environments for content deployment to succeed. In our situation we had a couple of masterpages, a number of page layouts, and about 20 odd SharePoint custom field controls. Most of the issues we encountered were around the custom field controls.
SharePoint Content Deployment has 3 distinct stages,
exporting from the authoring site,
transporting to the Internet-facing site, and finally
importing at Internet-facing site.
1) The first problem we encountered was that we could
export our content successfully from our authoring environment but were unable to
import this content into the Internet-facing site.
This was solved by deploying our custom code or file system artifacts to the Shared Services Provider (SSP) on the destination farm.
2) We then had a requirement to add validation to the custom field controls. We followed an article on MSDN (
http://msdn.microsoft.com/en-us/library/ms434697.aspx) to implement validation. The first approach in this article suggested that we validate the actual field. This method of validation worked perfectly in the authoring environment. However we encountered problems when we were importing into the destination Internet-facing site.
This was solved by changing our validation strategy to only validate the UI of the control (see second approach in the above article). Theoretically any value could be saved to the field, but if you were using the user interface to save a value (which the content authors were), then only certain correct values could be saved.
What we observed was that by validating the actual field rather than just the UI of the control we were crashing the content deployment process.
3) About this time we were worried about our ability to debug future Content Deployment issues. We investigated ways of using the API to create a Custom Content Deployment application, and can be seen in action in the SPDeploymentWizard codeplex project(
http://www.codeplex.com/SPDeploymentWizard).
This was pretty easy to do. We created a console app with some configuration switches to change Import/Export, and logging levels. The major advantage with this is that you can configure the app to have much more verbose logging than is typical with SharePoint OOTB. Basically you can print a line for every object that is being exported and can find the exact object that is causing the deployment to fail.
4) We then created and deployed two new custom field controls, and again the content deployment stopped on the Export.
The controls were created in exactly the same way as the previous controls. If we excluded the controls the content deployment worked fine. The controls were definitely deployed correctly as we could use them within the authoring environment.
To fix this we restarted all the servers. I noticed an error occurring from some code that was no longer present within our solution. I could only infer that SharePoint Content Deployment was caching a temporary version of the DLL somewhere. The restart flushed this cache, and content deployment started immediately.
This didn't take too long to write down but took a while to work out at the time. Hopefully this is useful for someone when they are in the process of enabling content deployment in the future.