Migrating DFS Namespaces to Preserve Old Domain Names

First published on TechNet on Nov 05, 2010
Hi folks, Ned here again. A few years ago Dave Fisher wrote a treatise on how to migrate your domain-based DFS namespaces from one forest or domain to another. It works great and a lot of people have found his article helpful. Recently, a few customers have asked how they can migrate a namespace out of an old forest into a new one and keep the old domain namespace structure . Today I explain how you can make this variant work.

The Scenario

Contoso Inc. recently purchased Fabrikam Corporation. Fabrikam had a domain-based DFS Namespace structure called:

\\fabrikam.com\Public

Inside that root they have a few Link Targets that provide access to software installation shares, procedural manuals, and public shared documents:

\\fabrikam.com\public\software
\\fabrikam.com\public\procedural_docs
\\fabrikam.com\public\shared

These Links point to file servers in the Fabrikam domain currently, but those file servers are going to be migrated over to the Contoso.com domain with ADMT.

Some users have been pointed to these Links through logon scripts and others have just been using UNC paths or mapped drives they added themselves. At this point, telling a few thousand former Fabrikam users that these paths are not going to work anymore is not acceptable to management. The old fabrikam.com forest must be removed, as it represents a significant problem for the future with its dozens of DC’s, non-default security settings, backdoor high privilege users, and other unknown configuration changes.

Woo, I sound like an MCP question!

What Won’t Work

When admins first explore this scenario they usually come up with this list below; none of them are recommended though:

• Aliased DNS record for a standalone or domain-based DFS to “pretend” to be a forest

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

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.

What Will Work

The best answer is to recreate the same-named domain as a different tree in the Contoso.com forest once the old forest has been decommissioned. This solves all of those problems and can be maintained with little cost or effort:

• It has an identical namespace so users are not affected.


• The Contoso IT staff is creating a new domain so none of the old forest’s risk is brought over.


• It runs on minimal resources at low cost – just two DC’s are enough, and they can be virtualized ; DFS can handle thousands of referrals a second without breaking a sweat. If you want to add more to individual sites to ensure local referrals, you can.


• There is no Trust maintenance and the domain will contain no users, groups, or member computers requiring operational overhead.


• The DCs do not have to be GCs nor host DNS application partitions, so they will not perform significant AD replication after promotion is complete.


• No DNS trickery is being used so the solution is good for the long term.

The Steps

Note: This article is not about ADMT or migrating file servers between domains, so I am going to gloss over those parts. If you need to learn more about that, review:

• Active Directory Migration Tool (ADMT) Guide: Migrating and Restructuring Active Directory Domains (Word version)


• ADMT Guide: Migrating and Restructuring Active Directory Domains (TechNet version)

Before you start, understand the timeline: this migration requires the old domain to be gone when the DFS migration is complete so that users can access their data without issues, and it requires that the DFS link target servers move to your new domain and be ready for use. This old domain is not coming back, so this would be the last step of a domain migration. This is going to happen on a weekend when users don’t need to access these file servers for a few hours; don’t do all this at 2PM on a Wednesday or you won’t be there on Thursday!

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:

<?xml version="1.0"?>

<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>

<Link Name="shared" State="1" Timeout="1800" >

<Target Server="2003-07" Folder="shared" State="2" />

<Target Server="2003-08" Folder="shared" State="2" />

</Link>

<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" />

</Link>

</Root>

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" />

</Link>

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

For example:

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’re done! You can use DFSDIAG to check all your work now and make sure everything is hunky-dory. Since the data and file servers and shares never changed during this process, simply recreating the old domain name and importing the old configuration takes care of everything. The default DFS root share permissions are for EVERYONE READ so there are no groups or other permissions needed. As long as your users can find the recreated tree domain via DNS, they will never know anything happened.

Until next time.

- Ned “Dave’s sock puppet” Pyle