Three ways to design your DFS Namespaces

Three ways to design your DFS Namespaces

  • Comments 3
  • Likes

Introduction

In this blog post, we’ll showcase the flexibility you have with DFS-N by showing three distinct ways that you could design a namespace.

Note: If you’re not familiar with DFS-N, please read this blog post first:
http://blogs.technet.com/josebda/archive/2009/03/10/the-basics-of-the-windows-server-2008-distributed-file-system-dfs.aspx

Scenario

The scenario here is simple: you have three file servers in different locations: S1 is in New York, S2 is in Amsterdam and S3 is in Hong Kong. Each server has a unique set of data (Proposals, Marketing information and Engineering documents for each geography) and you want to expose this under a single namespace. Here’s the structure on each file server:

Server S1 in New York:

  • F:\AMER\PROPOSAL – Proposals for the AMER (Americas) region
  • F:\AMER\MARKETING – Marketing information for the AMER region
  • F:\AMER\ENGINEERING – Engineering documents for the AMER region

Server S2 in Amsterdam:

  • F:\EMEA\PROPOSAL – Proposals for the EMEA (Europe, Middle East and Africa) region
  • F:\EMEA\MARKETING – Marketing information for the EMEA region
  • F:\EMEA\ENGINEERING – Engineering documents for the EMEA region

Server S3 in Hong Kong:

  • F:\APAC\PROPOSAL – Proposals for the APAC (Asia and Pacific) region
  • F:\APAC\MARKETING – Marketing information for the APAC region
  • F:\APAC\ENGINEERING – Engineering documents for the APAC region

Please note that this specific scenario does not include replication. Each server each has completely an independent set of files. For instance, a proposal for an EMEA customer would exist only in the F:\EMEA\PROPOSALS folder in S2 and it would not exist in servers S1 or S3. Replication across these servers could be accomplished using DFS-R, but I am purposely avoiding it in this example to focus specifically on DFS-N design.

Creating the folders and shares

First of all, I am providing the scripts to create the folder structure and the shares. These are 3 distinct scripts and each one needs to be run on a specific server (S1, S2 or S3). We could actually do this all remotely, but I’m keeping it simple.

CREATE-S1.CMD

REM ## RUN THIS SCRIPT in S1, the file server in New York
MD F:\AMER\PROPOSALS
MD F:\AMER\MARKETING
MD F:\AMER\ENGINEERING
NET SHARE AMER=F:\AMER

CREATE-S2.CMD

REM ## RUN THIS SCRIPT in S2, the file server in Amsterdam
MD F:\EMEA\PROPOSALS
MD F:\EMEA\MARKETING
MD F:\EMEA\ENGINEERING
NET SHARE EMEA=F:\EMEA

CREATE-S3.CMD

REM ## RUN THIS SCRIPT in S3, the file server in Hong Kong
MD F:\APAC\PROPOSALS
MD F:\APAC\MARKETING
MD F:\APAC\ENGINEERING
NET SHARE APAC=F:\APAC

Please note that the shares will end up with read-only permissions using the commands above. In your real-world deployment you will need to properly plan your NTFS and file share permissions and implement them properly with CACLS or ICACLS.EXE (for NTFS) and the /GRANT option in NET SHARE (for the file shares). The focus of this post is not on permissions but on the structure of the shares, folders and namespaces.

Namespace option 1 – Simple mapping of shares

The first option I will cover is a simple mapping at the root share on each server. This is simpler because it requires a namespace with only three folders (or links). Assuming we use a fourth server (S4) as the namespace server (or target) and NS1 as the name of the namespace (or root), users would basically use \\S4\NS1 as the UNC path to the entire set of data from all three file servers.

Note 1: You could host the namespace in one of the file servers, see details at  http://blogs.technet.com/josebda/archive/2009/06/26/how-many-dfs-n-namespaces-servers-do-you-need.aspx
Note 2: We’re using a standalone namespace here, but you could just as easily use a domain namespace instead.
Note 3: We’re not adding any fault tolerance for the namespace or the file servers in these scenarios. This could be accomplished with Failover Clustering for standalone namespaces or with multiple targets for a domain namespace.

