Discussion Locked

AD logon problems if site link is down

0 helpful
17 replies
Closed to new repliesThis discussion is closed. It stays readable, but it takes no new replies.
We are using Active Directory - forest level is 2003. One of our sites is connected by T1. This site has a domain controller which is also a DNS server and global catalog svr. DNS zones are AD integrated. This DC has no FSMO roles, it is only there to facilitate logons and provide file and print services to local users at the site. If T1 link is up, everything works as it should. If T1 is down, local users can't access file shares on the local DC nor can they log on to their workstations if their user is not cached. What do I need to do to enable local network domain functionality even if network link is down.

17 replies

by cg it

first is how do clients get their DNS info? from DHCP? if so, where's the DHCP server?

Might want to create a DHCP server for the site with its own scope and options. The options configured to say first DNS is local and if that DNS server is not available then go over the T1 line and look for the DNS server at the main.

by joshhansen

dns is running on the local dc and the workstations are pointing to that server. IP addresses and configured manually.

by shmaltz

All the clues you give indicate a DNS problem. Make sure the local DNS works fine and can resolve names and that the clients are setup to use the local DNS.

by joshhansen

It was a hidden DNS problem on the client. The computers were configured to use the local DNS server as their primary in TCP/IP settings. This was even configured in their site GPO. The problem was another GPO attached to the domain was specifying a DNS server outside the local subnet as primary which overrode all other settings. NSLookup verified this. I have correct the problem and all is well. Thanks

by willcomp

Sounds like all user authentication is on main server. Is one DC and other backup DC with AD replication or are both trying to be master DC?

by joshhansen

only 1 dc in this site. The DCs with FSMO roles are at central site. I'm using 2003 native mode and since AD uses multimaster, shouldn't be a primary/backup issue because there are no backup DCs.

by willcomp

Josh,

Win2K server is my last foray into server software.

But have you checked to verify that user accounts are on remote server?

Dalton

by cg it

http://www.computerperformance.co.uk/w2k3/W2K3_FSMO.htm

heres a link for basic info on the five flexible single master operation FSMO Roles for Windows 2003.

your problem still is DNS and how clients obtain autentication with the DNS server. Even though you say the clients point to the local DNS server, if that local DNS server provided authentication for that site and the domain that site belongs to you wouldn't have a problem if a WAN T1 site connection to a main office DNS server goes down. You have a problem. Look at the local DNS server and its role.

by joshhansen

It was a hidden DNS problem on the client. The computers were configured to use the local DNS server as their primary in TCP/IP settings. This was even configured in their site GPO. The problem was another GPO attached to the domain was specifying a DNS server outside the local subnet as primary which overrode all other settings. NSLookup verified this. I have correct the problem and all is well. Thanks

by edrossius

I think your problem may rely in the configuration of the "Active Directory Sites and Services" (ADSS). With your topology, the subnet of your remote site should be different of the one of your central site. You have to configure in ADSS a new site (by default, only the Default-First-Site is created) to which you assign the subnet of your remote site. Then make sure the DC on your remote site is well affected to the new site (then wait for replication). With such a configuration (and with use of appropriate IP addresses on your remote site), your workstations will know just after booting they're belonging to the remote site and that the nearest DC is the one on your remote site and not the ones in your central site.

Hope this will help...

by bfilmfan

Verify that the DC IS a global catalog. If the GC is not functioning properly and the link is down, you've described the error exactly. GC's are required for a user to login to AD.

by bfilmfan

You stated it is showing as a GC.
Go into Sites and Services.
Go that server's NTDS settings and uncheck the GC box.
Force Replication.
Use repadmin to verify that the replication completed.
From the remaining DC in the domain, go back to Sites and Services and change it back to being a GC.
Again, force replication.
Use repadmin to verify tha tthe replication completed.

See if that resolves the issue. I suspect that it didn't complete GC replication and the DC doesn't have a full replica of the domian's information. I have seen that issue in the past.

This discussion is closed to new replies.