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"
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Reply via email to