После ряда изъянов, выявленных в четырех кумулятивных обновлениях, выпущенных Microsoft для Exchange 2013 на сегодня, утешает уже тот факт, что пятое обновление Cumulative Update 5 (CU5) ничем не примечательно (см. экран). . Администраторы Exchange по всему миру приветствуют это ничем не примечательное обновление. Оно доступно в центре загрузки Microsoft (www.microsoft.com/en-us/download/details.aspx?id=43103). Список настроек, включенных в CU5, можно найти в статье в базе знаний под номером KB2936880.

 

Результаты применения обновления Cumulative Update 5 к Exchange 2013
Экран. Результаты применения обновления Cumulative Update 5 к Exchange 2013

В течение нескольких последних недель я применял сборки CU5 к серверам, и после небольшого сбоя на начальном этапе каждое обновление устанавливалось гладко и спокойно. Сбой же был вызван потерянным ключом реестра (CERES_REGISTRY_PRODUCT_NAME). Ключ связан с Search Foundation, и его отсутствие вызывает ошибку программы установки. По-видимому, это происходит еще с момента выхода Exchange 2013, о многих подобных примерах пишут в Интернете. В любом случае инженеры Exchange в CU5 все отладили, и проблема больше не должна себя обнаружить.

Выпущенное спустя 13 недель после появления Exchange 2013 SP1, CU5 включает исправления многих других ошибок, поскольку это соответствующее всем требованиям, окончательное обновление. Во внимание принято и то, что не попало в SP1, и ошибки, которые вновь заявили о себе в SP1. Одним из примеров может служить исправление, описанное в KB2958430. В данном случае администраторы заявили, что identity references (ссылки на свойства) нельзя преобразовать с IdentityNotMappedException, работая с командами Set-DatabaseAvailabilityGroup или Add/Remove-DatabaseAvailabilityGroupMember cmdlets Database Availability Group (в EMS или через EAC). По существу, Exchange не справляется, когда группы DAG развернуты в несвязанных пространствах имен, и мы получаем дамп от «Доктора Ватсона», когда работают эти команды. Вы не столкнетесь с этой проблемой, если вашему доменному имени DNS соответствуют суффиксы DNS, назначенные серверам. Ошибка вошла в Exchange 2013 SP1 и с тех пор причиняла немало неудобств тем, кому нужно было поддерживать несвязанные пространства имен.

О самом значительном техническом исправлении, включенном в CU5, Microsoft сообщила 13 мая, опубликовав информацию об изменениях в способе, с помощью которого в Exchange данные автономной адресной книги Offline Address Book предоставляются клиентам Outlook. В блоге EHLO (blogs.technet.com/b/exchange/archive/2014/05/13/oab-improvements-in-exchange-2013-cumulative-update-5.aspx) эти изменения названы «улучшениями», но я думаю, что исправления недостатков в формировании автономной адресной книги и механизмах хранения, введенных Exchange 2013, призваны решить некоторые известные проблемы в старой реализации. Исправления делают создание и распространение автономной адресной книги более эффективными в сценариях, в которых многочисленные арбитражные почтовые ящики автономной адресной книги существуют внутри организации. Тем не менее, различные арбитражные почтовые ящики OAB можно встретить лишь в масштабном и сложном развертывании, и изменения, реализованные в CU5, никак не повлияют на работу большинства клиентов.

Тем, кто реализовал OAB для многочисленных арбитражных почтовых ящиков, будет приятно узнать, что все их клиенты должны будут загрузить полную автономную адресную книгу после применения изменений. Помните, что масштабные развертывания также требуют объемных автономных адресных книг, и в перспективе у каждого клиента – загрузка нескольких сотен мегабайтов данных OAB, особенно в понедельник утром после обновления в выходные. Ничего не поделаешь, невозможно сделать омлет, не разбив яйца, и у вас не будет автономной адресной книги без загрузки данных.

Вопреки ожиданиям, CU5 не содержит ничего особенного, чтобы помочь нынешним общим папкам увеличить размер, весьма ограниченный, как было обнаружено в марте. Во время недавней сессии Experts Unplugged на конференции MEC представители Microsoft пообещали, что они будут усердно работать над тем, чтобы поднять границы до точки, на которой Exchange будет поддерживать миллион общих папок. Будем надеяться на Exchange 2013 CU6. Оптимизм внушает тот факт, что CU5 содержит исправление, позволяющее службе автообнаружения Autodiscover ссылаться на действующие общие папки при использовании MAPI over HTTP.

Маленькое замечание, которое следует иметь в виду: очевидно, гиперактивный мониторинг Managed Availability приводит к частым перезагрузкам службы. Тем не менее, служба, будучи перезапущенной, в действительности не используется, а ее зонд исследует все вокруг какое-то время. Он ничего не делает, только без нужды потребляет циклы процессора. В KB2971467 (support.microsoft.com/kb/2971467) объясняется, как с этим справиться.

Надо сказать, что я одобряю способ, посредством которого процедура Setup теперь приводит в порядок многие сценарии PowerShell, создаваемые в папке \ExchangeSetupLogs для выполнения различных операций при установке Exchange 2013. Эти файлы не должны сохраняться после успешной процедуры установки, и хорошо, что теперь они удалены.

Помните, что каждое кумулятивное обновление для Exchange 2013 – это полная версия продукта. Вы можете применить его к серверу, устанавливая Exchange 2013 с нуля, или обновить предыдущую версию Exchange 2013 с CU5.

