using remote site DC for logonserver

[Charles Munchow]

We have 10 physical sites with 10 AD sites and different subnets. I have
just setup a new site and I notice that the workstations (XP) are
displaying a remote DC in the LOGONSERVER environment var.

How do I get XP to use the local DC in it's own site and subnet ?

Some additional info:

* I have checked for correct AD dynamic DNS registrations, in particular the
site's own DC.
* The domains primary DNS zone is replicated correctly to a secondary zone
on the local DC. (the primary DNS is remote and not AD integrated. The
workstations point to the local secondary DNS server)
* The local DC is also GC.
* No IP connectivity problems from XP workstation to local server - can map
drives.

I have observed group policy and vbs logon script's sometimes work and
sometimes not - I am guessing this is because of the XP workstations
sometimes going to a remote DC for logon.

Thanks for any ideas.
CharlesM.

 

[Guest]

This all revolves around correct Sites and Subnets Definitions in AD sites
and Subnets. Ensure that your subnet Mask's are correctly defined and that
you have no colliding subnets (overlapping subnets where the DC’s are trying
to cover for an alternate site inadvertently). Ensure you have no undefined
subnets. Check the event logs on the Domain Controllers.

Ensure that you can set the secure channel to the domain controller in the
clients local site by using the

NLTEST \SC_RESET:your_domain_name\Domain_controller_name from a command line
on the client.

Run Netdiag from a command line and review and address any errors in this log.

That should give you enough to start with – post your findings and I will be
happy to respond.

Good Luck,

John Powell

 

[Guest]

in-line.

just setup a new site and I notice that the workstations (XP) are
displaying a remote DC in the LOGONSERVER environment var.

This variable is no longer as reliable as it used to be under XP. It may
indicate a DC name but could well be using cached logins. Did the machines
get connected physically to the remote DC onsite before (e.g. user travelled
there),
or were served by the remote DC because the current location's DC (where the
XP machine is plugged into) was too busy?

 

[Charles Munchow]

John, I re-checked the subnet definitions and can't fault it however I did
some tests with NLTEST as you suggested and had some interesting results:-

NLTEST /DSGETSITE ....gives the remote site which is on different subnet
than the workstation

NLTEST /SC_RESET:domain-name\local-dc
NLTEST /DSGETSITE ....now gives the correct site

LOGONSERVER environment var (after logging in again) = local-dc

{reboot computer}

NLTEST /DSGETSITE ....gone back to wrong site again

....it seems that XP just can't figure out what site it's in properly!
also "NLTEST /DCLIST:domain-name" correctly lists all DC's and their correct
sites, but the local workstation still get's confused which site it's in.

 

[Charles Munchow]

in-line.



This variable is no longer as reliable as it used to be under XP. It may
indicate a DC name but could well be using cached logins. Did the machines
get connected physically to the remote DC onsite before (e.g. user
travelled there),
or were served by the remote DC because the current location's DC (where
the XP machine is plugged into) was too busy?

Yes I think what you are saying is quite possible, it is a new (physical and
AD) site and the DC may not have registered itself properly in DNS the
first time the workstations started up..... but how do I get them to forget
all about any other DC's they've talked to ?

I have made some other interesting observations using "nltest.exe" which
I'll mention in reply to the other newsgroup response I had from JohnP.

 

[Guest]

but how do I get them to forget all about any other DC's they've
talked to ?

Try restart the client machines. In addition, you can also use "ipconfig
/flushdns" at the command line to purge all cached DNS entries. Worst still,
unjoin and rejoin the client to the domain. May still be possible to make
some changes in the registry if all else fails.

XP is a bit perculiar. Look for the kerberos utility from RK to verify that
it is indeed connected to the domain (and not via cached logins). One quick
way to check is to look for the execution of network login script e.g. all
network drives are properly mapped via network login script.