Migrating DFS Namespace from Windows 2000 Server mode to Windows Server 2008 mode



I recently helped a customer with this tricky little exercise.

The idea was to do the upgrade during office hours with as little downtime as possible and to run it remotely from one server.


It’s following the basic guide here: https://technet.microsoft.com/en-us/library/cc753875.aspx


But this formal guide wasn’t very “real world”. It forgets that there are clients out there with cached referrals who take a long time to realise that the namespace links have changed.


In my example, I use these names which you’ll need to change:

· The existing 2003 DFS server is FILE1. All the commands below are run on this server in C:\temp.

· The first new 2012 R2 DFS server is FILE2

· The domain is child.corp.contoso.com

· The DFS Namespace in the domain is called “Testing”, so the path is \\child.corp.contoso.com\Testing

· There are 3 target servers where all DFS links point to: TARGET1 , TARGET2 , TARGET3


First, start by setting the existing 2003 DFS servers to issue FQDNs in their DFS referrals. This was a requirement of the customer as they wanted other forests to access this namespace, and wanted to be as efficient as possible.

Note this requires restarting DFS-N:


dfsutil server registry DfsDnsConfig set \\FILE1

sc \\FILE1 stop DFS

ping -n 5 > NUL

sc \\FILE1 start DFS

Run this for each of the 3 existing DFS servers.


Next we copy the DFS root folder and share (including all security) to the new DFS servers:


robocopy C:\DFSRoots\ \\FILE2\c$\DFSRoots\ Testing /COPYALL /E /XJ

reg copy \\FILE1\HKLM\System\CurrentControlSet\Services\LanManServer\Shares \\FILE2\HKLM\System\CurrentControlSet\Services\LanManServer\Shares /s /f


You will run this command for all new DFS-N servers


We then set the new DFS servers to use FQDNs in their referrals:


dfsutil server registry DfsDnsConfig set \\FILE2


We need to restart the Server service so it can start sharing the shares we copied just before. This will also restart the DFS-N service for us, so the FQDN change will work:


echo net stop LanManServer /yes > \\file2\c$\Temp\restartsvc.bat

echo net start LanManServer >> \\file2\c$\Temp\restartsvc.bat

echo net start DFS >> \\FILE2\c$\Temp\restartsvc.bat

psexec \\FILE2 -d -accepteula c:\temp\restartsvc.bat

Echo Waiting for 30 seconds for the Server service on FILE2 to restart

ping -n 30 > NUL


PSExec is needed to run the bat file because once the server service is stopped, it can’t be started remotely because it’s needed to accept the remote commands.


Next, we need to export the existing DFS-N configuration and change all the short-name paths to FQDNs:


dfsutil root export \\child.corp.contoso.com\Testing C:\temp\export.xml

REM Get FNR.exe from here: https://findandreplace.codeplex.com/

fnr.exe --cl --dir "C:\temp" --fileMask "export.xml" --find "\\\\TARGET1\\" --replace "\\\\TARGET1.child.corp.contoso.com\\" --silent

fnr.exe --cl --dir "C:\temp" --fileMask "export.xml" --find "\\\\TARGET2\\" --replace "\\\\TARGET2.child.corp.contoso.com\\" --silent

fnr.exe --cl --dir "C:\temp" --fileMask "export.xml" --find "\\\\TARGET3\\" --replace "\\\\TARGET3.child.corp.contoso.com\\" --silent


We add the new DFS-N servers to the existing namespace:


dfsutil target add \\FILE2.child.corp.contoso.com\Testing


Repeat this for each of the 3 new namespace servers.


Then we find the PDCe for the domain. We need to restart the DFS-N service on the PDCe as it doesn’t seem to accept that we add a new namespace servers so easily:


nltest /dnsgetdc:child.corp.contoso.com /PDC | find ".">PDC.txt

FOR /F "delims=. " %i IN (PDC.txt) DO sc \\%i stop DFS

ping -n 5>NUL

