Friday, 14 December 2007

When to use the SharePoint Content Deployment Wizard

Following my introduction to the tool last time, today I want to try to help position the tool for people who aren't sure if it could be useful to them or for what scenarios - if you only take one thing away from my postings on the Content Deployment Wizard it should be this.

I see the 'value-add' of the Content Deployment Wizard over existing deployment methods such as STSADM export/content deployment in Central Administration to be:

  • ability to "cherry-pick" content to deploy using a treeview - this is from entire site collection down to individual list item or file. (This is the big one since the standard SharePoint tools do not supply a method to do this)
  • ability to control whether object GUIDs are retained - this is required for scenarios where the destination should be a mirror-image of the source, such as staging/production environments for the same site
  • ability to move certain objects (limited to webs and lists in the initial release) to a new location on the import target, known as 'reparenting'

I would suggest the tool could well have a place in your SharePoint toolbox, but it's likely to be something you use every now and then, rather than all the time. The two main scenarios where I use the tool are:

  • at the end of the development phase when I need to move a site from development to staging/production. Here, the tool allows me to be sure that all relationships/linkages between objects will be preserved (so no problems with ListViewWebParts/DataViewWebParts/InfoPath forms for example)
  • any odd occasions where I have a need to move a particular document library/list, or a particular set of files (e.g. master page, page layouts, CSS etc.). This assumes by the way, that the files were not deployed with a feature - I wouldn't recommend mixing the deployment methods like that.

N.B. It should also be possible to use the tool for ongoing updates to specific files/list items through different environments in a development/test/staging/production situation. An example of this is deployment of just master pages, page layouts and CSS files on a WCM site (meaning all other content authored by the client [e.g. in the 'Pages' library] does not get overwritten on the target) but I haven't had the opportunity to try this on a real project yet.

Some areas where the tool cannot be used (i.e. the tool does not yet support this usage) are:

  • exporting only changes since a certain timestamp (change token) from a site
  • importing individual list items/files to a new location on the target (reparenting)

On the last point, the 'new location' would be a document library or list, since these items have to be in such a container - they cannot exist at the root of a web. Currently the tool supports reparenting webs and lists, but not individual list items/files. What is currently possible with individual list items/files, is moving selected items from a source to a target where the structure is the same (e.g. move Doc2 and Doc5 from "Team documents" on the source to "Team Documents" on the target). Usefully, whenever a file is exported/imported using the tool, the associated list item is also deployed, meaning metadata updates to column values are deployable.

Hopefully that might help you understand where the Wizard fits in. If you're thinking the Wizard could be useful to you from time to time, stay tuned for my next post which will have more detailed 'usage' information. 

12 comments:

Meron Fridman said...

Rona Lustig's "Content Migration API Tool" allow you to export only changes (token \ time stamp) as well as full Export. The ability is in the API and she expose it via here tool.

you can find it here: http://blogs.msdn.com/ronalus/archive/2007/08/10/content-migration-api-in-action.aspx (look at the attachment in the bottom of page)

But the real problem is to export site columns (lookups), content types and selective content as you could via MCMS 2002 site manager (tree view).

Maybe the solution should be create some tool that will read the content from the CMP package and expose it as a tree view. than allow you to drop the not relevant content and package it back. see also Rona's "content migration package explorer"

http://blogs.msdn.com/ronalus/archive/2007/10/02/content-migration-package-explorer.aspx


Meron Fridman
http://blogs.microsoft.co.il/blogs/meronf/

Chris O'Brien said...

Meron,

Thanks for the info and links, very interesting.

You say:
-snip-
But the real problem is to export site columns (lookups), content types and selective content as you could via MCMS 2002 site manager (tree view).
-end snip-

The Content Deployment Wizard does allow 'selective content' deployment via a treeview. However, it does not allow deployment of underlying infrastructure such as site columns and content types only. That's to say they are captured as dependencies of content, but it's not possible to deploy them with the actual content.

Typically though, we need to deploy the site columns/content types etc. to support the content, so this isn't such a problem. For occasions where we really do want the site columns/content types but not the actual content, my view would be that the artifacts should be developed as Features to support this.

Cheers,

Chris.

Anonymous said...

