Tell me more ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.
up vote 2 down vote favorite

I have 2 servers with a share, \\servera\share and \\serverb\share. DFS is setup on \\domain\share to point to both machines. A 3rd party replication solution compares \\servera\share to \\serverb\share.

When I turn off serverb \\domain\share is still available, as expected. However \\serverb\share is also still available but shows the contents from servera. This messes up the replication.

Why is this happening and how can I be sure to connect to one specific server or another?

When you turn serverb off you can no longer ping it but you can still connect to the share (but see servera). At no point does the dns for serverb ever point at servera.

share|improve this question
1  
"A 3rd party replication solution compares \\servera\share to \\serverb\share" ... Can you elaborate on this? Why? – Mathias R. Jessen Jul 19 '12 at 10:15
Shouldn't be important but because it tracks history for backup as it syncs while dfs-r doesn't. (In case you don't know, DFS essentially points one windows share at multiple physical servers so the contents needs to be in sync) – JamesRyan Jul 19 '12 at 11:03
I think this is exactly the point of the DFS, to automatically point to the "other" share.. ? – MichelZ Jul 19 '12 at 11:51
@MichelZ - No, the exact point of the DFS namespace is to present a "load-balanced" view of 1 or more Folder Targets, while the point of DFS-R is to keep the target folders' file structure in sync. So, James, you use a 3rd party application to keep the folder targets in Sync, and not DFS-R ? – Mathias R. Jessen Jul 19 '12 at 11:59
2  
Yes, but with automatic failover to another one: technet.microsoft.com/en-us/library/hh341464(WS.10).aspx If a DFS client attempts to access a previously used target, and that target is unavailable, the DFS client works down through its referral list for the next available target. This process is often referred to as link target or root target failover. If the client reaches the end of the referral list (that is, there are no available targets), the DFS client fails the request. However, I'm not sure why the same holds true if he directly goes to \\serverb\share – MichelZ Jul 19 '12 at 12:10
show 4 more comments

3 Answers

up vote 3 down vote accepted
+50

You're seeing the intended behavior of the product. Accessing the DFS root using the domain's name, the "servera" name, or the "serverb" name will all result in the same behavior.

You might consider sharing the folder on "servera" and "serverb" a second time ("\servera\share-x", etc) and using that share name to access the folder with your replication software. Accessing the folder via this "secondary" share name won't cause the DFS client behavior you're seeing (since the "secondary" name of the folder isn't a DFS root or link target).

share|improve this answer
"For root target failover to work correctly, clients must access a domain-based DFS namespace by using the format \\DomainName\RootName, not \\RootServerName\RootName." would imply that it shouldn't do this – JamesRyan Jul 19 '12 at 15:56
I have tried a 2nd share however if it is based on the same folder it behaves in the same way, failing over. Only when based on another folder does it behave normally. Given that users don't know if a share on a server is DFS or not the inconsistency in behavior is pretty counterintuitive and unhelpful if it is deliberate – JamesRyan Jul 19 '12 at 15:58
I would accept this answer, except as it stands the advice doesn't work. I have worked around this in my case bay sharing a parent folder until I can transition the dfsroots away from my content. – JamesRyan Jul 20 '12 at 9:57
I can't reproduce the behavior you're seeing with Windows Server 2003 and Windows Server 2008. In both cases a second share on a folder already shared with DFS always "connects" to the correct server. I'm not sure why / how you're seeing what you are. – Evan Anderson Jul 20 '12 at 11:35
up vote 1 down vote

You could browse to admin shares of the physical disk instead of the actual share... i.e. \\server\d$\some\path\to\dfs\target instead of \\servera\target for replication purposes. Keep in mind... relying on 3rd party solutions for replication can present their own set of headaches.

I think I've run into every possible point of failure for DFS-R (and ntfrs before that), and have never had it successfully keep the peers in proper sync for more than a day or two. (before errors upon errors come up) I can completely understand your frustration and desire to switch to an alternative replication solution. You did make one incorrect assertion however... DFSR does keep backups of files in the dfsrprivate hidden folder... but running through all the logs to figure out which file is which and why it failed to replicate is a nightmare, and there is a maximum size to the "backups" before they are overwritten.

share|improve this answer
Just be sure not to try and fiddle with stuff in the dfs staging folder. – TheCompWiz Jul 20 '12 at 20:43
Yeah I am aware of those folders, I simply wouldn't describe them as a backup. The lack of information from DFS-R is really it's downfall, there is no way to troubleshoot what may be even a minor problem. – JamesRyan Jul 21 '12 at 13:54
up vote 0 down vote

But at all points does the DFS target for servera contain the identical information that serverb does. DFS knows this, and offers you a valid alternative.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.