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

Когда Microsoft объявила, что в Exchange 2013 CU11 и Exchange 2016 CU1 будет реализована «привязка почтовых ящиков» (mailbox anchoring) (http://blogs.technet.com/b/exchange/archive/2015/12/15/exchange-management-shell-and-mailbox-anchoring.aspx) — новый способ подключения сеансов командной консоли Exchange (EMS или PowerShell, если вам так больше нравится) к серверам Exchange, я поделился некоторыми мыслями на эту тему и объяснил, почему считаю новый подход удачным.

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

Однако я ошибался. Как выяснилось, были не правы и специалисты Microsoft, внедряя в локальном программном обеспечении изменения, которые были бы полностью оправданны в централизованном и строго регламентированном мире Exchange Online. Насколько провальным был результат, можно судить по отзывам на форумах TechNet (https://social.technet.microsoft.com/Forums/office/en-US/05897b40-0717-437d-90ca-d550e3226c2a/exchange-2013-cu-11-breaks-some-admin-accounts-? forum=exchangesvrdeploy), оставленным пользователями, которые попытались развернуть Exchange 2013 CU11.

Краткую оценку можно найти в публикации Эндрю Хиггинботтама по адресу: https://exchangemaster.wordpress.com/2016/01/06/mailbox-anchoring-affecting-new-deployments-upgrades/. Этот человек знает, о чем говорит, так как работает в службе поддержки DELL. Вероятно, эта публикация стала сигналом, заставившим специалистов Microsoft приступить к делу.

Будем справедливы к Microsoft, разработчики компании признали существование проблемы и изменили курс. В версии Exchange 2013 CU12 восстановлен прежний механизм (http://blogs.technet.com/b/exchange/archive/2016/03/01/remote-powershell-proxying-behavior-in-exchange-2013-cu12-and-exchange-2016.aspx), то же самое будет и в Exchange 2016 CU1. Несмотря на изъяны, старый механизм работал в течение многих лет, и разумно вернуться к началу, чтобы продумать, как можно выполнить привязку почтовых ящиков на локальных серверах.

Как Росс Смит IV отметил в блоге EHLO, в котором объявлено об изменении стратегии (http://blogs.technet.com/b/exchange/archive/2016/03/01/remote-powershell-proxying-behavior-in-exchange-2013-cu12-and-exchange-2016.aspx), вы можете использовать новый метод привязки почтовых ящиков, указав полное доменное имя сервера в качестве целевого объекта для удаленного подключения PowerShell. Вероятно, это проще другого рекомендованного подхода, связанного с точным указанием версии Exchange, выполняемой на сервере в пространстве имен с балансировкой нагрузки. Просто нужно: a) запомнить и б) ввести номер версии, например ExchClientVer = 15.0.225.0. Два других метода, предложенные специалистами Microsoft, — использовать сходство сеансов для удаленных сеансов PowerShell или удалить серверы со старыми версиями Exchange из пула с балансировкой нагрузки. Я полностью поддерживаю желание избавиться от старых серверов, но это не всегда просто сделать.

Предпочтительно указать сервер в качестве целевого объекта для удаленных сеансов PowerShell. Целевой сервер работает с новейшей версией Exchange, что соответствует нашему желанию. Помните, новым серверам известно о старых версиях, а старые серверы «теряют память» и ничего не знают об устройстве новой версии Exchange.

Возврат к старому методу — правильный шаг, но возникает вопрос, как изменение прошло все этапы тестирования в Microsoft, в ходе которого воспроизводятся возможные эксплуатационные среды Exchange. На этот вопрос нет удовлетворительного ответа. Скорее всего, тесты привязки почтовых ящиков были выполнены успешно, хотя бы по той причине, что трудно воссоздать многообразные формы развертывания и эксплуатации Exchange.

В случае со сложными программными продуктами, такими как Exchange, всегда существует опасность, что изменение, казавшееся вполне оправданным на этапе проектирования, приводит к сомнительным результатам в реальных производственных условиях. Тестирование должно выявить проблемы до того, как их обнаружат пользователи, но в данном случае этого не произошло. Что ж, мир по-прежнему несовершенен.