Как работает Active Directory на двух площадках?

Active Directory на двух площадках должна переживать обрыв межплощадочного канала без остановки локальной аутентификации. Для этого на каждой площадке нужен пригодный к работе контроллер домена, локальный DNS, правильно описанная топология сайтов и заранее проверенная зависимость приложений от центра. Один контроллер в центре и «кэшированные пароли в филиале» не дают такой устойчивости.

Сам обрыв WAN обычно не повреждает каталог. Опасность начинается раньше, когда клиенты выбирают не тот контроллер, и позже, когда администратор принимает накопившуюся очередь репликации за резервную копию или без проверки возвращает в сеть давно отключенный DC. Я видел больше аварий из-за неверного DNS и поспешного восстановления снимка виртуальной машины, чем из-за механизма репликации AD DS.

Контроллер на каждой площадке меняет границу отказа

Размещайте минимум один записываемый контроллер домена и DNS-сервер на каждой площадке, которая должна продолжать работу без WAN. Тогда локальные компьютеры смогут найти DC через DNS, получить Kerberos-билеты, проверить пароль, применить уже доступные групповые политики и обращаться к локальным службам, пока центр недоступен.

Два контроллера в одном дата-центре защищают от отказа сервера, но не от обрыва трассы, ошибки маршрутизации, отказа пограничного оборудования или отключения всей площадки. Перед обсуждением числа DC зафиксируйте требование: какие операции должны выполняться в филиале при полной изоляции и сколько времени. «Пользователи войдут в Windows» слишком расплывчато.

Для небольшой второй площадки один локальный DC часто оправдан, если площадка не может принять стоимость двух серверов. Но это осознанная точка отказа: при одновременном обрыве WAN и отказе этого DC новые проверки учетных данных прекратятся. Кэшированный вход частично смягчит ситуацию на рабочих станциях, однако не заменит контроллер для файловых ресурсов, приложений и администрирования. На критичной площадке нужны два локальных DC, разнесенные по узлам виртуализации и питанию.

Контроллер можно виртуализировать, но не размещайте оба экземпляра одной площадки на одном хосте, одном массиве и одном ИБП. Гипервизор не отменяет общие зависимости. Зафиксируйте правила размещения, запретите одновременную миграцию обоих DC на один узел и убедитесь, что служба времени, DNS и сеть управления переживают тот же отказ, от которого вы защищаете каталог.

Записываемый DC в филиале удобен, но хранит копию каталога и принимает изменения. Если физическая защита площадки слабая, рассмотрите RODC. Он уменьшает последствия кражи сервера благодаря управляемой политике кэширования паролей, но требует отдельного проектирования: пользователь, чей пароль не разрешен к кэшированию, не пройдет новую проверку при потере связи с записываемым DC. RODC нельзя выбирать только потому, что он «безопаснее».

Глобальный каталог на локальном DC обычно разумен в лесу с несколькими доменами: он нужен для поиска по лесу и определения членства в универсальных группах. Альтернатива для малой площадки, кэширование членства в универсальных группах, уменьшает объем реплицируемых данных, но добавляет зависимость от того, успел ли кэш обновиться. При двух площадках экономия редко стоит лишней переменной, если канал не настолько ограничен, что репликация GC действительно мешает прикладному трафику.

Не создавайте отдельный домен только ради второй площадки. Домен задает административную и репликационную границу для раздела каталога, но не обеспечивает автономность лучше правильно размещенного DC того же домена. Новый домен добавит DNS-делегирование, доверительные отношения внутри леса, отдельные политики, группы и процедуры восстановления. Для обычной пары «центр и филиал» один домен и два сайта проще проверять и восстанавливать.

Мощность контроллера выбирайте по пиковому числу проверок, LDAP-запросов, DNS-нагрузке и размеру каталога, а не по средней загрузке процессора в спокойный день. Проверьте, что локальный DC обслужит площадку один, когда партнер остановлен на обслуживание. Оставьте запас диска под NTDS, журналы, SYSVOL и диагностику: переполненный системный том способен остановить службы именно тогда, когда удаленная помощь недоступна.

Сайты и подсети управляют выбором контроллера

Active Directory Site описывает область надежной и быстрой сетевой связности, а не офис в организационной структуре. Создайте отдельный сайт для каждой площадки и привяжите к нему все клиентские подсети, включая проводные VLAN, Wi-Fi, серверные сегменты, VPN-пулы и новые диапазоны после адресного переезда.

DC Locator использует DNS SRV-записи и сведения о сайте, чтобы найти подходящий контроллер. Microsoft описывает процесс так: клиент получает список DC через DNS, проверяет доступность и кэширует выбранный контроллер через Netlogon. Если подсеть клиента отсутствует в Active Directory Sites and Services, клиент может получить контроллер не своей площадки. Пока WAN работает, ошибка выглядит как небольшая задержка. После обрыва она превращается в долгий вход, ошибки Kerberos и жалобы на «недоступный домен», хотя локальный DC исправен.

Проверяйте сопоставление с клиентской машины, а не только в консоли администратора:

nltest /dsgetsite
nltest /dsgetdc:corp.example /force
Resolve-DnsName _ldap._tcp.Branch-A._sites.dc._msdcs.corp.example -Type SRV

Первая команда должна вернуть ожидаемый сайт, например Branch-A. Во второй ищите имя локального DC и флаги KDC, TIMESERV, WRITABLE и, если требуется, GC. Третья должна показать site-specific SRV-запись локального контроллера. Если тест возвращает центральный DC, не лечите это статической записью в hosts: исправьте объект подсети, DNS-регистрацию и сетевую доступность.

Сделайте выгрузку подсетей частью управления IP-адресами. Частая поломка выглядит так: сетевой инженер добавил VLAN, DHCP уже раздает адреса, а команда AD узнает об этом после инцидента. Простая таблица «CIDR, сайт, владелец, назначение» полезнее красивой схемы, которую обновляют раз в год.

Не объединяйте площадки в один сайт ради «простоты», если между ними WAN. Внутрисайтовая репликация предполагает хорошую связь и активно уведомляет партнеров об изменениях. Межсайтовая репликация сжимает трафик, учитывает расписание и стоимость пути. Неверная модель заставляет AD использовать канал не так, как рассчитывает сеть.

Сами контроллеры тоже должны находиться в правильных объектах Site. После переноса VM между площадками ее AD-объект сервера не переезжает вслед за IP автоматически. Сверьте расположение объекта NTDS Settings, адрес интерфейса, привязанную подсеть и SRV-регистрацию. DC, логически оставленный в HQ, но физически работающий в Branch-A, заставит KCC строить связи на ложной карте.

Пустые или перекрывающиеся объекты Subnet требуют такого же внимания. Active Directory выбирает наиболее специфичное совпадение, поэтому забытая сеть /16 может скрыть отсутствие новых /24, пока адреса не изменятся. Экспортируйте список, сравнивайте его с IPAM и отмечайте события Netlogon о клиентах без сайта. Это дешевый контроль, который предотвращает длинное расследование после обрыва.

Стоимость связи выбирает путь, а расписание задает окно

Site Link сообщает KCC, какие сайты могут обмениваться репликацией, с какой относительной стоимостью и когда связь доступна. Стоимость не измеряет мегабиты, задержку или цену оператора. Это безразмерный вес: AD предпочитает маршрут с меньшей суммарной стоимостью.

Для двух площадок с одним каналом достаточно одной IP site link, включающей оба сайта. Поставьте осмысленное имя, оставьте доступность 24/7 и выберите интервал по допустимой задержке изменений. В современных локальных сетях разумнее начать с 15 минут, затем измерить нагрузку, чем сохранять историческое значение 180 минут без причины. Microsoft указывает 180 минут как стандартный интервал межсайтовой репликации и позволяет менять его через ReplicationFrequencyInMinutes.

Если есть основной MPLS и резервный VPN, не пытайтесь изобразить два физических канала двумя site link между той же парой сайтов. AD видит IP-связность между контроллерами, а маршрутизацию выбирает сеть. Стоимости связей AD полезны, когда существуют разные логические пути через три и более сайта. Переключение MPLS на VPN должны обеспечить маршрутизаторы или SD-WAN, сохранив нужные порты и разрешение имен.