Here’s a script to create the namespace, which should be run on S4:

CREATE-NS1.CMD

REM ## scenario 1 - Simple mapping of shares
REM ## RUN THIS SCRIPT in S4, the namespace server
MD F:\NS1
NET SHARE NS1=F:\NS1
DFSUTIL ROOT ADDSTD \\S4\NS1
DFSUTIL LINK ADD \\S4\NS1\AMER \\S1\AMER
DFSUTIL LINK ADD \\S4\NS1\EMEA \\S2\EMEA
DFSUTIL LINK ADD \\S4\NS1\APAC \\S3\APAC
DIR \\S4\NS1 /S /B
DFSUTIL ROOT EXPORT \\S4\NS1 F:\NS1EXPORT.XML VERBOSE

From an end-user perspective, the folder structure under \\S4\NS1 would look like this:

DFS NSD 1

At the end of this script, an XML export of the namespace is created. Here’s what it looks like:

NS1EXPORT.XML

<?xml version="1.0"?>
<Root xmlns = "http://schemas.microsoft.com/dfs/2007/03/dfsutil" majorVersion = "2" minorVersion = "0"
    Name="\\S4\NS1" State="OK" Timeout="300" >
    <Target State="ONLINE" >\\S4\NS1</Target>
    <Link Name="AMER" State="OK" Timeout="300" >
        <Target State="ONLINE" >\\S1\AMER</Target>
    </Link>
    <Link Name="EMEA" State="OK" Timeout="300" >
        <Target State="ONLINE" >\\S2\EMEA</Target>
    </Link>
    <Link Name="APAC" State="OK" Timeout="300" >
        <Target State="ONLINE" >\\S3\APAC</Target>
    </Link>
</Root>

Namespace option 2 – Flattening out the tree in the namespace

This second options shows the flexibility of DFS-N by creating a flat list of folders from the three servers and their folder structures. Users might find convenient to see a long list of folders without any nesting of folders. This shows how you can point your folder targets (or link targets) to a folder inside the share, not only the root of the file share. Again we’ll use that fourth server (S4) as the namespace server (or target), but now with NS2 as the name of the namespace (or root). Users would use \\S4\NS2 as the UNC path to the entire set of data from all three file servers.

Here’s a script to create the namespace, which should be run on S4:

CREATE-NS2.CMD

REM ## scenario 2 - Flattening out the tree in the namespace
REM ## RUN THIS SCRIPT in S4, the namespace server
MD F:\NS2
NET SHARE NS2=F:\NS2
DFSUTIL ROOT ADDSTD \\S4\NS2
DFSUTIL LINK ADD \\S4\NS2\AMERPROP \\S1\AMER\PROPOSALS
DFSUTIL LINK ADD \\S4\NS2\AMERMARK \\S1\AMER\MARKETING
DFSUTIL LINK ADD \\S4\NS2\AMERENGI \\S1\AMER\ENGINEERING
DFSUTIL LINK ADD \\S4\NS2\EMEAPROP \\S2\EMEA\PROPOSALS
DFSUTIL LINK ADD \\S4\NS2\EMEAMARK \\S2\EMEA\MARKETING
DFSUTIL LINK ADD \\S4\NS2\EMEAENGI \\S2\EMEA\ENGINEERING
DFSUTIL LINK ADD \\S4\NS2\APACPROP \\S3\APAC\PROPOSALS
DFSUTIL LINK ADD \\S4\NS2\APACMARK \\S3\APAC\MARKETING
DFSUTIL LINK ADD \\S4\NS2\APACENGI \\S3\APAC\ENGINEERING
DIR \\S4\NS2 /S /B
DFSUTIL ROOT EXPORT \\S4\NS2 F:\NS2EXPORT.XML VERBOSE

