Can you reset a client connecting to a remote Site DC back to it's

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hi,

Two part question:

In W2K AD and I expect W2003 AD, a client computer when logging in tries to
use a local Site DC for authentication. If none, is available, how does it
determine which DC it should authenticate to? The following article
explains the process but I wonder if it is completely correct:

http://www.windowsitpro.com/Windows/Article/ArticleID/37935/37935.html

Our experience has found that the DC's selected is not the fastest
responding (following network topology). I've read various articles, but
still not clear as to how that DC is selected. E.g. is it taking the first
15 DC, in DNS, based on alphabetical order, to ping, to see which one is the
closest? If so, is there a way to change this mechanism?

Once a client has information about which DC it is using,

how long is it cached?
does a reboot clear the cache? If not, is there a way to force a client the
next time the user logs in, to go and validate if a DC is available in the
Site?

Thanks for any input in advance,

Ed
 
Ed,

I suppose you could weight the DCs in the DNS to set up a preferential order
for their application but I am not completely sure if this would have the
unintended effect of overriding the "site stickiness". You would want to
ensure that, when available, the local DCs would be used first. This could
be effected through very careful planning.

As to the cache length, this would be only tied to the local DNS cache as it
would be queried to determine the local DC and the next ones to query.
 
Ryan,

Thanks for responding, but your response doesn't answer the questions.

I can share new info, that an article talks about 100ms being the max wait
time for DC's to respond within the Site for netlogon. have you heard this?
After that it looks at the generic DNS service records under the _tcp area to
find a DC.

However, if the local Site DC's don't respond within 100ms, but responds
before the remote DC's respond - does it still take the local DC for
authentication?

Also - does the 100ms include latency time or is it pure time from the time
the packet leaves the client?

Finally - going back to the original post - is there a way to force a client
to re-point to a local DC, without a cold reboot or logoff?

Ed
 
1. I am not 100% sure whether it will stop listening for timed out LDAP
pings. Generally, though, if it hasn't responded in 100ms, you have other
problems and really don't want traffic there anyway. Another server would
be more stable, even if it has slower access times.

2. The 100ms is based on the client's timer and does not take latency into
account.

3. When a workstation authenticates, it is not maintaining a session open
with the server constantly. The next time it needs to reference the AD or
generate a token, it will query the DNS again and start the process over.

Hope this helps.
 
Hi Ryan,

If I understand right, you are suggesting that if a DC does not get back to
a client request within 100ms, that you don't want traffic there. So - for
example, a frame/relay T1 link has a latency of 80 - 120ms on it's own.
Therefore, it would always not log onto the AD Site where it's subnet is
mapped to?

On note 2: You mentioned it looks up DNS everytime it needs to go back to a
DC. My understanding is quite different, otherwise everytime it went to do
any LDAP query (e.g. look up the GAL in Outlook), it would then do a DNS
lookup first to find which DC to go to?

I take it that no one know how to re-point a client PC back to it's home DC
for authentication without a reboot - unless your point 2 applies for all DC
access - everytime.

Ed
 
Once a client has information about which DC it is using,
how long is it cached?

does a reboot clear the cache?
Click to expand...

No, it's stored in the registry. Only if the DCs in the site don't respond
in a timely fashion does the locator start from scratch.

If not, is there a way to force a client the next time the user logs in,
to go and validate if a DC is available in the Site?
Click to expand...

The client's site information is stored in a dynamic key in the registry:
-- HKLM\ SYSTEM\ CurrentControlSet\ Services\ Netlogon\ Parameters\
DynamicSiteName


You can override this with this key to always specify a site:
-- HKLM\ SYSTEM\ CurrentControlSet\ Services\ Netlogon\ Parameters\
SiteName


You *should* not edit the dynamic value; override using the static value.

More info here:
--
http://www.microsoft.com/resources/...it/en-us/distrib/dsbc_nar_jqiy.asp?frame=true


--

Paul Williams

http://www.msresource.net/
http://forums.msresource.net/

Hi,

Two part question:

In W2K AD and I expect W2003 AD, a client computer when logging in tries to
use a local Site DC for authentication. If none, is available, how does it
determine which DC it should authenticate to? The following article
explains the process but I wonder if it is completely correct:

http://www.windowsitpro.com/Windows/Article/ArticleID/37935/37935.html

Our experience has found that the DC's selected is not the fastest
responding (following network topology). I've read various articles, but
still not clear as to how that DC is selected. E.g. is it taking the first
15 DC, in DNS, based on alphabetical order, to ping, to see which one is the
closest? If so, is there a way to change this mechanism?

Once a client has information about which DC it is using,

how long is it cached?
does a reboot clear the cache? If not, is there a way to force a client the
next time the user logs in, to go and validate if a DC is available in the
Site?

Thanks for any input in advance,

Ed
 
If I understand right, you are suggesting that if a DC does not get back
to a client request within 100ms, that you don't want traffic there. So -
for example, a frame/relay T1 link has a latency of 80 - 120ms on it's
own. Therefore, it would always not log onto the AD Site where it's
subnet is mapped to?
Click to expand...

Hmmm...interesting scenario. I'm not sure of the answer. I'd have to test
this. I will say that you can more than likely fudge this timeout. You can
practically change every TCP/IP setting in Windows NT 5.x.

On note 2: You mentioned it looks up DNS everytime it needs to go back to
a DC. My understanding is quite different, otherwise everytime it went to
do any LDAP query (e.g. look up the GAL in Outlook), it would then do a
DNS lookup first to find which DC to go to?
Click to expand...

Yes, this is as I understand it too. Excluding DNS Resolver (client)
caching. If it's not in the local cache, it makes a DNS call. Different
operations require different info. Look at all the sub-domains under _msdcs
for the kind of different calls you can expect.

I take it that no one know how to re-point a client PC back to it's home
DC for authentication without a reboot - unless your point 2 applies for
all DC access - everytime.
Click to expand...

Perhaps. I've added some comments specific to your initial post. You'll
find them directly underneath your original post. You can manually force a
client to use a certain site. You can also play with SRV weightings and
priorities in the local DNS server.


--

Paul Williams

http://www.msresource.net/
http://forums.msresource.net/

Hi Ryan,

If I understand right, you are suggesting that if a DC does not get back to
a client request within 100ms, that you don't want traffic there. So - for
example, a frame/relay T1 link has a latency of 80 - 120ms on it's own.
Therefore, it would always not log onto the AD Site where it's subnet is
mapped to?

On note 2: You mentioned it looks up DNS everytime it needs to go back to a
DC. My understanding is quite different, otherwise everytime it went to do
any LDAP query (e.g. look up the GAL in Outlook), it would then do a DNS
lookup first to find which DC to go to?

I take it that no one know how to re-point a client PC back to it's home DC
for authentication without a reboot - unless your point 2 applies for all DC
access - everytime.

Ed
 
Back
Top