Контроллер домена вернулся из простоя, репликация падает с 8614: почему увеличить tombstoneLifetime — плохая идея

Контроллер домена полгода стоял выключенным, а после запуска отвечает на ping и DNS-запросы, но не реплицируется: диагностика показывает 8614, журнал Directory Service — событие 2042. В такой момент особенно соблазнительно увеличить tombstoneLifetime и добиться зелёного отчёта. Я разберу, почему это не возвращает утраченную информацию об удалениях, как отличить реальный долгий простой от скачка времени, как проверить все локальные разделы каталога в advisory-режиме и по каким признакам выбрать между очисткой и переустановкой DC.

Что на самом деле сообщает ошибка 8614

Сценарий обычно начинается буднично: площадку закрыли на ремонт, стойку обесточили, физический контроллер убрали на склад. Через несколько месяцев сервер возвращают в сеть. Операционная система загружается, DNS и Netlogon стартуют, но тест репликации отвечает кодом 8614: с момента последней успешной репликации с указанным сервером прошло больше tombstone lifetime. В журнале Directory Service на контроллере назначения появляется событие NTDS Replication 2042: репликация с названным источником остановлена, потому что представление двух машин об удалённых объектах может различаться.

dcdiag /test:replications
repadmin /replsum
repadmin /showrepl * /csv

Удаление в AD DS — это реплицируемое изменение, а не мгновенное физическое стирание строки из каждой копии базы. Без включённой корзины объект превращается в tombstone с сокращённым набором атрибутов. При включённой Active Directory Recycle Bin сначала существует deleted object с сохранёнными атрибутами, затем recycled object. Атрибут msDS-deletedObjectLifetime задаёт длительность первой стадии; если он не задан, используется значение tombstoneLifetime. Сам tombstoneLifetime определяет, сколько живёт tombstone или recycled object до сборки мусора. Поэтому фраза «удалённые объекты хранятся 180 дней» без оговорки о корзине неполна: при корзине стадии и их сроки надо учитывать отдельно.

Сборка мусора запускается независимо на каждом контроллере; стандартный интервал атрибута garbageCollPeriod — 12 часов. Это не означает, что файл Ntds.dit тут же уменьшается: онлайн-сборка освобождает страницы внутри базы для повторного использования, но не выполняет офлайн-дефрагментацию файла. Для леса, созданного Windows Server 2003 SP1 или более новой версией, установленное при создании значение TSL по умолчанию равно 180 дням. Леса, созданные Windows 2000 Server либо Windows Server 2003 без пакета обновления, могут продолжать использовать внутреннее значение 60 дней. Обновление контроллеров до Windows Server 2019, 2022 или 2025 существующий TSL не меняет.

Требование репликации формулируется точно: каждая хранимая копия раздела каталога должна входящей репликацией получить сведения обо всех удалениях в скользящем окне TSL. Если контроллер это окно пропустил, на нём могут остаться объекты, которые на актуальных репликах уже удалены и окончательно собраны. Такие экземпляры называют lingering objects. Ошибка 8614 и событие 2042 не доказывают, что lingering objects уже найдены; они включают временной карантин из-за риска расхождения и заставляют администратора провести проверку до возобновления репликации.

Важно не перепутать роли. Контроллер, записавший 2042 или показавший 8614, является назначением неудачной входящей репликации и именно он применил временной запрет. Это ещё не доказывает, что аппаратная, DNS- или сетевая причина находится на нём. А событие 1988 записывает здоровый контроллер назначения, когда источник пытается прислать обновление lingering object; сам лишний объект находится на источнике. При отключённой Strict Replication Consistency назначение может принять объект и записать 1388. Поэтому фраза «ошибка видна на DC01, значит чистить надо DC01» опасна: сначала читаю поля Source, Destination и Naming Context в конкретном событии.

• 8614 — код временного карантина для входящей репликации после интервала, превышающего TSL;
• 2042 — событие NTDS Replication на контроллере назначения, где указаны источник, последняя успешная репликация и текущий TSL;
• 1988 — назначение со строгой согласованностью заблокировало входящую репликацию раздела от источника с lingering object;
• 1388 — назначение без строгой согласованности запросило полный объект, и удалённый ранее объект был повторно внесён в каталог;
• 8606 и 8240 тоже могут сопровождать проблемы с отсутствующими или отставшими объектами, но это не синонимы 8614.

Почему увеличение tombstoneLifetime не лечит прошлое

