Exchange: значение привязки почтовых ящиков
Вначале этой статьи необходимо упомянуть публикацию достаточно известного специалиста Exchange Роба Уэйли, в которой он рассказывал о способах соединения удаленного сеанса PowerShell с почтовым ящиком на сервере Exchange. Кстати, именно благодаря этой статье в IT среде появился новый достаточно популярный термин - «привязка почтовых ящиков» (в оригинале звучит, как mailbox anchoring). С содержанием данной статьи вы можете ознакомиться на http://blogs.technet.com/b/exchange/archive/2015/12/15/exchange-management-shell-and-mailbox-anchoring.aspx.
Суть данного материала сводилась к определению наилучшего способа установления входящего клиентского подключения к нужному почтовому ящику. По большей части это проблема подключения пользователя к его почтовому ящику. В Exchange результат достигается с помощью запроса, направляемого к Active Directory для получения уникального указателя GU1D на почтовый ящик, с последующим использованием этого GUID для запроса процесса Active Manager. Это позволяет выяснить, на каком сервере размещается активный экземпляр базы данных, содержащей данный почтовый ящик. На Active Manager возлагается отслеживание переходов базы данных в группах доступности базы данных. В целом эта схема работает очень хорошо.
Однако проблема, которую обнаружила группа разработчиков Exchange, заключается в различиях в поведении командной консоли Exchange (EMS). Как объясняется в упомянутой статье, при запуске EMS инициируется удаленный сеанс PowerShell, устанавливающий связь с локальным сервером Exchange или другим доступным сервером в организации.
Начиная с Exchange 2013 CU11 (http://blogs.technet.com/b/exchange/archive/2015/12/15/released-december-2015-quarterly-exchange-updates.aspx) и Exchange 2016 CU1 (выпуск ожидается в начале 2016 года) в сеансах EMS будут использоваться привязка почтовых ящиков и та же логика, что и во всех других клиентских протоколах - MAPI, OWA, ECP, EWS и т. д. Помимо рациональности единого подхода во всех протоколах, группа разработчиков Exchange хочет направить все сеансы EMS на серверы с высшей доступной версией Exchange в организации.
Логика, на мой взгляд, в данном случае заключается в том, что новые версии Exchange располагают обновленными командами, пригодными для использования в EMS. Опасность же состоит в том, что, если подключиться к старой версии Exchange и выполнить команду, программный код не будет поддерживать все свойства управляемых объектов и даже может содержать ошибки. Общее правило: новые версии EMS пригодны для управления старыми объектами Exchange, но старые версии EMS не распознают новые команды, параметры или объекты.
Не многие «рядовые» пользователи работают с PowerShell, поскольку это сфера администраторов и программистов. Логично предположить, что их почтовые ящики в большинстве случаев будут находиться на серверах с новым программным обеспечением, так как ИТ-администраторы и прочие технические специалисты тестируют новые версии.
