Когда я решил написать цикл статей о миграции на Exchange 2010, то предполагал, что практических советов накопится на несколько объемных статей. Но оказалось, что ситуация развивается несколько иначе: сама миграция не так сложна, а документация на Technet достаточно хороша, чтобы практически любой инженер мог самостоятельно разобраться в вопросе и успешно провести миграцию.
Сложности начинаются, когда мы в чем-то заблуждаемся. Проблемы начинаются, когда мы реализуем свои заблуждения.
Одно из таких заблуждений, которое может породить серьезные проблемы, связано с LegacyExchangeDN.
Вам, скорее всего, уже неоднократно попадалось на глаза это буквосочетание. И как показывает практика, многие считают, что атрибут LegacyExchangeDN явлется малозначительным рудиментом в силу своего названия: legacy – значит устаревший.
Но как раз наборот! LegacyExchangeDN это самое главное!
История. В середине 90-х компания Microsoft выпустила продукт ставший настолько популярным, что он не только завоевал большую часть рынка, но использовался долгое время спустя и даже ныне встречается – это Exchange 5.5.
Exchange 5.5 использовал для хранения учетных записей пользователей и других своих объектов собственную базу – каталог. Формат базы соответствовал разработанному к тому времени стандарту X.500, что делало продукт самым передовым на то время. Клиент Exchange сервера Outlook также использовал X.500 для работы с объектами Exchange.
Имена объектов Exchange 5.5 в этом формате выглядели вот так:
/o=Organisation/ou=Administrative Group/cn= Recipients/cn=Username
Знакомый формат, не так ли?
В 2000-м года компания Microsoft выпустила целый набор продуктов, которые кардинально отличались от предыдущих версий, в том числе Windows Server 2000, Exchange 2000 и Outlook 2000. В Windows Server 2000 компания Microsoft впервые предложила свою реализацию каталога по стандарту LDAP – Active Directory. Exchange 2000 вместо собственного каталога стал использовать каталог Active Directory.
Любой объект, хранимый в Active Directory, имеет уникальный идентификатор DN (Distinguished Name). Я не знаю точной истории, но очевидно, что перед разработчиками Exchange встала проблема: либо отказаться полностью от каталога стандарта X.500 и полностью перейти на каталог Active Directory, либо перенести элементы X.500 в AD. При этом одной из главных задач разработчиков было обеспечить прозрачную миграцию с Exchange 5.5 на Exchange 2000 и их сосуществование на время миграции (Это касалось и клиентской части – Outlook). Первый вариант требовал создание механизма трансляции адресов одного каталога в другой как на стороне сервера, так и на стороне клиента.
И как мы знаем сегодня, выбор пал на второй вариант: каталог Exchange 5.5 был фактически отображен в каталог Active Directory. Имена Distinguished Name каталога X.500 были размещены в атрибуте LegacyExchangeDN каталога Active Directory. Само название атрибута указывало, что содержимое относится к прежней версии каталога и прежней версии Exchange. Но Exchange 2000 как и Exchange 5.5 продолжал использовать внутри себя каталог X.500 и адресовать все объекты по этому стандарту.
Не знаю, предполагали ли в то время разработчики Exchange полностью отказаться в будущем от элементов X.500 в Exchange в пользу формата LDAP или просто выбрали название атрибута для указания на предыдущую версию Exchange 5.5, но факт остается фактом – все последующие версии Exchange – 2003, 2007 и 2010 – продолжают использовать внутри себя каталог X.500 и делают это посредством атрибута LegacyExchangeDN.
Таким образом внутренние механизмы Exchange 2010 используют LegacyExchangeDN как основной способ доступа к объектам почтовой системы.
Изменение LegacyExchangeDN – означает разрушение объекта почтовой системы. Изменили адрес, а LegacyExchangeDN это по сути DN, потеряли объект.
Содержимое LegacyExchangeDN адресует объект как уникальный своим значением. Иначе говоря, если вы перенесли объект из Exchange 2003 в Exchange 2010, то объект не меняется – это почтовый ящик той же самой учетной записи! И его уникальное имя (содержимое LegacyExchangeDN) не должно меняться: это же уникальное имя, если оно изменится, то мы потеряем объект. А вот местоположение объекта изменилось, но это задается другими атрибутами.
Теперь вам должно быть понятно, почему после переноса почтового ящика из Exchange 2003 на Exchange 2010 мы видим в атрибуте LegacyExchangeDN старое значение
First Administrative Group вместо ожидаемого Exchange Administrative Group (UID)
даже после удаления последнего сервера Exchange 2003 из организации.
Адреса в LegacyExchangeDN это не просто литеральная ссылка – она подчиняется правилам X.500. Внутри LegacyExchangeDN мы видим объект First Administrative Group. Если при удалении последнего сервера Exchange 2003 вы удалите административную группу (и соответствующую ей группу маршрутизации), то адреса LegacyExchangeDN потеряют свою структуру – каталог X.500 будет разрушен, почтовые объекты потеряны, маршрутизация нарушена. (Впрочем это лечится.)
Надеюсь, вы поняли, что объекты, оставшиеся в каталоге после удаления Exchange 2003, это не рудименты и не ошибки миграции, а важные для работы Exchange 2010 элементы, которые являются уже его неотъемлемой частью.
И как вы понимаете, Exchange 2010 никак не использует объекты оставшиеся от Exchange 2003 кроме как для формальной адресации почтовых объектов по X.500.
Полезные ссылки:
- Identifying Unresolved LegacyExchangeDNs via EWS and Powershell
- The legacyExchangeDN value is missing from this Exchange database
Другие статьи серии:
- Миграция с Exchange 2003 на Exchange 2010 – от сомнений к реализации
- Миграция с Exchange 2003 на Exchange 2010 – первые шаги
- Миграция с Exchange 2003 на Exchange 2010 – ситуации. Часть 1.
- Миграция с Exchange 2003 на Exchange 2010 – ситуации. Часть 2.
Filed under: Exchange |
После перехода на exch 2010 в AD остался объект EventConfig_oldserver. oldserver — имя сервера, которого уже нет три года. Можно удалить этот объект? Дело в том, что при создании группы рассылки exchange 2010 ругается, что oldserver не доступен.
Скорее всего это имя находится в контейнере Servers
CN=Servers,CN=Fist administrative group,CN=Administrative Groups,CN=Erste Organisation,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=domain,DC=local
Удалите Servers. Только не удаляйте CN=Fist administrative group.
Отличная статья спасибо что разьяснил что как.
Есть проблема, после миграции не можем найти LegacyExchangeDN ты сказал что это лечится а каким образом?
Чтобы давать совет, надо точно представлять вашу ситуацию. Опишите ее на форумах TechNet-RU и какие проблемы возникли — посмотрим, что можно сделать.
Написал https://social.technet.microsoft.com/Forums/office/ru-RU/1ec20923-3331-4d5c-973e-e237dafd8c80/microsoft-exchange-2010-?forum=otherservru