При трех и более площадках проверьте site link bridging. По умолчанию AD может считать IP site links транзитивными и построить путь через промежуточный сайт, если стоимости это допускают. Такая логика верна только когда сеть действительно маршрутизирует трафик между всеми включенными сайтами. В hub-and-spoke сети без связи branch-to-branch либо обеспечьте путь через hub на сетевом уровне, либо отключите автоматическое bridging и создайте нужные мосты явно.

Расписание запрещает межсайтовую репликацию вне разрешенных 15-минутных блоков. Оно не ограничивает полосу внутри разрешенного окна и не гарантирует, что большая очередь успеет передаться до закрытия окна. Запрет репликации в рабочее время популярен на узких каналах, но часто ошибочен: пароль, блокировка учетной записи и изменение группы безопасности будут дольше расходиться между площадками. Для безопасности и предсказуемости лучше разрешить репликацию постоянно, задать подходящий интервал и управлять качеством сервиса на сетевом уровне.

Создать связь можно воспроизводимой командой:

New-ADReplicationSiteLink -Name "HQ-Branch-A" `
  -SitesIncluded "HQ","Branch-A" `
  -Cost 100 `
  -ReplicationFrequencyInMinutes 15 `
  -InterSiteTransportProtocol IP

После изменения не судите по наличию объекта в консоли. Проверьте сгенерированные connection objects и реальный результат:

repadmin /showrepl * /csv
repadmin /replsummary
dcdiag /test:replications /e /v

В repadmin /replsummary важны largest delta, число ошибок и процент неудач. Нулевая ошибка при растущем largest delta не означает здоровье, если расписание или топология не дают свежей репликации. Для постоянного контроля собирайте момент последнего успешного обмена по каждому naming context, а не только доступность TCP-порта.

При обрыве канала каждая площадка продолжает со своей копией

После разрыва WAN контроллеры не переходят в специальный автономный режим. Каждый записываемый DC продолжает принимать локальные изменения в своей копии каталога, выдает Kerberos-билеты и отвечает на LDAP-запросы. Непереданные изменения ждут восстановления связности.

Пользователь на компьютере филиала войдет в домен через локальный DC, если DNS и сайт настроены правильно. Он получит доступ к локальному файловому серверу или приложению, если те тоже используют локальные DNS и DC и не зависят от центра по данным, лицензированию или сетевому маршруту. AD может быть доступна, а бизнес-служба все равно остановится из-за центральной базы данных. Поэтому тест изоляции должен включать прикладной путь целиком.

Компьютер без доступного DC может впустить ранее входившего пользователя по кэшированным учетным данным. Microsoft прямо предупреждает: такой вход открывает локальный рабочий стол, но не дает доступ к ресурсам, которым нужна доменная проверка. По умолчанию Windows обычно хранит сведения для десяти уникальных пользователей, а политика Interactive logon: Number of previous logons to cache может изменить число. Кэш не получает новый пароль, пока компьютер не свяжется с DC.

Это создает неприятную, но закономерную картину. Пользователь сменил пароль через центральный сервис до обрыва, а рабочая станция филиала не видела успешного входа с новым паролем. В автономном входе может сработать старый пароль, тогда как серверный ресурс после восстановления связи уже потребует новый. Нельзя объяснять персоналу, что «AD работает офлайн», не оговорив эту разницу.

Изменения на двух площадках не блокируются. Если администраторы одновременно поменяют разные атрибуты объекта, AD обычно объединит изменения по метаданным атрибутов. Если они изменят один атрибут, победит версия с более высоким номером, а при равной версии учитываются время и идентификатор инициирующего DC. Это механизм разрешения конфликтов, а не совместное редактирование. На время изоляции запретите параллельные изменения групп, GPO и учетных записей, если результат имеет значение для доступа.

Смена пароля обрабатывается лучше обычной задержки репликации: контроллер, получивший неверный пароль, может обратиться к владельцу роли PDC Emulator, чтобы проверить недавнее изменение. Но при разрыве между площадками этот путь недоступен. Назначение PDC Emulator не делает центральный DC обязательным для каждого входа, однако операции со свежими паролями и некоторые административные действия становятся чувствительны к месту изменения.

