Microsoft DFS-N and DFS-R Accidental Deletion Recovery

Freelancer, IT Consultant experienced on Microsoft server, AD and Messaging projects
Edited by: Andrew Leniart
This article demonstrates DFS namespace and replication group accidental deletion recovery. DFS-N and DFS-R configuration are stored with active directory. Few precautionary measures will enable DFS-N and DFS-R recovery either from DFS native tool (dfsutil) or active directory.

Applicability: The article applies to Windows server 2008 / 2008 R2 / 2012 / 2012 R2 / 2016 STD / ENT / DataCenter editions

Issue Statement:

You have active directory domain-based DFS namespace and DFS replication groups. Two servers (DFSR1 and DFSR2) are part of DFS namespace and replication group. A domain administrator accidentally deleted DFS namespace root (\\\ShareData) and / or DFS replication group (1st-Replica) from DFS management console. 

This action deletes the replicated folder and/or namespace from active directory, namespace share and namespace root registry from all DFS-N servers. The end result is, local and remote users won't be able to access shared data through DFS links and data replication is failing.

DFS-N and DFS-R configuration are stored in an active directory domain partition. When an administrator deletes DFS namespace or replication group from DFS console, it actually gets deleted from active directory. Since deletion gets replicated with active directory, DFS namespace and replicated group also gets deleted from all domain controllers.

There are a couple of ways to recover deleted DFS-N and DFS-R. Will demonstrate recovery options with an example:

DFS Name Space Accidental Deletion Recovery:

In order to recover deleted DFS namespace we need to backup below on regular basis:

  1. DFS namespace export file generated through Dfsutil command as shown below



  1. Active directory system state backup 
  2. DFS namespace root registry key export ( HKLM\Software\Microsoft\DFS ) on each DFS namespace server
  3. DFS namespace server shares registry key Export (HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Shares)

Option 1: (Restore from DFS namespace export through Dfsutil)

You can restore DFS namespace if you have DFS namespace folders exported with Dfsutil command before deletion of the namespace. This is the simplest and quickest method. The command is given below:

dfsutil /root:\\\ShareData /export:D:\Namespace.txt

The exported output should look like below:

Steps are below:

Note - You need to be logged on to DFS namespace server as domain admins since a new namespace will be created in AD domain partition and it needs admin rights on AD

Ensure that DFS namespace is deleted from all domain controllers from given active directory domain

Ensure on all DFS namespace servers, namespace root (ShareData) registry does not exist under [HKLM\SOFTWARE\Microsoft\DFS\Roots\domainV2]

Ensure that DFS namespace Share (ShareData) is not left on any DFS namespace servers and its entry is not present in the server Shares registry [HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Shares]

Now Create new DFS namespace with the same name as deleted one (\\\ShareData) from DFS management console on DFSR1 server and add DFSR2 as namespace server as shown below. Since we are creating a new namespace, we need to add additional namespace servers manually 

Force AD replication so that all DCs can pickup DFS config and run "dfsrdiag pollad" on both DFSR servers from an elevated prompt to poll active directory for config. We still need to restore namespace folders and their targets.

Now run dfsutil /root:\\\ShareData /import:"D:\namespace.txt" /set

DFS namespace folders with targets now got restored with above command.

We can see that all DFS namespace folders along with targets restored. Force AD replication followed by run "dfsrdiag pollad" on both DFSR servers from an elevated command prompt and ensure you can access namespace from DFS servers and client machines as appropriate

Option 2: (Restore DFSN from system state backup)


Recover DFS namespace by restoring active directory system state backup. This step is required only if you don't have a DFS namespace exported dump before deletion of the namespace with dfsutil and deleted DFS namespace has hundreds of namespace folders along with targets.

Restore AD system state backup non-authoritatively (for this demonstration I have used Windows server backup (WSB) tool for backup and restore, if you have any 3rd party tool, you need to use that and process recommended by them) - Since we are using WSB, after the restoration operation do not reboot domain controller, else the restored DFS namespace will be deleted during replication again by other alive domain controllers

Identify AD system state backup of any healthy working R/W domain controller (may be PDC) which is taken before deletion of DFS namespace

Reboot that domain controller in Directory service restore mode (DSRM)

Start the Windows Server backup utility, locate and identify the last successful system state backup before DFS namespace deletion and click the Recover wizard

Select the location where the backup is stored, either locally or on a network share

Select backup from available backup dates for restoration as decided earlier and click Next

Select System State as "recovery type" and click Next

Select Original location as restore location and click Next

Note - Do not select the "Perform an authoritative restore of active directory files" checkbox

Click Recover (You can see that System State as recovery item to be restored at original location and it is a Non-authoritative recovery)

Recovery operation completed. Do not reboot system until we restore DFS namespace configuration authoritatively

Open a command prompt with "Run as administrator" and run the commands below in sequence to authoritatively restore DFS namespace configuration.


activate instance ntds

auth restore

restore subtree "CN=Dfs-Configuration,CN=System,DC=testlab,DC=com"

