AD Sites issue

I have it from a good source that you must have reverse lookup zones for the client to really know what site he belongs to. Sorry, I've looked and looked but can't find that on MS site.

Anyway, it's worth checking.

Thanks for the reply,

Checked just to make sure, and we do have a corresponding reverse lookup zone for the various subnets.

What we have had to do to this point is manually edit the registry of the workstations that are affected by this. (Only 5 or so, but thats not the point).

Any other ideas

Try doing a dcdiag /fix and a netdiag /fix on the DCs in the main office and the branch office to make sure the srv records are all registered in DNS. Are the clients that are having problems successfully getting dhcp addresses in their new branch office? Are both sites replicating properly? I'm just wondering if both sites have a proper copy of the delegated _msdcs.forestroot.tld. Here's a good article about how clients choose what DC they will connect to: http://support.microsoft.com/kb/247811

Thanks for the link, that is a good read and helps explain the process for me.

I will run the fixes on the DC's.

To answer your question; they receive an IP address without trouble and in the correct subnet. Replication occurs normally, this is sort of a problem that has gone ignored for a few months and I finally decided to look into it

. The network functions as desired as far as AD replication (or so it seems), its just this logonserver issue that rears its head for a few people.

I will be going over that article with a fine-tooth comb to see what I can determine.

Thanks again,

Travis

Well, the article basically says, when the client talks to DNS to get srv record, DNS will try to check for a DC closest. The client will then talk to the DC and the DC will double-check if the client is talking to the best DC. If it's not, the DC re-directs the client to a new DC. Of course there's a lot more to it, but that's the jist of it. So the million dollar question, is why it isn't doing this? *shrugs* I'll try to look into it a bit more and see what I can dig up.

This is a longshot, but perhaps someone modified the registry entry SITENAME to have the client statically use a specific site for authentication. If you enter in a value for SITENAME, the DYNAMICSITENAME registry entry will no longer dynamically choose sites when a client is moved to a new site.

Some information regarding SITENAME: http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/regentry/55956.mspx?mfr=true

Hmmmm.. an interesting hypothesis about the static SITENAME entry. I will ask around at work tomorrow, pretty sure of the answer but it never hurts to ask.

Thanks for the continued interest Royal!

Hey again,

I looked at the registry for a computer that just got set up to deploy to a new user. The SITENAME contains a value, and it was not entered statically. I am trying to determine if DynamicSiteName replicates it's value to SITENAME, or if something is running in a GPO that affects the SITENAME key. Also, the machine does not have a SiteNameTimeout key. (the setting that tellls dynamicsitename how often to check which site it is in).

Interesting....

I read an article on technet while I was researching this saying that SITENAME should have no value. Interesting.... Let me know what you find.

Well I didn't get a lot of time to look at this today,

but I did log into one of the remote bridgehead DC's and found out that its DynamicSiteName value was that of our main office. However, the Site-Name and SITENAME entries were both that of its local site. Curious, I'm not sure if its somehow related to this whole thing lol.

I will hopefully have more time to look at this tomorrow.

Travis

You can check to see what sites a DC is covering, you can run the following command:

nltest /dsgetsitecov /server:dcname

This might show if you have a misconfigured site-link.

We know that the following is how a client finds a DC to use:

1. The client boots up and proceeds to contact a DC in the site it was last logged into (call it SiteAlpha) using either a cached DC name or DNS.
2. If the client is still in SiteAlpha, all is well as long as a DC is up and running.
3. If the client is now in SiteBravo, and the DC in SiteAlpha receives the request, it realizes by the clients IP that the client is no longer in SiteAlpha and returns the new site (SiteBravo) in the reply.
4. The client then performs a DNS lookup to find a DC in SiteBravo.
5. At this point the client either gets authenticated by a DC in SiteBravo, or if the DC fails to respond the client will attempt to find another DC in SiteBravo, or if the client fails to find a DC in SiteBravo to authenticate with it will then turn back to the DC in SiteAlpha to authenticate with the original server.

The last part of step 5 may be what is happening to your clients. Why? Network issues? misconfigured IP settings? Who knows....

