При переходе от Exchange 5.5 к Exchange 2000 вряд ли удастся одним махом перевести все почтовые ящики пользователей на новые серверы. Более вероятно, что серверы Exchange 2000 и Exchange 5.5 будут какое-то время эксплуатироваться совместно. Особенно это верно для организаций, насчитывающих тысячи пользователей.

Информация о почтовых клиентах Exchange 5.5 содержится в глобальном списке адресов GAL, управляемом службой каталога DS сервера Exchange. В Exchange 2000 аналогичные функции выполняет служба каталога AD операционной системы. При совместной эксплуатации серверов Exchange 2000 и 5.5 приходится вести единый глобальный список адресов (GAL) для всех клиентов, независимо от места расположения почтовых ящиков. Кроме того, обе системы должны предоставлять друг другу данные о настройках для прозрачного обмена сообщениями.

Коннектор Active Directory Connector (ADC) – достаточно сложный инструмент для объектно-ориентированной двунаправленной синхронизации между службами DS и AD, основанный на механизме репликаций сервера Exchange 5.5 и протоколе LDAP. Проще говоря, ADC синхронизирует данные получателей (т. е. почтовые ящики, внешние объекты-получатели, листы рассылки) сервера Exchange 5.5 с данными в AD (пользователи, контакты и группы), и наоборот. С точки зрения каталогов, ADC синхронизирует DS-контейнеры сайтов Exchange 5.5 с организационными единицами (OU) каталога AD. Результатом синхронизации является единый список GAL и другие данные, облегчающие взаимодействие двух почтовых систем. ADC связывает конфигурационный контейнер сервера Exchange 5.5 с контекстом именования конфигурации в AD. Существует несколько версий ADC, и для синхронизации нужно выбрать наиболее подходящую.

Версии ADC поставляются как с Windows 2000, так и с Exchange 2000. Какую же выбрать? Обычно рекомендуется использовать самую последнюю версию программы. Если сравнить версии разных файлов adc.exe, то выяснится, что на компакт-диске с Windows 2000 поставляется ADC версии 6.0.3939.7, а на компакт-диске с Exchange 2000 – ADC версии 6.0.4417.0. Если номер отличается от приведенных выше, то, скорее всего, это бета-версия программы, и ее надо заменить версией ADC с компакт-диска Exchange 2000.

Версии ADC имеют несколько важных функциональных отличий. Например, ADC из Windows 2000 синхронизирует между службами DS и AD только информацию, связанную с получателями. Для синхронизации других данных, без которых невозможно сосуществование Exchange 2000 и Exchange 5.5, следует применять ADC из поставки Exchange 2000. Вдобавок, ранние версии ADC помещали адресную информацию общих папок вместе с остальными данными синхронизации. ADC из Exchange 2000 располагает информацию об адресах папок отдельно. Это делает администрирование более гибким и упрощает настройку системы (ADC Exchange 2000 синхронизирует только адресную информацию, но не содержимое общих папок).

Вместе с тем, в ADC Exchange 2000 было исправлено множество ошибок. Поэтому наиболее точно синхронизировать две системы можно только при помощи самой последней версии ADC.

Компакт-диск с ADC включает набор расширений схемы, применяемых к AD. Эти расширения являются подмножеством расширений Exchange 2000 и используются ADC при создании специальных объектов в AD для представления почтовых ящиков, внешних получателей, списков рассылки сервера Exchange 5.5. Стандартная схема ADC из поставки Windows 2000 не содержит необходимых определений классов для представления этих объектов в AD. Проверьте, содержит ли установленный ADC все необходимые расширения.

Во время установки ADC программа инсталляции сравнивает значение атрибута AD, определяющего версию схемы расширений, с версией вновь устанавливаемой схемы. Такую проверку можно выполнить вручную, если сравнить значение атрибута rangeUpper объекта ms-Exch-Schema-Version-Adc (см. Экран 1) со значением этого же атрибута, определенного в конце файла adcschema9.ldf. Данный файл находится в каталоге установки ADC. В версии ADC, предназначенной для тиражирования, атрибут имеет значение 4197. Если при установке ADC выяснится, что значения атрибута совпадают, то новые расширения установлены не будут. Для минимальной установки ADC (только расширений схемы) следует выполнить команду setup.exe /Schemaonly в каталоге установки ADC.

Желательно заранее определить, будут ли установлены новые расширения во время инсталляции. Если устанавливаются новые расширения схемы для ADC, это приводит к репликации контекста именования схемы Schema Naming Context, в которой участвует весь лес AD. Расширения ADC изменяют некоторые атрибуты, и это приводит к их репликации на серверы глобального каталога GC Windows 2000. Вообще, если какие-то изменения касаются набора атрибутов, участвующих в репликации на сервере GC, то происходит полная репликация атрибутов GC во всем лесу. Таким образом, простое добавление расширений схемы может вызвать большую волну репликаций в AD. Особенно если AD состоит из множества объектов.

