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"
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- [ActiveDir] computer domain join process Kamlesh Parmar
- RE: [ActiveDir] computer domain join process Tony Murray
