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?