Уже выданный Kerberos-билет продолжает жить до истечения срока, даже если связь пропала или учетную запись заблокировали на другой площадке. Поэтому в первые часы аварии доступ может выглядеть стабильнее, чем будет позже. Для теста очищайте билеты только на выделенной машине и проверяйте повторную выдачу командой klist get, иначе вы измерите работу старого билета, а не доступность локального KDC.

Блокировка учетной записи и отключение пользователя тоже не становятся мгновенно общими через оборванный канал. Локальный DC действует по своей версии данных. На время изоляции сообщайте службе безопасности, где выполнено действие, какие DC его знают и какие ресурсы остаются доступны по уже выданным билетам. Репликация после возврата синхронизирует каталог, но не вернет время, когда запрет еще не дошел до второй площадки.

DNS, глобальный каталог и приложения решают исход изоляции

Локальный DNS с AD-интегрированной зоной нужен на каждой автономной площадке, потому что клиенты и сами контроллеры находят службы каталога через DNS. Указание публичного DNS или DNS провайдера на сетевых интерфейсах доменных компьютеров ломает поиск SRV-записей. Пересылку внешних запросов настраивайте на корпоративных DNS-серверах, а клиентам выдавайте только DNS, которые знают доменную зону.

Для DC с установленным DNS допустимы разные порядки локального и удаленного адреса, но каждый имеет последствия. Microsoft отмечает: контроллер, который предпочитает удаленный DNS, сильнее зависит от WAN; контроллер, который предпочитает себя, зависит от актуальности репликации зоны. Для двух площадок я ставлю локальный AD DNS первым, второй локальный DNS вторым, если он есть, и удаленный корпоративный DNS последним. После смены параметров очищаю кэш, регистрирую записи и проверяю зону, а не предполагаю, что служба сама все исправила.

ipconfig /all
ipconfig /flushdns
ipconfig /registerdns
dcdiag /test:dns /e /v

Зеленый ping по IP ничего не доказывает. Репликация AD требует разрешения GUID-based имен партнеров, RPC Endpoint Mapper, динамического диапазона RPC, LDAP, Kerberos, SMB и DNS. Фильтр, который пропускает 53 и 389, но режет RPC, оставляет видимость работающего каталога и постоянную очередь репликации. Проверяйте правила по документированному набору портов Windows Server и тестируйте фактическую сессию между DC в обоих направлениях.

Глобальный каталог влияет на вход пользователей в многодоменном лесу и на приложения, которые делают forest-wide поиск. Если локального GC нет, а WAN исчез, пользователь может столкнуться с отказом входа, даже когда обычный DC доступен. Исключение для членов группы Domain Admins при некоторых условиях не является планом устойчивости. Назначьте локальный GC или осознанно настройте Universal Group Membership Caching и испытайте его с реальными учетными записями.

Отдельно инвентаризируйте приложения, которые жестко указывают LDAP-сервер центра, используют IP вместо доменного имени, требуют центральный центр сертификации, NPS, файловый путь SYSVOL другого сайта или синхронный вызов базы в центре. Настройка сайтов AD не перенаправит плохо написанное приложение. Для каждого сервиса запишите метод поиска DC, DNS-зависимости, требование GC, сервисную учетную запись и поведение при истечении Kerberos-билета.

Разделяйте чтение и запись LDAP в требованиях приложения. Локальная копия каталога позволит читать большинство объектов, но приложение может направлять запись на заранее выбранный сервер, требовать владельца FSMO или использовать атрибуты, которые не доступны на RODC для изменения. Проведите конкретную операцию создания, изменения и удаления тестового объекта во время изоляции. Успешный поиск пользователя доказывает только чтение.

Групповая политика состоит из объекта в AD и файлов в SYSVOL. NTDS replication может быть исправна, когда DFSR еще отстает или остановлена. В результате оснастка покажет GPO, но клиент не прочитает шаблоны и скрипты. Сравнивайте версии GPO, состояние общего ресурса SYSVOL и события DFS Replication на обоих DC, особенно после долгой очереди или восстановления контроллера.

