Content Deployment: Ensure your platform hygiene before randomly abusing the product and calling support.

Print | posted on Wednesday, June 27, 2007 12:52 AM

Yeah, I know what you're thinking, 'it's that Harbar again, ranting uncontrollably about some admin crap I don't care about'. Well that might well be the case, but the thing is you should care. Especially if you are building solutions based upon the Web Content Management (WCM) features of Office SharePoint Server 2007. See the important bit is the word 'solutions' - that means the entire thing, not just the funky recursive wrapped wrapper you got for dealing with '/pages/', your reflection bling and email address capture widget.

One of the WCM features is that of Content Deployment. Content Deployment let's you deploy content from one Site Collection to another. It's pretty neat. It sorta came from the Site Deployment feature of MCMS and makes use of the 'PRIME' WSS APIs. It's pretty important if you are interested in the 'traditional' (in web terms) publishing scenario of separating content contribution from content delivery.

The trouble is Content Deployment is getting a bad rap. A really, really bad rap - think Vanilla Ice. That's bad. Worse than Tony M from the NPG.

Now I am not saying Content Deployment is the solution to world hunger (that's Windows SharePoint Services Solution Packages). I am not saying that Content Deployment doesn't have any "issues". I am not saying that Content Deployment doesn't need some love from the Product Group. I am not saying the SDK samples err, couldn't use some, err, sample code.

What I am saying is that most of the folk bitching and moaning about it don't have their platform house in order.

Over the last month or so I've been exposed to some pretty big Publishing Site based solutions along with the usual Portal addicts (and it's NOT all the same now!). Most of these have had problems with Content Deployment. I also had the pleasure of being at TechEd earlier in the month, and frankly the least pleasurable part of that was the number of Content Deployment conversations I had.

See, the most common cause of these problems is not Content Deployment being a disaster zone best left well alone, but a combination of a misunderstanding of the feature, a badly configured platform and zero awareness of publicly recognized and fixed bugs.

So, before you lament the feature for being utter rubbish and dialing up support expecting a miracle, please get your heads around the following essential information:

1. First up - get your head around what the feature is and how it works.
   No really. This is actually quite a good idea. It's a bit like a codehead slapping that paging data grid on their web forms and then scratching their head cos it's slow. Duh! The more you know the more you know, you know?
   Check out the essential information here: Content Deployment: Tyler Butler over on the SharePoint Team Blog. I'm frequently amazed how many people ask questions about Paths, Jobs and wotnot without having seen this. Then head over to TechNet and read up some more.
2. Stop whining when the problem you've got is cos you didn't do #1, above.
   "folder with the name Page Layout already exists, grrrr, Content Deployment sucks" Dude, give me a break - it isn't gonna work if your initial destination isn't a blank site. This is so common, but it's in the documentation, the item above and in a pretty explicit KB. You should also consider not using the blank site template via the Central Admin UI but use STSADM to create an empty site:
   
   STSADM.EXE -o createsite -url <url-to-site-collection> -ownerlogin domain\user -owneremail <email-address>
   
3. Get your platform house in order. Part One.
   Oh dear, did you upgrade from Beta 2 TR? That was silly. Sorry, but it was. I'm not interested in claims from vendor sales types, it's just not sensible. However, you can fix it easily by following the steps detailed here. 
4. Get your platform house in order. Part Two.
   Letting your "power users" rename system or feature created libraries? That's not a good idea. That's asking for trouble. It's just gonna break basically, so don't be renaming that stuff.
5. Get your platform house in order. Part Three.
   It's essential to have a platform which is up to date and all that. The most common content deployment problem has been fixed since mid-May. Also consider what other configuration in your environment might impact things. The configuration of the solution space is important, for example, disk space, for the temporary files - not just CD files but those for the WSS Timer service. In addition in large environments you need to architect your CD topology to avoid timeouts and bottlenecks.
   

Now that's not all for this sordid story, but I hope you get the general idea. I may be back with some more, but then again I may not. I'm pretty tired of talking about Content Deployment.

I was actually pretty tired of talking about Site Server's Content Deployment feature back in 1998/99 - when guess what? Most problems then were due to the same stuff. Go figure.

Before slagging the product ensure your own house is in order before wasting time and money (especially if it's your customers) trying to fix something you didn't configure correctly or consider up front in your project planning. Platform Hygiene is essential, even for developers!