3

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.

Improve this question
9
  • 1
    "A 3rd party replication solution compares \\servera\share to \\serverb\share" ... Can you elaborate on this? Why?
    – Mathias R. Jessen
    Jul 19, 2012 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, 2012 at 11:03
  • I think this is exactly the point of the DFS, to automatically point to the "other" share.. ?
    – MichelZ
    Jul 19, 2012 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, 2012 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, 2012 at 12:10

3 Answers 3

Reset to default
4
+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).

Improve this answer
4
  • "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, 2012 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, 2012 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, 2012 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, 2012 at 11:35
1

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.

Improve this answer
2
  • Just be sure not to try and fiddle with stuff in the dfs staging folder.
    – TheCompWiz
    Jul 20, 2012 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, 2012 at 13:54
0

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.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .