На столах были аккуратно расставлены салаты и закуски, но нам было не до еды — наступал решающий момент. Нет, это была не встреча Нового года, а один из многих вечеров, которые мы провели за внедрением Active Directory (AD). Знакомая картина: долгие дни, работа до ночи, еда всухомятку.
Шел четвертый день перехода с Windows NT 4.0 на Windows 2000 AD. Процесс подготовки к модернизации продвигался успешно. А затем произошла катастрофа, и закуски полетели по комнате, как будто начался ураган. Что же случилось и как исправить ошибку?
Подготовительные этапы
В нашей среде насчитывалось 30 контроллеров доменов (DC) в одном домене NT 4.0, охватывающем несколько удаленных офисов. Были проведены все важные подготовительные этапы, необходимые для нормального перехода к Windows 2000 и AD.
Мы установили два контроллера домена — DC2 и DC3 — в центральном офисе в Финиксе, и осталось модернизировать 28 резервных DC (BDC) NT 4.0 в различных филиалах. На следующем этапе модернизации планировалось обновить BDC в Делавере (DC1), чтобы использовать преимущества AD при замене клиентов Windows 95 на Windows XP Professional Edition. Два человека работали с DC1 в Делавере, а я и еще один техник сидели у центральной консоли в Финиксе.
Все DC имеют свои отличительные особенности, поэтому к каждому из них необходим индивидуальный подход в процессе миграции. Наша группа тщательно проанализировала процесс миграции DC1, чтобы провести его оптимальным способом. Мы могли выполнить обычную модернизацию, операцию типа «выжженной земли» (очистить жесткий диск с помощью Fdisk или функции Gdisk программы Symantec Ghost и начать все с нуля) или записать новый экземпляр Windows 2000 в существующий каталог winnt. Мы хотели инсталлировать Windows 2000 самым «чистым» способом, поэтому немедленно отвергли сценарий модернизации. Нам не хотелось полностью очищать всю систему, так как DC1 был клиентским узлом доступа Client Access Point (CAP) сервера Microsoft Systems Management Server (SMS) и, следовательно, содержал больше данных, чем мы готовы были удалить и восстанавливать. Поэтому был выбран третий вариант.
Установка
Прежде чем инсталлировать Windows 2000 на DC1, были сделаны резервные копии системы и всех файлов. Затем делаверская группа провела «чистую» установку Windows 2000, а мы с волнением ожидали результата.
Удаленная группа установила Windows 2000 на DC1, назначив систему автономным сервером. После перезагрузки удаленная группа запустила утилиту Dcpromo и выбрала DC1 как точную копию DC для данного домена. Началась синхронизация AD, и казалось, все идет прекрасно. Система перезагрузилась после репликации. Мы дождались, когда DC выведет консоль MMC и оснастки Active Directory Users and Computers и Active Directory Sites and Services и DNS. Оставалась одна проблема: DC1 был не в том узле. Наша группа в Финиксе воспользовалась оснасткой Active Directory Sites and Services, чтобы перенести DC1 в нужное место — и с этого момента начались наши беды. В AD нарушилась связь между DC2 и DC1, и DC1, казалось, исчез с лица Земли, а по комнате полетели тарелки.
Мы несколько раз безуспешно попытались перезагрузиться, а затем проанализировали ситуацию. Наш сервер Windows 2000 не выполнял в домене роли DC. Мы запустили Dcpromo на DC1, чтобы перевести DC в автономные серверы и очистить базу данных, но сделать этого не удалось. DC1 не имел связи с доменом и существовал сам по себе.
Требовалось быстро принять решение, которое, однако, не вызовет проблем в будущем. Нам предстояло выбрать один из следующих путей.
- Переустановить DC1 с другим именем NetBIOS. Но поскольку DC1 был сервером SMS CAP, все клиенты в Делавере использовали существующее имя. Для этого варианта требовалось меньше всего времени, но в дальнейшем пришлось бы провести большую работу по очистке.
- Удалить DC1 из AD, а затем реинсталлировать DC1 с первоначальным именем. Этот вариант был быстрым, но рискованным. Если в базе данных AD останутся межсайтовые соединения существующего DC, то у нового DC возникнут сложности с дублированием имен.
- Удалить DC1 из AD, а затем очистить базу данных AD и переустановить DC1 с первоначальным именем. Это самый трудоемкий, но, на наш взгляд, самый надежный метод.
Мы выбрали третий способ. Нам нужно было удалить DC1 из рабочей среды, очистить базу данных AD и переустановить DC1 с первоначальным именем.
Очистка
Если в AD существует «осиротевший» DC, то чистка затрагивает многие области. Необходимо удалить объект computer в консоли Active Directory Users and Computers и избавиться от объектов соединения DC, скрытых в базе данных AD. Кроме того, требуется очистить DNS. Чтобы успеть выполнить все эти задачи, мы немедленно приступили к работе.
В первую очередь, мы обратились к консоли Active Directory Users and Computers и попытались удалить объект computer. Нам повезло, и объект был удален. Мы немедленно запустили процедуру репликации, чтобы сообщить всем DC о том, что объект DC более не существует. Репликация базы данных AD через границы сайта была выполнена с помощью утилиты Replication Monitor (replmon.exe), которая входит в пакет Support Tools на компакт-диске Windows 2000. Более подробная информация о репликации и Replmon приведена во врезке «Переход через границы сайта» и в статье Гарри Розенфельда «Шесть программ для локализации сбоев в репликации AD» (опубликованной в Windows 2000 Magazine/RE №4 за 2002 г. — прим. ред.). Убедившись, что другие DC обновлены, мы открыли консоль Active Directory Sites and Services и попытались удалить объект server и объекты соединений из ассоциированного сайта. Однако нам не удалось удалить объект server из базы данных AD. Мы перешли к следующей операции, отметив, что нам придется вернуться к консоли Active Directory Sites and Services и удалить объект server.
Мы были готовы погрузиться в бездну базы данных AD. Для очистки «осиротевшей» записи базы данных было решено использовать утилиту Ntdsutil, мощный инструмент командной строки, в составе которой есть множество команд для работы с базой данных AD. Для удаления «осиротевшей» записи следует применить команду Metadata cleanup. Более подробные сведения об утилите Ntdsutil и ее командах можно найти, обратившись по адресу: http://www.microsoft.com/windows2000/techinfo/ reskit/en-us/default.asp, и выбрав пункты Distributed Systems Guide, Appendixes и Active Directory Diagnostic Tool (Ntdsutil.exe).
|
| Экран 1. Сеанс подключения к DC, запускаемый из командной строки. |
После того как мы получили доступ к AD, необходимо нацелить Ntdsutil на «осиротевший» объект DC1, а для этого нужно установить соединение с соответствующими доменом и сайтом. Мы воспользовались параметром выбора цели команды Metadata cleanup (см. Экран 2), чтобы получить список доменов и сайтов, а затем выбрали нужные домен, сайт и сервер.
Выбрав объект server, мы смогли воспользоваться параметром remove selected server команды Metadata cleanup, чтобы удалить объект из базы данных. Мы ввели команду (см. Экран 3), и появилось диалоговое окно с просьбой подтвердить наше намерение удалить объект server из базы данных. Мы проверили имя и местоположение сервера, убедились, что не ошибаемся в выборе удаляемого сервера, и утвердительно ответили на запрос в диалоговом окне. Затем система выдала сообщение об успешном удалении объекта. Чтобы убедиться, что всем другим DC известно об изменении, мы вновь провели репликацию с помощью replmon.exe. Затем мы использовали Ntdsutil на DC2 и DC3, чтобы удалить серверные записи DC1 со всех DC, на которых размещается база данных AD.
Следующий важнейший шаг процесса очистки был связан с DNS. Действия, которые необходимо предпринять для удаления главной записи (host record, также известной как A-запись) и записей SRV, зависят от типа сервера DNS. Мы использовали сервер BIND DNS, поэтому попросили администратора DNS-сервера удалить соответствующие записи. Убедившись с помощью утилиты Nslookup из Windows 2000, что записи удалены, мы вернулись к консоли Active Directory Sites and Services и попытались вновь удалить объект server. На этот раз объект был удален без труда. Все серверные записи в Active Directory Users and Computers, Active Directory Sites and Services, Ntdsutil и DNS наконец исчезли. Теперь можно было повторить попытку создания DC.
Мы установили сервер и присоединили его к домену. Затем проверили, все ли параметры TCP/IP (маска подсети, стандартный шлюз, DNS-сервер, WINS-сервер, конфигурация динамического обновления) в порядке. И, наконец, мы убедились, что IP-подсети правильно настроены для сайта, в котором должен располагаться DC1. Затем была запущена утилита Dcpromo. Эта процедура в основном не отличалась от прежней, но на сей раз завершилась успешно.
Как показывает наш опыт, незначительные ошибки могут привести к тяжелым последствиям. В процессе миграции приходится вносить различные изменения в контроллеры домена предприятия. Мы надеемся, что они не вызовут серьезных проблем, но в случае неполадок в распоряжении администратора есть ряд ценных инструментов, таких, как Replmon и Ntdsutil.
Переход через границы сайта
Репликация базы данных Active Directory (AD) — важнейшая функция любого домена Windows 2000 AD. Каждый контроллер домена (DC) содержит экземпляр базы данных AD, поэтому если в одном из DC происходят изменения, то их необходимо перенести на остальные DC домена. Репликация проводится автоматически по расписанию, но иногда ее приходится запускать принудительно, чтобы немедленно перенести изменения на все DC.
Для принудительной репликации DC внутри сайта можно использовать оснастку Active Directory Sites and Services консоли управления Microsoft Management Console (MMC). Следует открыть Active Directory Sites and Services и найти серверные объекты, на которые нужно перенести изменения. На каждом таком объекте следует дважды щелкнуть мышью, открыть диалоговое окно Properties и перейти ко вкладке NTDS Settings, на которой показаны все соединения AD между сервером и другими DC. Нужно щелкнуть правой кнопкой мыши на каждом соединении AD с DC, в котором были сделаны изменения, а затем выбрать из контекстного меню пункт Replicate Now. Если DC находится в том же сайте, то репликация произойдет немедленно. Но если DC расположен в другом месте, на экране появится диалоговое окно с напоминанием, что время репликации между выбранным серверным объектом и DC определяется расписанием. В этом случае использовать оснастку Active Directory Sites and Services для принудительной репликации нельзя.
Лучший инструмент для принудительной репликации между контроллерами домена в разных сайтах — Replication Monitor (replmon.exe), его можно найти в разделе Support Tools на компакт-диске Windows 2000. На мой взгляд, Replmon удобнее утилиты repadmin.exe, которая также входит в состав Support Tools, так как с помощью Replmon можно видеть как объекты DC, так и контексты именования DC. Replmon позволяет соединить несколько DC из одного интерфейса. Такая возможность очень важна, поскольку в большинстве случаев администратору полезно контролировать исходящие и входящие потоки данных разных DC в процессе принудительной репликации. После того как администратор установит соединение с DC, следует щелкнуть правой кнопкой мыши на контексте именования домена DC и выбрать пункт Synchronize This Directory Partition with All Servers, чтобы открыть диалоговое окно (см. Экран A). В этом диалоговом окне имеется три важных параметра. Первый из них отключает транзитивную репликацию, в процессе которой изменения передаются только на смежные DC в репликационной топологии. Второй параметр позволяет активно проводить репликацию из измененного DC на другие DC. В типичной процедуре репликации AD контроллер домена «вытягивает» изменения из обновленного DC. Третий параметр открывает DC в других сайтах для немедленной репликации, если они располагают соединением RPC (remote procedure call) с измененным DC. Безусловно, для принудительной репликации между DC в разных сайтах следует выбрать третий режим.
Дерек Мелбер — учредитель консультационной компании BrainCore.net, специализирующейся на обслуживании продуктов Microsoft. С ним можно связаться по адресу: derekm@braincore.net.