При тестировании скрипта для создания ~ 800 AD-документов на сервере Windows 2008 возникла следующая Ошибка:
Служба каталогов исчерпала пул относительных идентификаторов
После этого все попытки dsadd приводят к паузе ~ 10 секунд и Ошибка dsadd: указанный домен либо не существует, либо с ним невозможно связаться.
После перезапуска сервера первый dsadd выдает сообщение «исчерпал пул», за которым следует «не существует или невозможно связаться»
В журналах событий я вижу
Назначен максимальный идентификатор учетной записи, выделенный этому контроллеру домена. Контроллеру домена не удалось получить новый пул идентификаторов.
И
Запрос на новый пул идентификаторов учетных записей завершился неудачно. Операция будет повторяться, пока запрос не будет успешным. Ошибка: «Запрошенная операция FSMO завершилась неудачно. Невозможно связаться с текущим владельцем FSMO».
Проверка ролей RID / PDC / инфраструктуры FSMO показывает, что все они назначены этому серверу (это домен AD с одним сервером), так что еще может вызывать эту проблему? Я перезапустил сервер, но проблема не устранена.
Новые идентификаторы RID не создаются.
Это говорит о том, что либо служба RID не работает, либо роль хозяина RID неправильно назначена этому серверу, независимо от того, что показывают ваши проверки.
Я бы предложил запустить 'netdom query fsmo', чтобы дважды проверить владельца роли RID
Есть ли ошибки в журналах событий для служб, которые не запускаются?
Это определенно говорит вам, что он не может получить доступ к RID Master, как сказала Ксенни. DCDiag проведет набор тестов, которые дадут вам лучшее представление о том, что происходит:
dcdiag / v / test: Ridmanager
Это даст вам результат, подобный следующему, если все в порядке:
Запуск теста: RidManager
* Доступный пул RID для домена: от 8604 до 1073741823
* mydc1.mydomain.com - это мастер RID
* DsBind с RID Master прошел успешно
* rIDAllocationPool от 7604 до 8103
* rIDPreviousAllocationPool от 7604 до 8103
* rIDNextRID: 7768
......................... MYDC1 прошел тест RidManager
В конце концов отследил это - в DNS для _ldap._tcp.domain.com были случайные записи SRV, которые указывали на старый, удаленный контроллер AD - они не обновлялись должным образом, а контроллер домена обращался к ним и затем не связываться с самим собой по истечении времени ожидания.
Удаление записей вручную устранило проблему.
Среда проработала девять месяцев после удаления старого AD, без тайм-аутов или задержек, так что я не думал проверять при прохождении последних изменений, которые могли вызвать проблему.