Problems selecting the correct DC for logon/authentication

[PaulBarron]

I have two W2K AD DC's at my site. One of them has DHCP on, the other doesn't.

The one without DHCP on was introduced recently. Since doing so I am finding that some client PC's cannot logon to the network unless I switch off the new server until they have all successfully logged on.

Therefore, the new server is somehow becoming the clients preferred choice fpr logon/authentiaction.

Is there any way for me to stop this from happening?

Any advice welcome

 

[redwhip]

Your Active Directory DNS zone should have entries for kerberos which the clients use to locate a domain controller. They should be in the tcp subdomain.

There should be 2 SRV records for kerberos. Open the properties for them and you can then edit their priority.
Your clients will choose the one with the lowest prority as their preferred authentication server.

Hope this sorts it out.

 

[PaulBarron]

If one of my servers does not have a kerberos entry in the tcp section, how can I create one?

 

[PaulBarron]

This process did not work anyway. Does anyone have any idea of how I can stop the other DC from interfering with the logon process?

 

[redwhip]

Theoretically that should have worked. Check the _ldap._tcp.dc._msdcs SRV records as well.

Did you manually create the kerberos record? It should have been created dynamically.

Can you query the DNS server from the problem client PCs for SRV records using nslookup?

If all else fails do a google search for the LOGONSERVER enviroment variable.

 

[vbrocks]

On the clients just specify a static address for the primary dns server in tcp properties....

 

[xmsre]

Where do the two servers point for DNS. I'm guessing you have a registration problem. The first server points to itself for DNS. This doesn't seem a problem if you only have one domain controller. When you add the second, Clients attempt to log onto the second and are unable. The roots of this problem lie in service startup order, client name resolution order, and computer browser elections.

When a DC points to itself for DNS, the netlogon service attempts to start prior to DNS. That means that you don't get registered in DNS. Because this is the PDC emulator, it wins the browser election and becomes the master brouser. 2000 and XP clients try hosts, DNS, WINS, broadcast, lmhosts. Prior NT, 98, and 95 clients use lmhosts, wins, broadcast, dns, hosts name resolution order. 2000 and XP clients in such an environment would be noticably slower. Direct hosting of SMB over port 445 relies on being able to access the SRV record. In such an environment there would be no direct hosting, just downlevel RPC 135, 138 and 139 traffic.

When you add the second DC, it points to the first DC and does register in DNS. 2000 and XP clients will resolve the second DC only because the first is not registered in DNS, and DNS is first in the name resolution order.

To fix the problem you can do a couple of things. A sort of immediate workaround is to restart the netlogon service, ipconfig /registerdns, and nbtstat -RR on the first DC. This will resgister the first DC now that DNS has already started. The problem with this approach is that it needs to be done every time the DC is restarted.

A better way is, after initial replication, point the DCs at each other for DNS. Make your DNS zones AD integrated. Then, no matter what the state of any DC, each DC will always register with DNS and replicate the registration to the other DC.