Репликация не заменяет резервную копию и кворум решений

Репликация делает каталог доступным, но быстро разносит ошибку администратора на все контроллеры. Удаление организационной единицы, неверная GPO, сброс пароля службы или поврежденная запись DNS не остаются на «резервном DC». Второй контроллер хранит еще одну рабочую копию, а резервная копия хранит состояние, к которому можно вернуться по процедуре.

Защищайте как минимум системное состояние нескольких DC и проверяйте восстановление. Храните копии вне общего массива, учетной записи резервного копирования и площадки. Microsoft рекомендует иметь резервную копию хотя бы одного контроллера и следить, чтобы ее возраст не превышал tombstone lifetime. Я добавлю более жесткое требование: копия без проверенного DSRM-пароля, времени восстановления и доступа к носителю во время изоляции существует только в отчете.

Не используйте снимок гипервизора как обычную кнопку отмены. Современные виртуализированные DC распознают корректное восстановление с помощью VM-Generation ID и защищаются от USN rollback, но это не превращает любой snapshot в согласованную резервную копию леса. Поддерживаемый backup системного состояния и задокументированный сценарий восстановления дают понятную точку ответственности.

Роли FSMO тоже не являются кластером и не переходят автоматически из-за потери WAN. Большинство ежедневных входов продолжится без доступного владельца роли. Но создание некоторых объектов, изменение схемы, операции с доменами, выдача RID после исчерпания локального пула и срочная обработка новых паролей могут зависеть от конкретной роли. Не захватывайте роли в филиале при кратком обрыве: после возврата прежнего владельца получите лишнюю и опасную процедуру обратного переноса.

Active Directory Recycle Bin помогает вернуть случайно удаленные объекты с сохранением многих атрибутов, если функция была включена до удаления. Он сокращает число случаев авторитетного восстановления, но не защищает от поврежденных атрибутов, неверных GPO, захваченных административных учетных записей или потери всего леса. Включите его осознанно, настройте делегирование на восстановление и все равно храните системное состояние.

Перед аварией определите порог, после которого бизнес готов объявить потерю площадки, а не просто сетевой инцидент. Решение о seizure роли принимают после подтверждения, что прежний владелец не вернется в сеть в исходном состоянии. Этот порог должен учитывать запас RID, ожидаемые изменения и время ремонта, а не тревогу от красной панели.

Во время разрыва фиксируйте изменения и не чините здоровый каталог

При подтвержденном обрыве сначала отделите сетевую аварию от отказа DC. Проверьте локальный DNS, время, службы AD DS и DNS, локальную аутентификацию и доступность SYSVOL. Затем зафиксируйте время последней успешной репликации для каждого раздела каталога. Не запускайте принудительную репликацию по кругу: она не пробьет отсутствующий маршрут и засорит события вторичными ошибками.

Рабочий журнал инцидента должен содержать немного полей, но заполняться точно:

1. время начала и затронутые сетевые префиксы;
2. доступные DC и владельцы FSMO;
3. административные изменения на каждой стороне;
4. смены паролей привилегированных и сервисных учетных записей;
5. момент восстановления канала и результаты проверки репликации.

Назначьте одну сторону, где разрешены плановые изменения каталога, если бизнес может это выдержать. На второй стороне допускайте только аварийные операции и записывайте старое и новое значение. Такой порядок не нужен AD для математического слияния, он нужен людям, чтобы не получить две правильные по отдельности, но несовместимые конфигурации.

Не отключайте защиту строгой согласованности репликации ради быстрого устранения события 1988 или 2042. Эти события могут означать lingering objects или слишком долгий разрыв. Разрешение принять устаревшие объекты скрывает проблему и распространяет ее. Сначала измерьте длительность изоляции относительно фактического tombstone lifetime леса:

(Get-ADObject `
  "CN=Directory Service,CN=Windows NT,CN=Services,$((Get-ADRootDSE).configurationNamingContext)" `
  -Properties tombstoneLifetime).tombstoneLifetime

