SharePoint Config

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.

Deployment

• 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);
export.Run();

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.

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);
import.Run();

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.