DFS questions and moving it

When a user logs in to the network what determines if it looks for DFS and mappings to drives?  It's my understanding that it's not best practice to have DFS on a Domain Controller.  I just need to understand how it gets called.

Having said that I have DFS on a server that I took over.  I want to build a new DFS server.  What are the steps to migrate the existing to a new server?  We don't currently use replication.
Who is Participating?

Improve company productivity with a Business Account.Sign Up

AmericomConnect With a Mentor Commented:
A quick answer to your question is that I am assuming  you have a file server and installed configured with "File Services" and even with a standalone DFS configured. Users probably access this standalone DFS name via a \\ServerName\sharename. As far as how users access this share, they are probably accessing via a "shortcut" pointing to the UNC path of \\Servername\sharename or simply as you have mentioned via "drive mapping" which use the same UNC Path \\servername\sharename.

If that's all you have, you many not want to spend the time worry about migrating them as how users access the share probably depending on the shortcut or drive mapping however you provided to users, GPO or Script,
or a mix with logon script etc. But non of the above is a concern.

If you haven't used the "DFS Management" console, you may want to install it on your desktop/laptop via the RSAT admin tools. The DFS Management console is basically provide you a console to manage your DFS folders, links or targets. This console also available if you install the File Services on your file server.

With the above DFS management console, you can start using it by first verify the DFS Namespace and if that is something you also want to rename this is the time. Come up with a meaningful namespace and decide if you will create a "Standalone" DFS root or "Domain" DFS. If you have Active Directory, I suggest you create a Domain DFS root. It will make your life a lot more meaningful when comes to managing DFS, particularly the more DFS folders or targets you create throughout your organization.

Once you decided to go with Domain-based DFS root, then you may want to ask which server type should hosting your DFS, a domain controller or a member server. To me, it depends on how you want to manage the DFS and who would be involve in your IT department. But in general, it would be more meaningful to go with and use your domain controllers as your DFS servers. For many reasons, domain-based DFS configuration will be store along with your AD. Your DCs are generally function just as a DC and nothing else, except may be DNS and DFS. This makes sense as DNS if it's integrated active directory it is also a part of your AD and when user logon, DC/DNS work together for faster response. You usually have two or more DCs for redundancy, this will cover the redundancy of your DFS as well. No need to have dedicated server(s) for your DFS. The only reason I can think of is high availability  where you have DFS store on cluster volume. But regardless where you store your DFS roots, there's also cons and pros. If cluster storage, it may limited to a specific site if you have WAN links failed. But if you keep DFS and have it replicate to all DCs, it is unlikely that user will not be able to find the DFS name within your domain, unless no domain controller can be found locally or remotely.

Now, lets say you have decided to use Domain-based DFS root and will store it on your DCs. The next thing you would want to decide is a good "namespace", such as Human Resources or IT. You want to organize your DFS folders or targets within each department. This will give you an ideal environment to manage and for users to locate their resources.

Inside of these department, you will create DFS folder where you assign the target which points to the UNC path such as \\Servername\sharename. User access the DFS folder via the path of \\DomainName\DFSRootName\DFSTargetName. This means you can move your share from server to server and user will never have to worry about updating the UNC paths. Updating the creating DFS targets and making it available to users is instant, no need to logon/logoff. If for whatever reason you have to use drive mapping, just use the DFS folder path and not the UNC path. You manage and update the UNC path from the DFS management console regardless where your shares are at as changing DFS targets does not change the DFS path for user.
I suggest before you implement or make any changes, understanding more how DFS is being used would help you save time and prepare for good info to defending your implementation of DFS.

First, you need to know exactly how you would use DFS and who would be managing or using the DFS Management console.

I don't agree that it is best practice to have DFS installed on member servers or domain controllers. It really depends on how you use it and who would be manage it.

Be right back...lunch time. But this is a topic that I have spent a lot of time on would wish I can provide more info.
As others mentioned, I too suggest you to understand the DFS first and as per your requirement configure it. However if your domain functional level is more than 2008 then you can migrate SYSVOL to DFSR for replication. Configuring DFS namespace is different thatn DFS replication group. Please provide more details about what exactly you are trying to do, then we can assist you better.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.