Первый домен NT 4.0 в Active Directory: апгрейд без лишних нервов

Клиент работал на NT 4.0 уже несколько лет. Домен небольшой - около сорока пользователей, один PDC, один BDC. Windows 2000 Server давно лежит в коробке, купили ещё весной. Отложили, потому что «и так работает». В сентябре позвонили: хотим Active Directory, хотим групповые политики нормальные, хотим перестать заниматься каждым пользователем руками. Взялись.

Прежде чем что-то трогать - поставили Windows 2000 Professional на рабочие станции ещё в августе, там всё устоялось. Так что рабочие места к домену AD были готовы. Оставалось поднять сам контроллер.

Порядок, который мы согласовали

Схема для NT-домена с одним PDC выглядит так:

1. Берём BDC и делаем из него Windows 2000 Server - это будущий первый контроллер AD.
2. Поднимаем на нём Active Directory, запускаем dcpromo в режиме апгрейда домена.
3. Переводим функциональный уровень домена в mixed mode (пока PDC живёт).
4. Снимаем старый PDC - или оставляем как рядовой сервер, или убираем совсем.
5. Переносим политики, перепроверяем пользователей и группы.

На бумаге аккуратно. На практике вышло три сюрприза.

Ловушка первая - схема и права

Dcpromo при апгрейде домена требует расширить схему AD. Это делается автоматически, но только если у учётки, под которой запускаешь, есть права Schema Admin и Enterprise Admin. У нас был обычный доменный администратор - dcpromo это скромно не сообщил, а просто упал в середине процесса с ошибкой доступа. Хорошо, что не в самом конце.

Подняли учётку до нужного уровня, перезапустили - всё прошло. Но нервы потратили: когда процесс падает на полпути, секунду думаешь, не оставил ли ты домен в полуразобранном состоянии. BDC оказался живым, PDC живым - откатились к исходной точке без потерь.

Вывод простой: перед запуском dcpromo проверить права на схему, а не обнаруживать это в процессе.

Ловушка вторая - mixed mode и репликация

После успешного апгрейда домен живёт в mixed mode: AD-контроллер и старый NT PDC сосуществуют, реплицируются по старому протоколу. Это нормально и документировано. Но мы не ожидали, что при смене пароля на AD-контроллере изменения добираются до PDC с задержкой в несколько минут. Один пользователь поменял пароль, зашёл на машину, которая ещё ходила на PDC за авторизацией, - получил отказ. Позвонил. Разбирались минут двадцать, пока не поняли, что дело просто в репликации.

В итоге PDC убрали на следующий день - держать его не было смысла, только путаница. Переключили домен в native mode, отключили поддержку NT BDC. Всё стало ровнее.

Ловушка третья - политики не переезжают сами

В NT 4.0 политики хранятся в System Policy Editor - это файл ntconfig.pol на netlogon. Active Directory их не импортирует автоматически. Мы знали про это теоретически, но всё равно потратили время, когда несколько настроек рабочего стола перестали применяться после переезда.

Пришлось переносить руками через Group Policy Object. Настроек было немного - с десяток параметров реестра и ограничения на панель управления. Создали новый GPO, перенесли вручную, проверили применение через gpresult. Заняло часа полтора, потому что надо было проверить каждый параметр: часть в NT Policy и в AD GPO называется по-разному, часть вообще переехала в другие ветки реестра.

Хорошая новость: GPO в AD гибче, чем ntconfig.pol. Часть настроек, которые в NT делались через реестр вручную, теперь настраиваются нормально через интерфейс.

Итог

Домен переехал за два дня - один день апгрейд контроллера и проверка пользователей, второй день политики и тест на всём парке. Сорок пользователей, никто ничего не заметил в плохом смысле.

Что стоит держать в голове при таком переезде:

• Права Schema Admin/Enterprise Admin - проверить до запуска dcpromo, не после ошибки.
• Mixed mode - это временное. Чем дольше держишь старый PDC, тем больше вероятность путаницы с репликацией паролей. Убирать быстро.
• Политики NT в AD не мигрируют. Сделать список текущих параметров ntconfig.pol заранее и перенести руками в GPO.

Поддержку AD-инфраструктуры на постоянной основе мы ведём в рамках обслуживания ИТ-инфраструктуры. Проще, когда это не разовый переезд, а систематическая работа.