Monday, 29 October 2007

STSADM export, Content Deployment, Content Migration API, Features/Solutions - deployment options compared

Back in May I wrote a post titled SharePoint deployment options : Features or Content Deployment?, which discussed some thoughts on what was the "right" way to move assets from development to production (and perhaps environments in between) during the site development process in SharePoint. Having now worked on other projects and consciously used different deployment methods on each, I'm rapidly coming to the conclusion that the "right" way to do deployment varies according to circumstances. So I thought what might be useful is an analysis of the whole range of deployment options, with information which might help you decide more easily on how you will complete this crucial step of the process.

So let's run through the options and their characteristics. Note by the way, that none of the options use 'destructive synchronization', where all content is first deleted before import.

Using STSADM export/import

Description:

Uses STSADM commands to generate a file (export) which can then be transferred to the target for import. One of the simplest ways of moving content from one place to another, although unlikely to be suitable as a continuous deployment mechanism. Examples:

stsadm.exe -o export -url http://localhost -filename C:\Export.cab -includeusersecurity -versions 4 -overwrite

stsadm.exe -o import -url http://localhost/sites/newsite -filename C:\Export.cab -includeusersecurity

Good for:

  • Moving an entire site/web as a one off
  • Quick deployment tests
  • Reparenting webs (can be into a different site collection)

Considerations:

  • Content on target will be overwritten if already exists
  • Granularity down to web only
  • Object GUIDs are not preserved (so some things will need to be 'fixed up' e.g. anything that references a list by GUID - ListViewWebPart, using lists with InfoPath forms)
  • Not a backup/restore tool - although it's the option which is most like backup/restore, things like alerts, audit trail, recycle bin items, security state, workflow tasks/state are not exported
  • Not transactional

Using Content Deployment via Central Admin *

Description:

Configured via 'Content Deployment paths and jobs' in Central Admin ('/_admin/deployment.aspx'). A path defines the source/target and authentication details, specific jobs define exactly which content should be deployed and how often. Quick deploy functionality allows users with permissions to specify important content which should be deployed more regularly than existing job schedules configured by administrators (quick deploy items are deployed every 15 mins).

Good for:

  • Moving entire site collections/webs on a scheduled basis e.g. in an authoring/production or authoring/staging/production topology
  • Deploying only incremental changes, e-mail notifications of success/failures
  • Allowing site owners to have some control over content deployment via Quick Deploy
  • Automatically deploying dependencies of content selected for deployment, even if in different site (e.g. page layouts/content types/site columns/referenced images etc.)
  • Automatically transferring the deployment package to the target environment (via HTTP[S])
  • Not transactional

