AD DS – Выбор DC для операции ввода в домен с помощью PowerShell командлета Add-Computer

В большой доменной инфраструктуре AD DS с большим количеством сайтов можно столкнуться с ситуацией, когда при вводе в домен новых компьютеров в сайте с единственным контроллером RODC операция ввода в домен происходит не на ближайшем RWDC а на отдалённом. Это приводит к тому, что перед тем как можно будет начать использовать в домене такой компьютер, потребуется выждать репликацию от удалённого DC до местного RODC. Избежать данной ситуации можно используя утилиту NETDOM, явным образом указывая ближайший контроллер домена, на котором мы хотим произвести процедуру джойна:

Но так как по умолчанию в клиентских системах этой утилиты нет, хочется воспользоваться каким-то подручным средством без выполнения дополнительным манипуляций. И тут нам на помощь приходит PowerShell с командлетом Add-Computer… но когда я решил воспользоваться им на практике, то выяснилось что встроенный хелп PowerShell об этом командлете (равно как и сайт TechNet Script Center) о чём-то нам не договаривает.

Попытка выполнить ввод в домен строго по описанию не сработала, то есть при использовании командлета в виде…

Add-Computer -DomainName 'MYDOM' -Credential 'MYDOMadmin' -OUPath 'OU=Clients,OU=Branch,DC=mydom,DC=com' -Server 'MYDOMBestDC' -PassThru –Verbose

… приводила к ошибке, которая фиксировалась в логе NetSetup.LOG (расположен в каталоге C:Windowsdebug) примерно в следующем виде:

02/03/2011 11:43:51:403 ----------------------------------------------------

02/03/2011 11:43:51:403 NetpDoDomainJoin

02/03/2011 11:43:51:403 NetpMachineValidToJoin: 'MyWS001'

02/03/2011 11:43:51:403    OS Version: 6.1

02/03/2011 11:43:51:403    Build number: 7600 (7600.win7_gdr.100618-1621)

02/03/2011 11:43:51:403    SKU: Windows 7 Профессиональная

02/03/2011 11:43:51:403 NetpDomainJoinLicensingCheck: ulLicenseValue=1, Status: 0x0

02/03/2011 11:43:51:403 NetpGetLsaPrimaryDomain: status: 0x0

02/03/2011 11:43:51:403 NetpMachineValidToJoin: status: 0x0

02/03/2011 11:43:51:403 NetpJoinDomain

02/03/2011 11:43:51:403    Machine: MyWS001

02/03/2011 11:43:51:403    Domain: MYDOMBestDCMYDOM

02/03/2011 11:43:51:403    MachineAccountOU: OU=Clients,OU=Branch,DC=mydom,DC=com

02/03/2011 11:43:51:403    Account: MYDOMadmin

02/03/2011 11:43:51:403    Options: 0x23

02/03/2011 11:43:51:403 NetpLoadParameters: loading registry parameters...

02/03/2011 11:43:51:403 NetpLoadParameters: DNSNameResolutionRequired not found, defaulting to '1' 0x2

02/03/2011 11:43:51:403 NetpLoadParameters: DomainCompatibilityMode not found, defaulting to '0' 0x2

02/03/2011 11:43:51:403 NetpLoadParameters: status: 0x2

02/03/2011 11:43:51:403 NetpValidateName: checking to see if 'MYDOM' is valid as type 3 name

02/03/2011 11:43:53:697 NetpCheckDomainNameIsValid for MYDOM returned 0x54b, last error is 0x0

02/03/2011 11:43:53:697 NetpCheckDomainNameIsValid [ Exists ] for 'MYDOM' returned 0x54b

02/03/2011 11:43:53:697 NetpJoinDomainOnDs: Domain name is invalid, NetpValidateName returned: 0x54b

02/03/2011 11:43:53:697 NetpJoinDomainOnDs: Function exits with status of: 0x54b

02/03/2011 11:43:53:697 NetpDoDomainJoin: status: 0x54b

Как видно из лога, имя домена формируется как то не совсем адекватно. Немного поигравшись с использованием разных вариантов передачи параметров и проведя аналогию с использованием утилиты NETDOM, был найден работающий вариант, а именно:

Add-Computer -DomainName 'mydom.comBestDC' -Credential 'MYDOMadmin' -OUPath 'OU=Clients,OU=Branch,DC=mydom,DC=com' -PassThru –Verbose

То есть вместо параметра Server можно использовать передачу имени DC в параметре DomainName. Данный способ проверен и работает как на Windows 7, так и на Windows XP SP3.

Если у кого-то есть комментарии по поводу того, как можно ещё обуздать механизм ввода в домен для компьютеров в сайте с RODC будет интересно их здесь услышать.

Дополнительная информация для размышления:

Windows Server TechCenter Forums - Selection of DC during a workstation join to domain operation

Blog Jorge 's Quest For Knowledge! - DC Locator Process in W2K, W2K3(R2) and W2K8 - PART 1