I've been working with a client for the last few months to develop a handful of public facing web sites running under MOSS publishing. I headed over to the UK to deploy the framework for these sites and ensure that we could do content deployments from their internal staging environment to their production environment in their DMZ. I've had some success in the past with content deployment in SharePoint but its always made me nervous even following SP1 and the post-SP1 infrastructure updates that were suppose to target many problems with content deployment. After a frustrating day without success and cryptic errors we initiated a call to MS. Our client was concerned with some regulatory compliance issues if the site wasn't deployed so we figured it warranted a call to MS to get things going. Not my first call to MS probably not my last.

After working with MS for almost 12 hours straight with no success our call was pushed up the ladder. In the end we finally got some resolution but I think that Content Deployment really needs some more maturing. I was hoping for a better experience with all the infrastructure updates that addressed numerous issues. It would appear that those updates only took the functionality from broken to "mostly working" status lol. The administration experience is still fairly primitive and even MS support could not agree on the best practices or even proper steps  in some sceneries. I especially didn't get the warm fuzzy with MS support mentioned about every hour that there were still known issues with Content Deployment. Unfortunately I couldn't seem to dig out of him what those known issues where.

I thought I might pass on a couple issues that caused us some grief:

1) Feature Receivers - The solution for our client was meant to be a turn key solution that could be reused on many sites. Because of this all entities for the site had to be wrapped up in features and activated on demand as needed (or from a site def). Now lookup fields can not be created declaratively because they require instance IDs that don't exist at the time of definition. A common practice is to place these within feature receivers so that when a feature is activated, in our case creating new lists and site columns among other things required lookup fields get generated along side the declarative fields. This works great until content deployment. Content deployment jobs start with an empty site then they activate the appropriate features and then they push content over. Because the feature is "reactivated" prior content deployment and in our case the lookup column is created it causes a conflicting column error during content deployment. Now I completely understand that MS can't account for things that occur in feature receivers, the possibilities could be endless, but it would be nice to have a hook somewhere in a context that allowed me to have logic in the feature receiver to deal with this scenario. We were able to get around this but being a big fan of feature receivers to overcome short comings in the CAML\Declarative feature syntax it makes me give pause to quickly slap things into feature receivers in the future when I know content deployments will be used.

2) Using a Blank Site for the target of Content Deployments - Starting a few months back I began creating the default site collection of a target content deployment site using the command line (stsadm). This is the only reliable way to create a truly empty site as even a blank site has artifact in it which can cause conflicts. Throughout the process with MS we were told time and time again to use a blank site template. I asked them to confirm this several times and they insisted that this was correct way of "priming" the target site. In the end we ended up using the stsadm -o createsite command which doesn't require you to specify a template and the content deployment package successfully deployed. It's pretty scary that something at the core of content deployments still has conflicting practices at MS.

3) Consistent naming of the webtemp.xml for custom site definitions - Our biggest teaser was that we were able to create sites using our custom site definition on the target farm but content deployment errors kept insisting that the site definition didn't exist. At first we thought it was a language issues because it mentioned 1033 several times and we were on a UK server but that wasn't the problem. Somewhere along the lines on our internal staging server our webtemp.xml file got named from webtemp[customname].xml to webtemp.[customname].xml (period separator). I can only think that we changed it by accident in passing while checking content deployment problems so this really isn't a MS problem but at the same time the error message implied that the custom site def wasn't registered when in fact it was, just with a different webtemp.xml filename. So this brings me to my biggest remaining beef with content deployments...

Content deployments are still very hard to diagnose and resolve the source of conflicts and issues. We cranked up logging to the highest level and that just made our life even more difficult as we had to wade through 10 times as much garbage without it contributing much to the resolution of our issue. I think 2 out of the 3 issues we had can be rather common out there. Completely legitimate but common none the less but even if they aren't common it shouldn't be this hard to figure out and resolve content deployment issues. Now that the majority of stability issues are hopefully resolved with the post SP1 infrastructure patch I think its a good time for MS to start improving the usability and manageability of content deployment beyond the level of something I would expect from a CodePlex project (no offense to all the great CodePlex projects out there lol).

Hopefully this may help a couple folks out there in their own Content Deployment hell :) Have any horror stories you'd like to share?