Как мы недавно узнали, в накопительных пакетах обновления Exchange 2013 CU11 и Exchange 2016 CU1 в командной консоли Exchange (EMS) появились изменения, сближающие ее с другими протоколами при подключении к почтовому ящику. Раньше этот процесс был очень простым, но теперь, когда Exchange переключает почтовые ящики между базами данных быстрее, чем хорек ныряет в нору за кроликом, пользователю нужна помощь в поиске их текущего местоположения. Одни полагают, что это полезное изменение, другие считают, что оно только создает проблемы. Предлагаю вам составить собственное мнение.
Публикация Роба Уэйли, широко известного специалиста по Exchange, работающего над бета-версиями локальных и «облачных» продуктов, целиком посвящена способам соединения удаленного сеанса PowerShell с почтовым ящиком на сервере Exchange. Или, если использовать термин, ставший популярным благодаря этой публикации, «привязке почтовых ящиков» (mailbox anchoring) (http://blogs.technet.com/b/exchange/archive/2015/12/15/exchange-management-shell-and-mailbox-anchoring.aspx).
Так или иначе, вопрос заключается в способе установления Exchange входящего клиентского подключения к нужному почтовому ящику. По большей части это проблема подключения пользователя к его почтовому ящику. В Exchange результат достигается с помощью запроса, направляемого к Active Directory для получения уникального указателя GUID на почтовый ящик, с последующим использованием этого GUID для запроса процесса Active Manager. Это позволяет выяснить, на каком сервере размещается активный экземпляр базы данных, содержащей данный почтовый ящик. На Active Manager возлагается отслеживание переходов базы данных в группах доступности базы данных. В целом эта схема работает очень хорошо.
Однако проблема, которую обнаружила группа разработчиков Exchange, заключается в различиях в поведении командной консоли Exchange (EMS). Как объясняется в упомянутой статье, при запуске EMS инициируется удаленный сеанс PowerShell, устанавливающий связь с локальным сервером Exchange или другим доступным сервером в организации. Как правило, соединение не бывает дальним, и EMS подключается к локальному серверу.
Начиная с 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, поскольку это сфера администраторов и программистов. Логично предположить, что их почтовые ящики в большинстве случаев будут находиться на серверах с новым программным обеспечением, так как ИТ-администраторы и прочие технические специалисты тестируют новые версии.
Бывает, что у администраторов нет почтовых ящиков Exchange. В таких случаях EMS подключается к почтовому ящику разрешения конфликтов с именем SystemMailbox{bb558c35-97f1-4cb9-8ff7-d53741dc928c}, а если он недоступен, то используется какой-то еще из почтовых ящиков разрешения конфликтов. Если вы устанавливаете Exchange 2016 в существующей организации Exchange 2013 или Exchange 2010, то специалисты Microsoft настоятельно рекомендуют переместить почтовые ящики разрешения конфликтов и все почтовые ящики, принадлежащие пользователям EMS, в базу данных, размещенную на сервере Exchange 2016. Как отмечалось выше, это может быть сделано в любом случае, но теперь, как подчеркивают разработчики Microsoft, таким образом гарантируется, что сеансы EMS, созданные для управления организацией Exchange, всегда работают с новейшим программным кодом.
В публикации EHLO содержатся подробные сведения о том, как переместить почтовые ящики разрешения конфликтов с помощью EAC, но пользователи PowerShell могут задействовать EMS, чтобы выполнить команду:
Get-Mailbox -Arbitration | New-MoveRequest -TargetDatabase ‘DB on New Server’
Простое внесение изменений группой разработки Exchange не означает, что все согласны с новым подходом. Это верно в данном случае, учитывая, что несколько опытных специалистов со статусом MVP указывали на проблему, которая может возникнуть, если базы данных, содержащие почтовые ящики администратора, по какой-то причине недоступны. Еще одно замечание: производительность EMS может быть невысокой, если вы сильно удалены от центра обработки данных, в котором размещен ваш почтовый ящик. Думаю, это действительно так, но по большей части производительность PowerShell на протяженных линиях связи приемлемая, особенно если требуется всего лишь выполнить несколько команд.
Если происходит авария и почтовые ящики оказываются недоступны, Microsoft рекомендует запустить сеанс PowerShell и добавить оснастку Microsoft Exchange, чтобы иметь возможность выполнять команды Exchange с использованием той же процедуры, которая требуется для управления серверами Exchange 2013 с единственной установленной ролью CAS (см. заметки о выпуске Exchange 2013 (https://technet.microsoft.com/en-us/library/jj150489%28v=exchg.150%29.aspx)). Это связано с тем, что EMS работает только на серверах Exchange 2013, поддерживающих роль хранилища почтовых ящиков. Команда для загрузки оснастки проста:
Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn
Однако при добавлении оснастки к сеансу PowerShell возникает проблема: не выполняется проверка управления доступом на основе ролей RBAC, чтобы ограничить доступ пользователя к командам и параметрам в зависимости от членства в группах ролей управления Exchange. Проблема не актуальна, если пользователь является членом группы ролей «Управление организацией» с широчайшими возможностями и, в сущности, может выполнять любые действия в организации, но у пользователей с меньшими полномочиями могут возникнуть трудности. Это еще один вопрос, который необходимо учесть в вашем плане аварийного восстановления.
В любом случае, надеюсь, вы никогда не лишитесь доступа к административным почтовым ящикам и почтовым ящикам разрешения конфликтов. Если такая ситуация возникает, то, вероятно, у вас есть более актуальные проблемы, чем отсутствие RBAC. И конечно, пользователям Exchange Online не следует беспокоиться: сеансы EMS в службе уже задействуют привязку почтовых ящиков.
В заключение хочу отметить, что недавно Эндрю Хиггинботам, ведущий специалист по диагностике службы Dell Support, широко известный своими выступлениями на конференции IT/DEV Connections, опубликовал у себя в блоге описание некоторых проблем, сопряженных с привязкой почтовых ящиков и обнаруженных у клиентов, развернувших Exchange 2013 CU11 (https://exchangemaster.wordpress.com/2016/01/06/mailbox-anchoring-affecting-new-deployments-upgrades/).