Johan Björnfot
Nov 23, 2010
  8406
(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
Upgrade RSS Feed Integration to Optimizely CMS 13 – v3.0.0 Beta

I’ve upgraded my  RSS Feed Integration library for Optimizely CMS to support Optimizely CMS 13. Version 3.0.0 is currently released as a beta to...

David Drouin-Prince | Feb 21, 2026 |

Multi Site NuGet v2 for Optimizely CMS 13 – Breaking Changes & Migration

The beta version 2 of DavidHome.Optimizely.MultiSite is now available on NuGet: https://www.nuget.org/packages?q=DavidHome.Optimizely.MultiSite Thi...

David Drouin-Prince | Feb 21, 2026 |

Automate Your OCP Opal Tool Development with PowerShell

Creating an OCP (Optimizely Connect Platform) Opal Tool app from scratch can be time consuming and error prone. You need to set up the project...

Sanjay Kumar | Feb 21, 2026

Using HeadlessKit to build a head for an Optimizely SaaS CMS in .NET 10

Headless has a tendency to promise freedom and deliver alignment meetings. Two codebases. Two sets of models. Two teams trying very hard not to dri...

Allan Thraen | Feb 19, 2026 |