Monday 9 March 2009

Update on next version of Content Deployment Wizard

Generally I only ever talk about SharePoint tools I'm working on once they're 100% complete and ready for use, but recently I had a conversation with someone at a user group which made me think about a policy change. Regular readers will know the main tool I'm associated with is the SharePoint Content Deployment Wizard which has become fairly popular (over 7000 downloads) - occasionally I've mentioned that one goal was to implement a command-line version, since this opens up all sorts of deployment possibilities. However I've not talked about this for a while, and just recently I've spoken to a couple of people who assumed I dropped this/didn't have the time to look at it, so here I am to tell you this is not the case!

For anybody that cares, the good news is I've actually been working on this since December interspersed with blogging, and am nearly done. The yicky refactoring work is complete, and I got chance to write the custom STSADM command on the front of it on the flight to the MVP summit last week. I need to do more testing first, but I'm hoping to release a beta to Codeplex over the next couple of weeks - if you're interested in the idea of scripted deployment of specific sites/webs/lists/list items between sites or farms (remember MOSS Content Deployment only does sites/webs and requires HTTP(S) connectivity), I'm hoping some friendly beta testers will help me screw the last bits down. The key aspects of this release are:

  • Command-line support
  • Support for saving of import/export settings to a file (in the Windows Forms app) for later re-use

Shortly after this release, I'm hoping to add support for incremental deployments (so only the content which has actually changed in the sites/webs/lists/you select will be deployed), but that's not going to make into this next cut unfortunately.

Keep tuned for further updates :-)

Other stuff

Whilst I'm at it, other things in the pipeline from me include:

Needless to say, there are plenty of other blog articles on my 'ideas list' too.

Sidenote - reflecting on 2 years of SharePoint blogging

Bizarrely, I'm into my 3rd year of SharePoint blogging now. I've no idea how this happened. Having done some interesting work with SharePoint's Feature framework, the initial idea was to write 4 or 5 articles I had material for - as a record for myself more than anything - and be done with it. Since then, although I do write the odd 'easy' post (like this one), generally my articles seem to take a long time to get completed, but I know they could be better. Occasionally I get reminded of this! So there's a long way to go for me to become a better blogger, but I'm fully hoping to still be at it in another 2 years time - and I'll have plenty more to say when the next version of SharePoint approaches :-)


Anonymous said...

concentrate on quality not quantity mate. there's no rule that says u gotta post for the sake of it. u be doing just fine.


Chris O'Brien said...

Yep that's generally the thinking I've had too..


Rod said...

Hi Chris

I hope you are well. I spoke to you at the sharepoint user group meeting. You mentioned to me about a third party tool you used to update content types. I tried to find it googling but I think I got the wrong name.Could you kindly drop me an email with the name of the tool please. I would like to have a look at



Chris O'Brien said...

Hi Rod,

I was probably talking about Kivati Studio, but note there are several approaches to this. You should also check out Gary Lapointe's STSADM command for updating content types.



Rod said...

Hi Chris

thanks for getting back to me



Kyle said...


I've got a spot in our build script just waiting for the command line version of the deployment wizard. Would be happy to help beta test when you are ready.


Chris O'Brien said...


Excellent, just what I'm looking for :-) Just need a couple more big sessions at the keyboard and I should be ready.

Thanks in advance,


P.S. Kyle - would you expect the STSADM command to automatically copy the exported file to a specified target location, or would you expect to deal with this separately XCOPY commands or similar?

Robin Meuré said...

Mate.. don't worry about the quality and quantity of your posts.
The fact that you make a contribution to the community is the thing that counts (you didn't get the MVP award for nothing ;)

Just keep up the good work and see you in London in a couple of weeks!


Chris O'Brien said...

Yep, looking forward to it mate - I'm sure you and Mr McPherson owe me a beer from something! I'll be more than happy to claim it ;-)


Unknown said...

I've been working with the OOTB Content Deployment and WCM functionality provided with MOSS and have run across several snags that have just about run my patience thin. We've had downtime twice this month in order to kill the PROD Site Collection, create a new truly blank (No Template) Site, and redeploy. I don't want to see the Dev -> Authoring -> Production model get scrapped because I believe its a very worthwhile configuration for many reasons as well as the fact that I've been developing some dashboard functionality of Content related activity (based on XML reports) in addition to and in conjunction with an "Administration Portal" that would allow certain functions to be performed without necessarily being a super user [read HelpDesk] that I hope to be able to push source out soon for. I have a question... Do you have any pointers as far as where the Changelog that the incremental deployment functionality uses? It is conceivable that I could scrape the information via the myriad of API/ASMX calls available, but I was curious to know if there is anything filesystem based (dear God, please let there be XML :) ) or if it was all wrapped up in the DB? If it is all in the DB, is it scattered across a bunch of tables or is it relatively normalized?

Thanks for all your hard work!

Chris O'Brien said...


The change log is a database table, so nothing on the filesystem I'm afraid. You can work with it using either the SPChangeQuery/SPChange classes or the GetListItemChangesSinceToken() method of the Lists web service.

In general though, building custom deployment tools around this shouldn't be necessary for successful use of content deployment. What problems did you run into?