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

Hello! Warren here to talk about a very specific scenario involving the new DB cloning feature added to DFSR in Windows Server 2012 R2. The topic is how to 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 here. 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 Windows Server 2012 R2. Trust me you will want to use it.

Why Would I Want to Limit the Number of Replicated 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 Replicated 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 "Export-DfsrClone" . 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 "Import-DfsrClone"

6. Add the import server to the Replication 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?

How to Edit the Config.xml file

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

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 here and install it.
3. Register for a free PID here
4. Open Visual Studio and enter your PID when prompted.
5. Click File\Open File and select the config.xml file from the exported DB.
6. Select Edit\Advanced\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?")

How to locate your RFs in the config.xml:

Each RF in the config.xml can be located by these tags. <DfsrReplicatedFolder> and </DfsrReplicatedFolder> . Each RF name located by the tags <DfsrReplicatedFolderName> and </DfsrReplicatedFolderName>. 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 <DfsrReplicatedFolder> 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

9. 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.
10. 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.

Warren

Comments

• Anonymous
  February 13, 2015
  I've not been able to successfully import a cloned database when the local paths of the replicated folder aren't identical on each server. Could the same process be used to edit the RootPath and StagingPath elements to import to a server when the paths are different?