Hi there,
i have a big problem. On a customer project, which uses content deployment, all site columns and site content types are missing in the target web application after the deployment. the deployment itself works without errors and copies all the content (documents, list, structure etc.) fine, but the site columns and site content types are missing. The strange thing is, in our environment (which is normally the same) it works.. Can anyone help me ? its frustrating :(

Thx
Thomas

Chris O'Brien said...

Thomas,

I've not seen this behaviour before - if the API successfully moves the content it should also transfer the underlying content types and columns etc. Are you using Content Deployment from Central Administration or using the Wizard? If the latter, is anything reported in the log file for the operation?

Thanks,

Chris.

Wanderson Lima said...

Hi Chris,

Congratulations by the tool that you developed. It's very useable!!

But, as you say, i need exporting only changes since a certain timestamp (change token) from a site.
I'm trying to create a SPChangeToken as below:


...

SPChangeToken token = new SPChangeToken (SPChangeCollection.CollectionScope.Site,
siteCollectionId, startDate);
exportSettings.ExportChangeToken = token.toString();

...

But it packe all changes not only the changes after startDate.

You have some idea about it?

Thanks

Chris O'Brien said...

Wanderson,

Just wondering, did you remember to set the SPExportSettings.ExportMethod property to SPExportMethodType.ExportChanges? This needs to be done in addition to passing the change token to specify an incremental export.

If you've not already seen it, Stefan has some good samples on incremental export at http://blogs.technet.com/stefan_gossner/archive/2007/08/30/deep-dive-into-the-sharepoint-content-deployment-and-migration-api-part-2.aspx.

HTH,

Chris.

Edward said...

Hi, just taking over a development task which involves the Content deployment wizard and Ive been told there is problems using it with Infopath forms (I still need to validate for myself).

What Ive been told is that as the deployment job doesnt take features or solutions then I will get errors involving the infopath form templates which are held and controlled via the Central Admin site as wsp packages (and activated as features within the actual site). Ive googled and seen a couple of instances involving FT01-guid type errors (the infopath feature naming starndard) but no guidance on how to move the content and form templates, which the cms editor can create themselves.

Do you have and guidance on how to keep the content and infopath form feature/solutions in step without resorting to manual insprection of the template folder and manually reinstalling on the destination service before the content deployment run ?
Regards
Ed

Chris O'Brien said...

@Edward,

Absolutely - Features are effectively a dependency of content being deployed, and must be in place before the import to the target environment. There is no clever solution to managing this dependency I'm afraid - if you're moving things wholesale between environments, you just have to make sure you deploy the Feature(s) first so the form templates are deployed.

I think of it as a clear distinction between the form template (infrastructure, or schema) and the form instances (content) - maybe that helps slightly?

Thanks,

Chris.

5pinx said...

Hi Chris,

Been using the tool but can't find out out to export a top-level site from a sitecollection(eg from an upgraded Content DB- http://portal/sites/Infromation Tech) and importing it in as a subsite. Whenever I do this I receive the error:
Cannot import site. The exported site is based on the template STS#0 but the destination site is based on the template SPS#0. You can import sites only into sites that are based on same template as the exported site( i expect it is trying to overwrite on the site collection instead of adding it as a subsite)
If I export a subsite(/sites/Information Tech/IT Internal) from within the upraded sitecollection i can successfully migrate the subsite to a site below the SPS site(intranet/IT Internal.
Essentially looking at moving from the old Sharepoint Portal setup of having a seperate site collection for each site and merging it under the new MOSS 2007 server as a subsite.
The option which I thought would work was the Export Root Web Only, but whenever I import I get the same error.

Am I doing something wrong?

Thanks
Michael.

Chris O'Brien said...

@5pinx,

I agree with your conclusion that it seems it's trying to overwrite something rather than add as a child. I think the options you need are:

- Ensure 'root web only' is selected on export
- Ensure an 'import web URL' is selected on import - this should be the URL of the parent web
- Ensure 'Retain object IDs and locations' is NOT checked

The site should then import successfully, but let me know if you're still having trouble.

Thanks,

Chris.

casy said...

Chris,
Have used your tool quite a bit, its very good, was delighted to see SPD workflows copied.
Could you say if this is possible ;-
Move a form lib with an admin approved infopath browser form + promoted columns to anoher site collection same heirarchy?
It copies but the browser link points to the original site.
When I replace the contenttype on the second site with the correct admin aproved type for that site I get some repeated columns in the Lib,
Hope you can understand and be able to say yay or nay !
Kerry

Chris O'Brien said...

@casy,

Afraid to say, I'm not sure! Infopath does do a couple of specific things, and under some circumstances does store references to things like URLs in .xsn files. So it might work with some fix-up, but on the other hand I can't help wondering if applying the form to the 2nd library some other way (e.g. feature activation) might be better.

Sorry I can't be more helpful.

Chris.