Exchange: значение привязки почтовых ящиков. Продолжение
Бывает, что у администраторов нет почтовых ящиков Exchange. В таких случаях EMS подключается к почтовому ящику разрешения конфликтов с именем SystemMailbox{bb558c35-97f1-4cb9-8ff7-d53741dc928с}, а если он недоступен, то используется какой-то еще из почтовых ящиков разрешения конфликтов. Если вы устанавливаете Exchange 2016 в существующей организации Exchange 2013 или Exchange 2010, то специалисты Microsoft настоятельно рекомендуют переместить почтовые ящики разрешения конфликтов и все почтовые ящики, принадлежащие пользователям EMS, в базу данных, размещенную на сервере Exchange 2016. Как отмечалось выше, это может быть сделано в любом случае, но теперь, как подчеркивают разработчики Microsoft, таким образом гарантируется, что сеансы EMS, созданные для управления организацией Exchange, всегда работают с новейшим программным кодом.
В публикации EHLO содержатся подробные сведения о том, как переместить почтовые ящики разрешения конфликтов с помощью ЕАС, но пользователи PowerShell могут задействовать EMS, чтобы выполнить команду:
Get-Mailbox -Arbitration | New-MoveRequest -TargetDatabase 'DB on New Server'
Простое внесение изменений группой разработки Exchange не означает, что все согласны с новым подходом. Это верно в данном случае, учитывая, что несколько опытных специалистов со статусом MVP указывали на проблему, которая может возникнуть, если базы данных, содержащие почтовые ящики администратора, по какой-то причине недоступны. Еще одно замечание: производительность EMS может быть невысокой, если вы сильно удалены от центра обработки данных, в котором размещен ваш почтовый ящик. Думаю, это действительно так, но по большей части производительность PowerShell на протяженных линиях связи приемлемая, особенно если требуется всего лишь выполнить несколько команд.
Если происходит авария и почтовые ящики оказываются недоступны, Microsoft рекомендует запустить сеанс PowerShell и добавить оснастку Microsoft Exchange, чтобы иметь возможность выполнять команды Exchange с использованием той же процедуры, которая требуется для управления серверами Exchange 2013 с единственной установленной ролью CAS. Это связано с тем, что 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/).
