Blogs

Clearing up a common misconception about DFS namespaces

  • Comments 1
  • Likes

At least once a month a customer asks us whether a namespace can be used to combine the contents of multiple shared folders into a single view. This is a fair interpretation of a namespace, though this is not how a DFS namespace works in Windows Server. Below is an example of one such question, which I really liked because it (a) illustrates how customers sometimes expect a namespace to work and (b) illustrates how a namespace really works. I’m also including the response from our PSS engineer Ned Pyle, who provided a short a helpful explanation.

Customer question:
I set up a domain-based namespace called \\Corp\Data. On the C:\ drive of my root server, I created two shared folders, \\server1\Group1 and \\server1\Group2, and then I created a text file in each of these two shares, one called group1.txt and one called group2.txt. Under this root I created a link called Group Reports and associated the two shared folders as link targets. When I map to the Group Reports folder, I only see one of the text files, usually group1.txt, but sometimes I see group2.txt. I need to be able to see both…I don’t want an “either-or” view. I need the accumulative view. We are planning to create 8 new drives to break up our 2-TB Global Reports share.   I was hoping to use DFS to bring \\Server1\Group1, Group2, Group3, Group4, and Group5 together for users, each of the shares has unique folders we need to combine all these individual shares into one common view.   Looking at some of the help screens it appears I may not be able to do this, but I hope I am just mis-interpreting this is what we have been trying to accomplish with the namespace.

Ned’s reply:
Short answer:  You are seeing expected behavior, and it’s not going to work as you want it to.

Long answer:  What’s actually happening is you’re getting referrals that will connect you to one of two true shares on the same server. When all is said and done, DFS is just a fancy way to simplify a namespace – a client still just ends up using SMB to connect to a single share with a single distinct set of data tree’d from that share. DFS just makes it more ‘seamless’ to the end user what the path is.

If you aren’t doing all this on the same server, you can configure replication and keep the two shares in sync, but that won’t work if the shares on the same server (and doesn’t exactly sound like what you want anyways). As long as you keep mapping different folders on the same server to the same target link, this will happen.

Now, you can use DFS to provide all “group*” folders into a single contiguous space under the root. But it will end up looking like:

\\domain\root\group1  
                     \group2

                      \group3

                     etc…

 

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • I had the same question, thanks.

    So without DFS being my way to go, i still experience the same problem!

    Nothing Windows based that supports a accumulative view of some shares. The best solution i found is using mounts/inodes/symlinks in a Linux samba share.

    Is this the best solution? Can't Windows do this too?

    Details on my case;

    The accumulative share should be read only.

    We have over 20 shares of about 200GB each. All files are categorized in logical folder trees. The same folder names are used over all shares, the only duplicate names that exist are folders. (by design)

    PS;

    A RAID solution is not possible here. Besides making a 10TB* raid that replicates existing shares via a script ofcourse, but that would be overkill and to expensive.

    PS2;

    If not possible now, will the newly designed (and still unreleased) Longhorn filesystem be able to do this?

    Thanks.