В то время, когда все пребывали в уверенности в безопасном корпоративном развертывании Exchange 2013, специалисты Microsoft обнаружили возникшую в последний момент ошибку, о которой сообщили спустя два дня после выхода Exchange 2013 SP1. Как результат – продукты сторонних фирм, которые зависят от транспортных агентов, при интеграции с Exchange не работают. К счастью, поправить дело относительно легко.

Как и многие, я с нетерпением ожидал появления Exchange 2013 SP1. Первый пакет обновлений любого серверного приложения Microsoft оказывает особый эффект на существующую базу установленных серверов, и большинство неохотно развертывает RTM-версию программного обеспечения. Гораздо лучше, скажем так, предоставить людям возможность самим проложить путь к славе. Опытные администраторы ждут, пока в программном обеспечении все уравновесится, ошибки будут обнаружены и зафиксированы, функции доработаны, а накопленные знания позволят в лучшем виде представить процессы развертывания и эксплуатации. По счастливой случайности мы увидели как раз такое сочетание, когда дебютировал SP1.

И вот меня встревожило сообщение Microsoft о необходимости вносить исправления, чтобы уладить проблему с транспортными агентами для сторонних фирм, которая препятствует перезапуску служб транспорта после обновления Exchange 2013 SP1, иначе не получится осуществить установку агентов на Exchange 2013 SP1. Исправление уже предоставлено Microsoft.

Благодаря службе транспорта в Exchange вы можете быть уверены в том, что сообщение пройдет весь путь от отправки до получения. Вот почему правила транспорта столь эффективны при применении в механизме disclaimers (заявление об отказе) и использовались Microsoft в системе защиты корпоративной информации от утечек (Data Loss Prevention). Агенты разработки третьих сторон задействуют Transport Agents SDK для интеграции своих продуктов, чтобы обеспечить взаимодействие с сообщениями до или после того, как они покинут почтовые ящики. Продукты класса аnti-malware или anti-spam – это общие примеры использования транспортных агентов.

Агенты зависят от кода. NET Framework, предоставляемого Microsoft для интеграции с Exchange. Вероятно, самые последние исправления, которые были внесены во время развертывания Exchange 2013 SP1, спровоцировали проблему. Ошибка была допущена, когда исправляли одну неполадку (текущие исправления настроек безопасности MS13-061 требуют установки средств для деинсталляции), и в двух файлах политики перенаправления сборки появилась плохо отформатированная строка комментариев XML. Этот файл позволяет коду работать на различных версиях Exchange. В результате любая попытка загрузить агенты транспорта в список Global Assembly Cache (GAC) отвергается, что, в свою очередь, делает их недоступными Exchange.

