Если бы каждая неделя приносила перемены, облегчающие нашу жизнь, мы все были бы счастливы. Разработчики Exchange, видимо, ощущают недовольство пользователей локально установленных серверов Exchange, которые жаловались, что все действия сосредоточены в «облаке» — новые функции появляются в Office 365, но нет никаких шансов в скором времени увидеть их в локально устанавливаемом продукте. Три улучшения в функциях и одно уведомление о готовящемся изменении в OWA — свидетельство прогресса, достигнутого в последнее время. Впрочем, теперь мы можем услышать жалобы на слишком быстрые изменения...

За последнее время в мире Exchange произошло много приятных событий. Возможно, вы не заметили их из-за недостаточно широкого обсуждения или из-за растерянности перед лавиной новых функций в Office 365. Хочу поделиться радостными новостями с пользователями локальных экземпляров Exchange.

Прежде всего, 9 января было объявлено, что Microsoft устранила технические неполадки, которые блокировали размещение следящего сервера (известного также как FSW) в центре обработки данных Azure. Мысль использовать Azure в качестве надежного арбитра между двумя центрами обработки данных, которые составляют расширенную группу обеспечения доступности базы данных (DAG), впервые была высказана на конференции TechEd North America в 2013 году. Идея хорошая, так как Azure, по-видимому, будет очень надежным ресурсом, доступным обоим центрам обработки данных. Если один центр обработки данных переведен в автономный режим, то следящий сервер на основе Azure будет по-прежнему доступен для поддержания кворума и группа DAG остается рабочей.

Однако, как объясняется в публикации EHLO (blogs.technet.com/b/exchange/archive/2013/08/07/database-availability-groups-and-windows-azure.aspx) от августа 2013 года, тестирование показало, что Azure не обеспечивал два VPN-соединения типа «сеть-сеть», необходимые для устойчивого подключения к следящему серверу из обоих центров обработки данных. И вот компания Microsoft объявляет, что теперь виртуальную машину Azure можно использовать как следящий сервер (blogs.technet.com/b/exchange/archive/2015/01/09/using-an-azure-vm-as-a-dag-witness-server.aspx). Особой похвалы достойны группа высокой доступности Exchange и Тим Макмайкл, специалист по поддержке кластеров, вклад которого трудно переоценить.

Эти новости порадуют тех, кто работает с расширенными группами DAG, но вряд ли повлияют на планы большинства владельцев локальных установок. Microsoft очень осторожно подчеркивает, что использование Azure для производственных серверов Exchange не поддерживается. Многие применяют Azure для тестовых серверов, а компания Amazon, похоже, вполне одобряет развертывание Exchange на AWS, однако специалисты Microsoft все еще не уверены, что Azure — подходящая платформа для Exchange. Отчасти такая осторожность может объясняться планами компании относительно поддержки, отчасти экономическими соображениями (blogs.technet.com/b/timmcmic/), а отчасти — нежеланием идти вразрез с принципом «облако в первую очередь», который должен побуждать потребителей переместить рабочую нагрузку Exchange в Office 365. Как заявил в октябре 2014 года главный управляющий Сатья Наделла: «Office 365 — новый Exchange».

Тем временем, чтобы помочь переходу клиентов на Office 365, компания Microsoft увеличила максимальный размер объектов, которые можно перенести в Exchange Online, до 150 Мбайт — шестикратное увеличение по сравнению с прежним лимитом в 25 Мбайт, определенным MaxSendSize (максимальный размер сообщения, которое может быть отправлено) (technet.microsoft.com/en-us/library/exchange-online-limits.aspx). В действительности предел составляет 35 Мбайт, а не 25 (дополнительные 10 Мбайт выделяются с учетом таких факторов, как кодирование и инкапсуляция). В любом случае, увеличение немалое; оно должно помочь клиентам в переходе на Office 365, в том числе в переносе объектов любой величины, которые могут находиться в почтовых ящиках пользователей. О новом лимите для миграции объявлено в декабрьском обновлении Office 365 за прошлый год; ныне он вступил в действие.

Необходимо помнить о двух обстоятельствах. Во-первых, лимит увеличен исключительно в целях миграции. После того, как почтовый ящик становится полностью функционирующим в Office 365, вновь применяется документированный лимит (25 + 10 Мбайт). Другими словами, можно перемещать очень большие объекты в Exchange Online, но вам не удастся закупоривать транспортные артерии, пересылая их друзьям и родственникам. Во-вторых, миграция очень больших объектов с сервера потребителя через Интернет в Office 365, вероятно, будет длительным процессом с высокой вероятностью ошибок. Однако рано или поздно гигантские объекты будут перенесены и станут прекрасно храниться в «облаке».

Последнее качество — самое примечательное. Клиенты, желающие сохранить рабочие нагрузки локально, используют мастер гибридной конфигурации HCW (technet.microsoft.com/en-us/library/hh529921(v=exchg.150).aspx) для настройки соединений между локальной организацией Exchange и Exchange Online. Мастер HCW – отличный пример автоматизации многочисленных предварительных шагов, связанных с настройкой вручную. Однако, как всякий «черный ящик», HCW превосходен, когда работает исправно, но почти не дает подсказок при сбоях.

В последнем случае вам поможет автоматизированная программа поиска неисправностей Hybrid Configuration Troubleshooter, относительно которой группа разработчиков Exchange Hybrid Team пока предпочитает информации не давать. Программа диагностики (aka.ms/HCWCheck) запускается с того же сервера, который поддерживает связь с Exchange Online, и помогает выяснить причины отказа мастера HCW. В сущности, программа собирает и интерпретирует журналы, формируемые HCW, в поисках возможных источников проблем. Сейчас средство представлено первой версией, и, вероятно, потребуется еще пара версий, чтобы сгладить острые углы и сделать программу действительно полезной. Разработчики данного инструмента отдают себе отчет в сложности задачи и будут благодарны за отзывы, которые можно направлять по адресу HCWCHeckFeedback@microsoft.com.

Среди недавних новостей Exchange: 12 января группа разработки объявила о планах внесения изменений в процесс выхода из OWA. Подробности можно найти в блоге EHLO (//blogs.technet.com/b/exchange/archive/2015/01/12/owa-forms-based-auth-logoff-changes-in-exchange-2013-cumulative-update-8-and-good-news-for-tmg-customers.aspx). Изменения вступят в силу после выпуска Exchange 2013 (http://windowsitpro.com/exchange-server/exchange-server-2013) CU8 в ближайшие два месяца. Цель изменений — добиться единообразного поведения при выходе при любых обстоятельствах, что будет очень полезно.

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