In theory you could have a forward lookup zone that resolves to a standalone DFS server so that it appears to be the old domain. But now you have the main disadvantage of standalone namespaces: they must be clustered for high availability. You could use domain-based DFS with multiple servers and create more complex manual DNS records. But in all cases you have to manually build and maintain SPNs to make Kerberos work. And this means that you cannot make any mistakes with DNS or SPN maintenance ever , especially if you plan on having computers access files through DFS – NTLM cannot be used by Windows to talk to other Windows computers; NTLM only works for users. Worst of all, you are creating a solution so customized and non-standard that it becomes a supportability problem for your colleagues and whoever replaces you someday.
DFS Root Consolidation shims non-DFS servers into a new standalone DFS namespace so that the old computer names continue to work. It does not handle consolidating old domain-based DFS namespaces into new ones.
1. Export the domain-namespace from the old domain you are decommissioning.
DFSUTIL.EXE /root:\\<domain fqdn>\root> /export:<somefile.txt> /verbose
For the fabrikam.com example:
Note : If using Windows Server 2003 you will need the Support Tools . If a later OS, DFSUTIL is built in when you install the DFSN role.
2. Examine the export file and you will see that it lists out the entire configuration with all the server names, links, and targets. For example:
<Root Name="\\FABRIKAM\public" State="1" Timeout="300" Attributes="64" >
<Target Server="2003-03" Folder="public" State="2" />
<Target Server="2003-04" Folder="public" State="2" />
<Link Name="software" State="1" Timeout="1800" >
<Target Server="2003-07" Folder="software" State="2" />
<Target Server="2003-08" Folder="software" State="2" />
<Link Name="shared" State="1" Timeout="1800" >
<Target Server="2003-07" Folder="shared" State="2" />
<Target Server="2003-08" Folder="shared" State="2" />
<Link Name="procedural_docs" State="1" Timeout="1800" >
<Target Server="2003-07" Folder="procedural_docs" State="2" />
<Target Server="2003-08" Folder="procedural_docs" State="2" />
3. Migrate all of your Link Target servers over to the new domain with ADMT , making sure to do security translation on all the files and shares. Consider using SID history as well. The Root Target servers are totally immaterial and do not need to be touched, unless you plan to use them as the hardware in step 5. If these Link Target servers were using FRS or DFSR to replicate in the past you will need to note this down and recreate that replication when all done with step 9. It’s beyond the scope of this article to go into details, but if you want more info let me know and I’ll cover it in another article.
4. Decommission the old domain. So in my example, Fabrikam.com no longer exists at this point. Make sure you take note of the old NetBIOS domain name before you zap it. Also make sure you remove the old trust and any previous name resolution done to make the trust work.
5. Using DCPROMO , recreate the old decommissioned domain as a new tree domain in the target forest. In my example, this would be Fabrikam.com as a new tree domain in the Contoso.com forest, like below:
6. Configure DNS conditional forwarders in the domains so that everyone can find your new domain tree and the new domain tree can find the domain containing all the link target file servers. In my example these are:
Note : If you have some other way you configure DNS that allows clients and link targets to work, that’s fine too; conditional forwarders are just my recommendation.
7. Add one more DC to that new tree domain. Now you have high availability and the basis for your two DFS root servers. No other servers are needed unless you want them. Make sure that the DFS Namespace role is installed on both servers if using Win2008 or later.
8. Using DFSMGMT.MSC , recreate your old root namespace. In my case it is named “Public”. Use your tree domain DC’s as the two namespace servers when configuring this root, so that you have high availability. Don’t recreate the links manually. You can use DFSUTIL.EXE /AddFtRoot to do this also.
9. Here’s the only step that requires you to pay attention to the export file:
A. If your servers listed in the export file only use NetBIOS names, import the TXT file back into the new tree domain by running DFSUTIL on one of the tree domain DCs.
B. If your servers listed in the export file use fully-qualified domain names, you must edit the TXT file to have them point to their new FQDNs. For example:
<Link Name="software" State="1" Timeout="1800" >
<Target Server="2003-07.contoso.com" Folder="software" State="2" />
<Target Server="2003-08.contoso.com" Folder="software" State="2" />
You don’t have to change anything else because the root names, shares and links have not changed. So after step A or B, you run:
DFSUTIL.EXE /root:\\<domain fqdn>\root> /import:<somefile.txt> /set /verbose
Note : Don’t worry about the TXT file containing the old domain root server names (which may have changed). DFSUTIL ignores those root server targets during import. It only cares about the links and link target info. That’s why you had to pre-create the namespace in step 8.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.