Johan Björnfot
Nov 23, 2010
  8467
(4 votes)

Troubleshoot import/mirroring

In this post I will share some knowledge that can be useful when an import or a mirroring job fails. The first thing I usually do is to turn on logging for the relevant namespaces which can be done by adding a block like below to your EPiServerlog.config file:

  <logger name="EPiServer.Core.Transfer">
    <level value="All" />
    <appender-ref ref="fileLogAppender" />
  </logger>

  <logger name="EPiServer.Enterprise">
    <level value="All" />
    <appender-ref ref="fileLogAppender" />
  </logger>

Then you often get an indication on what has failed.  A typical error is that some page property in the package contains corrupted data. In that case the log message often contains which page that it failed on.

The next step is often to open up the package itself and look at the page in its serialized format (it is serialized to xml so it is readable). You do this by copy your .episerverdata file and rename the copy to .zip and then uncompress the file. Inside the uncompressed folder you will find a file called epix.xml. How to find the failing page inside the xml depends a bit on where it failed. The log file might contain the original PageGuid of the failing page. In that case you can search for the guid in the xml file and then get directly to that page. In cases where the original PageGuid is not present in the log file you typically searches up in the log file from the failing location and locates the original page guid for the previous succeeded page. Then you can find that page in in the xml file and then you know that the next page in the file is the failing one.

When you have located the failing page in the package you can find the value of each property and see if some value seems corrupt. A typical error is that there is some mismatch in the property types, that is e.g. that in the package property with name “a” is of type “x” but at importing site property with name “a” is of type “y”. You can detect this by comparing the elements Type and TypeName for each property in the xml file with the properties on the page type on the site.

In CMS6 we have added the possibility to add custom data to the export package. This data is found in folder “handleddata” in the uncompressed folder. Here is also where the DDS data is found. The DynamicDataSerializer also serializes data in a xml format so this data is also readable.

If a mirroring job fails the failed package will be kept at the source server. The location can be configured on the mirroring service but default it will be stored at windows temporary folder (like “C:\Windows\Temp\episerver\cms6\mirroring”).

In the upcoming CMS6 R2 release we have added some more logging that will make it simpler to identify the failure.

Nov 23, 2010

Comments

Petter Klang
Petter Klang Nov 23, 2010 10:50 AM

This is great!

Nov 23, 2010 01:36 PM

Yes, a great read :)

Please login to comment.
Latest blogs
From Prompting to Production: Optimizely Opal University Cohort and the Future of Agentic MarTech

Most organizations today are still playing with AI. They experiment with prompts, test ideas in isolated chats, and occasionally automate a task or...

Augusto Davalos | Apr 28, 2026

Six Compelling Reasons for Upgrading to CMS 13

Most software updates ask you to keep up. Optimizely CMS 13 asks something different — it asks whether your digital strategy is built for a world...

Muhammad Talha | Apr 28, 2026

Optimizely CMS 13 breaking changes: GetContentTypePropertyDisplayName

When upgrading from CMS 12 to 13, resolving property display names may not work as before. Here’s what changed.

Tomas Hensrud Gulla | Apr 27, 2026 |

Accelerate Optimizely DAM Adoption: Unlocking Business Value with Metadata Bulk Import

Accelerating Optimizely DAM Adoption How a Metadata-Driven Bulk Import Utility Unlocks Real Business Value Executive Summary For enterprises runnin...

Vaibhav | Apr 27, 2026