0

target:
want to replicate a folder on 2 machines

situation: we have 2 windows 2003 servers (for this purpose) in a domain and each of these servers has 2 network cards; and each server have 2 ips, one on the LAN and one on the internet like:

20.20.0.100, 192.168.0.100

20.20.0.101, 192.168.0.101

problem: when I use DFS Management tool to create a replication between 2 servers it chooses public ips instead of LAN ips; and our LAN is much much faster. how can I tell the DFS Replication to use LAN ip?

Improve this question

3 Answers 3

Reset to default
1

I'm not aware of any configuration parameters for DFS-R to control the interfaces that it binds to, or to influence how it selects the partner interface to route traffic to. Doing a quick search, I'm coming up with this dirty hack from the Microsoft Storage Team blog (albeit from 2006) that indicates that you should use a HOSTS file on each replication set member to influence their name resoultion such that you effectively "force" them to use the private IP addresses.

This is an ugly hack, and I'm typically violently opposed to using HOSTS files. In this case, though, it may well be the only way to accomplish what you're trying to do.

Rather that doing the HOSTS file hack (which, if you do, you should document so that the next guy who works on it knows why it was done) I have one other idea you might try.

Try putting a host route for the other host on each of the DFS-R replication set computers. If it works, make the the route persistent. I'm about 80/20 in thinking this won't work versus that it will, but it's worth a shot:

Member 1: route add 20.20.0.101 mask 255.255.255.255 192.168.0.100

Member 2: route add 20.20.0.100 mask 255.255.255.255 192.168.0.101

That might just work to get that traffic flowing over the private network. (If I wasn't under orders from The Wife(tm) to get some house work done this morning I'd give it a try myself and tell you if it works... If she catches me writing on Server Fault this morning it will be bad... >smile<)

Improve this answer
0

This is an assumption which will require some investigation on your part, but here's my thought:

DFS Root and Link targets are identified by host name (although it is possible to create link targets based on ip address instead of host name), those host names are resolved using DNS, if you configure the NIC with the public ip address to not register with DNS (which is how it really should be configured, anyway) then only the internal ip address of the NIC on the LAN will be resolved for the host name of each server, which should force the replication to use the LAN NIC.

This seems to be pretty close to the solution Evan referenced but without the need to use hosts files or static routes on each host.

Improve this answer
3
  • It's certainly possible that he wants the public NIC's address registered in DNS for other reasons. If not, though, then this is totally viable. I'd definitely prefer something simple to something ugly like HOSTS files or static routes.
    – Evan Anderson
    Dec 20, 2009 at 19:03
  • Thanks for your answer. In DFS Replication documentations it is strictly written that nodes need to be in a domain. So they can not be referred to by ip in DFS Replication.
    – Kaveh Shahbazian
    Dec 20, 2009 at 22:30
  • I think you misunderstood me. What I mean is that ultimately DFS replication is going to occur between the ip addresses of the hosts that hold the DFS Root and Link targets. If you make sure that only the host names associated to the internal NIC are registered in DNS then when those host names are resolved to their ip address, they'll be resolved to the internal ip address and this may force the replication to use the LAN NIC.
    – joeqwerty
    Dec 20, 2009 at 22:57
0

I found a way to achieve this!

I am synching two servers, S1 (Windows Server 2008) and S2 (Windows Server 2008 R2), using DFSR.

The way I did it was to change the dNSHostName attribute for each Server in Active Directory Users and Computers, to one on the second network card, eg, s1.system.int and s2.system.int.

It seems DFSR looks at this attribute first before synching, and voila!

However, I just rebooted and had to set the setting again and don't know yet how to make it stick in AD.

I also don't know what else uses this dNSHostName attribute, so be warned!

Improve this answer

You must log in to answer this question.