Идея выглядит логично: было 180 дней, сервер отсутствовал 224 дня, поставим 400 и пройдём арифметическую проверку. Но TSL описывает срок хранения сведений об удалениях, а не создаёт их заново. На актуальных контроллерах tombstone или recycled object, чей срок уже истёк, мог быть удалён сборщиком мусора. Повышение TSL сегодня не восстанавливает удалённые записи вчерашнего дня из воздуха. Оно лишь расширяет будущий срок хранения и, после распространения нового значения, может перестать срабатывать как временной порог для этого разрыва.

Есть и практическая тонкость, которую форумные рецепты обычно пропускают. tombstoneLifetime хранится на объекте Directory Service в разделе Configuration и реплицируется по лесу. Контроллер в карантине может ещё не получить изменение, сделанное на другом DC, потому что соответствующий раздел тоже не реплицируется. Попытка менять значение локально на проблемной машине создаёт новое исходящее изменение конфигурации именно там, где целостность ещё не доказана. В обоих вариантах администратор меняет лесовое правило ради одной аварийной связи и усложняет расследование.

Когда устаревший DC снова становится источником, строгая согласованность на получателе спасает каталог. Если источник присылает обновление объекта, которого на назначении уже нет, назначение прекращает входящую репликацию конкретного раздела от этого источника и пишет 1988. Если Strict Replication Consistency равна нулю, назначение запросит полный объект и вернёт его в каталог; это фиксируется событием 1388. Воскресший пользователь может принести прежний SID, атрибуты и членства, а старый объект группы — неожиданно попасть в токены доступа. Зелёный результат одного теста после изменения TSL не является доказательством согласованности.

Цена изменения распространяется шире одного DC. Tombstone и recycled objects будут храниться дольше на всех контроллерах, а полезный срок AD-совместимых резервных копий и допустимое окно простоя изменятся на уровне леса. Если msDS-deletedObjectLifetime не задан, он вычисляется из TSL, поэтому вместе с TSL меняется и срок стадии deleted object при включённой корзине. Это может быть осознанным проектным решением, но не аварийной кнопкой для сервера, который уже пропустил удаления.

Штатный локальный механизм для снятия именно временного карантина существует: параметр реестра Allow replication with divergent and corrupt partner в ветке HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters. Microsoft требует сначала проверить и удалить lingering objects во всех локально хранимых разделах, затем установить значение на контроллере, который показывает 8614, устранить исходную ошибку репликации и после успешной синхронизации удалить параметр либо вернуть ноль. Через repadmin это выглядит так:

# Фактический атрибут TSL на объекте конфигурации леса
$ConfigNC = (Get-ADRootDSE -Server GAR-DC01).configurationNamingContext
$DirectoryServiceDn = "CN=Directory Service,CN=Windows NT,CN=Services,$ConfigNC"
Get-ADObject -Server GAR-DC01 -Identity $DirectoryServiceDn -Properties tombstoneLifetime,msDS-DeletedObjectLifetime |
    Select-Object DistinguishedName,tombstoneLifetime,msDS-DeletedObjectLifetime

# Снять временной карантин на одном DC только после проверки и очистки
repadmin /regkey GAR-DC03.garage-pro.ru +allowDivergent

# После успешной репликации немедленно вернуть защиту
repadmin /regkey GAR-DC03.garage-pro.ru -allowDivergent

Если tombstoneLifetime в выводе отсутствует, нельзя автоматически заключать, что любой старый лес использует 180 дней: внутреннее значение зависит от происхождения леса. Событие 2042 показывает TSL, применённый при срабатывании, а история создания леса и официальная документация помогают отличить внутренние 60 дней от 180. Повышение старого, осознанно проверенного значения 60 до 180 дней может быть нормальной профилактической настройкой на будущее. Повышать TSL выше фактического простоя задним числом, чтобы скрыть 8614, я не рекомендую.

• TSL не возвращает уже собранные tombstone и recycled objects;
• изменение реплицируется через раздел Configuration и влияет на весь лес;
• при незаданном `msDS-deletedObjectLifetime` срок deleted object следует за TSL;
• временный карантин снимают на DC с 8614 только после проверки всех его разделов;
• `+allowDivergent` после восстановления обязательно отменяют через `-allowDivergent`.

Сначала проверяю время и реальную длительность разрыва

У 8614 две документированные группы причин. Первая — контроллер назначения действительно не выполнял входящую репликацию раздела от указанного источника дольше TSL. Вторая — системное время назначения перескочило так, что движку репликации интервал показался длиннее TSL. Возможна и цепочка: DC уходит далеко в прошлое, успешно реплицируется с неверной отметкой, затем возвращается в настоящее и видит искусственно огромный разрыв. Поэтому одной даты Last Success недостаточно.