В актуальных лесах стандартное значение часто равно 180 дням, но обновление Windows Server не меняет ранее заданный параметр. Поэтому число из чужой памятки не годится для решения о возврате DC. Получите значение из своего каталога и сопоставьте его с последней успешной входящей репликацией.

Сохраняйте вывод диагностики с обеих сторон до изменения настроек. Время события, код ошибки, source DC, destination DC и naming context позволяют отличить DNS, RPC, доступ, рассинхронизацию времени и устаревшие объекты. Скриншот красного значка в панели мониторинга этого не делает. Если требуется помощь другой смены, передайте исходные файлы repadmin и журналы Directory Service, DNS Server, System и DFS Replication.

Возвращайте канал под наблюдением, а не одним нажатием Sync all

После восстановления маршрута сначала проверьте DNS и время между DC, затем обычную репликацию одного ожидаемого партнерства. Если сразу запустить repadmin /syncall на весь лес, одна понятная ошибка превратится в десятки записей, а большой backlog может занять канал раньше прикладного трафика.

Порядок безопасного возврата выглядит так:

1. подтвердите двустороннее разрешение A, SRV и GUID-based CNAME записей;
2. проверьте разницу времени и доступность RPC;
3. выполните repadmin /showrepl на DC обеих площадок;
4. запустите репликацию одного раздела с ожидаемого источника;
5. после успеха проверьте все naming contexts и очередь DFSR для SYSVOL.

Для точечного запуска используйте repadmin /replicate <DestinationDC> <SourceDC> <NamingContext>. В выводе нужен результат Sync from source: ... completed successfully. Затем repadmin /replsummary должен показать уменьшающийся largest delta, нулевые ошибки и свежие успешные попытки. Не ограничивайтесь разделом домена: Configuration и Schema общие для леса, DomainDnsZones и ForestDnsZones влияют на DNS, а SYSVOL идет через DFSR, не через NTDS replication.

Большой backlog после многодневного разрыва не требует удаления connection object или повторного продвижения DC. Дайте штатной репликации время, наблюдайте пропускную способность и ошибки, при необходимости временно защитите трафик AD политикой QoS. Ручное создание множества соединений редко ускоряет процесс предсказуемо, зато мешает KCC и оставляет конфигурацию, о происхождении которой забудут к следующей аварии.

Создайте малое обратимое изменение для проверки бизнес-пути, например тестовую группу в выделенной OU, и проследите ее появление на втором DC:

Get-ADReplicationAttributeMetadata `
  -Object "CN=AD-WAN-Test,OU=Service Tests,DC=corp,DC=example" `
  -Server "dc-branch-a.corp.example" |
  Select-Object AttributeName,Version,LastOriginatingChangeTime,OriginatingServer

Метаданные показывают, какой DC создал версию атрибута и когда. Это сильнее, чем визуально увидеть объект в оснастке, которая могла обратиться к другому контроллеру. После теста удалите объект обычным способом и убедитесь, что удаление тоже реплицировалось.

Завершите возврат проверкой входа нового пользователя, смены пароля, доступа к локальному ресурсу, применения GPO и запроса приложения к локальному DC. Если GSE.kz проектирует серверную платформу и интеграцию для двух площадок, в приемочные испытания стоит включить физический разрыв WAN, а не только выключение одного виртуального DC. Каталог считается устойчивым после наблюдаемого отказа, а не после согласования схемы.

Потерянный контроллер обычно выгоднее построить заново

Если один DC утрачен, а в домене остался исправный контроллер, чаще безопаснее очистить метаданные потерянного DC, построить новый сервер и выполнить обычную репликацию, чем восстанавливать старый образ. Microsoft тоже рекомендует для большинства таких сценариев новый DC или неавторитетное восстановление: рабочая копия каталога остается источником истины, а восстановленный контроллер получает изменения от партнеров.

Перед удалением убедитесь, что сервер действительно не вернется, проверьте роли FSMO, Global Catalog, DNS-зоны, DHCP-настройки, сертификаты и приложения с жестко заданным LDAP endpoint. Если DC держал роль и восстановление невозможно в приемлемый срок, захватите роль на живом DC и никогда не включайте старого владельца без переустановки или корректного понижения.