From an end-user perspective, the folder structure under \\S4\NS2 would be flat, like this:

DFS NSD 2

At the end of this script, an XML export of the namespace is created. Here’s what it looks like:

NS2EXPORT.XML

<?xml version="1.0"?>
<Root xmlns = "http://schemas.microsoft.com/dfs/2007/03/dfsutil" majorVersion = "2" minorVersion = "0"
    Name="\\S4\NS2" State="OK" Timeout="300" >
    <Target State="ONLINE" >\\S4\NS2</Target>
    <Link Name="EMEAMARK" State="OK" Timeout="300" >
        <Target State="ONLINE" >\\S2\EMEA\MARKETING</Target>
    </Link>
    <Link Name="APACENGI" State="OK" Timeout="300" >
        <Target State="ONLINE" >\\S3\APAC\ENGINEERING</Target>
    </Link>
    <Link Name="APACMARK" State="OK" Timeout="300" >
        <Target State="ONLINE" >\\S3\APAC\MARKETING</Target>
    </Link>
    <Link Name="AMERMARK" State="OK" Timeout="300" >
        <Target State="ONLINE" >\\S1\AMER\MARKETING</Target>
    </Link>
    <Link Name="AMERENGI" State="OK" Timeout="300" >
       <Target State="ONLINE" >\\S1\AMER\ENGINEERING</Target>
    </Link>
    <Link Name="AMERPROP" State="OK" Timeout="300" >
        <Target State="ONLINE" >\\S1\AMER\PROPOSALS</Target>
    </Link>
    <Link Name="APACPROP" State="OK" Timeout="300" >
        <Target State="ONLINE" >\\S3\APAC\PROPOSALS</Target>
    </Link>
    <Link Name="EMEAPROP" State="OK" Timeout="300" >
        <Target State="ONLINE" >\\S2\EMEA\PROPOSALS</Target>
    </Link>
    <Link Name="EMEAENGI" State="OK" Timeout="300" >
        <Target State="ONLINE" >\\S2\EMEA\ENGINEERING</Target>
    </Link>
</Root>

Namespace option 3 -  Namespace reversing the original tree structure on each file server

Last but not least, the most interesting exhibit of the flexibility of DFS-N. In this case we’ll create a namespace showing the collection of folders group by type instead of geography. DFS-N makes it easy, since we can basically restructure the shares as we create the namespace. This shows how you can also use a tree structure on the DFS folder (or link) side of the equation, which can do a lot when you combine with what we did in option 2 above. Again we’ll use that fourth server (S4) as the namespace server (or target), but now with NS3 as the name of the namespace (or root). Users would use \\S4\NS3 as the UNC path to the entire set of data from all three file servers.

Here’s a script to create the namespace, which should be run on S4:

CREATE-NS3.CMD

REM ## scenario 3 –  Namespace reversing the original tree structure on each file server
REM ## RUN THIS SCRIPT in S4, the namespace server
MD F:\NS3
NET SHARE NS3=F:\NS3
DFSUTIL ROOT ADDSTD \\S4\NS3
DFSUTIL LINK ADD \\S4\NS3\PROPOSALS\AMER \\S1\AMER\PROPOSALS
DFSUTIL LINK ADD \\S4\NS3\MARKETING\AMER \\S1\AMER\MARKETING
DFSUTIL LINK ADD \\S4\NS3\ENGINEERING\AMER \\S1\AMER\ENGINEERING
DFSUTIL LINK ADD \\S4\NS3\PROPOSALS\EMEA \\S2\EMEA\PROPOSALS
DFSUTIL LINK ADD \\S4\NS3\MARKETING\EMEA \\S2\EMEA\MARKETING
DFSUTIL LINK ADD \\S4\NS3\ENGINEERING\EMEA \\S2\EMEA\ENGINEERING
DFSUTIL LINK ADD \\S4\NS3\PROPOSALS\APAC \\S3\APAC\PROPOSALS
DFSUTIL LINK ADD \\S4\NS3\MARKETING\APAC \\S3\APAC\MARKETING
DFSUTIL LINK ADD \\S4\NS3\ENGINEERING\APAC \\S3\APAC\ENGINEERING
DIR \\S4\NS3 /S /B
DFSUTIL ROOT EXPORT \\S4\NS3 F:\NS3EXPORT.XML VERBOSE

