Re: PINGing the Active Directory Domain

this post was not finished yet... I will resend it as soon as it finished

--

Cheers,
(HOPEFULLY THIS INFORMATION HELPS YOU!)

# Jorge de Almeida Pinto # MVP Windows Server - Directory Services

BLOG (WEB-BASED)--> http://blogs.dirteam.com/blogs/jorge/default.aspx
BLOG (RSS-FEEDS)--> http://blogs.dirteam.com/blogs/jorge/rss.aspx
------------------------------------------------------------------------------------------
* How to ask a question --> http://support.microsoft.com/?id=555375
------------------------------------------------------------------------------------------
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always test before implementing!
------------------------------------------------------------------------------------------
#################################################
#################################################
------------------------------------------------------------------------------------------
"Jorge de Almeida Pinto [MVP - DS]" <SubstituteThisWithMyFullNameSeparatedByDots@xxxxxxxxx> wrote in message news:Ov$DhvvuHHA.3660@xxxxxxxxxxxxxxxxxxxxxxx
DC Locator Process in W2K, W2K3(R2) and W2K8:

by default a client that knows in what AD site it is in, will ask for a DC in that same site by querying DNS with:
_ldap._tcp.<SITE>._sites.dc._msdcs.<Domain>.<Tld>

By default all DCs in AD site <SITE> will register that DNS SRV record. If no DC are in that AD Site, the DCs in the nearest AD site will cover that AD site by registering their records in the DC-less AD site. The DCs in the site list are in a random order and provided by the DNS round robin mechanism.

If a client does not know in what site it is in it will ask for a DC in that same domain by querying DNS with:
_ldap._tcp.dc._msdcs.<Domain>.<Tld>

By default all DCs in AD domain <DOMAIN> will register that DNS SRV record. The DCs in the domain list are in a random order and provided by the DNS round robin mechanism.

To determine the AD site of a client --> NLTEST /DSGETSITE
To determine a DC within a DC of DCs that could authenticate the client --> NLTEST /DSGETDC:<FQDN DOMAIN>

So if you look at the situation where a client queries for a DC in the domain because it does not know in what AD site it is in, it can be somewhat interesting when you find out the client is communicating with some DC on the other side of the world. Not really efficient!. In HUB and SPOKE environments this can be a problem. It can be really annoying when some client in branch office X is authenticating to a DC in branch office Y, while then WAN links between both branch offices (SOKES) and the datacenter (HUB) are not that fast. To prevent that situation, it is a best practice to allow the DCs in the datacenters (HUB) register whatever SRV record and allowing the DCs in the branch offices (SPOKES) to register only their site specific SRV records. That way when a client queries for a DC in the domain it will be serviced by one of the DCs in the datacenter (HUB) and NOT in some branch office far far way!

This same situation occurs when a client is joined to the domain using the GUI. At that momemt the client does not know its site and it will thus query for A DC in the domain to create its computer account. Guess what, after the clients reboots you might experience authentication problems because the computer account was created at a DC in branch office X while the client is in branch office Y. The issues will go away as soon as the computer account replicates from branch office X to the datacenter and from the datacenter to branch office Y. How hong that takes depends on your AD site and replication topology. By using the configuration explained above, the computer account will be created on a DC in the datacenter. That way it only needs to replicate from the datacenter to the branch office. To target the correct AD site where the client will based it is better to use the command-line tool NETDOM. Using that command-line tool you can specify a DC in the AD site where the client will based AND you can specify in what OU the computer account should be placed. The syntax is:
NETDOM JOIN %COMPUTERNAME% /DOMAIN:<DOMAIN>\<DC> /OU:<distinguished name of OU> /USERD:<DOMAIN>\<USER> /PASSWORDD:<PASSWORD>

Because DCs by default register all SRV records, you need to configure the branch office NOT to register certain records.






how to configure to register only certain srv records


Also have a look at:
SRV record
http://en.wikipedia.org/wiki/SRV_record

How to verify that SRV DNS records have been created for a domain controller
http://support.microsoft.com/?kbid=816587

SRV Resource Records
http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/distrib/dsbc_nar_sdns.mspx?mfr=true

How to optimize the location of a domain controller or global catalog that resides outside of a client's site
http://support.microsoft.com/?kbid=306602


--

Cheers,
(HOPEFULLY THIS INFORMATION HELPS YOU!)

# Jorge de Almeida Pinto # MVP Windows Server - Directory Services

BLOG (WEB-BASED)--> http://blogs.dirteam.com/blogs/jorge/default.aspx
BLOG (RSS-FEEDS)--> http://blogs.dirteam.com/blogs/jorge/rss.aspx
------------------------------------------------------------------------------------------
* How to ask a question --> http://support.microsoft.com/?id=555375
------------------------------------------------------------------------------------------
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always test before implementing!
------------------------------------------------------------------------------------------
#################################################
#################################################
------------------------------------------------------------------------------------------
"JD" <dopamine@xxxxxxxx> wrote in message news:1183161976.272686.222740@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
I noticed that when I PING the domain name (PING OURCOMPANY.COM), a DC
on the other side of the world responds.. By what process is the
responding DC selected? Clearly not by site!

Thanks.

<JD>



.

Relevant Pages

  • Re: PINGing the Active Directory Domain
    ... If no DC are in that AD Site, the DCs in the nearest AD site will cover that AD site by registering their records in the DC-less AD site. ... If a client does not know in what site it is in it will ask for a DC in that same domain by querying DNS with: ... By default all DCs in AD domain will register that DNS SRV record. ... It can be really annoying when some client in branch office X is authenticating to a DC in branch office Y, while then WAN links between both branch offices and the datacenter are not that fast. ...
    (microsoft.public.windows.server.active_directory)
  • Re: Exchange 2007 CAS role and multiple sites
    ... "Protecting the world from PSTs and brick backups!" ... at this point autodiscover only works when the client ... Branch office has separate connection to the ...
    (microsoft.public.exchange.admin)
  • Re: DC replacement
    ... Yes there are two DCs and we only need to replace one. ... that server will error instead of just finding the other DC. ... Even under NT the client ... [phone number on web site] ...
    (microsoft.public.windows.server.active_directory)
  • Re: Overloading problem after adding 2003 DCs to 2000 domain.
    ... I don't think if all Windows Server 2003 DCs down will cause ... client to authenticate with the DCs outside of this site because: ... Therefore, if Windows Server 2003 DCs are all down, netlogon will try the ...
    (microsoft.public.windows.server.migration)
  • Re: Port 1025 RPC /Lsass.exe
    ... Clients use DNS to locate all domain controllers in domain. ... Next thing -- client will try to talk to the DC it chose. ... from command line to see which server authenticated the client. ... We have a branch office with approx 40 users. ...
    (microsoft.public.windows.server.networking)
Loading