Check the SRV records for the remote site DC in DNS.  Read Below:

 

When a client logs on or joins the network, the client must be able to locate a domain controller. The client sends a DNS Lookup query to DNS to find domain controllers, preferably in the client's own subnet. Therefore, clients find a domain controller by querying DNS for a record of the form:

_LDAP._TCP.dc._msdcs.domainname

After the client locates a domain controller, the client establishes communication by using Lightweight Directory Access Protocol (LDAP) to gain access to Active Directory. As part of that negotiation, the domain controller identifies which site the client is in, based on the IP subnet of that client. If the client is communicating with a domain controller that is not in the closest (most optimal) site, the domain controller returns the name of the client's site.

 

If the client has already tried to find domain controllers in that site (for example, when the client sends a DNS Lookup query to DNS to find domain controllers in the client's own subnet), the client uses the domain controller that is not optimal. Otherwise, the client performs a site-specific DNS lookup again by using the name of the optimal site. The domain controller uses some of the directory service information for identifying sites and subnets.

 

After the client locates a domain controller, the domain controller entry is cached. If the domain controller is not in the optimal site, the client flushes the cache after 15 minutes and discards the cache entry. The client then attempts to find an optimal domain controller in its own site.

 

After the client has established a communications path to the domain controller, the client can establish its logon and authentication credentials and, if necessary for Windows-based computers, set up a secure channel. The client then is ready to perform normal queries and search for information against the directory.

 

The client establishes an LDAP connection to a domain controller to log on. The logon process uses Security Accounts Manager (SAM). Because the communications path uses the LDAP interface and the client is authenticated by a domain controller, the client account is verified and passed through SAM to the directory service agent, then to the database layer, and finally to the database in the Extensible Storage engine (ESE).

 

http://support.microsoft.com/default.aspx/kb/314861/EN-US/

 

 

-Sergio

 

 

-----Original Message-----
From: Steele, Aaron [BSD] - ADM [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 26, 2006 10:30 AM
To: [email protected]
Subject: [ActiveDir] oddness with sites.

 

Okay I have a perplexing problem that I haven't found any help for on

the web. Maybe someone her can help.

 

I have a fairly simple AD forest

single forest, single domain.  2 sites, defined properly as far as I can

tell.

In the remote site, there is a DC/GC, both physically and in Sites and

Services.

The x.x.81.X subnet is tied to the correct site.

 

Output form nltest is below.

 

nltest /dsgetdc:<domain-name> /site:UCPG

     DC: \\<DC-At-Remote Site>

     Address: \\X.X.81.217

     Dom Guid: XXXXXXXX-1c6b-4645-ac78-b0f2444eac2c

     Dom Name: Domain

  Forest Name: domain.fqdn.edu

 Dc Site Name: UCPG

Our Site Name: UCPG

        Flags: GC DS LDAP KDC TIMESERV WRITABLE DNS_FOREST CLOSE_SITE

The command completed successfully

 

In the registry of a workstation/server on the remote site, the registry

 

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters

\DynamicSiteName is equal to "UCPG"

 

Yet,  whenever I log onto a workstation/server there

"set l" returns a DC/GC that is at our HUB site, and not the DC/GC

identified and located in the remote site.

 

Nltest /sc_query:<domain>  returns the same DC/GC located in the hub

site, and again, not the DC/GC in the remote site.

 

Pings between remote workstation and remote DC/GC are less than 1ms,

between remote workstation and hub DC/GC are more like 30 to 40 ms on

average.

Both remote site and hub site DC/GC are ping able and nbtstat -a

findable by short name and reverse ip lookups.

 

Any help anyone has, I would greatly appreciate it.

 

Thanks so much.

/aaron

 

 

Aaron Steele

University of Chicago

Enterprise Systems Administrator

P: 773.834.9099

E: [EMAIL PROTECTED]

This email is intended only for the use of the individual or entity to which it is addressed and may contain information that is privileged and confidential. If the reader of this email message is not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication is prohibited. If you have received this email in error, please notify the sender and destroy/delete all copies of the transmittal. Thank you.

List info   : http://www.activedir.org/List.aspx

List FAQ    : http://www.activedir.org/ListFAQ.aspx

List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/

Reply via email to