Неавторитетное восстановление системного состояния уместно, когда нужно вернуть сам контроллер, а другие DC содержат правильный каталог. Авторитетное восстановление нужно для выбранных объектов или SYSVOL, которые должны победить реплицированные копии, и требует отдельной процедуры. Восстановление всего леса применяют, когда нельзя доверять ни одному доступному DC, например после распространенного логического повреждения. Эти три операции отвечают на разные аварии, смешивать их опасно.

Давно отключенный DC требует отдельного решения. Если он не реплицировался дольше tombstone lifetime, не подключайте его «на пять минут, чтобы посмотреть». Microsoft объясняет риск прямо: удаленные объекты могли исчезнуть из остальных копий после garbage collection, а изолированный DC сохранил их как lingering objects. Событие 2042 блокирует входящую репликацию именно для защиты каталога. Обычно такой сервер переустанавливают; очистка lingering objects нужна только по проверенной процедуре с известным хорошим DC.

Очистка метаданных включает больше, чем удаление строки из контейнера Domain Controllers. Проверьте объект сервера и NTDS Settings, DNS A, CNAME и SRV-записи, членство в site link topology, ссылки DFSR, настройки DHCP и записи мониторинга. Используйте поддерживаемое принудительное удаление и metadata cleanup, а затем убедитесь, что живые DC больше не пытаются реплицироваться с утраченным GUID.

Если потеряна вся площадка, сначала восстановите сетевую, DNS- и временную основу на уцелевшей стороне. Затем решите, нужен ли forest recovery или достаточно развернуть новые DC из здоровой копии. Forest recovery начинают с доверенного резервного экземпляра одного DC в корневом домене леса, изолируют восстановленную среду и возвращают домены в предписанном порядке. Это не improvisation для ночной смены, поэтому шаги, носители, DSRM-пароли и ответственные должны существовать до аварии.

Испытание изоляции дает ответ до настоящего обрыва

Проверяйте архитектуру контролируемым отключением межплощадочного маршрута не реже, чем после крупных изменений сети, DNS, виртуализации или приложений. Тест должен длиться достаточно, чтобы истекли старые Kerberos-билеты и проявились обращения к центру. Пятиминутный запрет ICMP проверяет только терпение инженера.

До теста снимите базовые результаты repadmin /replsummary, dcdiag /e, dcdiag /test:dns /e и состояние DFSR. Подготовьте обычную учетную запись, новую учетную запись, пользователя со свежей сменой пароля и сервисную операцию. Во время изоляции проверьте вход на уже использованном и новом компьютере, доступ к локальным ресурсам, создание билета через klist, применение GPO и работу хотя бы одного критичного приложения.

Отдельно проверьте отрицательный сценарий: остановите локальный DC при уже разорванном WAN. Это покажет, какие компьютеры входят по кэшу, какие службы сразу останавливаются и умеет ли дежурная смена отличить кэшированный вход от доменной аутентификации. После возврата локального DC убедитесь, что время синхронизировалось до проверки Kerberos.

Критерии приемки должны быть измеримыми: клиенты выбирают локальный сайт, локальная аутентификация проходит, DNS отвечает на доменные записи, приложения выполняют заданные операции, очередь репликации после возврата сокращается, а все разделы и SYSVOL сходятся без ошибок. Укажите допустимое время для каждого пункта. Формулировка «система работает штатно» не помогает закрыть дефект.

Мониторинг должен предупреждать до жалоб пользователей. Собирайте возраст последней успешной репликации по каждому партнеру и разделу, события Directory Service 1311, 1925, 1988, 2042, DNS 2087 и 2088, состояние DFSR и свободное место на томах NTDS и SYSVOL. Доступность самого сервера добавьте отдельно: контроллер может отвечать на ping и месяц не получать раздел DNS.

Рабочая схема двух площадок скучна: локальные DC и DNS, полная карта подсетей, постоянно доступная site link, известная роль GC, независимые резервные копии и отрепетированный порядок возврата. Именно скука здесь хороша. Если во время теста команда спорит, какой пароль должен работать и можно ли включать старый DC, архитектура еще не готова к обрыву.