Существует множество административной литературы о том, как правильно управлять серверами Windows. Но в реальной жизни вещи не всегда происходят так, как вы этого хотите. В Microsoft Windows Server 2003 Administrator's Companion из более чем 1400 страниц есть только одна страница, которую я смог найти, когда дело доходит до настройки дополнительных контроллеров домена. Они делают это бессмысленным и не раскрывают многого о том, что происходит, если «равноправные» контроллеры домена не могут реплицироваться.
Что касается конкретной проблемы, около месяца назад у нас отключился DC из-за неисправного RAID-контроллера. Не было ничего критического, что требовало бы немедленного внимания, так что возвращение на задний план было отложено. Через месяц мы снова запускаем DC, и все казалось нормальным. На следующий день никто не может войти в систему, жалуясь, что "Пользователь не существует" или «не может установить доверительные отношения». Зная, что я только что подключил отключенный DC к сети, я немедленно отключил его от сети и приказал всем перезагрузить рабочие станции. После этого обмен прошел нормально, общие ресурсы стали доступны, и все смогли войти в систему. После некоторого плавания в журнале событий могло показаться, что все началось из-за проблем с репликацией в SYSVOL. Я читал, где можно принудительно выполнить репликацию, но это означало бы вернуть его в сеть. Я боюсь снова включить DC в сеть, опасаясь, что что-то еще может пойти не так. Итак, с какими еще проблемами можно ожидать столкнуться, если два контроллера домена не реплицируются более месяца?
В зависимости от того, сколько времени они не синхронизированы, вы можете столкнуться с ситуацией, когда достигнете своего Срок службы надгробия после чего у вас начинаются проблемы с возвращением удаленных объектов к жизни. При этом минимальное значение по умолчанию составляет 60 дней, поэтому вы должны быть в порядке, если прошло меньше времени.
AD (а также DNS и множество других служб) решает проблемы синхронизации путем увеличения серийного номера при каждом внесении изменений. Итак, если вы использовали PRIMARYDC и внесение изменений, SECONDARYDC будет иметь меньшее число и будет переходить к более высокому.
Если вы ДЕЙСТВИТЕЛЬНО обеспокоены, вы всегда можете стереть SECONDARYDC, вручную извлеките его из Active Directory, повторно создайте образ, а затем аккуратно превратите его в другой DC. Я думаю, вы можете безопасно перенести его в онлайн и решить проблемы с SYSVOL. Если вы хотите быть лишним параноиком, делайте это в нерабочее время, чтобы не получить несоответствий при разрешении SYSVOL.
РЕДАКТИРОВАТЬ Нижеприведенный Adaptr дает хорошее замечание - убедитесь, что никакие роли FSMO не назначены SECONDARYDC перед тем, как стереть его, если вы решите пойти по этому пути.