Hi,
At the moment the network runs W2KSP3 and upgrading the complete network
(trust me its large, maybe not as large as other networks, but its large) to
W2K3 is not an option, at least not now. I'm aware of the "shortcommings" of
the W2K DFS and the advantages of W2K3 DFS. The least-cost site mechanism
would be the solution, but for now I was hoping to be able to configure the
W2K (DFS) SYSVOL locator like the LDAP server locator (e.g. authenticating
DC) (registering the domain-wide SRV RRs of the HUB DCs). OK, it is not that
pretty when a client uses a DFS referral in another branch office, but you
really get screwed if the network is not fully routed. Because of security
policies the branch offices can only communicate with central sites and
cannot communicate with other branch offices.
In such a situation, when the clients local DCs are unavailable, the client
tries to use some referral in another site (branch office) but it cannot
communicate with the SYSVOL hosting server. ;-((
QUOTE FROM DEAN
###############
1. Its default referral mode is "same site" which is downlevel compatible
and provides referrals to targets in the same site as the calling client
followed by a random list of ALL other targets regardless of site cost
2. "Nearest site" mode (configured via DFSUTIL I believe), returns same site
targets first followed by next nearest site targets followed by a random
list of ALL other targets, again, regardless of site cost
###############
I have never tested it but I have been wondering if the default domain DFS
in W2K3 (SYSVOL) needed to be configured with DFSUTIL for the "Nearest site"
mode. Is it true that the W2K3 domain DFS (SYSVOL) is default configured
with the first option mentioned by Dean?
To use the nearest site mode you need a W2K3 DC as the ISTG! (which will be
automatically assigned to the W2K3 DC if one exists in a W2K site)
For a custom DFS i created the DFSUTIL displays the following:
{dfsutil /root:"\\WINDOWS-INFRA.LAN\DFSROOTSHARE" /SiteCosting /Display
/Verb
ose > DFS-SYSVOL.TXT}
#####OUTPUT#####
Microsoft(R) Windows(TM) Dfs Utility Version 4.0
Copyright (C) Microsoft Corporation 1991-2001. All Rights Reserved.
Namespace \\WINDOWS-INFRA.LAN\DFSROOTSHARE: Cost-based Site Selection
DISABLED
Done processing this command.
#####OUTPUT#####
For the default domain DFS (SYSVOL)the DFSUTIL displays the following:
{dfsutil /root:"\\WINDOWS-INFRA\SYSVOL" /SiteCosting /Display /Verbose >
DFS-SYSVOL.TXT}
#####OUTPUT#####
Microsoft(R) Windows(TM) Dfs Utility Version 4.0
Copyright (C) Microsoft Corporation 1991-2001. All Rights Reserved.
System error 2 has occurred.
The system cannot find the file specified.
Done processing this command.
#####OUTPUT#####
The error "The system cannot find the file specified." is generated because
the SYSVOL root does not exist in the container
[DOMAIN\System\DFS-Configuration
So now I'm wondering if the "Cost-based Site Selection" option for DFS is
enabled/disabled in W2K3?
Check out the following (found it in TECHNET)
>>>>1<<<<
Restricted same-site target selection
By using Dfsutil.exe /InSite parameter, you can limit client access to only
those targets that are in the same site as the client. You enable this
feature on a DFS root or on individual links in the namespace. If you enable
this feature on the root, referrals for any link in the namespace return
only targets that are in the same site as the client. If this functionality
is disabled on the root, the individual settings on each link are used. When
using this feature, plan to have at least one target (or two targets, for
fault tolerance) in every site, and plan to monitor servers to make sure
they are online and accessible. If no same-site targets exist, clients in
that site are denied access to the data in the namespace.
>>>>1<<<<
>>>>2<<<<
Least expensive target selection
If you create a stand-alone or domain-based DFS root on a server running
Windows Server 2003, and the domain controller acting as the Intersite
Topology Generator
Intersite Topology Generator
An Active Directory process that runs on one domain controller in a site
that considers the cost of intersite connections, checks if previously
available domain controllers are no longer available, and checks if new
domain controllers have been added. The Knowledge Consistency Checker (KCC)
process then updates the intersite replication topology accordingly.(ISTG)
is also running Windows Server 2003, you can use the /SiteCosting parameter
in Dfsutil.exe to enable DFS to choose an alternate target based on
connection cost if no same-site targets are available. Windows Server 2003
uses the site and costing information in Active Directory to determine
whether sites are linked by inexpensive, high-speed links or by expensive
WAN links.
Site costing is not available in the following situations:
When a stand-alone DFS namespace is hosted on a server that is not part of
any domain.
When the closest domain controller acting as the ISTG is running Windows
2000 Server.
(This situation occurs when there are only domain controllers running
Windows 2000 Server in the site of the DFS root server, or when there are no
domain controllers in the site of the DFS root server and the closest site
with at least one domain controller has only Windows 2000 Server domain
controllers in that site. The closest site is defined in Active Directory.)
If you plan to enable site costing, review the following:
You can enable site costing on a per-namespace basis.
When the domain controller acting as the ISTG is running Windows 2000
Server, DFS uses the default target selection, described earlier in this
section. If domain controllers running Windows 2000 Server and Windows
Server 2003 exist in a site, the ISTG role is automatically given to the
domain controller running Windows Server 2003.
>>>>2<<<<
So, anyone?
Regards,
Jorge
-----Original Message-----
From: [EMAIL PROTECTED]
To: AD mailing list (Send)
Sent: 4/20/2004 1:52 AM
Subject: RE: [ActiveDir] AD Sites and SYSVOL
As little more than an FYI, the last time I reviewed 2003's DFS referral
behavior, it did indeed support a "nearest site" mechanism but there
were 2 caveats:
1. Its default referral mode is "same site" which is downlevel
compatible and provides referrals to targets in the same site as the
calling client followed by a random list of ALL other targets regardless
of site cost
2. "Nearest site" mode (configured via DFSUTIL I believe), returns same
site targets first followed by next nearest site targets followed by a
random list of ALL other targets, again, regardless of site cost
PS - During those tests, the clients did indeed use SYSVOL from the
authenticating DC but, as I mentioned, that was some time ago. With any
luck, the behavior persists.
PPS - For the sake of completeness, there's also a 3rd referral behavior
known as "same site" which seems fairly self explanatory.
Deano
--
Dean Wells
MSEtechnology
* Tel: +1 (954) 501-4307
* Email: [EMAIL PROTECTED]
http://msetechnology.com <http://msetechnology.com/>
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Grillenmeier,
Guido
Sent: Monday, April 19, 2004 7:36 PM
To: [EMAIL PROTECTED]
Subject: RE: [ActiveDir] AD Sites and SYSVOL
actually, the SYSVOL folder is "just another" share redirected via DFS
(which also allows the folder to be replicated via FRS...).
I've never really thought about it, but Jorge's comment makes sense, as
in a Win2k DFS hierarchy the client will receive a list of link-targets
from a DFS server (every DC is a DFS server for SYSVOL) listing the
links of the same site as the client at the top of the list - any other
DFS link-targets in AD will be randomly ordered (was changed in Win2k3).
The DFS client would then check the list from the top until it finds an
available target - usually the one in the same site as the client.
In the example given, there are no DFS link-targets (SYSVOL in this
case) available in a site of the client, so that it would be natural to
choose any target, i.e. any DC to access SYSVOL (even if a specific DC
had been found to authenticate the user/machine). I guess everyone
expects the client to use the same DC as the one found in DNS for
authentication - would be worth a test to see if this is really the
case. If you've already tested this, it would be good to hear some more
about it.
If you have a Win2k3 DFS server (or DC, once the domain is upgraded),
the list returned from the DFS server still lists the links of the same
site as the client at the top of the list, but then lists the other DFS
links in an order that respects the site-link costs from the client to
the other link targets when adding the targets to the list... So that
would mostly solve the problem for you, at least in a star-toplology -
but this shouldn't be your main driver to upgrade to 2003... ;-)
/Guido
_____
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Montag, 19. April 2004 12:01
To: [EMAIL PROTECTED]
Subject: RE: [ActiveDir] AD Sites and SYSVOL
The DC locator process is the job of DNS. Your zone records will contain
the site-wide and domain-wide list of Domain Controllers. When a client
tries to contact a DC, it looks first of all at the site-wide list in
DNS and tries to contact a DC in it's own site. If this fails it will
select one at random from the domain-wide list.
What is required here is some DNS tinkering, you need to manually delete
the remote DC records from the domain-wide list on the branch office DNS
server.
eg
Main Site DNS server:
Site-wide list contains SRV records for DC's in the main site
Domain-wide list contains SRV records for every DC in the domain
Branch DNS server 1:
Site-wide list contains SRV records for DC's in branch site 1
Domain-wide list contains SRV records for every DC in site 1 and the
main site
Branch DNS server 2:
Site-wide list contains SRV records for DC's in branch site 2
Domain-wide list contains SRV records for every DC in site 2 and the
main site
With this scenario, clients in the remote sites can only contact DC's in
their own site or in the main site, not in another branch site which I
think is what you are after.
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jorge de
Almeida Pinto
Sent: 19 April 2004 07:50
To: [EMAIL PROTECTED]
Subject: [ActiveDir] AD Sites and SYSVOL
Hi Everyone,
In a large AD network (W2K SP3 + hotfixes) only the HUB DCs register the
domain-specific SRV RRs and all DCs register the site-specific SRV RRs.
When all DCs in a site fail the HUB DCs are contacted. Works as
expected, at least for AD info. For SYSVOL info this does not work. When
all DCs in a site fail the client enumerates all DCs that host the
SYSVOL and it picks the first DC in the list (which is randomly
created).
Is there any way to configure DCs so that the following situation exist:
* All DCs provide SYSVOL info for the clients in their respective site
* Only the HUB DCs provide SYSVOL info to clients in a specific site
when all the DCs in that site are unavailable
Any comment on this appreciated
Thanx!
Regards,
Jorge
Met vriendelijke groet / Kind regards,
Jorge de Almeida Pinto
Infrastructure Consultant
__________________________________________
<<...OLE_Obj...>>
LogicaCMG Nederland B.V. (BU SD/AT)
Division Industry, Distribution and Transport (ID&T)
Kennedyplein 248, 5611 ZT, Eindhoven
* Postbus 7089
5605 JB Eindhoven
* Tel : +31-(0)40-2957777
* Fax : +31-(0)40-2957709
* Mobile : +31-(0)6-29067977
* E-mail : [EMAIL PROTECTED]
" < <http://www.logicacmg.com/> http://www.logicacmg.com/> -
Solutions that matter -
This e-mail and any attachment is for authorised use by the intended
recipient(s) only. It may contain proprietary material, confidential
information and/or be subject to legal privilege. It should not be
copied, disclosed to, retained or used by, any other party. If you are
not an intended recipient then please promptly delete this e-mail and
any attachment and all copies and inform the sender. Thank you.
This e-mail and any attachment is for authorised use by the intended recipient(s)
only. It may contain proprietary material, confidential information and/or be subject
to legal privilege. It should not be copied, disclosed to, retained or used by, any
other party. If you are not an intended recipient then please promptly delete this
e-mail and any attachment and all copies and inform the sender. Thank you.
List info : http://www.activedir.org/mail_list.htm
List FAQ : http://www.activedir.org/list_faq.htm
List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