FOR /F "delims=. " %i IN (PDC.txt) DO sc \\%i start DFS

ping -n 5>NUL


You now need to wait for a DAY for the new namespace servers to actually take effect on the SMB clients out there on the network.

If a session has an open write connection to any file on the DFS namespace path, then it will NOT update its target list.

You verify this by logging on to the client computer and running:


dfsutil.exe cache referral

If it shows something like this…:

Entry: \child.corp.contoso.com\Testing

ShortEntry: \child\Testing

Expires in 276 seconds

UseCount: 0 Type:0x81 ( REFERRAL_SVC DFS )

  0:[\OLD-SERVER-1\Testing] AccessStatus: 0 ( ACTIVE TARGETSET )




…and doesn’t list the new server names, then do NOT proceed to the next step. You can try flushing the DFSN cache, but if there are open files, this won’t have any effect. You will need to reboot this server before it learns of the new DFSN servers.


dfsutil.exe cache referral flush

You are looking for an output which looks like this:

Entry: \child.corp.contoso.com\Testing

ShortEntry: \child.corp.contoso.com\Testing

Expires in 276 seconds

UseCount: 0 Type:0x81 ( REFERRAL_SVC DFS )

  0:[\OLD-SERVER-1\Testing] AccessStatus: 0 ( ACTIVE TARGETSET )







If you are sure that all the important SMB clients have updated their lists of possible namespace servers to include the 3 old servers and the 3 new servers (so 6 in all), then you can do the next step.

The next step can only be run in the GUI because dfsutil cannot disable links. Open the DFS console, select the 3 old namespace servers and choose “Disable Namespace Server” for each of them:


This will make sure that anyone who is still using the old Namespace servers can continue to do so, but that anyone who asks for a new referral will NOT receive the old servers.



We need to make sure that all SMB clients end their sessions (by closing all their open write handles) and create new referral caches with only the new DFS-N servers in them.

Logon to one of the big SMB clients on the network and verify that the OLD name space servers do NOT appear in referral cache:


dfsutil.exe cache referral

This should now look like this:

Entry: \child.corp.contoso.com\Testing

ShortEntry: \child.corp.contoso.com\Testing

Expires in 276 seconds

UseCount: 0 Type:0x81 ( REFERRAL_SVC DFS )

   0:[\NEW-SERVER-1.child.corp.contoso.com\Testing] AccessStatus: 0 ( ACTIVE TARGETSET )




If old server names appear in the list, do NOT continue to the next step. Again, you can try to flush the DFS referral cache, but this is unlikely to work. The SMB client will likely need to be restarted (again).


Remove the old namespace servers. Don’t use the GUI as this will attempt to also remove the share, which may cause extra difficulties if you need to rollback this step:


dfsutil target remove \\FILE1\Testing


Repeat this command for each of the 3 old namespace servers.


We will now delete the existing DFS-N namespace and create a new one which is in Windows Server 2008 mode (aka v2). Existing sessions will be unaffected as they work from their referral cache. New sessions may fail if they are created in the next few seconds. Retrying will succeed without any intervention.

Run these commands on one of the new DFS-N servers. Copy the export.xml file from the old DFS-N server where you have been running the previous commands from.

This needs to be run locally due to the time it takes to re-create the links. It will be around 15 seconds when run locally and about 1-2 minutes if run remotely:


dfsutil root remove \\child.corp.contoso.com\Testing

dfsutil root AddDom \\FILE2.child.corp.contoso.com\Testing V2

dfsutil root import set C:\temp\export.xml \\child.corp.contoso.com\Testing NoBackup

dfsutil target add \\FILE3.child.corp.contoso.com\Testing

dfsutil target add \\FILE4.child.corp.contoso.com\Testing


Where FILE3 and FILE4 in the example above are the additional new DFS-N servers.


That will do it. You are now running the same exact namespace setup with the same permissions, but on new computers, using FQDN referrals and a v2 namespace.