However, one thing I have never been able to find an answer for is in regard to step 1 in the DC Locator process a client goes through. What if the client boots up and tries to contact a server in SiteAlpha (even though he is now in SiteBravo) but cannot contact the DC to find out it's now in SiteBravo? In other words, no response at all from the DC in SiteAlpha (which could easily happen if the sites are using IPSec to secure communication between DC's for replication but not between clinets and DC's). Does it then use DNS to locate ANY domain controller?

Running the nltest showed that each DC is covering the site it is designed to, so that's good I guess.

I am just tossing this out there, I wonder if it has something to do with a cache on the client side? I am curious to see if the next time we have this problem with a user's machine, we wait to determine if it actually clears itself up before someone edits the registry.

This would be a lot easier if it was happening to everyone, not just the odd user here and there!

theseman wrote:

This would be a lot easier if it was happening to everyone, not just the odd user here and there!

I hear ya! That's why I wonder if it's a caching issue, and combined with a slow (timeout) response from the original server since the request is traversing the WAN. On the offending client machines, what happens if you try the following:

arp -d *
ipconfig /flushdns
ipconfig /registerdns
NBTSTAT -R
NBTSTAT -RR

These steps can also be accomplished by simply using the "Repair" option on the network connection properties. I'm just wondering that since, by default, XP does not wait for the network to login a user, could stale arp cache or dns cache cause the problems of finding the right DC?

strauchr

sprkymrk wrote:

theseman wrote:

This would be a lot easier if it was happening to everyone, not just the odd user here and there!

I hear ya! That's why I wonder if it's a caching issue, and combined with a slow (timeout) response from the original server since the request is traversing the WAN. On the offending client machines, what happens if you try the following:

arp -d *
ipconfig /flushdns
ipconfig /registerdns
NBTSTAT -R
NBTSTAT -RR

These steps can also be accomplished by simply using the "Repair" option on the network connection properties. I'm just wondering that since, by default, XP does not wait for the network to login a user, could stale arp cache or dns cache cause the problems of finding the right DC?

This was my way of thinking. Considering the PC's are logging on to another site first before being shipped out, all sorts of caching occurs.

Also, this may or may not be an issue but would be something I would check anyway, is the DC at the PCs local branch a GC?

keatron

Just curious here. Is there a Global Catalog at each site?

Stauchr and Keatron have a good point about Global Catalog servers.

If your forest has more than 1 domain and they are using the UPN to logon (as opposed to the domain\username method in Pre-W2K) it has to contact a GC for logon.

So, do some users use:
joeblow@mydomain.com

And others use:
mydomain\joeblow (or just joeblow and the domain selected from the drop down box, same thing).

Sorry its been a while since I had any time to work on this problem!!

To answer some of the above questions: 1 Domain with a GC in each site.

Just today I was troubleshooting a DNS aging issue and viewed the properties of the reverse-lookup zones for each subnet. There is no aging/scavenging setup. I wonder if someone (you know who you are) knows how the client uses the reverse lookup zone to determine its site? Since there could be stale records in the main office reverse lookup zone, might it be tricked to think it still belongs to that site?

Travis

Wow.. 1 year later.

So I did end up getting this resolved, but not until pretty recently. I was permanently pulled off this problem a few days after my last post (July last year) and did not get some true free time until last month.

So here were the issue(s) that were at fault here:

1) DHCP - was not updating records as desired (this was due to a credential issue on SOME servers)
2) DNS - scavenging problems, also as per above records were not being updated
3) GPO - I did not find this at first, for some reason, but I found that the GPO setting "Site Name" was set, which has been since removed.

So, which one fixed it exactly, well I was so excited at the time that I am not entirely sure, but it looks like all 3 were playing a part here.

Thanks for all of the assistance!

-Travis

gojericho0

theseman wrote:

1) DHCP - was not updating records as desired (this was due to a credential issue on SOME servers)

-Travis

Just out of curiosity, do you let your DHCP servers update DNS by putting them in the DNSUpdate Proxy group and disable the updating by the clients? I know I had dhcp updating record and this fixed the problem