Иногда необходимость модернизации Active Directory обнаруживается во время совсем другой работы. Нужно обновить сертификат для корпоративного веб-приложения, добавить сервер или настроить резервное копирование — и выясняется, что контроллеры домена работают на Windows Server 2008 и 2012 R2, а сам домен сохранил настройки начала 2000-х.

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

Разберу это на обезличенном примере проекта, который начался с обновления TLS-сертификата. Сертификат удалось заменить, а проверка инфраструктуры показала отдельную задачу: старые контроллеры нужно планомерно выводить из эксплуатации. Ниже — что было установлено инструментально и какой путь модернизации из этого следует. Эти работы относятся к разным этапам: выпуск сертификата сам по себе не обновляет Active Directory.

Почему старые контроллеры нельзя оставлять «пока всё работает»

В рассматриваемом домене действовали два контроллера: Windows Server 2008 и Windows Server 2012 R2. Первый держал все пять ролей FSMO, включая PDC Emulator — роль, важную для иерархии времени. Функциональные уровни домена и леса оставались на Windows Server 2003.

Обычная расширенная поддержка Windows Server 2008 закончилась в январе 2020 года, Windows Server 2012 R2 — в октябре 2023 года. Для 2012 R2 существуют платные Extended Security Updates при выполнении условий программы, но они дают время на миграцию, а не заменяют её. Своевременная установка доступных обновлений важна, однако она не позволяет бесконечно эксплуатировать DC на неподдерживаемой ОС. Считать старую ОС защищённой только потому, что сервер отвечает на запросы, нельзя.

Вторая проблема — совместимость с новым поколением контроллеров. Функциональный уровень не равен версии Windows на конкретном сервере. Он задаёт возможности домена и ограничения для DC, которые можно в него добавить. По документации Microsoft, Windows Server 2019 и более новые DC требуют как минимум функционального уровня леса Windows Server 2008. Для ввода DC на Windows Server 2025 в существующий домен требования выше: нужны функциональные уровни домена и леса Windows Server 2016 (условия Microsoft). Поэтому в описанном состоянии нельзя просто поставить новый сервер и сразу назначить его контроллером домена.

Это не означает, что инфраструктура обречена на полную перестройку или что все рабочие станции придётся заново включать в домен. Обычно путь состоит из последовательных изменений в существующем лесу. Но до них нужно установить реальное состояние AD, а не полагаться на схему серверов, составленную много лет назад.

Как сертификат привёл к проверке AD

Веб-приложение работало на Windows Server 2008 через IIS и HTTP.sys на нестандартных HTTPS-портах. Прежний сертификат давно истёк. Современный ACME-клиент решили запускать на отдельном Windows Server 2022, а не на старом веб-сервере или контроллере домена: разработчик win-acme описывает работу с актуальной версией клиента на новой ОС и вынос выпуска сертификата на другую машину для старых Windows.

Для проверки владения публичным именем выбрали DNS-01. Этот способ проверяет TXT-запись в публичной DNS-зоне и не зависит от того, на каком нестандартном порту открыто приложение. В отличие от него, HTTP-01 у Let’s Encrypt начинает проверку через порт 80 (описание способов проверки). Публичная зона у DNS-провайдера и внутренние зоны Active Directory — разные системы; ошибку внутреннего AD DNS нельзя объявлять причиной просроченного сертификата.

В выбранной схеме отдельный сервер и будущая управляемая доставка сертификата опирались на внутреннюю инфраструктуру: разрешение имён, доменные учётные записи, предсказуемые политики и время. Поэтому до дальнейшей автоматизации проверили действующие контроллеры и DNS.

Первый взгляд выглядел обнадёживающе: сводка репликации показывала ноль ошибок в проверенных направлениях, действующие контроллеры публиковали необходимые записи. Однако dcdiag выявил ошибки делегирования: в DNS оставались ссылки на давно выведенные серверы без соответствующих адресных записей. В каталоге обнаружились следы старых узлов, и пришлось отдельно доказывать, какие из них действительно больше не являются контроллерами.

Ещё одна находка касалась времени. PDC Emulator сообщал источником Local CMOS Clock, а сравнение с доступными внешними источниками показывало расхождение примерно в 53 секунды. При этом эффективная настройка W32Time приходила из групповой политики и перекрывала локальные параметры. Одна команда настройки NTP на сервере здесь не устранила бы причину: нужно разбирать применённую GPO и проверять фактический источник после изменения. Microsoft описывает приоритет политики над локальной конфигурацией W32Time и рекомендует настроить для корневого PDC надёжный источник времени (рекомендация). Это был выявленный риск, а не доказанная причина ошибки выпуска сертификата.

Что исправили, прежде чем двигаться дальше

Сначала сохранили исходное состояние AD и DNS и сверили ответы обоих действующих контроллеров. Затем по отдельности проверили делегирование внутренней зоны, NS-записи, записи поиска контроллеров, остатки старых серверов в AD Sites and Services и расположение реплик DNS-разделов. Сам факт существования старого имени в DNS не был основанием удалить его: требовалось установить, что за ним нет действующего DC или другого сервиса.

Исправления проводили небольшими пакетами. Сначала в делегировании подтвердили оба действующих DNS-сервера. После проверки репликации удалили устаревшую NS-запись. Следующим изменением убрали семь точно идентифицированных записей в зоне _msdcs: ссылки на выведенные серверы и устаревшие SRV/CNAME. Каждый пакет сопровождался снимком состояния, проверкой ответов обоих DNS и возможностью точечного возврата записи.