На отдельном физическом сервере я видел именно такую картину: после отключения питания BIOS вернулся на несколько лет назад из-за батарейки CMOS, а Windows успела загрузиться и записать неверные временные метки. В таком случае сам по себе возврат правильных часов ещё не разрешает произвольно снимать карантин: сначала я изучаю события и убеждаюсь, не успел ли DC в неверном времени выполнить входящие или исходящие изменения. Но это принципиально другой инцидент, чем 224 дня реального хранения сервера без питания, и переустанавливать контроллер только по возрасту отметки Last Success было бы ошибкой.

Проверка начинается с трёх ракурсов: текущее состояние W32Time, конфигурация источников и хронология репликации. На PDC Emulator корневого домена должен быть настроен надёжный внешний источник времени; остальные доменные компьютеры обычно следуют доменной иерархии NT5DS. Я ищу даты до установки этой версии ОС, события из будущего, пустые интервалы журнала и резкий разрыв между Last Attempt и Last Success. Команды диагностики не исправляют конфигурацию и безопасны для первого прохода.

w32tm /query /status /verbose
w32tm /query /configuration
w32tm /monitor /domain:garage-pro.ru
repadmin /showrepl GAR-DC03.garage-pro.ru
repadmin /showrepl * /csv > C:\Temp\showrepl.csv

Для Hyper-V официальная рекомендация Microsoft для виртуальных DC — отключить синхронизацию времени между хостом и гостевой ОС, чтобы контроллер следовал доменной иерархии. Это делают в параметрах выключенной виртуальной машины, в Integration Services, сняв Time synchronization. Однако я не переношу этот совет автоматически на VMware, облачного провайдера или аппаратный комплекс: там сверяюсь с документацией конкретного гипервизора. Главное — не оставить два конкурирующих источника, каждый из которых периодически поправляет часы.

Параметры MaxPosPhaseCorrection и MaxNegPhaseCorrection лежат в HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config и ограничивают принимаемую положительную и отрицательную коррекцию. Для контроллеров домена Windows Server 2012 и новее документация Microsoft указывает стандартное значение 172800 секунд, то есть 48 часов. Значение 0xFFFFFFFF означает отсутствие такого предела и не рекомендуется для DC. Сначала я смотрю результирующую конфигурацию, затем причину отклонения; превращать принудительную синхронизацию в замену диагностики нельзя.

w32tm /query /configuration | Select-String 'Type|NtpServer|MaxPosPhaseCorrection|MaxNegPhaseCorrection'
Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Services\W32Time\Config' |
    Select-Object MaxPosPhaseCorrection,MaxNegPhaseCorrection

Команду принудительной синхронизации я запускаю лишь после того, как исправлен источник и оценены журналы. Если часы расходятся на годы, безопаснее планировать обслуживание и контролировать последствия для Kerberos, журналов, сертификатов и репликации, а не слепо выполнять ресинхронизацию на рабочем DC. После нормализации времени повторяю отчёт, но не трактую исчезнувший временной симптом как доказательство отсутствия lingering objects.

• сопоставить Last Success и Last Attempt на всех входящих соседях и по каждому Naming Context;
• проверить события из будущего, даты до установки ОС и интервалы без журналов;
• подтвердить роль PDC Emulator корневого домена и его внешний источник;
• на остальных DC проверить тип NT5DS и отсутствие конкурирующего источника гипервизора;
• проверить пределы положительной и отрицательной коррекции времени до принудительной синхронизации.

Ищу lingering objects по всем разделам, а не только по домену

У repadmin есть advisory-режим: он сравнивает контроллер с актуальной записываемой репликой и регистрирует объекты, которые были бы удалены, но ничего не удаляет. Синтаксис Microsoft задаёт четыре сущности: список назначений с предполагаемыми lingering objects, DSA object GUID эталонного DC, distinguished name раздела и необязательный флаг advisory_mode. GUID нужен от объекта NTDS Settings эталонного контроллера, а не GUID учётной записи компьютера. Его удобно взять из верхней части вывода repadmin /showrepl или repadmin /showreps.

Расхожая инструкция «проверьте домен, Configuration и Schema» неполна. Проверять нужно каждый Naming Context, который проблемный контроллер хранит локально. Помимо доменного, конфигурационного и схемного разделов это обычно application partitions DomainDnsZones и ForestDnsZones; в лесу с дополнительными приложениями могут быть и другие. Глобальный каталог содержит частичные read-only копии доменных разделов других доменов, и их тоже надо проверять. Перечень разделов беру из вывода репликации конкретного DC, а не из памяти.

