Домен один, репликация и ДНС все пучком, если создавать юзверя в стандартной оснастке или через "New-ADUser", то через 5-10 секунд он уже доступен на других контроллерах. Данная хня обнаруживается только через "net user".
Короче заснапшотил, и мякготелым тикет отправил, жду реакции.
А если добавить ключ /domain лучше не становится?
quote:
Originally posted by Bob11:
А если добавить ключ /domain лучше не становится?
Насколько помню, с данным ключем юзер создается применительно к основному контроллеру домена, что неприменимо к задуманному.
При чем здесь контроллер домена. Юзер создается в АД, и если он на одном контроллере есть а на другом нет - это глюк. Обычно такое бывает из-за глюков репликации. К тому же в 2012 сервере нет понятия - основной контроллер домена.
Кстати а dcdiag /a проходит без ошибок?
quote:
Originally posted by Bob11:
При чем здесь контроллер домена. Юзер создается в АД, и если он на одном контроллере есть а на другом нет - это глюк. Обычно такое бывает из-за глюков репликации. К тому же в 2012 сервере нет понятия - основной контроллер домена.
Ты немного не понял ситуацию, пользователя вообще не видно в оснастке, но он есть и можно его поймать по UIDу.
Все настроено без ошибок. Контроллеры в одном лесу, но находятся в разных сайтах, отсюда и задача, со сменой OU по дефолту, для каждого из контроллеров отдельная OU куда кидать новых пользователей.
Собственно задача такая: есть некая "дикая" софтина в которой регаются пользователи (что такое AD и вообще LDAP она не знает) далее из нее экспортируется список юзверей. Далее скриптом юзвери создаются в AD, на дефолтовую для пользователей OU привязана определенная GPO. В виду того что разные подсети c GPO передаются настройки актуальные только для опеределеной подсети. Далее либо юзверь так и остается обрызганным, либо уже вручную перемещаются в нужную OU.
В частности в скрипте не хотелось городить что-то сложнее "net user /add", все-таки пришлось идти немного другим путем.
quote:Это как? Default OU меняется для домена, а не для контроллера.
для каждого из контроллеров отдельная OU куда кидать новых пользователей.
quote:
Originally posted by Bob11:
Это как? Default OU меняется для домена, а не для контроллера.
Странно, а мне всегда казалось что можно для отдельного контроллера сделать сугубо индивидуальные настройки.
з.ы. Короче говоря не суть важно как, главное зачем.
А кто мешает использовать dsadd user вместо net user?
quote:
Originally posted by Bob11:
А кто мешает использовать dsadd user вместо net user?
как то не подумал на счет этого, но средствами powershell в разы удобней, на чем и остановился, но сам факт "бага" заставил обратить на себя внимание.
Еще неизвестно баг ли это. Я бы провел репликацию, потом посмотрел бы чем-нимбудь типа adsiedit. Скорее всего это проблемы net.exe в недокументированном режиме. Хотя интересно что мелкомягкие ответят.
quote:Я вижу непонимание. АД - это распределенная база данных, а контроллер - один из элементов содержащий ее часть. GC содержит всю базу леса. Без обид почитайте http://ru.wikipedia.org/wiki/Active_Directory
Странно, а мне всегда казалось что можно для отдельного контроллера сделать сугубо индивидуальные настройки.
quote:
Originally posted by Bob11:
Еще неизвестно баг ли это. Я бы провел репликацию, потом посмотрел бы чем-нимбудь типа adsiedit. Скорее всего это проблемы net.exe в недокументированном режиме. Хотя интересно что мелкомягкие ответят.
Я вижу непонимание. АД - это распределенная база данных, а контроллер - один из элементов содержащий ее часть. GC содержит всю базу леса. Без обид почитайте http://ru.wikipedia.org/wiki/Active_Directory
Естественно без обид, но дискуссия завернула немного в другую сторону и FSMO в контексте этого вопроса не играет никакой роли.
Я не про FSMO.
quote:Вот эти фразы глаз режут. Юзер создается в домене а не на контроллере итп.
2 контроллера, на обоих изменены дефолтовые OU, причем одинаково изменены,
на 1м создаю юзверя (net user testguest * /add) все пучком, на 2м делаю все точно так-же,
для каждого из контроллеров отдельная OU куда кидать новых пользователей.
quote:
Originally posted by Bob11:
Я не про FSMO.
Вот эти фразы глаз режут. Юзер создается в домене а не на контроллере итп.
Создание юзера происходит на контроллере, в частности в "локальной" БД, а далее уже реплицируется по всему домену, и пока она не пройдет учетка будет актуальна только для родительского контроллера. При создании юзера ему выдается GUID и его выдает именно родительский контроллер, которому RID спускает сразу целую пачку, даже если у контроллера роль RID'а, он все равно жрет их из пачки. По этому до репликации "балом" правит родительский контроллер. Так, что если я не прав ткните носом.
Нет локальной БД, это реплика АД. Соответственно юзер создается в АД, просто пока не прошла репликация оно находится в несогласованном состоянии. Репликация все равно произойдет, поэтому работать с несогласованной базой не имеет смысла. Я понимаю что это проблемы терминологии, но если рассмотреть вашу задачу, то при правильной терминологии решение находится сразу-же. Просто я недавно писал аналогичный скрипт по добавлению компов в домен поэтому в курсе.
quote:
Originally posted by Bob11:
Нет локальной БД, это реплика АД. Соответственно юзер создается в АД, просто пока не прошла репликация оно находится в несогласованном состоянии. Репликация все равно произойдет, поэтому работать с несогласованной базой не имеет смысла. Я понимаю что это проблемы терминологии, но если рассмотреть вашу задачу, то при правильной терминологии решение находится сразу-же. Просто я недавно писал аналогичный скрипт по добавлению компов в домен поэтому в курсе.
По ходу дела в терминологии мы оба страдаем, вооружившись талмудом все таки нашел в чем был косяк. Если интересно в пм, или можете покурить разделение БД AD на контексты.
з.ы. И все таки это баг
не умеет net корректно работать с AD в 12м сервере, 8ра обрабатывает корректно.