ADC определяет правила синхронизации объектов DS сервера Exchange 5.5 и объектов AD сервера Windows 2000. Эти правила называют соглашениями о соединении – connection agreements (CA). CA определяют характеристики синхронизации: например, исходный и целевой серверы для проведения ограниченной синхронизации, исходное и целевое расположение в соответствующих каталогах, а также способы отображения связанных объектов и аутентификации, позволяющие ADC взаимодействовать как с DS, так и с AD.

Обычно соглашение о соединении определяет отображение контейнеров между каталогами по принципу: «многие к одному». Это значит, что, определяя расположение источника для данного CA, можно указывать множество контейнеров, чьи объекты планируется синхронизировать. Все эти объекты отображаются в одном контейнере целевого каталога. Например, на Экране 2 показаны три контейнера сервера Exchange 5.5, которые отображаются в одну OU в AD. Указывать несколько целевых каталогов ADC не позволяет.

Зато отображение по типу «многие к одному» не требует задания для каждого исходного контейнера только одного CA, что необходимо, если исходный каталог состоит из множества контейнеров, и следует сохранить эту структуру при синхронизации. Функция отображения ADC «многие к одному» позволяет синхронизировать иерархию контейнера. Поэтому можно весь сайт Exchange 5.5 (вместе со всеми объектами) отобразить в одну OU и поддерживать иерархию при помощи синхронизации.

Для централизованного управления объектами DS серверов Exchange 5.5 и объектами AD при помощи оснастки Active Directory Users and Computers консоли управления MMC требуется для каждого сайта Exchange 5.5 определить собственное соглашение о соединении. Хотя бы одно CA для сайта требуется для фиксации изменений объектов DS сервера Exchange 5.5, так как объекты Exchange 5.5 вне домашнего сайта доступны только для чтения.

Соглашения о соединении могут быть односторонними или двусторонними. Односторонние CA действуют в одном направлении, например от DS сервера Exchange 5.5 к AD или от AD к DS. Двусторонние CA позволяют проводить синхронизацию в двух направлениях. Хотя предпочтительней именно двусторонние CA, в некоторых случаях достаточно односторонних. Важно понимать функциональное различие между одно- и двусторонними CA.

На Рисунке 1 приведен пример определения одностороннего CA, отображающего контейнер Recipients сайта Alderaan сервера Exchange 5.5 на OU с именем Exchange 5.5 Server Recipients. В этой конфигурации ADC реплицирует любые изменения объектов, сделанные администратором Exchange 5.5 в контейнере Recipients, в контейнер Exchange 5.5 ServerRecipients в AD. С другой стороны, если администратор AD изменяет синхронизированный объект в контейнере Exchange 5.5 Server Recipients, то ADC не передает эти изменения назад на объект сервера Exchange 5.5. Однако надо помнить, что при очередном запуске ADC будет проведена синхронизация, и измененный атрибут объекта AD вновь примет значение атрибута объекта DS на сервере Exchange 5.5. Односторонние соглашения о соединении чаще всего применяют на первом этапе миграции от Exchange 5.5 к Exchange 2000, когда администраторы почтовой системы стараются защитить Exchange 5.5 от ошибок при настройке AD.

Чтобы обеспечить двунаправленную синхронизацию изменений, следует настроить CA для работы в двустороннем режиме. Это позволит AD стать единственной точкой администрирования объектов Exchange 2000 и Exchange 5.5, поскольку ADC будет реплицировать все сделанные в контейнере Exchange 5.5 Recipients каталога AD изменения в контейнер в DS на сервере Exchange 5.5.

Работа CA в двух направлениях требует симметричной настройки имен контейнеров в закладках From Exchange и From Windows. Эти закладки находятся на странице свойств атрибута синхронизируемого контейнера. Например, чтобы рассмотренное ранее одностороннее CA сделать двусторонним, следует задать в поле Exchange recipients containers значение Recipients, а в поле Default destination имя Exchange Server 5.5 Recipients. Затем на закладке From Windows нужно указать в поле Windows Organizational Units значение Exchange Server 5.5 Recipients, а в Default destination – Recipients.

Просто определить CA как двустороннее и в дальнейшем создать произвольный набор контейнеров и организационных единиц (OU) недостаточно для определения двусторонней синхронизации. Например, если выбрать закладку From Exchange, в поле Exchange recipients container указать Recipients, в поле Default destination определить Exchange Server 5.5 Recipients, а затем на закладке From Win-dows в поле Windows Organizational Units указать Users и в поле Default destination – Recipients, то при такой настройке сконфигурировать двустороннее СА не удастся из-за несбалансированности синхронизации. С точки зрения ADC в данном случае отсутствует механизм репликации изменений в синхронизируемых объектах из контейнера Exchange Server 5.5 Recipients в контейнер SMALL-ED Reci-pients сервера Exchange Server 5.5.

