DFSR: Limiting the Number of Imported Replicated Folders when using DB cloning

First published on TechNet on Feb 12, 2015

Hello! Warren here to talk about a very specific scenario involving the new DB cloning feature added to DFSR in 2012 R2. The topic is limit or control which RFs you import on the import server in a DB cloning scenario.

Ned Pyle has already covered in detail the topic of DB cloning over at the Filecab blog, which you can find


. If you do not know anything about DB cloning in DFSR, you should read Ned's blog post first before reading this blog post. Otherwise, this topic will not make much sense to you. Every DFSR admin should know about DB cloning, it is a very significant feature in DFSR on 2012 R2. Trust me you will want to use it.

Why Would I Want to Limit the Number of Folders on the Import Server?

To understand why you may need to limit the number of RFs on an import server you need to understand these two facts:

  • When you export a DFSR DB the export will include every Folder (RF) on the volume.
  • The import server must have a preseeded copy of each RF on the import volume or the import will fail.

What this means is that if you want to setup or recover a DFSR server using DB cloning, the import and export servers must replicate a common set of RFs. If the export server has 5 RFs on the volume the import server must have the same 5 RFs preseeded on the import volume. This makes DB cloning unusable in some situations such as hub and spoke deployments. Luckily, there is a workaround.

What is the Workaround?

Fortunately, a workaround is available to limit the number of RFs on the import server. Before we discuss the guts of the workaround we will briefly discuss the DB cloning process. Please

Ned's blog post

for in-depth details.

1. Have at least one established RF or create a new one with one primary member

2. Export the DB from the source server with the cmdlet


. This Exports both the DB and a config.xml file

3. Preseed the RF data on the import server.

4. Copy the exported DB and config.xml file to the import server

5. Import the DB on the import server with the cmdlet


6. Add the import server to the Group

7. Configure connections

8. Configure membership in the RFs

The workaround consists of editing the config.xml file created in step 2 above to remove the RFs that you will not host on the server. Simple enough! How do I edit the config.xml file?

Edit the Config.xml file

Editing the config.xml file will be much easier using or some other XML editing tool. The steps below use 2012 for Windows Desktop, which you can use free of charge.

Whatever tool you use must not encode the file when you save the file. XMLNotepad for example, cannot be used as it enforces saving in the UTF-8 format. I recommend using Visual Studio as it “just works” for this task and is free.
  1. Make a backup copy of the config.xml file just in case you make a mistake.
  2. Download Visual Studio Express 2012 for Windows Desktop from


    and install it.
  3. Register for a free PID


  4. Open Visual Studio and enter your PID when prompted.
  5. Click


    Open File

    and select the config.xml file from the exported DB.

  6. Select



    Format Document

    . This will switch the format to a hierarchical format, which is much easier to edit.

  7. Locate the RFs you want to remove from the config.xml file. (I bet you are asking, “Exactly how do I locate the RFs I want to remove in the config.xml?”)

locate your RFs in the config.xml:

Each RF in the config.xml can be located by these tags. and . Each RF name located by the tags and . In the example below I have identified the RF “RF01” and circled the beginning and ending tags.


8. Locate the RF or RFs that you do not want to import. Next to the tag click the minus sign to collapse the node. You should now see the collapsed RF as a single line in the config.xml file. An example of a collapsed RF is shown below circled in red


  1. Highlight the collapsed RF, right click and select cut. This will remove the RF you do not want to import from the config.xml. Repeat for each RF you want to remove.
  2. Save the edited config.xml file. The Import-DfsrClone cmdlet is hardcoded to use the filename config.xml. Do not try to use another file name.

Now that you have your edited config.xml you can finish your DB clone as you normally would.



This article was originally published by Microsoft's Directory Services Team. You can find the original article here.