SIte location is actually done in an unauthenticated manner with CLDAP calls. The UDP LDAP is connectionless with no TCP session and doesn't allow for a bind so the information has to be returned to anonymous callers (assuming they know the right query to submit and the right attributes to ask for and how to decode the binary data returned in the attribute).
 
The sad thing is that it should be working with site affinity already as it has the needed info. The client from what I have seen in the traces actually does a UDP ping and gets back the site info quite early in the join process (like the 5th packet in the trace I looked at).
 
I have submitted a "wish" to have that change put in. Anyone who also would like this I would recommend submitting DCRs through your various channels that are available to you.
 
   joe
 


From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tony Murray
Sent: Monday, December 19, 2005 7:10 PM
To: [email protected]
Subject: RE: [ActiveDir] computer domain join process

My guess is that it has to do with security.  Until the machine is a member of the domain you don’t want a DC to provide site and subnet information to it.

 

Tony

 


From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kamlesh Parmar
Sent: Tuesday, 20 December 2005 11:22 a.m.
To: [email protected]
Subject: [ActiveDir] computer domain join process

 

As we know that, when a new machine tries to join the win2k/3 domain,
it will first try a SRV query for  _ldap._tcp.dc._msdcs.DnsDomainName
and which ever DC is first in the list, it will connect to that DC and create account there and proceed for domain joining.
This order of DCs in query result is not uniform, it changes every time you query.

Now, If you have geographically dispersed DCs with long enough replication delay.
This approach leads into trouble, as machine might have created account on remote DC
and on next reboot it will try to find its account into local site DC, where it might not be present.

This is also more troublesome in the case, I want to refresh the machine using Ghost, I will delete its account in local DC and after Ghost restore it will try to join the domain by connecting to any random DC, and in this case, remote DC might/might not have account depending on replication reached it in time.

So one of the solution,is to use netdom.exe to join machines to domain, where at the command line we can target specific DC for joining process.
This is the command we use, where,
DOM = Domain to join
DOMDC1 = nearest DC for that computer
DOM\siteadmin = account with rights to join computer to domain

netdom.exe join %computername% /domain:DOM\DOMDC1 /UD:DOM\siteadmin /PD:* /OU:%OU-2-CREATE-ACCOUNT-IN% /Reboot

Now, my question, is why can't machine itself find the nearest DC to join, based on query to configuration NC for subnet/site mapping and then DNS query for DC in that particular site. (like normal domain client would do to find its nearest DC)

After all we are providing a privileged account while domain joining, which computer can use to get the pertinent info.

Also, is there better way to target joining computer towards its local DC.

--
Kamlesh
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Be the change you want to see in the World"
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002.

Reply via email to