Try our conversational search powered by Generative AI!

Johan Björnfot
Nov 23, 2010
  7539
(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
Optimizely and the never-ending story of the missing globe!

I've worked with Optimizely CMS for 14 years, and there are two things I'm obsessed with: Link validation and the globe that keeps disappearing on...

Tomas Hensrud Gulla | Apr 18, 2024 | Syndicated blog

Visitor Groups Usage Report For Optimizely CMS 12

This add-on offers detailed information on how visitor groups are used and how effective they are within Optimizely CMS. Editors can monitor and...

Adnan Zameer | Apr 18, 2024 | Syndicated blog

Azure AI Language – Abstractive Summarisation in Optimizely CMS

In this article, I show how the abstraction summarisation feature provided by the Azure AI Language platform, can be used within Optimizely CMS to...

Anil Patel | Apr 18, 2024 | Syndicated blog

Fix your Search & Navigation (Find) indexing job, please

Once upon a time, a colleague asked me to look into a customer database with weird spikes in database log usage. (You might start to wonder why I a...

Quan Mai | Apr 17, 2024 | Syndicated blog