На Рисунке 2 показано, что администратор AD переместил синхронизируемый объект из контейнера Exchange Server 5.5 Recipients в Alternative 5.5 Recipients. Обратите внимание, что не было определено CA, связывающее контейнер Exchange 5.5 Server Recipients с контейнером Alternative 5.5 Recipients, расположенным в AD. Тем не менее если администратор изменит объект на сервере Exchange 5.5, то ADC реплицирует изменение в синхронизируемый объект AD несмотря на то, что он был перенесен в другой контейнер. В этом случае синхронизация осуществляется ADC так, как будто действует незримое одностороннее CA от контейнера Exchange 5.5 Server Recipients к контейнеру Alternative 5.5 Recipients в AD. Независимо от того, куда администратор перемещает объект внутри AD, он может быть найден при помощи уникального глобального идентификатора (GUID) Windows 2000. Это позволяет CA всегда реплицировать изменения сервера Exchange 5.5 в AD.

Обратное утверждение неверно. ADC не реплицирует изменения, сделанные администратором в контейнере Alternative 5.5 Recipients, в исходный объект на сервер Exchange 5.5. Чтобы это произошло, требуется определить дополнительное CA, связывающее Alternative 5.5 Recipients с контейнером Recipients сервера Exchange 5.5.

Прежде чем в очередной раз выполнить синхронизацию серверов Exchange 5.5 и 2000, ADC ищет в AD объект, соответствующий объекту-источнику в Exchange 5.5. Если синхронизация уже проводилась, то ADC ищет объект, имеющий атрибут msExchADCGlobalNames со значением, равным имени DN исходного объекта. Значение атрибуту присваивается при первой синхронизации, и это помогает отыскать объект репликации внутри AD. На Экране 3 показано значение этого атрибута для почтового ящика Exchange 5.5. Почтовый ящик имеет имя KarenW, находится в контейнере Recipients и принадлежит сайту Valbonne в организации Compaq Research.

Если ADC не удается найти объект по значению атрибута, то поиск осуществляется по GUID объекта. При первой синхронизации объекта ADC записывает GUID синхронизированного объекта AD в атрибут ADC-Global-Names исходного объекта сервера Exchange 5.5. В дальнейшем ADC использует строковое значение этого атрибута для поиска объекта в AD (атрибут ADC-Global-Names добавляется в схему DS сервера после установки пакета SP3 для Exchange 5.5).

При неудачном поиске по описанным выше правилам или если ADC еще ни разу не выполнял синхронизацию объекта с AD, он применяет правила, заданные по умолчанию, и использует атрибуты SID и SID History для поиска соответствия.

Когда ADC находит совпадающий объект, информация атрибутов из DS сервера Exchange 5.5 копируется в найденный объект AD. Если объект для синхронизации не был найден, ADC создает его, и информация атрибутов из DS сервера Exchange 5.5 копируется в новый объект AD.

В тот момент, когда ADC первый раз находит совпадение объекта из DS сервера Exchange 5.5 с объектом в AD или создает новый AD-объект, происходит кое-что интересное с именем DN объекта в AD. По умолчанию имя DN объекта AD принимает то значение объекта на сервере Exchange 5.5, которое установлено в поле Display name. Правило отображения определяется атрибутом msExch-Server2Sch-maMap политики Default ADC Policy и может быть переопределено при помощи соглашения о соединении CA. В следующем примере правило отображения предписывает ADC заменить существующее имя DN объекта в AD на атрибут cn объекта Exchange 5.5:

Атрибут cn является LDAP-именем, соответствующим Display name на сервере Exchange 5.5.

Возможность связать имя почтового ящика на сервере Exchange 5.5 с именем DN объекта в AD полезна, но иногда приводит к путанице из-за изменения уже существующей структуры имен. Чтобы такое связывание не выполнялось, нужно установить значение параметра (т. е. 140 в предыдущем примере) равным 10. Или можно изменить правило и дать указание ADC использовать в качестве источника другой атрибут сервера Exchange 5.5.

На первый взгляд ничего сложного в использовании ADC нет: нужно только указать одну точку репликации на стороне сервера Exchange 5.5 и другую – на стороне AD. Результат в виде единого каталога не заставит себя ждать. В целом это верно, но есть пара тонких моментов. Чтобы строить современные системы на базе Windows 2000, нужно разобраться в принципах работы ADC. В этой статье мы рассмотрим несколько не вполне очевидных аспектов этой работы. В следующей статье я более подробно расскажу о совместной эксплуатации серверов Exchange 5.5 и Exchange 2000 и представлю план перехода от одной версии Exchange к другой.

(Продолжение следует.)

КИРАН МАККОРРИ живет в Ирландии, является старшим консультантом группы Technology Leadership Group в Compaq. Автор книги «Connecting Microsoft Exchange Server» (Digital Press). С ним можно связаться по адресу: kieran.mccorry@compaq.com.