Considerations:

  • Content on target will be overwritten if already exists
  • Granularity down to web only
  • No differentiation between site content (e.g. pages/images) and site 'infrastructure' (e.g. master pages, page layouts)
  • Object GUIDs are preserved
  • Blank site template should be used for source and destination site collection (see http://support.microsoft.com/kb/923592)
  • Also not a backup/restore tool (see above)

Using the content migration API *

Involves writing code which uses the content migration API (known as PRIME) to export then import content - the API is easy to use.

Good for:

  • Complete flexibility over deployment options
  • Granular control over what gets deployed (down to item level)
  • Ability to preserve object GUIDs (so that list GUIDs do not need to fixed-up)
  • Ability to select options for security, versioning and user roles

Considerations:

  • Blank site template should be used for source and destination site collection (see http://support.microsoft.com/kb/923592)
  • Not transactional
  • Also not a backup/restore tool (see above)
  • Need development skills to write code

Using Features/Solutions

The focus of this blog for several articles. Involves defining XML configuration files which SharePoint uses to add artifacts in the correct way on the target. This can be significantly more complex than simply developing in SharePoint Designer but can allow for better management throughout a solution's lifecycle.

Good for:

  • Iterative development/deployment
  • Deployment of assemblies and filesystem files (none of the other methods deal with this)
  • Ability to deploy assemblies/filesystem files to all servers in a farm with Solution packages
  • Possibilities for continuous integration

Considerations:

  • Developer is responsible for evaluating and deploying dependencies (e.g. underlying content types).
  • Updates to content types, list definitions, site columns etc. deployed via a Feature must be done with the API - modifying original Feature files and then reprovisioning is not supported
  • Can be very time-consuming due to lack of assistance from current tools

* Some additional notes on using Content Deployment or content migration APIs:

- appropriate Features will automatically be activated on the target, but they must be present (i.e. installed) for content deployment to work (N.B. publishing feature should not be enabled on target for first deployment)

- using Content Deployment or content migration API with RetainObjectIdentity option should not be combined with STSADM -export/import, since the latter will allocate new IDs!

So clearly there can be a few aspects to consider in choosing how to go about deployment for your project. In many scenarios where Features/Solutions aren't the most appropriate option, I favor using the content migration API, mainly due to the flexibility which isn't provided in any of the other options. Of course it does mean writing code, but as I mentioned last time, I'll soon share the mini-app I wrote so you don't have to!

Some useful references:

20 comments:

Serge van den Oever [Macaw] said...

To make deployment easier than programming everything out with features I had my hopes on content deployment and the PRIME api... but this post does not make me happy: http://www.bluedoglimited.com/SharePointThoughts/ViewPost.aspx?ID=278

Robin Meuré said...

Really useful post mate!

Blogged you at http://glorix.blogspot.com/2007/10/some-good-read-aka-linklove.html

Chris O'Brien said...

@Serge,

Wow, Maurice's post has pretty serious implications, I hadn't seen it. Obviously he's a credible source though.

I also liked PRIME as the solution to many deployment tasks. It worked perfectly on my last project, though I'll be keeping a close eye out for any issues whenever I use it now.

I think it still has it's place in the toolbox at this stage.

Cheers,

Chris.

Anonymous said...

What's this about most methods only working with blank site templates? Does that mean that using the admin deployment options and PRIME are effectively utterly useless??

Chris O'Brien said...

No, it doesn't mean that - and I think there was an inaccuracy in the article which could make you think this:

- in fact, only the destination site collection must be created with the blank site template

You'll see I've updated the article to strike through the "source and destination" bits above to reflect this.

The reason I gave this guidance originally was because I've seen errors from PRIME which state:

Cannot import site. The exported site is based on the template XYZ but the destination site is based on the template ABC. You can import sites only into sites that are based on same template as the exported site.

The fact that the destination needs to be on the blank site template is fairly widely known, however this error made me think the source must be too, in order to match. However, I've since discovered the wording of this message is slightly inaccurate - the error will not occur if the source is created with (e.g.) the publishing template but the destination is blank.

Hope that clarifies, apologies for the original inaccuracy.

Chris.

Anonymous said...

Finally, a fix!

MOSS 2007 Content Deployment QFE Pack Now Available via MSFT CSS:

http://harbar.net/archive/2008/05/21/MOSS-2007-Content-Deployment-QFE-Pack-Now-Available-via-MSFT.aspx

Chris O'Brien said...

Yes indeed, be very interested to hear if this resolves/doesn't resolve any Content Deployment issues people are having..

Certainly the previous round of hotfixes cleared up an issue we had, so this round hopefully will deliver a further increase in robustness.

Chris.

Eunice said...

Chris,
My company tested on creating My Sites for the people in the certain group on test server. Now we are about to move those My Sites to the production server. I researched on the articles and forums to find out the best way to do it and finally decided to use stsadm import/export operations. Do you think this is the proper way to do it? If yes, should I export and import one My Site at a time?
Thank you in advance.

Chris O'Brien said...

Hi Eunice,

I've not tested moving My Sites with any of the deployment options I'm afraid, but I can see a potential issue with STSADM export. My Sites tend to use web parts which refer to lists by their GUID - this will change if you deploy with STSADM export, meaning the lists will no longer show correctly.

I can't guarantee it will work with My Sites, but you might want to take a look at my Content Deployment Wizard - this has an option to retain object IDs across environments, thus avoiding the issue.

HTH,

Chris.

MarC said...

Good post thanks Chris. It made thing clearer to me. I blogged the post at my own blog http://www.information-worker.nl/post/Stsadm-export.aspx

San said...

Hi Chris,

whats the best way to sync Staging server data with prodction server data. i wanted to configure staging server farm such that every week it gets sycn using new data from production server.

Thanks,
San

Chris O'Brien said...

@San,

Generally it sounds like Content Deployment should work for you - either the OOTB functionality or with my Content Deployment Wizard utility based on the Content Migration API if you need more granular control than the web level.

However, note that if you need bi-directional updates with Content Deployment (e.g. because you are also going from staging to production, CD is not the right choice. In this scenario, I'd suggest looking at a vendor solution which can handle conflicts such as Syntergy/AvePoint/Repliweb etc. Note these solutions are much more expensive than OOTB Content Deployment! The other route of course, is to consider your requirement.

HTH,

Chris.

Barry said...

Hi Chris

After a company re-org I copied some content to a new site collection within the same farm, in it's dedicated content database using the wizard. Now I notice that some pages are broken due to references to GUID's which are no longer correct for the lists intended. I had done the copy with v1.1 of your tool without ticking the box "retain Object ID's". This is because I thought all GUID's used in the farm ought to be unique. Or is it OK just to have a GUID as being unqiue in a site collection/content database? If so I could re-copy this time ticking the box...

Thanks
Barry

michelle said...

Hi, For users new to sharepoint.. What would you recommend as the best way for them to pick up ways of deploying webparts

Chris O'Brien said...

@Michelle,

Web parts should always be deployed with Features/Solutions. Chris Johnson has a good post which covers the process - in SharePoint 2007, most folks choose to use WSPBuilder to generate the Solution package.

HTH,

Chris.

Anonymous said...

Using the excellent instructions from your blog, I recently exported a sharepoint site using the following command:-
stsadm.exe -o export -url http://(Site Collection A) -filename C:\Export.cab -includeusersecurity -versions 4

And them imported it under the defaut Sharepoint publishing page at http://localhost using the following command:-

stsadm.exe -o import -url http://localhost/sitecollectionA -filename C:\Export.cab -includeusersecurity

Which worked fine and sure enough a new tab appeared with the imported site collection. Now here's the problem.... I went into the site and from 'Groups and People' I clicked on Members } New to add a new member. The 'Add user' screen appeared and I added the user from AD. In the give permissions section there are two options:
1. Add users to sharepoint group
2. Give users permissions directly
The problem is each group in option one states (NO ACCESS) in brackets (e.g Homesite Members (No Access)) and second option 'give users permissions directly is completely greyed out and not selectable.

r00ts

Chris O'Brien said...

@r00ts,

Sorry I've no idea why this would happen.

Chris.

Anonymous said...

I have deoployed the content from dev to prod server. Everything looks fine but my users permissions are not copied hence I am getting access denied error to the deployed site. Any adea how to reslove that?

Chris O'Brien said...

@Anonymous,

You didn't say which deployment method you used to move your content, but if it's STSADM export/import or some form of Content Deployment, you'll need to make sure you set IncludeSecurity on both the export and the import.

HTH,

Chris.

Anonymous said...

Was having issues moving a site from one farm to another with PowerShell. Came across this post and used your recommendations using STSADM and the site move worked just fine.