Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top


  • Windows 2008 Server at Data Center 1 - call it Server A

  • Another Windows 2008 Server at DC 2, call it Server B

  • Fiber link dynamic IP client, connected via VPN to Server B, call it Client A

Client A wants to see shared drives from Server A. Server A can't allow everyone through the firewall, so it is configured for Server B to access it's shared folders, via firewall hole. Idea is to map Server As drives on Server B, then re-share them for Client A.

We know that this is not possible per se. So, I tried junction points, they don't work with shared drives. I tried DFS, and found out that:

When browsing a folder in the namespace, users are not aware that the folder is hosted by multiple servers. When a user opens the folder, the client computer is automatically referred to a server on its site. If no same-site servers are available, you can configure the namespace to refer the client to a server that has the lowest connection cost as defined in AD DS.

Is there any way to get DFS to re-share a network drive?

I am grasping at straws here, and am referring to the last part of above quoted paragraph, how should I configure the DFS mount point so that it doesn't REDIRECT, but RE-SHARE?


Server B can't store complete copy of the data from Server A, since server a is collecting data at a rate of 100GB/day.

share|improve this question
Dial-up fiber? Huh?? Anyways, start accepting answers before asking more – pauska Feb 29 '12 at 17:42
I don't understand what you're asking in your last sentence. – joeqwerty Feb 29 '12 at 17:49
@joeqwerty what about now? – Daniel Mošmondor Feb 29 '12 at 17:50

In light of your most recent update and comments, I think that your best bet is to allow connections to Server A via VPN access directly. It doesn't make a lot of sense to involve Server B in the mix at all.

There are packages in the Samba 4 release that can potentially do SMB proxing, but I haven't heard of anyone using them with any level of success. You certainly can't do this with any native Windows tool.

In light of your updates, this isn't an answer to your question, but it's still good knowledge nonetheless, so I'll leave it.

There are two different DFS technologies: Namespaces and Replication.


A DFS Namespace allows for multiple file-servers to have the same UNC. For example \\domain\share could be backed by \\server1\share and \\server2\share. The users have no idea, they just connect to \\domain\share and are transparently redirected to one of the backing file servers.

You can define what server users are connected to by a number of ways. One of the most common is by what AD Site they are in. If you want your users to access the share on either server transparently by \\domain\share, then you want to use DFS Namespaces, but this isn't a complete answer to your problem.


DFS-R allows for files to replicated (go figure) across multiple servers. If you had \\server1\share and \\server2\share in a 2-way replication group, then any changes to either share will propagate to the other. If you want your two servers to have the same contents, then you will use this. It can be used independently of a DFS Namespace, but many times it is used in conjunction with it for seamless access to resources based on AD Site or for redundancy/loadbalancing in general.

You're not "resharing" like your question asks how to do, but rather you're keeping an actual copy of everything in both places, including permissions. This is, at a minimum, what you need to accomplish what you're asking.

If you choose to use DFS Namespaces in addition to DFR-R, then that's up to you and is a design decision. It will certainly simplify access from your users, but is not completely necessary.

tl;dr Use DFS-R and maybe DFS Namespaces, but definitely DFS-R.

Edit: Since it seems that my text wasn't understood clearly, here's a nice picture


share|improve this answer
unfortunately, that doesn't solve my problem, since Mosh can't ever access Hetzner directly, and Replication isn't a solution since there is too much data to move around. – Daniel Mošmondor Feb 29 '12 at 18:15
@DanielMošmondor After the initial seed, it uses compression and only transfers changed data. You can use robocopy to make a seed of the data initially. How frequently do the files change and how large are the changes? I'm afraid you're not going to find any better solution using SMB. You could do some NFS cross-mounting, but that's a house of card and will be miserable when it fails. Not to mention NFS on Windows is trash at best. – MDMarra Feb 29 '12 at 18:26
Also, I have no idea what Mosh and Hetzner are, but if I understood your question correctly, access isn't a problem. The only (potential) problem is the replication across the firewall. Since Client A can connect to Server B, and Server A replicates with Server B, Client A never needs to communicate directly with Server A. – MDMarra Feb 29 '12 at 18:29
I can't use replication. Period. Hetzner collects several 100GB of data daily, and moving it out isn't feasible, but only upon request. – Daniel Mošmondor Feb 29 '12 at 18:48
@DanielMošmondor That's usually the kind of thing that you know...write in your question. A design constraint like that is kind of a big deal. – MDMarra Feb 29 '12 at 18:49

Your Answer


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.