This subtree contains DFS namespace data which we need to recover, you can restore entire subtree OR you may restore specific namespace (For Ex: CN=ShareData,CN=Dfs-Configuration,CN=System,DC=testlab,DC=com )


Click Yes

Note - Above command will increase USN of DFS-Configuration subtree by 100000 numbers so that after a reboot this subtree will get replicated to all other domain controllers as a directory update. If you miss this step after system state non-authoritative restore, the restored DFS namespace will get deleted after DC reboot as other DCs have namespace deletion record in their deleted items container with higher USN than the restored object and hence deletion will get replicated to this DC and again namespace will get deleted

The operation is successful. We can locate above text file for details

Details of DFS namespace restoration. This restoration will contain the entire Root namespace along with DFS namespace subfolders and their folder targets with referral settings. Now we can reboot the domain controller

Upon reboot, press Enter when prompted. This prompt tells us that System State recovery operation is successful

We can see that DFS namespace (Sharedata) along with folders including targets is recovered under CN=Dfs-Configuration,CN=System,DC=testlab,DC=com, force AD replication across all DCs by running repadmin /syncall /AdeP from an elevated command prompt

Now on each DFS namespace server import root namespace registry key from earlier registry key export, the file should look like above.

ShareData is a domain-based DFS root namespace share

Now on each DFS name space server, import Shares registry from earlier key export. The actual shares registry output contains all available shares on the server with their respective hex values, for DFS namespace restoration purpose we should remove all other share entries from the file and keep only DFS namespace share (ShareData in our case) entry

Note - Before importing shares registry, ensure that Root name Space folder (C:\DFSRoot\ShareData in our case, it can be different if you changed it during initial deployment) are available on the system. If it's not there, you need to recreate those folders at their original location when you created namespace the 1st time

Once both registries are imported on each DFS namespace server, restart Server service on each server to make registry changes effective. This will restart DFS namespace service, as well as this service, is dependant on server service. 

Now on anyone DFS namespace server, open DFS management console, right-click namespaces and click Add Namespaces to Display

Now we can locate and select \\\ShareData as DFS namespace and click OK

namespace along with namespace folders, namespace servers along with folder targets are restored. Check if you and users can access restored namespace folders and folder targets as appropriate.


Now one can argue that if they have a DFS namespace server System state backup, they can simply restore the entire DFS namespace configuration from the system state backup instead of doing all above exercise. Since DFS namespace configuration is deleted from active directory, restoring system state back up on DFS server will not restore namespace configuration in active directory. 

1st you need to recover DFS namespace config with active directory system state restore and then you may restore DFS server from its system state backup which will restore DFS namespace root and shares registry. But this process needs extra time, downtime for restoration and unnecessary restoration of other server components involved in system state which I feel absolutely not required.

It's a different story when you have DFS namespace installed on a domain controller. In that case, simply restoring the domain controller from a system state backup followed by an authoritative restore of DFS namespace will do the trick. System state backup will take care of everything and you don't need the extra step on this server. However, the other namespace server needs to be initialized with DFS root namespace registry and shares registry import.

DFS Replicated folder Accidental Deletion Recovery:

In order to recover a deleted DFS-R replicated folder, you can either create new replication group with an existing replicated folder or you can restore one from AD system state backup

Option 1: (Recreate DFS replication group and add replicated folder in group)

The best option could be, create new replication group from DFS management console for same servers and same data. Note that when you delete DFS-R replication group, it will delete members along with replicated folder logical entry in DFSR database on the local server and from active directory. However, process neither deletes actual physical data folder from server nor DFSR database located under system volume information from the local drive. 

Hence its easy to simply create new DFSR replication group pointing to the same data and it will use the existing database. The benefit is, replicated folder initialisation on a primary member (event ID 4112) and initial sync process on a secondary member (event ID 4104) will happen very quickly and replication will start back and forth. Steps are given below.

Ensure that replication group entry is deleted from all domain controllers, no stale data is left on any domain controller

Ensure that DFSR database folder under system volume information is not deleted, in fact, nobody can delete that folder unless he takes system volume information ownership

Now delete DfsrPrivate shortcut from the actual data folder

Finally, configure the new replication group by defining original members along with existing data folder on members. DFSR will force us to select one member server as the primary member and other members as secondary. 

Since data to be replicated and previously synchronised DFSR database is already present on both members, it eliminates the need for data staging and hashing and thus saves the major time and complete designation of the primary member and initial sync on other members very quickly as shown below. 


Once Replicated folder initialisation on primary and Initial sync on other member completed, both servers can replicate data back and forth.

Option 2: (Restore DFSR from AD system state backup)

If you don't want to create new replication group and undergo subsequent initial sync process, you can restore AD system backup and recover deleted DFS replication group from there. 

Steps to restore active directory non authoritatively from system state backup remains the same as demonstrated earlier. 

After that do not reboot the DC, we need to use ntdsutil utility to authoritatively restore CN=DFSR-GlobalSettings,CN=System,DC=testlab,DC=com OR actual deleted replicated folder (CN=1st-Replica,CN=DFSR-GlobalSettings,CN=System,DC=testlab,DC=com)

Run below commands from an elevated command prompt:


activate instance ntds

auth rest

restore subtree CN=1st-Replica,CN=DFSR-GlobalSettings,CN=System,DC=testlab,DC=com

Select Yes to perform an authoritative restore of the replicated folder

Note - Above command will increase USN of restored AD object by 100000 numbers so that after reboot object will get replicated to all other domain controllers as a directory update. If you miss this step after system state non-authoritative restore, restored DFS replicated folder will get deleted after DC reboot as other DCs have deletion record in their deleted items container with higher USN than restored object and hence deletion will get replicated to this DC and again object will get deleted

The authoritative restore is successful. We can open above text (txt) file to verify restored object details

Now reboot server and login with domain admins

Press Enter to continue, system recovery completed successfully

We can see that the DFS replication group 1st-Replica with userdata as the replicated folder is restored in ADUC. Force AD replication on DC server from elevated command prompt (repadmin /syncall /AdePq) and poll changes on DFSR servers by running "dfsrdiag  pollad" command from an elevated cmd.

Maybe you need to restart DFS-R servers one by one. DFS-R servers should be able to poll active directory successfully as shown above

Now open DFS management console and add replicated group (1st-Replica) to display and check all details, maybe you get an error to see folder local path and won't be able to see folder details

In the above condition, you cannot disable and enable replicated folder to initialize with or even folders won't replicate with each other as shown below

If you try to disable and enable replicated folder from for any member in DFSR console above, it will throw an error

If you tried to replicate from connections tab in DFSR console, again it will throw an error

In the above case, the only option left:

From DFSR console screenshot above, Delete one member, force AD replication and poll updated configuration on DFSR servers by running "dfsrdiag pollad

Add deleted member again by Add member wizard, force AD replication and poll updated configuration on DFSR servers by running "dfsrdiag pollad

Do the same step for the other members as well.

Now you should see replicated folder with status normal for both DFSR servers

On the connection tab, right click connection object and click Replicate Now

Replication is successful. Check other Connection objects also in the same way. 

Data can be replicated back and forth.

Note - When you delete a member from DFSR replicated folder, the deleted member entry remain in DFSR database of deleted servers for 60 days in tombstone. Since you are adding deleted member again ASAP, DFSR database on added member retrieve member object from tombstone and consider himself authoritative for replicated data and start replicating back and forth. 

There is no initial sync here. hence if you have deleted / moved any data from the server after deletion from DFSR, data deletion will get replicated to the other member after you add the server again as a replicated member. Hence do not delete any data from removed DFSR member if you want to add it again in DFSR as a replicated member until 60 days.

DFSR Formatted Drive Recovery:

If you accidentally formatted DFSR replicated folder drive on one server, you can restore DFSR replicated folder in two way.

Note that DFSR replicated folder configuration remain alive in active directory and DFSR data remains available on another member.

Now, if data size to be replicated back is large:

Disable the replicated folder for the affected server from DFSR console

Use DFSR data preseeding followed by database cloning to copy data and DFSR database on the affected server in advance which will cut downtime required for data staging and hash generation

Now enable replicated folder, this action will trigger non-authoritative sync (Initial sync) on the affected member (event ID 4102) and once completed it will log event Id 4104 and start replicating folder back and forth.

Reference Article: DFS Replication Initial Sync in Windows Server 2012 R2: Attack of the Clones

If the data size is small:  You can simply create an empty root folder with the same name as previous on a formatted drive and run "dfsrdiag pollad" from elevated command prompt on both DFSR servers to poll active directory. This will trigger DFSR event ID 4102 on the formatted member and start initial sync process. Data will get replicated from another healthy server and once initial sync is completed, you will notice DFSR event ID 4104 on the formatted member. Now both servers will replicate data back and forth. 

Reference Article:  Recovery process of a DFS Namespace in Windows 2003 and 2008 Server

I hope this article will help you in recovering DFS accidental deletions.

If you liked this article, please click the Thumbs-up icon below

Freelancer, IT Consultant experienced on Microsoft server, AD and Messaging projects

Comments (3)

Albert WidjajaIT Professional

Does DFS can also support VSS for Previous Version that can be used by the user as self service restoration ?
Distinguished Expert 2023


If user does save previous version of file from VSS, the restored previous version gets replicated to DFSR partner

If VSS is enabled on both replicated partners, the last restored file will win and replicated to all partners

Note that since VSS copy is server specific it will not get replicated across DFSR partners
The VSS versions of same file on both servers can be different based on time difference of VSS snapshot is triggered
If VSS snapshot is triggered on all replicated members at same time, you would get previous version data similar on all members, note that this is workaround as VSS copy is separate for every member

I hope this is clear
Albert WidjajaIT Professional

Many thanks, Mahesh for the clarification, it's all clear from now on.

Have a question about something in this article? You can receive help directly from the article author. Sign up for a free trial to get started.