Эталон обязан иметь актуальную записываемую копию проверяемого раздела и быть доступен очищаемому DC по LDAP, включая порт 389. Для доменного раздела дочернего домена нельзя бездумно использовать GUID контроллера корневого домена, если у того есть только частичная GC-копия: выбираю исправный writable DC именно этого домена. Литерал gc: в первом параметре разворачивается во все глобальные каталоги, но команду всё равно повторяют для каждого проверяемого доменного NC с подходящим эталоном.

Ниже полный сухой проход для одно-доменного леса из разбора. Сначала оператор получает настоящий DSA object GUID из вывода и вводит его в переменную; это исключает путаницу с ObjectGuid компьютерной учётной записи. Все пять стандартных разделов проверяются отдельно.

repadmin /showrepl GAR-DC01.garage-pro.ru
$GoodDsaGuid = Read-Host 'Введите DSA object GUID из вывода GAR-DC01'
$DomainNC = 'DC=garage-pro,DC=ru'
$ConfigurationNC = 'CN=Configuration,DC=garage-pro,DC=ru'
$SchemaNC = 'CN=Schema,CN=Configuration,DC=garage-pro,DC=ru'
$DomainDnsNC = 'DC=DomainDnsZones,DC=garage-pro,DC=ru'
$ForestDnsNC = 'DC=ForestDnsZones,DC=garage-pro,DC=ru'

repadmin /removelingeringobjects GAR-DC03.garage-pro.ru $GoodDsaGuid $DomainNC /advisory_mode
repadmin /removelingeringobjects GAR-DC03.garage-pro.ru $GoodDsaGuid $ConfigurationNC /advisory_mode
repadmin /removelingeringobjects GAR-DC03.garage-pro.ru $GoodDsaGuid $SchemaNC /advisory_mode
repadmin /removelingeringobjects GAR-DC03.garage-pro.ru $GoodDsaGuid $DomainDnsNC /advisory_mode
repadmin /removelingeringobjects GAR-DC03.garage-pro.ru $GoodDsaGuid $ForestDnsNC /advisory_mode

После сухого прохода читаю журнал Directory Service на очищаемом контроллере и сохраняю результаты. Только согласованный список запускаю повторно без флага. В многодоменном лесу отдельно проверяю частичные реплики GC; в следующем примере лес одно-доменный, поэтому одна доменная команда охватывает все GC, но DNS application partitions и Configuration не исчезают из плана проверки.

# Сухая проверка доменного NC на всех GC одно-доменного леса
repadmin /removelingeringobjects gc: $GoodDsaGuid $DomainNC /advisory_mode

# Удаление с одного подтверждённого проблемного DC после анализа журнала
repadmin /removelingeringobjects GAR-DC03.garage-pro.ru $GoodDsaGuid $DomainNC
repadmin /removelingeringobjects GAR-DC03.garage-pro.ru $GoodDsaGuid $ConfigurationNC
repadmin /removelingeringobjects GAR-DC03.garage-pro.ru $GoodDsaGuid $SchemaNC
repadmin /removelingeringobjects GAR-DC03.garage-pro.ru $GoodDsaGuid $DomainDnsNC
repadmin /removelingeringobjects GAR-DC03.garage-pro.ru $GoodDsaGuid $ForestDnsNC

# Включить строгую согласованность на всех DC леса
repadmin /regkey * +strict

Минимальные права из документации: Domain Admins соответствующего домена для доменного раздела; для Configuration и Schema — Enterprise Admins. При лесовом проходе и работе с разными application partitions я заранее проверяю делегированные ACL и обычно выполняю согласованное окно под учётной записью Enterprise Admins, а затем вывожу её из использования. Утилита должна видеть нужные DC по DNS, Kerberos, RPC и LDAP; ошибка подключения не равна нулю найденных объектов.

Microsoft называет Lingering Object Liquidator v2 предпочтительным способом обнаружения и удаления. Актуальная страница Download Center отдаёт версию 2.0.21 от 15 июля 2024 года; утилита умеет advisory-поиск по всем DC и разделам и экспорт в CSV. Но у неё есть граница: при событии 1388 объект уже повторно внесён в каталог, и стандартный проход LoLv2 или repadmin /removelingeringobjects этот сценарий не исправляет. Такой объект оценивают как обычный существующий объект, подтверждают, нужен ли он, и удаляют штатными средствами либо следуют отдельной процедуре для abandoned objects.

