DFS Stand-Alone Roots from Consolidation to Domain Roots?

Hi everyone,

I was able to migrate our servers to DFS and had to keep the prior naming
conventions so I used the DFS Consolidation Root Wizard in the File Server
Migration Toolkit and everything worked well. The only problem I have is
that when I migrated the servers I was only able to create stand-alone DFS
roots (I didn't seem to have an option to migrate to domain DFS roots). I've
been having issues with the stand-alone root server since when it goes down
the DFS namespaces become unavailable to our users. I've tried to figure out
a way to migrate the stand-alone roots to domain roots (we have AD in place
already) but have had no luck. I have successfully exported the roots to
text files using dfsutil. I then created new domain roots and tried to
import the previously exported roots into the newly created domain roots but
I still cannot access the shares using the old naming conventions (which are
via mapped drives: \\oldservername\share).

Is there a way to do this without going the cluster route? I would love to
integrate the dfs roots into AD without losing the consolidated naming
conventions. Any help is greatly appreciated. Thanks!

 

Hi Justin,

DFS Root Consolidation only works with standalone roots. Domain based
roots must be accessed via \\domain\root therefore eliminating the
possibility to consolidate roots. If you are looking for redundancy with
Root Consolidation then a server cluster must be used.

Hope this helps,

Brian Delaney
Microsoft Canada

 

Thanks Brian,

I figured as much. I wanted the fault tolerance that dfs-r brought to the
table but it looks like it'll be at a cost of having to ensure the
reliability of the root. Though since our employees access the shares via
mapped drives from logon scripts I could probably migrate the shares to a
domain root structure and just make the changes at the scripts. Hopefully
I'm not too far off base here.

Thanks!

 

Hi Justin,

DFSR can still be utilized in a stand-alone DFS namespace. However,
without clustering the stand alone namespace the namespace itself has no
redundancy.

In a situation like this I usually recommend this:
Utilize a Consolidation Root to preserve the existing namespace
Ensure LogServerConsolidation is configured on the consolidation server(s).
Configure a domain based namespace including all the links you wish to
consolidate with DFS
Update logon scritps, home drives, etc with the domain based namespace path.
Monitor the event logs on the consolidation server watching for events from
dfssvc which will indicate when the old file server paths are used and the
IP that used it
Correct any usage of the old path found in the event logs (static drive
mappings, shortcuts, etc)
Once the dfssvc events stop showing that the consolidation roots are being
used, remove them.


Hope this helps,

Brian Delaney
Microsoft Canada
--

This posting is provided "AS IS" with no warranties, and confers no rights.
--------------------

 

That makes a lot of sense to me. I do have a question on step 3: Configure
a domain based namespace including all the links you wish to consolidate
with DFS. I want to build the namespace and the links in a way that makes
the most sense for us. We currently have UNC names that map to drives like
\\server1\sales, \\server1\marketing, \\server2\engineering which are pretty
straightforward. When I build my new namespace I assume each of the links
will be to \\domain\sales, \\domain\marketing, \\domain\engineering, etc. I
just want to make sure I'm utilizing DFS in the way it was intended before I
start moving the locations of the files into a newly created namespace.

Thanks Brian for your help! I greatly appreciate it.

Justin