I have just returned from the MVP summit in Redmond, where I spent the best part of a week with the Active Directory Product Group and other Directory Services MVP’s. In conversation with a fellow Directory Services MVP Mike Kline, I mentioned a way that I had spoofed a domain to ensure a DFS namespace continued to seamlessly function after a company we had acquired was integrated into our environment. Mike thought it would be a good insight for me to share.
We are company XYZ Ltd. and we have an Active Directory forest called xyz.com.
We buy ABC Ltd. who are part of a larger company and they have servers in a domain called continent.abc.com, which is a child domain in a global forest.
Ignoring logistics around user accounts and file permissioning (which was also resolved), when company became our entity, we acquired their file servers (but no Domain Controllers)but we had to enable them to be able to access their existing data in the same DFS namespace as a majority of the files all had embedded links and shortcuts.
The way I achieved this was by using a standalone DFS Server and DNS.
In our domain xyz.com I built a domain joined windows server called the same as the domain name that was used for DFS-N resolution in the acquired company. In this case continent(.xyz.com).
In our domain (xyz.com) I then created a DNS zone called abc.com and then created a CNAME pointing to continent.xyz.com within the abc.com zone, this way I ended up with a server addressable as continent.abc.com. On continent.xyz.com I installed DFS as a standalone implementation and configured all the targets, after which I was left with a server emulating the acquired companies old domain and DFS Namespace.
It goes without saying that this was a temporary solution, as the standalone server was a single point of failure, but it got us over the initial hurdle of seamless data access in a hurry.