Тот факт, что CU5 содержит только исправление ошибок и никаких новых свойств, – на самом деле положительное изменение. CU5 выполняет обновление схемы, и вам по-прежнему нужно протестировать новый код, перед тем как вы установите CU5 на рабочий сервер, но есть все признаки того, что применение CU5 приведет вас прямо к цели. Приятно, что сборка 913.22 не доставляет никаких хлопот. Думается, остальные тоже.

Когда я писал эту статью, Майкл ван Хоренбек (MVP) обратил мое внимание на то, что в CU5 включены нужные обновления мастера Hybrid Configuration Wizard (HCW). Он пишет об этом в своем блоге.

В заметке на странице Exchange 2013 в Facebook (www.facebook.com/groups/MSEX2013/) Брайан Дэй из Microsoft отметил, что CU5 возвращает аутентификацию для Exchange ActiveSync на основе сертификатов. Очевидно, документация все еще дорабатывается.

Кроме того, кажется, ошибка, требующая перезапуска пула приложений, для того чтобы соединения ActiveSync с почтовыми ящиками отражались в Exchange 2013 (описанная на www.expta.com/2014/04/fix-for-exchange-activesync-failures.html), не исправлена в CU5. Пока не ясно, войдет ли исправление в CU6 или в обновление для Exchange 2010.

Статья базы знаний KB2958434 (support.microsoft.com/kb/2958434) описывает решение проблемы, о которой рассказано во врезке «Берегите старые базы данных». Подход, который Microsoft взяла на вооружение, заключается в сокращении срока жизни куки-файла, кэшированного CAS. Тем самым уменьшается период времени, в течение которого вам нужно сохранять базу данных после перенесения всех почтовых ящиков. Однако нет причин сокращать срок службы куки-файла до точки, где вы могли бы сразу удалить базу данных, так как это повлияет на производительность (кэшированные данные – это ключ к оперативности). Поэтому по-прежнему сохраняйте старые базы данных, но не так долго, как раньше.

Берегите старые базы данных

Еще одна досадная ошибка. На этот раз причина кроется в обращениях Exchange 2013 SP1 к старым базам данных после того, как почтовые ящики были перемещены из Exchange 2007 или Exchange 2010. Все в порядке, пока базы данных на месте, но если они перемещены, то клиенты OWA и EAS получают дивную ошибку DatabaseGuidNotFound. Есть простой обходной маневр — обслуживать эти базы данных немного дольше и дать пользователям время для подключения к новым почтовым ящикам Exchange 2013 SP1.

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

  • почтовые ящики пользователей перемещены из Exchange 2007 или Exchange 2010 в базы данных Exchange 2013 SP1;
  • старые базы данных удалены;
  • пользователи пытаются установить соединение через Outlook Web App (OWA) или клиента Exchange ActiveSync (EAS) и возникает ошибка HTTP 500;
  • заголовки в HTTP-ответе в журнале OWA и EAS (в Exchange Server\v15\Logging\HttpProxy\Owa или \EAS) содержат код ошибки X-CasErrorCode: DatabaseGuidNotFound.

Примеры неполадок, с которыми сталкиваются пользователи, можно найти на сайтах TechNet и Reddit. Некоторые интересные обходные приемы, такие как обмен пулов приложений OWA/EAS или удаление связей с устройствами EAS из Active Directory, применялись с переменным успехом. Однако, как показано ниже, есть простой обходной прием, который можно использовать, пока компания Microsoft не предложит окончательного решения.

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

Пока программисты разбираются в тонкостях проблемы и ищут пути ее устранения, компания Microsoft выпустила извещение KB2958434, признавая ошибку. Ее основная причина определена следующим образом:

«Ошибка возникает, потому что идентификатор GUID базы данных почтовых ящиков пользователей (источник) содержится в файле cookie на клиентской стороне и добавляется в кэш сервера на сервере клиентского доступа (CAS). HTTP-прокси на сервере CAS пытается найти базу данных почтовых ящиков с использованием идентификатора GUID старой базы данных в кэше. Поскольку GUID старой базы данных удален, попытка завершается неудачей и возвращается ошибка DatabaseGuidNotFound».

Проблема возникает, когда почтовые ящики перемещаются из старой версии Exchange в Exchange 2013 SP1. Это единственный способ перевести пользователей на новую версию. Важно понимать, что за перемещением почтовых ящиков вскоре следует удаление исходных баз данных. Ошибка DatabaseGuidNotFound указывает, что была предпринята неудачная попытка установить соединение с базой данных по идентификатору GUID. В этом случае клиенты стремятся установить соединение со старым (исходным) почтовым ящиком, но не могут найти его, и возникает ошибка.

Перемещение почтовых ящиков между различными версиями Exchange — сложная задача. Существует огромная разница между внутренней структурой баз данных Exchange 2007 и Exchange 2013. Потребовалось немало строк программного кода, чтобы сгладить миграцию и добиться надежной работы после замены данных в Active Directory для переориентации Exchange на новую базу данных. В этом случае, похоже, Exchange по какой-то причине пытается обратиться к исходной базе данных после того, как пользователь попытался выполнить регистрацию в Exchange 2013.

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

Microsoft осведомлена о проблеме, и члены группы поддержки, которые дважды выступали на семинарах «Expert Unplugged: Top Support Issues» в ходе конференции Microsoft Exchange Conference (MEC) в Остине, активно работают над более удачным решением, чем простое ожидание подключения почтовых ящиков к их новому дому.