Re: Metaphysical question about DFS
- From: "Anthony" <anthony.spam@xxxxxxxxxxxxxx>
- Date: Wed, 4 Oct 2006 21:57:03 +0100
I agree, the advice is flawed. If the locations are truly connected as a
single site it would not matter which DFS replica was selected. If it does
matter, then by definition it is not one site,
Anthony
"steve_t" <stevet@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:589EA900-1632-4869-BE5D-60F1990150C3@xxxxxxxxxxxxxxxx
It's been quite some time since I played w/DFS, but from what I've found,
it
appears that you are correct regarding the site designation - that is,
clients will select any available DFS server in the site, and since all of
your locations will be in a single site, there doesn't appear to be any
way
to link to a subnet instead of a site. The following is from "How DFS
Works":
http://technet2.microsoft.com/WindowsServer/en/library/a9096e88-1634-4da6-b820-537341d349061033.mspx?mfr=true
How Target Selection Works
When a client computer attempts to access a root or link in the namespace,
a
domain controller or root server provides a referral to the client. The
referral contains a list of target servers, and this list is sorted
according
to the currently configured target selection method.
Default Target Selection
By default, DFS places target servers in the referral in the following
order:
1. Targets in the same site as the client are listed in random order at
the
top of the referral.
2. Targets outside of the client's site are listed in random order.
The question I would ask is what benefit will your organization gain by
placing all of your locations into a single AD site? What justification
did
the consultant give for making this change to your infrastructure?
Steve
"ThOF" wrote:
Hi all the group;
I've a a little "complex" question about DFS working in Windows 2003 and
I'd
need your help and comments about it
At present, in my enterprise, we work with a network topology divided in
five sites, everyone of them with its own GC/DC (one site can be one main
office or branch-office)
A consultant firm has come to take a look to our present situation and
they
have proposed to merge all the sites in only one new site, due to the
fact
that our WAN links are very fast (10 -100 Mpbs). So, by performing that
change, we would have all the GC/DCs logically located in the same site
(of
course, the physical location won't change).
In fact, I've to confirm that our WAN links are quite good (fast and
reliable) as we work with MPLS technologie and fiber optic from end to
end
The thing is, we have already implemented DFS some months ago, so access
to
shared resources is transparent to the users, no matter their physical
location (the user will always access to, for example,
\\mycorporation.com\Data no matter they are working today in Madrid or
tomorrow in Barcelona, because the XP clients will always connect to a
local
DFS server -target server- located in the same site as the user is.
This is to say that every main office/branch-office will keep having its
own
subnet in 'Active Directory & Services', so this is not going to change
(for
example, Barcelona offices will keep its 192.168.1.0/24 subnet range,
Madrid
will continue having 192.168.2.0/24, and so on)
What we're afraid is that, when we merge all the sites into the new one,
all
the network subnets will belong, of course, to the same site
(192.168.1.0/24, 192.168.2.0/24, ...); in other words, all the network
subnets will be preserved and they will belong to the new 'MyEnterprise'
site but... what about DFS behaviour from that moment on?
I've readed that, when working with DFS, the DFS client -this is, the
Windows XP PC- when starting the network session and logging into the
domain, it will always look first for a target DFS server located in the
same site as the user is (based in the pair IP-subnet) but nowhere in the
FAQs nor white papers it is specified anything about looking first one
target server in the same SUBNET, too (I mean, this is not clear if the
DFS
client only looks first for a target server in the same site OR also in
the
same subnet)
For example, if the client PC has an 192.168.1.25 IP address, then I'm
not
very sure about the DFS client looking first for a target server also
located in the 192.168.1.0/24 subnet or, on the contrary, it will only
search for any alive DFS server no matter the client IP matches or not)
If the last happens, it could occur that, for example, an user located in
Madrid would sometimes/always connect against a DFS server in Barcelona,
or
vice versa
We're a little worried about this possible issue, because we don't want
that, when merging sites, the user DFS experience gets worse (OK, our WAN
lines can be fast enough, but you will have to agree with me that there
is
no point in the users connecting to a "remote" server when there is
another
one located locally and where they can connect to with a speed of 1 Gpbs,
so
is not the desired situacion)
I've also readed that starting with Windows 2K3 SP1, new DFS features and
improvements have been added (for example, more available options when
using
the 'dfsutil' tool). Now it is possible to define some kind of
"priority",
so we can define an ordered list with the preferred DFS servers in one
site
(high, low or normal priority) but I'm afraid this new stuff wouldn't
solve
our problem, because as all the servers will be located in the same site,
defining priorities won't help (if I define the Barcelona server as the
one
with the highest priority, then I guess it is for sure that all the rest
of
clients located in remote offices will always connect to Barcelona, which
is
not desired)
Well, I don't know if I explained myself in a clear way. I hope so.
Any feedback or comments about the subject will be highly appreciated.
Regards and many thanks in advance.
.
- References:
- Metaphysical question about DFS
- From: ThOF
- RE: Metaphysical question about DFS
- From: steve_t
- Metaphysical question about DFS
- Prev by Date: Re: World Wide Web Publishing service
- Next by Date: Re: 30 network drive
- Previous by thread: RE: Metaphysical question about DFS
- Next by thread: Re: Help - User permission logon
- Index(es):
Relevant Pages
|
