SharePoint Config

Ari Bakker's thoughts on customising and configuring SharePoint

MOSS content deployment tips and tricks

with 5 comments

I’ve been involved in several public website projects that have involved using MOSS content deployment. While content deployment is easy to set up for simple scenarios, there are a number of things that can trip you up if you have a significantly customised environment. In this post I’ll give details and solutions to on some of the common problems, and general tips on how to make this process run as smoothly as possible.

This post doesn’t contain a step by step guide for setting up content deployment, for that see the article “Content Deployment Step by Step Tutorial” on Jackie Bodine’s blog, or for a introduction see the articles “Plan content deployment” on TechNet or “Content Deployment” on the SharePoint team blog.

Pre-deployment tasks

It is important to understand the process before attempting to run the content deployment process. In particular you should ensure that:

  • The destination SharePoint site is created using the blank site template (not a publishing site). All content and features (including the publishing features) will be copied and activated as per the source site so you need to deploy to a completely blank site collection.
  • Any custom features/solutions need to be installed on the destination server. Solution packages are not copied as part of the content deployment, so ensure these are available on the destination server and deployed to the relevant web application before starting content deployment.
  • Ensure all items are published. Unpublished items are not visible to anonymous users and if dependant resources are not available this can mean pages do not display. An easy way to ensure that you publish everything is to use the ‘All draft documents’ report. Select Site Actions > View Reports > All draft documents to see a list of items not yet published.


  • Test the full deployment in a test environment – If you have made significant customisations to the publishing site there is a high chance that problems will arise the first time you run a content deployment job. Don’t leave this til the production deployment, set this up when you do your first release to the test environment so you can iron out bugs early. If you don’t have two separate servers in your test environment at least create two separate web applications and deploy between them, this still provides a good test of the export/import process.
  • Enable detailed logging to identify what caused failed exports/imports – As any developer will attest, identifying where an error occurs is crucial to solving the problem. Using the following code to run as export will give you details on the item that caused deployment to fail (originally from Stefan Gobner’s excellent article) .

SPExportSettings settings = new SPExportSettings();
settings.SiteUrl = “http://source“;
settings.ExportMethod = SPExportMethodType.ExportAll;
settings.FileLocation = @”c:\export”;
settings.FileCompression = false;
settings.CommandLineVerbose = true;

SPExport export = new SPExport(settings);

The key here is the CommandLineVerbose property of the SPExportSettings object. When running this from the command line you will see detailed output containing each item as it is processed for export, allowing you to identify the item that the export failed on.

The screenshot below shows an example of what this looks like running as a console app if an error occurs.

Detailed import logging

A similar process can be used for import with the following code.

SPImportSettings importSettings = new SPImportSettings();
importSettings.SiteUrl = “http://destination“;
importSettings.FileLocation = @”c:\export”;
importSettings.FileCompression = false;
importSettings.RetainObjectIdentity = true;
importSettings.CommandLineVerbose = true;
SPImport import = new SPImport(importSettings);

Post deployment

Almost there! But there are a few things that still might catch you out

  • Master pages settings are not deployed correctly – If you have changed the master page for the site this might not get set in the destination site. This may cause errors with the default page for the site if your page layouts contain additional content placeholders. According to Andrew Connell there is now a hotfix that resolves this issue but at the time of writing this is not publicly available. To fix the problem without the hotfix, navigate to http:///_layouts/settings.aspx and select ‘Master Page’ to change the master page to the one you are using.
  • Turn on error messages for the destination site – If you are still getting errors and haven’t turned on detailed error message set the stacktrace attribute of the SharePoint/SafeMode element to “true” and the mode attribute of the system.web/customErrors to “off” in the web .config.

I’ve come across a number of different errors with content deployment so I recommend testing this as early as possible. Most of the problems are easily fixed but some may require rework, so identifying these early helps reduce the impact on development effort (and reduce stress at deployment time). And while the content deployment process isn’t as stable as one might like, since it has been around for a while most of the bugs have either been fixed or are documented and provide workarounds.

Post to Twitter Post to Delicious Post to Digg Post to Reddit Post to StumbleUpon

Written by Ari Bakker

June 3rd, 2008 at 11:40 am

5 Responses to 'MOSS content deployment tips and tricks'

Subscribe to comments with RSS or TrackBack to 'MOSS content deployment tips and tricks'.

  1. Hi Paul, Is your deployment job set to 'Deploy only new, changed, or deleted content'? This setting should ensure content is only sent to the target when it changes on the source.

    Ari Bakker

    25 Oct 08 at 10:46 pm

  2. We've had content deployment for MOSS working fine for around 6 months, but recently noticed that the target (production) content database is many times larger than the source (authoring) content database. Looks like issue relates to versioning. Example: Library in source has a document that hasn't been modified in six months. Corresponding library in target has 32 versions of the same document, each with the original "Modified" date from six months ago. Looks like content deployment is creating a new version of the document on each Full Deployment job (weekly). Both libraries are set to allow versions.
    Should we turn versioning off on target side? We need versioning on source side. Is there a configuraiton setting on the deployment job that we should consider?
    Appreciate your help!


    24 Oct 08 at 8:18 pm

  3. @Jason it looks like the ListDisplaySettingFeature feature isn't available on the destination farm. I'd check the features folder (Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\FEATURES) on the destination farm to make sure the ListDisplaySettingFeature is there and installed on the farm. This looks like a custom feature, so you might want to check that any solutions installed on the source farm are also installed on the destination farm (as this might be part of a custom solution i.e. wsp file). You can do this by navigating to Central Administration > Operations > Solution management. Hope that helps.

    Ari Bakker

    12 Oct 08 at 8:14 am

  4. I keep get this error:

    'Microsoft.SharePoint.SPException' : 'Could not find Feature ListDisplaySettingFeature.'

    Any suggestions?

    I have looked at the farm and site features in both site and they are the same.


    8 Oct 08 at 8:16 pm

  5. Two hotfixes that address numerous content deployment issues are now available from Microsoft. See the links below or Joel Oleson’s overview for more details.



    Ari Bakker

    9 Jul 08 at 10:53 pm

Leave a Reply