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.
A standalone DFS namespace cannot participate in DFS-R (If it is not a member of an AD domain).
Clarification:
DFS can utilize two methods to replicate data:
- DFS-R - newer and used for Win2k8, Win2k8 R2, & Win2k3 R2
- FRS - used for older versions of Windows.
If the server you are setting up the namespace on, and the target servers are members of an AD domain then, Yes you can use DFS replication.
If you do not have Domain Admin rights you will need to be delegated permissions to create replication groups:
Detailed delegation
Grant permissions to create a replication group
This action is one of the two delegation actions that are available in DFS Management. To manually perform this action in Active Directory Users and Computers, follow these steps:
- Start Active Directory Users and Computers.
- Right-click the Domain\System\DFSR-GlobalSettings node, and then click Properties.
- Click the Security tab, and then click Advanced.
- Grant the desired users or groups the Create All Child objects permission, and then click to select This object only in the Apply onto area.
Or alternatively you could ask to be set to control all Replication groups:
Control of all replication groups
To grant a user control of all existing and future replication groups in a domain, follow these steps:
- Start Active Directory Users and Computers.
- Right-click the following node, and then click Properties:
- Domain\System\DFSR-GlobalSettings
- Click the Security tab, and then click Advanced.
- Grant the desired users or groups the Full Control permission, and then click to select This object and all child objects in the Apply onto area.
- Add the users or groups to each member's local Administrators group. Or, grant the Full Control permission for the computer objects of each server in the replication groups.
Steps were taking from KB911604
Best Answer
I managed to resolve this.
Firstly, I created the shares in the namespace.
Secondly, In my single replication group I started creating new Replicated Folders.
I pointed the replicated folder to the root folder of my share on the drive of each server.
After creating a standalone Target in the Namespace, and a standalone Replicated Folder, I could then link them together by right clicking on my Replicated Folder under the Replication section, choose share and publish to Namespace (it actually auto-detected the shares for me on both servers at this stage).
At this point, the Replicated Folder and Target Folder were linked as if I had done it the reverse way around.