Exchange Server Schema Games 2016

Давным давно, то ли в момент выхода Exchange Server 2010, то ли в момент выхода Exchange Server 2013 возник у нас тогда еще в чатике Skype, посвященному Exchange Server, спор по поводу методов расширения схемы для Exchange. Бились разные уважаемые доны в кровь, балансируя на грани личных оскорблений. Но единого мнения так и не сформировалось.

Поводом для всего этого послужил подлый ход команды тогда еще Lync Server, которые позволяли готовить схему для своего продукта простейшим и кустарнейшим методом – путем запихивания определений непосредственно в нее. Для этого использовалась штатная утилита ldifde.exe, которая идет в наборе со средствами управления AD DS\AD LDS.

Команда же Exchange Server встала в позу и заявила примерно следующее: «Пользуйте наш православный и канонiчный setup.exe <bla-bla-bla> /IAcceptExchangeServerLicenseTerms
и он все, в отличие от вас, дебилов, сделает правильно, православно и канонiчно. А кто возложит на наши рекомендации, того ждет проклятие в виде отказа в поддержке.»

Но по сути хитрые писатели Exchange в итоге делали, как оказалось, практически то же самое, что делают все – пихали определения напрямую в схему. И именно для этого, и ни для чего другого (ну вру, еще для подготовки леса и домена) им и нужны установленные компоненты управления AD DS, в просторечии RSAT-ADDS, которые они пишут аж в системные требования для установки Exchange Server. Да, все же понимают, что эти компоненты нужны ТОЛЬКО на первом сервере, и то не всегда, но об этом ниже.

В принципе, все эти хитрые операции можно выполнить и на контроллере домена, если сильно хочется. Надо скопировать дистрибутив на сервер (ну или вставить DVD с Exchange Server непосредственно в) и запустить setup.exe с нужными ключами и соответствующими правами. И тогда RSAT-ADDS на первом сервере Exchange вам вообще не нужны.

Но на самом деле не все так просто…

Начались сегодняшние Schema Games с обращения одного товарища из далекого индийского города Bangalore. Товарищ плакался вот по какому поводу: идет проект миграции на Exchange Server 2016, фаза некоего pre-stage, когда все готовят к тому, чтобы начать. И вот столкнулись они с такой вот ошибкой:

Оказалось, что у парней контроллеры домена все поголовно Windows Server 2008 SP2, что вроде бы и не противоречит системным требованиям… Но вот прославленный setup.exe отказывается запускаться без наличия предустановленных компонентов, таких как Windows Management Framework 4.0 и .NET Framework 4.5.2. Но и это еще не все. В процессе запуска setup.exe выполняет проверку под названием OSBuildCheck (так она потом отражается в логе ExchangeSetupLog) и если видит там ядро ниже NT 6.1 (Windows Server 2012), то закатывает вот такую вот истерику, как на скриншоте выше.

Товарищ очень плакал по поводу, что ему сложно согласовать ввод сервера под управлением Windows Server 2012 в целевой лес и вообще там с этим полная опа и бюрократия. Мы обсудили этот момент еще с одним товарищем, на этот раз из солнечного Виннипега, родины Винни-Пухов, на что тот тоже поматерился красочно в стиле «мне иногда такое надо делать в корневых доменах заказчиков, где сидит SchemaMaster и там тоже те еще приседания, если контроллеры старые, а уговорить обновиться как? Написано в документации, что удовлетворяют требованиям и все тут».

Я решил поиграть в Schema Games и заодно проверить, как оно там с простыми инструментами-то вообще?

Развернул минимально поддерживаемый контроллер домена (Windows Server 2008 SP2) и попытался расширить на нем схему штатно (установив, предварительно. Нужные компоненты в виде WMF и .NET). Результат на том же скриншоте выше.

Окей, прикинул ситуацию, что я могу воткнуть каким-то мифическим образом ноутбук с клиентской ОС в тот сегмент, где у меня мастер схемы. Взял ОС Windows 8.0 (ядро NT 6.1) и попытался запустить все это на нем. Результат вот такой и тоже невнятный (ну хоть на версию не ругался):

Я проверил и перепроверил состояние сервисов и файрволлов, отключал, приседал, отжимался, бил в бубен – результат оказался такой же.

Окей, гайз! Я принес таки сервер с Windows Server 2012. Адрес тот же, что и у клиента, все ровно то же самое – в результате схема была подготовлена без ошибок и rangeUpper в ms-Exch-Schema-Version-Pt радостно сообщил мне, что он теперь 15317, что соответствует Exchange Server 2016 RTM.

И вот тут я вспомнил про наш давний спор…

В Exchange Setup Log заглядывать вообще полезно. Я туда и отправился. Читать его занятие не быстрое и не самое веселое. В начале выполняется целая куча проверок: какая у вас OS, есть ли домен в принципе, были ли в домене установлены предыдущие версии Exchange и т.п. Т.е. проверок море. И вот когда они все проходят удачно, запускается собственно процедура импорта определений в схему. И да, все делается через вызов ldifde.exe.

