Windows 2012 R2 introduces a great feature for speeding up DFS Replication initial sync: Database Cloning. The details are covered very well by Ned Pyle’s excellent blog posts, especially this one. Seeing as how this is pretty new stuff, there doesn’t seem to be a lot of documentation about the possible errors, and I encountered the one in the title.

I started the process for a project of my own on a fileset consisting of about 1.8 TiB across ~5.5 million files. Unfortunately, I hit a stumbling block shortly after trying to import the database using the Import-DfsrClone cmdlet: 

Import-DfsrClone : “Could not import the database clone. Error code: 0x00001129”

When I checked the event log, I found event ID 2414 indicating

The DFS Replication service failed to import a cloned database

along with

Error: 4393 (The tag present in the reparse point buffer is invalid.)

Reparse Points and Junctions

As pointed out by Ned Pyle, mixing DFS Replication and reparse points is tricky business. I figured that something was going on in this fileset that the database didn’t like.

So I set out to find all the junctions since that is the most likely type of reparse point I would have in this collection:

dir /AL /S "B:\" 

Lucky for me it found the offender very early in what would have been a long walk of the directory structure. A junction referencing an old volume with a different drive letter (this file system was cloned).

As it happens, it was an old DfsrPrivate folder from an earlier attempt at DFSReplication at a deeper folder level. A quick delete was all I needed:

rd /S /Q "B:\Path\To\DfsrPrivate" 

I was worried at this point that I would have to export the entire database again, but luckily, that was not the case! The import worked from that point on.

I feel like had I done a normal initial sync, this folder would have been replicated (in its broken state) or skipped, rather than killing the entire sync process, and I kind of wish the database import would handle it as gracefully. Maybe in a future revision?