Проблема затрагивает продукты третьих фирм, где используются транспортные агенты для интеграции с Exchange, включая известные и широко используемые продукты, такие как TrendMicro Antivirus, Code Two, Symantec Anti-Virus, Exclaimer, а также ORF anti-spam. Обнаружил проблему и сообщил о ней на встрече Exchange development forum Питер Кансаи из Vamsoft (разработчики ORF). Сообщения о проблемах, связанных с транспортными службами в обновлениях, появились и в комментариях в блоге EHLO (blogs.technet.com/b/exchange/archive/2014/02/25/exchange-server-2013-service-pack-1-available.aspx#comments). Code Two оказалась первой компанией, которая предоставила полную информацию о необходимых исправлениях.

Замечу, что у вас не возникнет проблем при обновлении сервера, не использующего транспортные агенты. К счастью, решение, как это часто случается с досадными проблемами, подобными этой, – простое. Microsoft разработала соответствующий сценарий PowerShell. Если вы используете транспортный агент, включите сценарий в процессе установки Exchange 2013 SP1 или примените его позже. Проблема скорректирована и в кодовой базе продукта, поэтому не появится в следующем кумулятивном обновлении. Я бы предпочел, чтобы Microsoft повторно выпустила SP1 с интегрированным исправлением, но пониманию, что его разработка – это сложный и длительный процесс.

Разработка программного обеспечения требует много времени. В данном случае Microsoft фактически отложила выпуск SP1, чтобы обеспечить лучшую проверку данных и тестирование, ведь ошибку обнаружили именно разработчики.

Всякий раз, когда возникают подобные проблемы, пользователи делают вывод, что процессы разработки Microsoft не дают на выходе устойчивое к ошибкам, надежное программное обеспечение. Критики могут выдвинуть несколько обвинений против Microsoft:

  1. Автоматизированное тестовое обеспечение, используемое Microsoft для проверки новых вариантов программ Exchange, не способствует высокому качеству кода. Действительно, в различных выпусках обновлений Exchange на протяжении нескольких последних лет возникали проблемы. Тем не менее, верно и то, что Exchange занимает центральное место в целой экосистеме, и невероятно сложно тестировать все известные комбинации программного обеспечения, которые могут быть развернуты в какой-либо области. С другой стороны, должна быть возможность проверить основные десять продуктов сторонних компаний, которые будут развертываться клиентами наряду с Exchange.
  2. Программа Technology Adoption Program (TAP), используемая Exchange для проверки ранних версий программ у заказчиков, третьими фирмами и независимыми экспертами, не соответствует целевому назначению, поскольку данный вид ошибки должен был быть обнаружен перед выходом SP1. На деле же ошибку обнаружила третья сторона и сообщила о ней после того, как пакет SP1 стал доступен. Build 847.32 – это пакет обновления SP1 и, как выяснили в Code Two, ошибка проявляется в сборке версии 847.30. Exchange TAP –программа, хорошо зарекомендовавшая себя как помощник в поиске ошибок и проблем, до того как код станет доступен заказчикам. Вполне возможно, что темп выпусков программного обеспечения настолько высокий, что сторонним фирмам невозможно обнаружить ошибки в процессе тестирования продуктов, к тому же на фоне выпусков Microsoft свежих версий для тестирования, еще перед выходом в свет кумулятивного обновления. Каждая третья фирма, принимающая участие в TAP, несет ответственность за тестирование своего продукта, и в то же время Microsoft выпускает сборки, и если тестирование для данной сборки не выполняется (так тоже бывает), риск возникновения проблем повышается.
  3. Нарушается процесс отбора, используемый для оценки ошибок. Не думаю, что это утверждение верно. Об ошибке Microsoft сообщили 27 февраля, за два дня до выхода SP1. У Microsoft нет возможности решить, устранять проблему или нет (проблема выявления важности переделки) до появления SP1.
  4. Слишком много внимания уделяется службам, вместо локального варианта развертывания. Office 365 — масштабное и очень важное окружение для Microsoft, но при этом его регламентированное и структурированное развертывание мало похоже на то, с чем вы столкнетесь при локальной установке. В общем случае, Office 365 не использует продукты сторонних компаний, зависящие от транспортных событий, и проблемы никогда не возникнут. Microsoft могла почить на лаврах, увидев хорошие результаты, когда новый код был введен в Exchange Online, в особенности в новой технологии, которая прошла служебную проверку перед локальным развертыванием (например, как упрощенные группы доступности). Хотя существует множество трудностей, связанных с тестированием взаимодействия с Exchange, думаю, Microsoft следует уделять больше внимания сторонним программам при утверждении нового программного обеспечения, прежде чем оно попадет к клиентам.

Таким образом, возникшая в последний момент ошибка, о которой стало известно после выхода SP1, вызвала множество затруднений и причинила урон репутации Exchange. Хорошо, что группа разработчиков взяла на себя ответственность на раннем этапе и быстро среагировала на проблему. Будет ли желанный отклик от клиентов – еще увидим. В то же время я считаю, что Exchange 2013 SP1, с недостатками и всем прочим (а в случае с таким программным обеспечением можно ожидать еще большего количества ошибок), развертывать стоит.

Количество сторонних продуктов, работающих вместе с Exchange, невероятно усложняет его продвижение. Естественное желание Microsoft быть лидером в «облачных» службах должно уравновешиваться заботой о тех, кто работает в своей локальной сети.