• получить DSA object GUID эталона из `repadmin /showrepl`, а не GUID компьютера;
• составить перечень всех локально хранимых NC, включая DNS application partitions;
• для каждого NC выбрать эталон с актуальной writable-копией;
• сначала выполнить `/advisory_mode`, сохранить события и согласовать удаление;
• для GC повторить проверку по доменным NC других доменов с эталонами из этих доменов;
• после очистки включить Strict Replication Consistency и лишь затем временно снять карантин 8614.

Разбор практики: автосервисная сеть «Гараж-Про», 3 точки, 50 РМ

Условный клиент — автосервисная сеть «Гараж-Про», 3 точки, 50 РМ, одно-доменный лес garage-pro.ru. Три контроллера: GAR-DC01 на Windows Server 2019 в центральной точке, GAR-DC02 на Windows Server 2022 в ЦОД и GAR-DC03 на Windows Server 2025 в третьей точке. GAR-DC01 держал все пять FSMO-ролей; GAR-DC01 и GAR-DC02 были глобальными каталогами. Уровни работы леса и домена — Windows Server 2016, что официально допускает DC на Windows Server 2016, 2019, 2022 и 2025. После подготовки схемы под Windows Server 2025 значение objectVersion стало 91.

12 января 2026 года третью точку начали переносить. Стойку отключили, GAR-DC03 перевезли и оставили в подсобке до 24 августа 2026 года: между датами прошло 224 дня. Его включили без окна обслуживания, а рабочие станции площадки по старой DHCP-настройке продолжили использовать этот сервер как первый DNS. Пользователи увидели проблемы с обнаружением домена и входом в опубликованную 1С, хотя сам сервер отвечал на сеть. На GAR-DC03 диагностика показала 8614 и событие 2042; часы были правильными, а Last Success по затронутым связям указывал на 12 января. Это был реальный простой, не скачок времени.

На GAR-DC01 и GAR-DC02 события 1988 показали попытки входящей репликации от GAR-DC03 по доменному NC. Строгая согласованность на обоих назначениях была включена, поэтому разделы от проблемного источника блокировались. Я немедленно изолировал GAR-DC03 от пользовательского трафика, сохранил журналы и построил список всех его NC. Это важно: если оставить сервер обслуживать площадку во время расследования, на нём могут появиться новые локальные изменения — смены паролей, регистрации DNS, изменения групп — и простой сценарий «он всё время был выключен» перестанет быть правдой.

Advisory-проход дал 214 lingering objects в доменном разделе: 118 учётных записей компьютеров, накопившихся после замен и переустановок, 71 пользовательскую учётную запись сезонных и уволенных сотрудников, 19 групп и 6 OU. Сумма сходится: 118 + 71 + 19 + 6 = 214. В Configuration обнаружились ещё 3 объекта: NTDS Settings закрытой площадки и два connection objects. В Schema, DomainDnsZones и ForestDnsZones лишних объектов не было. Проверка GC не выявила дополнительных частичных реплик: лес состоял из одного домена, а GAR-DC03 глобальным каталогом не был.

Главный вопрос был не «можно ли удалить 217 объектов», а «есть ли на GAR-DC03 полезные исходящие изменения, которых нет больше нигде». Одной команды, которая математически докажет отсутствие всех уникальных originating updates, нет. Up-to-dateness vector показывает знания реплики об обновлениях, но не заменяет инвентаризацию. Здесь доказательство строилось из фактов: сервер физически был выключен 224 дня; после первого запуска мы быстро отсекли клиентов; роли FSMO находились на GAR-DC01; аудит AD, сравнение критичных объектов и журналов не показали локальных административных изменений. Отдельно проверили DHCP, DNS и файлы, потому что они не становятся безопасными только от того, что AD-часть признана устаревшей.

На GAR-DC03 оставалась область DHCP на 254 адреса и файловая primary-зона DNS этой точки; перед разжалованием я сделал штатные экспорты и проверил их чтение на тестовом сервере. После этого выбрали принудительное разжалование и новую установку вместо очистки каталога. Вся работа заняла около полутора часов активных операций, не считая установки обновлений: экспорт сервисных данных, forced demotion, очистка метаданных, удаление устаревших DNS-записей, повторное присоединение и promotion. Число 254 относится к адресам области, а не к рабочим местам: у клиента по условию 50 РМ на трёх точках.

Поднимать TSL с 180 до значения больше 224 не понадобилось. Снимать карантин через +allowDivergent тоже не понадобилось, потому что мы не собирались сохранять устаревшую копию базы. После новой promotion GAR-DC03 получил чистые копии разделов и SYSVOL от живого партнёра. Затем я повторил dcdiag, сводку репликации, проверку общих ресурсов SYSVOL и NETLOGON и регистрацию DNS. Строгая согласованность выполнила свою задачу: пока старый DC находился в сети, 214 доменных lingering objects не вернулись на здоровые реплики.