From an end-user perspective, the folder structure under \\S4\NS3 is shown below. It examplifies how DFS-N can completely mask the physical infrastructure behind the namespace:

DFS NSD 3

Note that \\S4\NS3\ENGINEERING, \\S4\NS3\MARKETING and \\S4\NS3\PROPOSALS don’t actually exist as DFS folders (or links) at all. They are basically abstract constructs shown only in the UI, which don’t map to any specific target. You can confirm this when you look at the export of the namespace:

NS3EXPORT.XML

<?xml version="1.0"?>
<Root xmlns = "http://schemas.microsoft.com/dfs/2007/03/dfsutil" majorVersion = "2" minorVersion = "0"
    Name="\\S4\NS3" State="OK" Timeout="300" >
    <Target State="ONLINE" >\\S4\NS3</Target>
    <Link Name="MARKETING\APAC" State="OK" Timeout="300" >
        <Target State="ONLINE" >\\S3\APAC\MARKETING</Target>
    </Link>
    <Link Name="MARKETING\AMER" State="OK" Timeout="300" >
        <Target State="ONLINE" >\\S1\AMER\MARKETING</Target>
    </Link>
    <Link Name="ENGINEERING\EMEA" State="OK" Timeout="300" >
        <Target State="ONLINE" >\\S2\EMEA\ENGINEERING</Target>
    </Link>
    <Link Name="MARKETING\EMEA" State="OK" Timeout="300" >
        <Target State="ONLINE" >\\S2\EMEA\MARKETING</Target>
    </Link>
    <Link Name="ENGINEERING\AMER" State="OK" Timeout="300" >
        <Target State="ONLINE" >\\S1\AMER\ENGINEERING</Target>
    </Link>
    <Link Name="PROPOSALS\AMER" State="OK" Timeout="300" >
        <Target State="ONLINE" >\\S1\AMER\PROPOSALS</Target>
    </Link>
    <Link Name="PROPOSALS\APAC" State="OK" Timeout="300" >
        <Target State="ONLINE" >\\S3\APAC\PROPOSALS</Target>
    </Link>
    <Link Name="PROPOSALS\EMEA" State="OK" Timeout="300" >
        <Target State="ONLINE" >\\S2\EMEA\PROPOSALS</Target>
    </Link>
    <Link Name="ENGINEERING\APAC" State="OK" Timeout="300" >
        <Target State="ONLINE" >\\S3\APAC\ENGINEERING</Target>
    </Link>
</Root>

Conclusion

I hope this helped you understand how DFS-N folder (or links) and folder targets (link targets) work. Please note that we could create this all using the DFS Management graphical user interface (or MMC). We did this in the command line because it’s easier to document that way. Here’s a view from the MMC of all the three namespaces we created:

DFS NSD 4

Please note that you do not want to create all three namespaces simultaneously. I did this just for showing it here. You would choose the option that best fits your purpose. The goal here is to simplify things for the users, not to confuse them :-)

I also did not cover replication here at all. In fact, this example uses only DFS-N and can even be run without the DFS-R role service installed. We could certainly design a namespace that takes replication into account, but that’s a topic for another blog post…

Links

For more information about DFS-Namespaces, see also the following links from TechNet:

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • Good description. It's lacking in the MS docs.

    BUT - some guidance as to the benefits / drawbacks of each structure would be worth doing.

    Also a tip to only map the DFS levels and not to the Share levels will often improve client performacne due to connectiing to a local DFS root replica rather than to a remote site server.

    Catchya

    Paul