Folder Redirection, when properly setup, can provide a huge amount of value for your organization. It separates the connection between user and computer. Staff can move between computers and have access to any data that they need. Enabling it is easy but that is where most IT departments stop. Perfecting it takes a bit more work.
Over the next few posts, we are going to cover folder redirection and the other tools you can use to extend it. These will include DFS namespaces, data deduplication, Volume Shadow Services, Offline Files, Security, and remote file access. As you can see, we have a lot to cover! Today, we are going to setup a DFS Namespace. Our next post will enable folder redirection and configure our file system security permissions.
What are DFS Namespaces and why should I care?
DFS can be divided into two technologies: DFS Namespaces and DFS Replication. These are commonly abbreviated to DFS-N and DFS-R. The first one, DFS-N, allows you to move away from the traditional \\SERVER\Share method of file access. Instead, you create a namespace and point locations in the namespace to specific servers. This is essentially how you can go to \\DOMAIN-Name\SYSVOL and access the SYSVOL directory in C:\Windows\ of your closest domain controller.
What are the advantages of using a namespace when you have to create the shares on a server anyways? For me, there are two:
- Reduce IT overhead. You can point your software shares, folder redirection, home folders, shared drives, etc to one namespace. You don’t have to remember which server holds what data – you just go to \\DOMAIN-NAME\data (or whatever you name your DFS Namespace). You are pointed to the correct server through the magic of Directory Services!
- A more agile environment. You are no longer tied to specific servers paths. If you want to move data to a new server, you can do so without breaking shortcuts or processes! End users and services have no idea that the data in the background has been moved.
DFS-R is another animal. DFS-R is great when you have multiple sites and you want data to replicate between them. It allows you to host data between two servers and keep that data in sync. Personally, I’ve had bad experiences with DFS-R and real time data access. The issue is always related to users having multiple paths to modify data. The trick to successful DFS-R implementation is to understand replication status and supported configurations. You can read all about that here. Back to our topic now!
Creating and configuring your first DFS Namespace
On your file server, launch the Add Roles and Features Wizard. Under Server roles, select DFS Namespaces. In the screenshot below, I also installed the Data Deduplication service, DFS replication, File Server Resource Manager, and the Work Folders role (for remote file access).
After the roles have installed, launch the DFS Management MMC. Right click on Namespaces and select New Namespace. Browse to your server and then press next. Give your Namespace a name – for example data or users. Change the local path of the shared folder to the correct location. You probably do not want to use the default location of C:\DFSRoots\Data. Under Shared folder permissions, select customize and give Everyone the Full Control Permission. You will be using local security permissions to control access.
On the Namespace Type screen, accept the default selections of Domain-based and Enable Windows Server 2008 mode. This will allow you to use Access-based enumeration (users do not see files that they can not read). If your domain level is 2003, you will want to raise it first before creating a namespace. This is my go-to article on raising the domain or forest functional level.
Continue through the wizard and finish creating your namespace. And that is it! You now have your very own DFS namespace! 🙂
In our next post, we go from a fancy folder to a fancy folder with some data in it.
First let me start by saying “excellent write up”! It made setting up my redirected folders with DFS shares very easy. Unfortunately I think I made a mistake along the way and I am hoping there is an obvious answer to my problem. I have two DFS servers up with replication functioning between them. The path is set to D:\Shares\UserFiles on both servers. The problem comes in when I take Server1 offline. When I take down Server1 the files stored in D:\Shares\UserFiles on Server2 are not made available. Instead C:\DFSRoots\UserFiles is made available. C:\DFSRoots only exists on Server2. What am I missing and is there an easy way to correct this?
Thank you John! What is the UNC pat that you are using to share your home folder?
I am using \\DOMAIN NAME\UserFiles\LOCATION\USERNAME. I used UserFiles to keep redirected folders separate from other DFS shares and location is simply for organization.
This is very helpful stuff.
However, I do have a question.
I have two namespace servers and I’m not sure if I completely understand the DFS concept.
Let say, I create folders and add folder targets pointing to files on server A and replicate those to server B. Now, If the server A goes down with all those folder targets.
Would I have to recreate folder targets pointing to server B so the user(s) can access his/her files until the server A is back on-line or will this be taken care automatically as I thought it would?
Is there something else that needs to be configured so it would work without causing interruption to users in case of the server failure?
Thank you
You would use the domain name \ namespace . This makes the address not need a specific server.
how do i get to the next post?
Or is the next post ‘Configuring Folder Redirection – Part 2 – Group Policy and Security’??
do you know of a way to set the DFS Share permissions for everyone via Powershell? I’ve tried the dfsutil property sd grant command as well as the Grant-DfsnAccess command and neither seem to work. Basically I won’t to programmatically create a new folder/share and then set the permission for everyone from read to full.
Good write-up Joe – I find it funny I always stumble across something here when I am in the middle of a similar project. In my case, I am moving from an existing Windows 2008 file server with redirected folders (no DFS) to a new 2012 R2 file server and plan on implementing DFS so as not to tie user’s docs to a specific server (should make migrations much easier in the future). Hope to pull off the migration this weekend.
Few observations between your write-up and what I’m doing:
1) Using the default C:\DFSRoots folder – I had planned on keeping this since it really is only a table of contents and shouldn’t be storing any information. I agree, if users could write stuff here, it should probably be moved, you wouldn’t want them filling up your OS partition! But, to ensure they can’t write any data here, I planned on making the shared folder permissions for the DFS root to “Administrators have full access, other users have read-only permissions.” I believe if you give Everyone full control, the default NTFS permissions on the DFS root folder (in the example C:\DFSRoots\Data) would allow users to write stuff to it.
2) Well after typing up point 1, I just noticed in part 2 of this article you had created a FR folder in your DFSRoots\Data folder which is where you are applying the NTFS permissions so that make more sense now. I am planning on not actually creating a real folder under my DFSRoots\Data folder, but rather adding a folder with a target that will point to \\MYfileServer\FolderRedirections which will have the share permissions and NTFS permissions set to allow users to write to it. Sound OK?
3) I was debating a name for my root, I think I am going to go with Data as well – something really generic. Under that I’ll have the FolderRedirections and I plan on adding another “Shares” folder for shared folders used by departments (Finance, Marketing, etc.). Do you think there is any value in using multiple namespaces, or just keep it under one namespace?
Thanks! Enjoy your blog!
Thanks James! 🙂
Your method of redirection sounds good. I like to use multiple namespaces when I have disjointed data or when I want a separate logical break in namespaces.
DFS was really helpful from windows 2003 R2.. now much more
Agreed pb!
Hi,
Great website with some fantastic articles. Question on this one though. We have existing 2012r2 servers without dfs install with existing file shares. Would it be better to create a new dfs folders outside these existing shares then copy data into the new dfs folders after or can you use your existing shares and Folders? Only wanting to use the name space side of things not replication.
Thank you Mark!
You can use existing folders. When you create your DFS namespace, just change the path to that location. It will use the security settings on that folder though to control share/folder access. As always, make sure you have a backup and practice the steps first on a test namespace/environment.
Would you install this on a file server that already has data that you want to add to the namespace, or would this be a separate server? I ask because if the server already has the data you want to add, then wouldn’t you have two copies of your data? That could be a LOT of used space on one server.
Hi Terry – I am writing this from a new server standpoint. Most environments would have their file server on an older box (say 2008R2 or so). If you had a new server running 2012 or 2012R2, you could enable data deduplication – this would stop your space from doubling. Here is my guide on data dedupe: https://deployhappiness.com/data-deduplication-server-20122012-r2-saving-gbs-checkbox/
I don’t follow why this would cause you to have two copies of data. I too am setting up DFS namespace on a server that is live.
I think Terry was talking about setting up a share with DFS-N and moving data in it while keeping the other location live until a switch over.
Good topic, waiting for more articles!.
Thank you Vaseem!