In this Ask the Admin, I’m going to demystify the process of setting up a Distributed File System (DFS) namespace in Windows Server 2012 R2.
DFS namespaces provide users with a logical way to access files without needing to know their physical location. Sitting in front of your physical file servers, a DFS namespace is a hierarchy of UNC paths that don’t reference the actual file servers, but transparently redirect users to the nearest copy of the data via NTFS shares. DFS can also help to mitigate some of the issues commonly associated with migrating or consolidating existing file servers, such as maintaining UNC paths during migration projects.
When used with DFS replication, IT can provide users access to local copies of their data in different geographical locations without needing to pull data across expensive wide-area networks. DFS replication is an optional feature, and in this article I want to concentrate only on the namespace aspect of the equation.
A DFS namespace can be created even if you only have one file server, and the file server itself can act as a namespace server, i.e. the server where DFS will be installed and the namespace configured. The folders that contain the data to be accessed are known as folder targets, and even when they are located on the namespace server, they must be shared because DFS doesn’t differentiate between folder targets located on the namespace server or remote file servers.
When configuring a DFS namespace, you create a DFS root on a namespace server. This root must also exist as a shared folder. In Figure 1 below, you can see a DFS root (\\contoso\public) configured on a namespace server with folder targets (Tools and Training Guides) being directed to a series of remote file servers.
There’s also a folder called Software. DFS folders are optional, existing purely to provide extra flexibility in organizing the namespace hierarchy. So for example, a user can access Tools using \\contoso\public\software\tools\ and will be transparently redirected to the London or New York server depending on their physical location. Similarly, \\contoso\public\Training Guides will direct users to the Training share on the New York server.
For simplicity I’m going to create a DFS namespace called files in Windows Server 2012 R2. Theres only one file server (contososrv1) in my domain, and this will be where I install the DFS bits, and it will act as the namespace server. To configure and install the DFS namespace feature, log in to the file server with domain administrative privileges, open a PowerShell prompt and type the command below:
The file server currently has no shared folders, so I'm going to create three folders: sales, accounts, and production; and a folder for the namespace (DFS root), using the mkdir cmdlet. Note that you can use existing shared folders that are already populated with files.
Once the folders have been created, they need to be shared. The code below shares each folder using the New-SMBShare cmdlet, giving Everyone full access.
Now that the necessary folders and shares are in place, I can create the DFS namespace using the New-DfsnRoot cmdlet. \\ad.contoso.com\files is the UNC path for accessing the namespace, and \\contososrv1\files is used to specify the DFS root namespace server and path. The –Type parameter can be set to one of three values:
Finally, we need to add the folder targets to the namespace, i.e. sales, accounts, and production, which are separated from the DFS root in the shares folder. The code below adds each share to the files namespace:
Now users can access the namespace in File Explorer from any domain-joined device using \\ad.contoso.com\files\, and the sales, accounts, and production folders can be populated with files.