В одном из следующих изменений защитная проверка остановила скрипт: после удаления NS фактическое представление верхушки зоны оказалось не тем, которое ожидалось. Изменение уже произошло. Повторять удаление было бы ошибкой. Сначала прочитали состояние обоих DNS без записи, затем проверили действующие NS и только после этого приняли результат. Это хороший пример, почему сообщение STOP или код завершения инструмента не заменяют проверку фактического состояния.

После адресных исправлений итоговая проверка dcdiag не выдала ошибок, а сводка repadmin показала отсутствие ошибок репликации в проверенных направлениях. Это результат этапа ремонта DNS, а не подтверждение полной модернизации или отсутствия всех рисков в домене. Остаточные legacy-зоны и ссылки разбираются отдельно; массовой очистки не делали.

Для сервиса затем вручную выпустили новый сертификат на отдельной машине и переключили только заранее определённые HTTPS-привязки старого IIS. Проверка TLS прошла, а ответ приложения 401 Unauthorized показал, что после успешного защищённого соединения сработала прикладная авторизация. Автоматическое продление в этом проекте ещё не завершено: задача расписания отключена, поскольку ручной DNS-01 не сможет надёжно повториться сам. Старый веб-сервер также остаётся отдельным объектом модернизации.

Как перейти от ремонта к замене старых DC

Для домена с двумя контроллерами Windows Server 2008/2012 R2 и уровнями 2003 разумен поэтапный план. Конкретные окна работ и команды определяются после обследования; ниже — последовательность решений и контрольных условий, а не универсальная команда «обновить домен».

  1. Проверить восстановление и зависимости. Установить полный список DC, роли FSMO и Global Catalog, версии ОС, DNS-зоны, репликацию AD и SYSVOL, публикацию SYSVOL/NETLOGON, события и применённые GPO. Получить проверяемые резервные копии состояния системы контроллеров и план восстановления. Экспорт DNS или снапшот виртуальной машины не заменяют AD-совместимую резервную копию System State. Отдельно инвентаризировать приложения, жёстко привязанные к именам и адресам старых DC.
  2. Устранить неисправности до миграции. Проверить репликацию между всеми DC, внутренний DNS, разрешение записей поиска контроллеров, доступность SYSVOL и источник времени PDC. Устаревшие NS, SRV и объекты бывших DC удалять только после доказательства, что они больше не обслуживают инфраструктуру. Изменение времени выделить в отдельное окно: перенос PDC Emulator потребует заново проверить всю иерархию времени.
  3. Согласовать промежуточные уровни. При действующих DC не старше Windows Server 2008 и отсутствии скрытых старых контроллеров можно планировать повышение уровней домена и леса с 2003 как минимум до 2008. Для перехода к DC на Windows Server 2022 лес должен быть не ниже уровня 2008; уровень домена 2008 нужен также для планирования миграции SYSVOL с FRS на DFSR, если она потребуется. Перед повышением проверяют совместимость всех доменов и приложений, готовность резервных копий и отсутствие ошибок репликации. Функциональные уровни не повышают «на всякий случай»: возврат ограничен и зависит от конкретного перехода (Microsoft).
  4. Отдельно выяснить состояние SYSVOL. Уровень домена 2003 сам по себе не доказывает, что SYSVOL реплицируется через FRS: это проверяют на работающей системе. Если используется FRS, перед вводом современного DC нужна спланированная миграция на DFS Replication с контролем состояния на каждом контроллере. Microsoft предупреждает, что переход FRS → DFSR после завершения необратим. Расхождения SYSVOL устраняют до этого шага.
  5. Вводить новые DC и выводить старые по одному. После прохождения предварительных проверок развернуть серверы с чистой установкой совместимой версии Windows Server — например, 2022 после подготовки уровней и SYSVOL, — добавить их как DC существующего домена, дождаться репликации и проверить DNS, SYSVOL, вход пользователей и работу приложений. Перенести роли FSMO, включая PDC Emulator, настроить новый источник времени и лишь затем штатно понизить каждый старый DC. Именно такой путь с установкой новых серверов и последующим выводом старых рекомендует Microsoft вместо обновления ОС действующего DC поверх старой установки.
  6. Повышать итоговые уровни после вывода старых ОС. Для функциональных уровней Windows Server 2016 все оставшиеся DC должны работать на совместимых версиях. Только после проверки этого условия, репликации и резервного копирования имеет смысл решать, требуется ли соответствующее повышение. Если целевая версия DC — Windows Server 2025, функциональные уровни домена и леса 2016 понадобятся до его повышения до DC. Если целевая версия — Windows Server 2022, отдельного функционального уровня «2022» нет: максимальный для неё — 2016.

Такой план сохраняет существующий домен, учётные записи и большинство настроек, но не переносит автоматически на новые ОС приложения со старых серверов и не исправляет небезопасные права или политики. Проверка безопасности и совместимости нужна перед заменой DC и после неё.

С чего начать владельцу инфраструктуры

Если в компании есть контроллеры Windows Server 2008 или 2012 R2, первым результатом проекта должен стать не счёт на новые лицензии, а понятная карта состояния: какие DC действительно работают, кто держит FSMO, чем реплицируется SYSVOL, откуда берётся время, какие сервисы зависят от старых адресов и насколько проверяемо восстановление AD. По этой карте уже можно определить порядок изменений, окна работ и условия остановки.

В описанном проекте удалось восстановить корректные DNS-ответы действующих контроллеров и решить срочную задачу с TLS. Это дало управляемую отправную точку. Вывод старых DC, завершение настройки времени и автоматизация продления сертификата остаются отдельными этапами. Именно так и стоит относиться к модернизации Active Directory: вовремя устранять технический долг, проверять каждое изменение и не выдавать временный обходной путь за окончательное обновление домена.

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