Using DFS roots as shared folders

dfsdistributed-filesystemsnetwork-shareserver-message-blockwindows-server-2008

I am curious if I can use DFS roots as shared folders without using any DFS links.

Some background: I like the idea of using DFS for name abstraction. By using domain-based namespaces, I can abstract away server name reference and have the flexibility of relocating shared folders to different machines in the future. However, as my network is small (~10 machines with one one AD server), DFS is somewhat overkill as it generally introduces too many level of indirection: DFS roots which contain folder links which point to actual SMB shares. While it makes sense if your SMB shared are distributed across different machine, it doesn't seem so when everything is on one machine. You end up have both DFS roots and SMB folders mapped one-to-one on the same machine.

Nevertheless, it looks like DFS roots are just normal folders. Instead of putting DFS links there, I can put files and documents in them. Thus, I wonder if it is possible to use DFS roots as shared folders, without creating DFS links? What are the shortcomings to this approach? Or perhaps you could also point out any point that I might misunderstood.

Best Answer

You absolutely can populate the root of a DFS namespace with content. There's nothing stopping you and it'll work fine.

In Windows 2008 DFS you can selectively disable root referrals so the problematic issues associated with partial replicas that existed in Windows 2003 DFS are removed.

Background for an unlucky soul who might still be using Windows 2003 DFS and who comes upon this post: In Windows 2003 DFS the main reason for not populating the root of a DFS namespace with content was because you couldn't disable referrals to incomplete replicas. Imagine a scenario in which you create a DFS root, populate it with 100GB of content, create a second root target, and enable replication. Referrals to the new root target, which isn't fully replicated, can't be prevented (unlike referrals to links within the root, which can be disabled on a link-for-link basis).

Related Solutions

Windows – Long pause when accessing DFS namespace

Well, we finally appear to have resolved this issue in our environment. For the benefits of others, here's what we discovered and how we fixed the problem:

To try and gain further insight into what was occurring before/during/after the delays we used Wireshark on a client machine to capture/analyse network traffic whilst that client attempted to access a DFS share.

These captures showed something strange: whenever the delay occurred, in between the DFS request being sent from the client to a DC, and the referral to a DFS root server coming back from the DC to the client, the DC was sending out several broadcast name lookups to the network.

Firstly, the DC would broadcast a NetBIOS lookup for DOMAIN (where DOMAIN is our pre-Windows 2000 Active Directory domain name). A few seconds later, it would broadcast a LLMNR lookup for DOMAIN. This would be followed by yet another broadcast NetBios lookup for DOMAIN. After these three lookups had been broadcast (and I assume timed out) the DC would finally respond to the client with a (correct) referral to a DFS root server.

These broadcast name lookups for DOMAIN were only being sent when the long delay opening a DFS share occurred, and we could clearly see from the Wireshark capture that the DC wasn't returning a referral to a DFS root server until all three lookups been sent (and ~7 seconds passed). So, these broadcast name lookups were pretty obviously the cause of our delays.

Now that we knew what the problem was, we started trying to figure out why these broadcast name lookups were occurring. After a bit more Googling and some trial-and-error, we found our answer: we hadn't set the DfsDnsConfig registry key on our domain controllers to 1, as is required when using DFS in a DNS-only environment.

When we originally setup DFS in our enviroment we did read the various articles about how to configure DFS for a DNS-only environment (e.g. Microsoft KB244380 and others) and were aware of this registry key, but had misintepreted the instructions on when/how to use it.

KB244380 says:

The DFSDnsConfig registry key must be added to each server that will participate in the DFS namespace for all computers to understand fully qualified names.

We thought this meant that the registry key has to be set on the DFS namespace servers only, not realising that it was also required on the domain controllers. After we set DfsDnsConfig to 1 on our domain controllers (and restarted the "DFS Namespace" service), the problem vanished.

Obviously we're happy with this outcome, but I would add that I'm still not 100% convinced that this is our only problem - I wonder if adding DfsDnsConfig=1 to our DCs has only worked around the problem, rather than solving it. I can't figure out why the DCs would be trying to lookup DOMAIN (the domain name itself, rather than a server in the domain) during the DFS referral process, even in a non-DNS-only environment, and I also know I haven't set DfsDnsConfig=1 on domain controllers in other (admittedly much smaller / simpler) DNS-only environments and haven't had the same issue. Still, we've solved our problem so we are happy.

I hope this is helpful to the others who are experiencing a similar issue - and thanks again to those that offered suggestions along the way.

Windows – Is it possible to have simultaneous ‘net use’ connections established to two shared folders on the same remote machine (avoiding error 1219)

Using FQDN, hostname and IP address, you can have three connections with different credentials to the same server.

E.g.:

net use \\pc1.domain.net\Shared\DirA /user:user_of_DirA@domain.net pwd1
net use \\pc1\Shared\DirB /user:user_of_DirB@domain.net pwd2
net use \\1.1.1.1\Shared\DirC /user:user_of_DirC@domain.net pwd3

(I've always entered password as the last parameter)

Best Answer

Related Solutions

Windows – Long pause when accessing DFS namespace

Windows – Is it possible to have simultaneous ‘net use’ connections established to two shared folders on the same remote machine (avoiding error 1219)

Related Topic