Для теста я взял самый простой вариант: у вас древний домен, в котром контроллеры все поголовно Windows Server 2008 SP2, нет ни одного сервера с ядром NT 6.1 и новее, и никогда не было Exchange. И вот вы решили воткнуть Exchange Server 2016.

Для начала по логам я определил, что импортируются файлы .ldf из каталога \ExchangeSetup\Setup\Data, но не все подряд, а только те, которые имеют в названии префикс PostWindows2003. Всего их набирается 100 штук (PostWindows2003_schema0.ldf – PostWindows2003_schema99.ldf), плюс один файлик с названием SchemaVersion.ldf, который выставляет временные штампы (когда все это дело происходило) и задает значение rangeUpper для ms-Exch-Schema-Version-Pt.

Я собрал эти файлики и утащил их в отдельный каталог, C:\SchemaSource.

А далее попытался затолкать их втупую в схему вот такой командой:

Get-Item
-Path C:\SchemaSource* | ForEach {ldifde
-f $_.Name -I -s «dc01.contoso.com» -c «<SchemaContainerDN>» «CN=Schema,CN=Configuration,DC=contoso,DC=com»}

Что-то как-то затащилось, ошибок практически не было. Я решил схемы сравнить.

Схему можно выгрузить с помощью того же ldifde.exe, как-то вот так:

Ldifde.exe -f MySchema.ldif -d CN=Schema,CN=Configuration,DC=contoso,DC=com

И можно сравнить несколько файлов схем как между собой, так и с текущей схемой с помощью утилиты ADSchemaAnalyzer.exe (есть на любой машине с установленными AD DS\AD LDS\RSAT-ADDS). Подробненько про сравнение схем вот тут: https://technet.microsoft.com/ru-ru/magazine/2009.04.schema(en-us).aspx

Итог сравнения со схемой, которую подготовил Setup.exe неутешительный. В моей схеме, подготовленной вручную, не хватало пары сотен аттрибутов и пары же десятков классов. А причина вот в чем. Получая список файлов из каталога C:\SchemaSource, я получаю их в дефолтной сортировке, а именно:

File0.ldf

File1.ldf

File10.ldf

File11.ldf


File19.ldf

File2.ldf

И в таком же порядке содержимое файлов импортировалось в схему. А там есть взаиомзависимости (например модификация аттрибута, который был создан импортом предыдущего определения, а если вы перепутали фалы местами, то и модифицировать пока еще нечего).

Немножко пораскинув мозгами я нашел вот такое решение:

$files = Get-Items C:\SchemaSource\PostWindows2003*

$FileNamePrefix = ‘PostWindows2003_schema’

for ($i=0; $i
-lt $files.count; $i++)

{

ldifde -i -s «dc01.contoso.com» -f $FileNamePrefix$i‘.ldf’

-c «<SchemaContainerDN>» «CN=Schema,CN=Configuration,DC=contoso,DC=com»

}

В таком виде файлы импортируются в нужном порядке. И вишенкой на торте стала команда:

ldifde -i -s «dc01.contoso.com» -f C:\SchemaSource\SchemaVersion.ldf -c «<SchemaContainerDN>» «CN=Schema,CN=Configuration,DC=contoso,DC=com»

После этого я выгрузил схему и приступил к сравнению:

Импорт схемы, подготовленной вручную в анализатор схемы

Импорт схемы, подготовленной с помощью setup.exe

Как видно невооруженным глазом, количество элементов полностью совпадает.

Если нажать в анализаторе кнопку Schema – Hide present elements, то он показывает ровно 0 различий. Ну и если посмотреть на значение rangeUpper в ms-Exch-Schema-Version-Pt (а именно по нему предлагается проверять, что схема обновлена успешно, и именно его проверяет setup.exe на этапе подготовки леса), то там тоже все ок

Другими словами, можно приступать к следующему этапу (об этом я может быть когда-нибудь напишу в более следующий раз).

Да, на заметку:

  1. У команды Lync\Skype for Business решение куда изящнее, там нужно импортировать всего четыре файла. Тоже в нужном порядке.
  2. У них же этот способ является полностью поддерживаемым, а вот у нас с вами есть проблема…

Описанный способ не является поддерживаемым решением, вся эта эквилибристика описана только с научно-познавательной точки зрения и не рекомендуется к воспроизведению в продуктиве. Если же вы все это проделаете в продуктиве, то все последствия только на вашей совести, а я предупреждал J

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

Реклама
Exchange Server Schema Games 2016

Exchange Server Schema Games 2016: Один комментарий

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход /  Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход /  Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход /  Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход /  Изменить )

w

Connecting to %s