I have two Active Directory servers set up with replication, ad2 and ad4.
ad4 has a higher latency than ad2 as it is offsite.
All clients are supposed to log in and authenticate to the ad2 server.
The problem is that every once in a while ad4 will be the login server
servicing the login request.
I can tell because the login script shows a message dialog with the
ad server that serviced the login request.
Are there any threshold settings (number of users, wait time)
that I can change on ad2 and ad4 to always get ad2 to service
login requests / authentication?
Add a comment
|
3 Answers
It sounds like you need to use the "Active Directory Sites and Services" snap-in to define the subnets, physical locations (known as "Sites") with well-connected subnets, and connections between sites (known as "Site Links") that make up the physical network underlying your Active Directory (AD) so that your domain controllers can make good replication decisions and clients can make good decisions about which server computer(s) to use to service logons. Without a description of the physical topology of your network all the various parts of the server and client operating systems that rely on communication to Domain Controller (DC) computers are basically "flying blind" and have no ability to judge which DCs are physically close and, thus, more efficient to communicate with.
Once you've informed AD about the physical layout of the network you should find that things "just work" a lot more effectively. Don't worry too much about balancing load for "number of users"-- that's not going to be a factor once you've got the sites and subnets defined (unless you have a really, really bad user-to-domain controller ratio or a very high rate of logons). I think most of your problems are coming from the fact that you haven't told AD anything about the physical topology of your network. (There are some deeper "tweaks" that can be performed in DNS to influence selection of DCs within a given site but, basically, clients "roll the dice" and communicate with any DC in their site. That's always been good enough for me in production deployments.)
All this tweaking with sites, site links, and subnets is really just changing what's stored in DNS. The clients use DNS to determine which site they're located in (by looking-up their subnet) and, once they know that, they use DNS to locate DCs to communicate with. The actual DNS records that do the work are the "SRV" resource records (RRs) stored in the "_msdcs.domain.com" DNS zone. Obviously, for all of this to work clients must have access to a DNS server that can return records for the "_msdcs.domain.com" DNS zone. It's generally preferred to use a DC as a DNS server (because Microsoft has made this configuration "just work" very well), to not specify any non DC-based DNS servers in client network configurations (i.e. don't put the ISP DNS servers as "secondary" DNS servers in DHCP scopes or "hard coded" on clients / servers), and always be sure that every physical location has a DNS server on-site such that a WAN / VPN failure doesn't remove all DNS services for the clients in that physical location.
I'm making the assumption here that you haven't bridged a single IP subnet across multiple locations. If you have done that you'd be better served with changing your network topology to use multiple subnets, rather than trying to "hack" AD to handle such an odd topology.
Robert Moir wrote a nice overview of what Active Directory sites "mean" for another question. I'd have a look there.
As an aside to this, you need to think about having at least one DC in each site ticked as a Global Catalog (GC) server, as well. The procedure to set a DC as a GC is really straightforward and you should have one in each site (even if you don't necessarily understand what they're for). Ticking every DC as a GC isn't really the best idea, though in an environment as small as yours it wouldn't make much different. In larger environments, though, more is not necessarily better when it comes to GC replicas.
answered Oct 27, 2011 at 17:41
What you are describing is most likely completely normal. If a local DC is unresponsive for a short period of time, the client will contact any another DC in the domain, regardless of location. (Windows 2008 there is a new setting that makes the next closest location more efficient). There is actually a very sophisticated algorithm that Windows clients follow, called the DC Locator.
It is possible to make the process more deterministic by configuring Sites and Site Link costs (if you have not done that), and by using the Priority and Weight of the SRV DNS records in the _msdcs subdomain. Clients attempt to contact the server with the lowest priority. Weight is a load-balancing mechanism that is used when selecting a target host from those that have the same priority. Clients randomly choose SRV records that specify target hosts to be contacted, with probability proportional to the weight.
DNS returns a list of IP addresses that match the target domain in the SRV records (that is, IP addresses of domain controllers in the specified domain) that are sorted by priority and weight. The client pings each IP address in the order returned. The ping is a UDP LDAP query to port 389. The client pings each domain controller from the list. After each ping, the client waits one-tenth of a second for a response to the ping (or to any previous ping), and then pings the next domain controller. Choosing the domain controllers at random provides a first level of load balancing. Doing multiple pings in quick succession ensures that the discovery algorithm terminates in a finite amount of time.
Note that when a client establishes a connection to a DC, it creates an affinity (sometimes referred to as "stickiness") with that DC. Windows Vista/2008 and later clients will attempt to rediscover domain controllers every 12 hours by default, and that is configurable with group policy. There is also a hotfix to enable this behavior for Windows XP/2003.
More information:
How to optimize the location of a domain controller or global catalog that resides outside of a client's site http://support.microsoft.com/kb/306602
SRV Resource Records
http://technet.microsoft.com/en-us/library/cc961719.aspx
Domain Controller Location Process
http://technet.microsoft.com/en-us/library/cc978011.aspx
DsGetDcName function
http://msdn.microsoft.com/en-us/library/windows/desktop/ms675983%28v=vs.85%29.aspx
Enabling Clients to Locate the Next Closest Domain Controller
http://technet.microsoft.com/en-us/library/cc733142%28WS.10%29.aspx
Types of Locators
http://technet.microsoft.com/en-us/library/cc978019.aspx
answered Oct 27, 2011 at 18:55
I'm going to assume (maybe incorrectly) that you have AD clients at the remote site and that that's why you have a DC at that site. If so, then as Evan stated you'll want to set up Active Directory Sites and Services for both sites/subnets. The KCC will then build a replication topology between the DC's based on the ADS&S configuration. As it stands now you've probably got replication traffic traversing the WAN based on an Intra-Site replication topology rather than an Inter-Site replication topology.
The DC locator on each client will then find a DC in it's closest site to authenticate to. Make sure to configure the DC at the remote site as a GC (or enable Universal Group Membership caching in the NTDS Site Settings for the remote site).
If I'm wrong and you don't have AD clients at the remote site, why do you have a DC at the remote site?
answered Oct 27, 2011 at 18:02
