В большой доменной инфраструктуре 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
Как и в предыдущей заметке было решено оптимизировать скрипт изложенный ранее в заметке PowerShell – Поддержание групп безопасности политики репликации паролей RODC в актуальном состоянии для выполнения с использованием новых командлетов из PowerShell модуля ActiveDirectory на Windows Server 2012 R2 таким образом, чтобы в результате работы скрипта не происходило полное переписывание членства пользователей в группах безопасности. 
При использовании контроллеров домена «только на чтение» (RODC) для каждого RODC должна быть определена доменная группа безопасности, в которую входят учетные записи пользователей, чьи учетные данные могут реплицироваться на этот RODC. В крупной географически распределённой инфраструктуре с большим количеством контроллеров домена задача поддержания состава этих групп безопасности «в рукопашную» может стать проблемой, особенно если учесть «человеческий фактор», когда например, в каком-то из удалённых подразделений местный администратор создаёт новую учетную запись доменного пользователя, а включить в группу репликации паролей эту запись забывает. Для того чтобы исключить в данном случае «человеческий фактор», можно автоматизировать данный процесс с помощью PowerShell. Рассмотрим пример скрипта, который можно включить в планировщик задач на контроллере домена на периодическое выполнение.
RSS - Записи