Dfs, FRS, and site awareness

[Fari Fuladi]

Hi there,

I am using the Dfs+FRS services of W2K server, but the
results that I am getting is not quite consistent with the
Dfs documentation. I am wondering if anyone has
experienced this problem before:

My setup includes 2 sites:
site 1: DC and foo (both W2K servers)
site 2: bar_1 and bar_2 (W2K servers)

The Dfs root is hosted by the domain controller, and my
only Dfs Link is set up such that it points to physical
locations on servers foo (Primary), bar_1. So, the virtual
path looks something like this:
\\domain_name\dfs_root\dfs_link

In happy day scenarios all seems to be fine, and
replication happens as expected. As soon as a file is
modified on one share, it is replicated almost in real-
time.

However, the results are not as pleasant when replication
falls behind. I stress the CPU on server bar_1 (site 2),
and modify a file on its share. Since the CPU on bar_1 is
really stressed, it'll be a while before the modified file
is replicated to the share on foo (site 1). Since the DC
is on the same site as foo (has the old copy), if I try to
access the file from the DC using the virtual path, I
expect to see the old copy of the file. In otherwords,
when I use Windows Explorer on the domain controller to
access
\\domain_name\dfs_root\dfs_link\filename
I should see the old copy of the file. But, that's not the
result that I get. I see the new file which I can only
assume that it fetches from across the newwork from bar_1
(on site 2) because the share on foo does not have the new
copy of the file yet. Well, this violates Dfs
documentation.

And, if I try to access the same file from bar_2 (site 2)
using the virtual path, I should get the new copy as bar_2
is located on the same site as bar_1. But, it gives me
back the old copy. This is a very weired behavior that I
was not expecting.

I should mention again that I use explorer to access the
files, and I don't know if it's not an appropriate tool to
access the files in these scenarios.


Your comments/suggestions is appreciated.

thanks,

Fari

 

[Brendon Rogers]

From your servers map drives to \\domain_name\dfs_root

Then open Windows Explorer and right-click the Dfs_link, Properties then the
Dfs tab. This will tell you which replica you are connected to.

Dfs is site-aware, so you should check your subnet assignments to your sites
in Active Directory Sites and Services

 

[Fari Fuladi]

Thanks for the suggestion. However, there remains one
issue which is related to having two or more replicas
hosted by servers that are located on the same site. It
seems to me that in scenarios like this where there is
more than one replica in a given site Dfs chooses
the "closest" replica on a random basis; this may be
because it basically has two replicas to choose from.

For example, I have the following Dfs links:

\\domain\dfs_root\foo1
that physically maps to
\\server1\J\f1
and
\\san1\J\f1
and
\\server2\J\f2

The other Dfs link is
\\doman\dfs_root\foo2
that physically maps to
\\server1\J\f2
and
\\san1\J\f2
and
\\server2\J\f2

where server1 and san are on the same site, and server2 is
on a different site.

Then, On server1, I map network drives to
\\domain\dfs_root\foo1 and \\domain\dfs_root\foo2, and
check the properties in Windows Explorer - Dfs tab, foo1
indicates that it's pointing to server1 and foo2 shows
that it's pointing to san.

What's also worth noting is that if you map the network
drives on san, you will get results that are different for
some of the replcas that you may have.

Therefore, behavior like this leads me to believe that Dfs
uses a "random" selection algorithm where there is more
than one replica in a given site i.e. for some replica it
uses the mapping to server1 while for others it points to
the physical mapping on the san.

I'd appreciate if you have any inputs or comments.

thanks,

Fari