• 224 дня — фактический подтверждённый простой при TSL 180 дней;
• 214 объектов найдены в доменном NC и ещё 3 — в Configuration;
• проверены также Schema, `DomainDnsZones`, `ForestDnsZones` и состав GC;
• FSMO-роли и две здоровые реплики оставались на других контроллерах;
• DHCP-область на 254 адреса и локальную DNS-зону экспортировали отдельно;
• после переустановки выполнена повторная проверка AD DS, SYSVOL, NETLOGON и DNS.

Когда восстанавливаю DC, а когда переустанавливаю

Моя рабочая презумпция проста: если DC действительно был выключен дольше TSL, не держит единственную нужную копию данных и в домене есть здоровые контроллеры, переустановка обычно даёт меньше неопределённости. Это не правило Microsoft «девять из десяти» и не нормативный срок в полтора часа; это выбор по риску. Очистка может быть полностью штатной, но требует доказать полноту по каждому NC и GC. Новая promotion создаёт копию из актуального источника и сокращает число состояний, которые надо объяснять.

Сохранять и лечить контроллер приходится, если он работал в изоляции и принимал изменения, которые не ушли на другие DC. Forced demotion безвозвратно теряет такие добавления, удаления, смены паролей, изменения групп, объектов конфигурации и GPO. Microsoft прямо предупреждает об этой потере originating updates и не считает принудительное разжалование единственным способом восстановления 8614. Тогда я сначала устраняю время, DNS, сеть, аутентификацию или топологию, удаляю lingering objects, временно разрешаю репликацию на DC с 8614, синхронизирую и снова закрываю разрешение.

Особая осторожность нужна с единственным DC домена. Его нельзя трактовать как обычную расходную реплику: forced demotion может означать потерю самого домена. Если проблемный сервер держит FSMO-роли, оцениваю доступность прежнего владельца. Роли переносят штатно, когда владелец доступен, и захватывают с -Force, когда вернуть прежний DC в роль не планируется. После захвата старый владелец нельзя бездумно включать обратно как контроллер. В одно-доменном лесу пять ролей включают Schema Master, Domain Naming Master, PDC Emulator, RID Master и Infrastructure Master.

Перед решением составляю отдельный список не-AD-нагрузок: DHCP, файловые DNS-зоны, центр сертификации, NPS, агенты резервного копирования, профили служб, приложения с локальными базами и ключами. AD-интегрированные зоны должны реплицироваться в своих application partitions, а файловая primary-зона может существовать только на одном сервере. Наличие DHCP на DC не делает область частью базы AD. Эти данные экспортируют и проверяют независимо; иначе технически чистая переустановка домена превращается в потерю сетевой конфигурации.

Для поддерживаемых Windows Server использую Uninstall-ADDSDomainController, а не несуществующий cmdlet Remove-ADDomainController. Пример ниже выполняется локально на проблемном DC после переноса или захвата ролей. Параметр -ForceRemoval применяют, когда нормальная связь для штатного разжалования невозможна; -DemoteOperationMasterRole разрешает продолжить, если локальная проверка всё ещё считает сервер владельцем операции. -Force подавляет подтверждения, поэтому пароль локального Administrator задаю явно и заранее фиксирую план отката.

# Выполнять на GAR-DC01 только если недоступный GAR-DC03 был владельцем ролей
Move-ADDirectoryServerOperationMasterRole -Identity 'GAR-DC01' `
    -OperationMasterRole SchemaMaster,DomainNamingMaster,PDCEmulator,RIDMaster,InfrastructureMaster `
    -Force

