Хорошо тому, кто всегда принимает верные решения. Хотел бы я, чтобы мне это удавалось хотя бы через раз. А в том, что касается привязки почтовых ящиков, я был совершенно не прав. Но ошибался не только я, коллективный разум группы разработчиков 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. Целевой...

Это не вся статья. Полная версия доступна только подписчикам журнала. Пожалуйста, авторизуйтесь либо оформите подписку.
Купить номер с этой статьей в PDF