Transparent switch from single fileserver to DFS

Question

Currently we're maintaining an environment with a single Windows Server 2008 R2 fileserver. We'd like to replace the server with a Server 2012 R2 machine and switch to DFS (fileshare on dfs server, without replication).

Now I have the problem that the old server could have been referenced by:

• \\IP\sharename
• \\hostname\sharename
• \\FQND\sharename

And I don't know what links the users have in their documents. When I now switch to the new server with dfs, the old hostname becomes invalid anyway and I can only reference the new share by:

• \\hostname\sharename (which would be without DFS and therefore wrong and, of course, the new host has a new name anyway) or:
• \\domain\namespace\share

Long story short: Is there a possibility to switch to DFS but keeping the old paths still valid (some sort of alias or something)?

Answer 1

Okay, as it doesn't seem like somebody here has an answer, I'm going to post what I've found out (if somebody has a better way to do it, please feel free to post it;))

First, it seems like my statement from above is true: a new DFS-Namespace can't be compatible with an old fileshare which has been accessed by its UNC-Path. For some situation there is a feature which may help in some situations, called 'DFS Consolidation Roots'. Be aware though, that this solution only works with standalone namespaces and not AD integrated (AFAIK).

For me, I chose the following solution:

1. Robocopy all the files to the new server
2. Create the shares on the new server with the same relative UNC-Path (what I mean is: \hostname\"everything after hostname stays the same")
3. Robocopy a second time (diff only)
4. Remove old server from AD-Domain (very important for later steps ;))
5. Shutdown old server
6. Add a CNAME-Record to the DNS, pointing from the old hostname to the new one
7. Configure DFS
8. Configure all applications under my controll to use the DFS-Path from now on

Be aware though, that you need to configure the new server that it accepts requests initiated to this alternate name (got it from here: http://md3v.com/enable-windows-server-smb-2-0-alias-cname):

1. regedit: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanServer\Parameters
2. REG_DWORD 32bit: DisableStrictNameChecking, Value : 1
3. reboot your server.
4. setspn -a host/"oldname" "hostname of new server"
5. setspn -a host/"oldFQND" "hostname of new server"

I didn't rollout it in production yet, but in the lab it worked decently. In my opinion, it's a good way to rollout DFS without breaking all document templates or user-built scripts you aren't even aware of.

But: Next time I'm setting up a fileserver for a new customer, I'm totally going to use DFS from the beginning ;)

Kind regards, Christian