# Локально на GAR-DC03: принудительное разжалование
$LocalAdminPassword = Read-Host 'Пароль локального Administrator после разжалования' -AsSecureString
Uninstall-ADDSDomainController -ForceRemoval -DemoteOperationMasterRole `
    -LocalAdministratorPassword $LocalAdminPassword -Force

Принудительное разжалование не удаляет автоматически все сведения о DC с живых партнёров. Актуальная документация Microsoft предлагает два надёжных пути очистки метаданных: удалить объект компьютера контроллера из OU Domain Controllers через Active Directory Users and Computers с подтверждением, что DC постоянно недоступен, — метаданные будут очищены автоматически; либо использовать ntdsutil. В командном варианте подключаюсь к живому партнёру удалённого DC.

ntdsutil
metadata cleanup
connections
connect to server GAR-DC01
quit
remove selected server GAR-DC03
quit
quit

После очистки проверяю, удалён ли NTDS Settings, не остался ли пустой server object из-за других установленных ролей, ушли ли старые connection objects и записи GUID CNAME в _msdcs. Затем проверяю обычные A, AAAA, SRV и NS-записи, делегирование DNS и объект компьютера. Удалять всё по маске имени нельзя: сервер после разжалования может оставаться членом домена с законными записями, а одинаковый префикс может принадлежать другому узлу.

Windows Server 2025 добавляет ещё одну развилку. Новая установка AD DS создаёт базу, способную работать с 32K-страницами, но до включения forest-wide optional feature она использует режим совместимости с 8K. In-place upgrade сохраняет прежний 8K-формат. Для включения Database 32k pages все DC должны работать на Windows Server 2025 или новее, иметь 32K-capable database, а уровни леса и домена должны быть Windows Server 2025. В смешанном лесу из разбора эта фича включена быть не могла; связывать её с лечением 8614 не надо. После включения откат к 8K simulation mode невозможен, и старые 8K backup media нельзя использовать для обычного восстановления такого DC.

• переустановка предпочтительна, когда DC был выключен, уникальных изменений нет и живы другие writable DC;
• очистка и возврат предпочтительны, когда изолированный DC принимал полезные изменения;
• единственный DC домена нельзя удалять по типовой процедуре;
• FSMO-роли сначала штатно переносят либо осознанно захватывают на живом контроллере;
• для forced demotion используется `Uninstall-ADDSDomainController`, а очистка метаданных выполняется через ADUC или `ntdsutil`;
• не-AD-роли и локальные данные инвентаризируют и экспортируют отдельно.

Не забываю про SYSVOL и отдельный карантин DFS-R

Успешная репликация разделов AD DS ещё не означает, что контроллер готов обслуживать вход. SYSVOL в современных доменах реплицируется DFS Replication и имеет собственную content freshness protection. На контроллерах Windows Server 2012 и новее она включена по умолчанию; значение MaxOfflineTimeInDays равно 60. Если репликация папки не выполнялась дольше этого срока, DFSR переводит её в ошибочное состояние и пишет событие 4012. Это независимый механизм: повышение TSL, удаление lingering objects и +allowDivergent его не снимают.

Поэтому после 224 дней GAR-DC03 мог одновременно иметь карантин AD DS по 180-дневному TSL и остановленный SYSVOL по 60-дневному пределу DFSR. Я проверяю наличие общих ресурсов, состояние replicated folder и журнал DFS Replication. В Windows Server 2025 утилита WMIC доступна лишь как Feature on Demand и считается устаревшей, поэтому для WMI-классов DFSR использую PowerShell.

net share
Get-CimInstance -Namespace 'root\MicrosoftDFS' -ClassName DfsrMachineConfig |
    Select-Object MaxOfflineTimeInDays
Get-CimInstance -Namespace 'root\MicrosoftDFS' -ClassName DfsrReplicatedFolderInfo |
    Select-Object ReplicatedFolderName,State

Для DfsrReplicatedFolderInfo состояние 4 означает Normal, 5 — In Error; промежуточные 0–3 имеют отдельные значения и не должны автоматически считаться готовностью. Если сработал 4012, Microsoft рекомендует неавторитетно переинициализировать пострадавший SYSVOL от здоровой копии. Если все DC оказались в состоянии ошибки, сначала выбирают контроллер с заведомо актуальным SYSVOL и только тогда выполняют авторитетную синхронизацию. Поднимать MaxOfflineTimeInDays выше фактического простоя ради запуска старой папки — та же логическая ошибка, что и задним числом растягивать TSL.

В статье я намеренно не привожу универсальный набор ADSI-изменений для авторитетной и неавторитетной синхронизации: выбор msDFSR-Enabled и msDFSR-options, порядок отключения членов и fan-out зависят от того, сколько контроллеров здоровы и где лежит эталонный SYSVOL. Неверно назначенный авторитетный источник способен разнести старые GPO и скрипты входа. Здесь безопаснее открыть официальную процедуру Microsoft для DFSR-replicated SYSVOL и выполнить её по топологии конкретного домена.

После новой promotion ожидаю события 4614 о начале ожидания initial sync и 4604 об успешной инициализации SYSVOL, затем проверяю публикацию SYSVOL и NETLOGON. Событие 2213 относится к паузе DFSR после dirty shutdown и требует отдельной оценки; оно не равнозначно 4012. Такое разделение событий помогает не применять процедуру content freshness к обычной приостановке после некорректного завершения работы.

• событие 4012 — content freshness DFSR, а не ошибка репликации базы AD DS;
• на DC Windows Server 2012 и новее рабочее значение `MaxOfflineTimeInDays` обычно равно 60;
• состояние replicated folder 4 — Normal, состояние 5 — In Error;
• при наличии здоровых DC пострадавший SYSVOL восстанавливают неавторитетно;
• авторитетный SYSVOL выбирают только при отсутствии здоровой реплики и после проверки содержимого;
• после promotion ждут 4614, затем 4604 и проверяют SYSVOL и NETLOGON.

Как не доводить репликацию до TSL

224 дня без успешной репликации — не внезапная авария, а пропущенный сигнал. Microsoft рекомендует ежедневно контролировать сквозную репликацию и отдельно отслеживать DC, дошедшие до 50 % и 90 % TSL. При фактическом TSL 180 дней это 90 и 162 дня. На половине срока уже нужен жёсткий план устранения, на 90 % — решение о принудительном удалении проблемного DC, если восстановление не успевает. Я добавляю более ранний внутренний порог в 30 дней: это моя эксплуатационная политика, не значение по умолчанию Windows.

Самый дешёвый источник данных — CSV от repadmin. Его можно собирать планировщиком и разбирать в PowerShell, Excel или системе мониторинга. Важно тревожиться по каждому сочетанию Source DC, Destination DC и Naming Context: общая сводка может выглядеть терпимо, пока один DNS application partition не реплицируется месяцами. Отдельно отслеживаю 1862, 1863, 1864, 2042, 1988 и ошибки KCC, но событие без контекста не заменяет временной ряд Last Success.

New-Item -ItemType Directory -Path 'C:\ADHealth' -Force | Out-Null
repadmin /showrepl * /csv > C:\ADHealth\showrepl.csv
repadmin /replsum > C:\ADHealth\replsum.txt
repadmin /showbackup > C:\ADHealth\showbackup.txt

Регламент длительного отключения должен опережать переезд. Мой внутренний порог — если DC планируют обесточить больше чем на 30 дней, его штатно разжалуют заранее или назначают владельца, контрольную дату и проверку возврата существенно раньше TSL. Microsoft не устанавливает универсальное правило «разжаловать после 30 дней»; это сознательный запас нашей эксплуатации. Официальная граница риска — фактический TSL, но ждать 179-й день без пользы.

Строгую согласованность проверяю на всех контроллерах. Для лесов, созданных Windows Server 2003 или новее, значение по умолчанию на добавляемых DC равно 1. В лесах, родившихся на Windows 2000 Server, оно могло остаться нулём, а повышение functional level это не исправляет. Команда +strict устанавливает защиту на указанном списке DC; после выполнения читаю результат и журнал, потому что недоступный контроллер мог не получить изменение.

repadmin /regkey * +strict

Сам параметр расположен в HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters, имя — Strict Replication Consistency, тип — REG_DWORD, безопасное значение — 1. Любое временное отключение строгой согласованности оформляю как исключение с владельцем и сроком возврата. При лесовом запуске отдельно фиксирую недоступные узлы: успешное выполнение для части списка не доказывает состояние каждого DC.

Резервные копии тоже связаны с TSL. Microsoft рекомендует регулярно защищать как минимум два writable DC каждого домена для forest recovery, а возраст пригодной AD-совместимой копии не должен превышать применимый срок. Событие 2089 возникает при превышении backup latency interval, который по умолчанию равен половине TSL; при 180 днях это 90. Практически копировать System State стоит значительно чаще — Microsoft указывает ежедневную частоту почти для всех сценариев. Файловая копия Ntds.dit не считается корректной резервной копией AD DS.

Наконец, ежемесячно сверяю источник времени PDC Emulator, батареи физических серверов, настройки гостевого времени и пределы фазовой коррекции. Изменение хозяина PDC, миграция виртуальной машины или замена гипервизора — повод повторить проверку. Такая рутина скучнее разбора lingering objects, зато 8614 остаётся редким предохранителем, а не способом обнаружить, что одну из трёх точек никто не наблюдал семь месяцев.

• ежедневно собирать Last Success по всем источникам, назначениям и NC;
• ставить предупреждения на 50 % и 90 % фактического TSL, а внутренний ранний порог определить регламентом;
• планово разжаловать DC перед длительным хранением либо назначать владельца и дату возврата;
• держать Strict Replication Consistency равной 1 на каждом контроллере;
• ежедневно создавать AD-совместимые резервные копии и контролировать событие 2089;
• регулярно проверять PDC Emulator, внешний источник времени и настройки гипервизора.

Частые вопросы