Общие Папки (Public Folders) cross-premise: настройка доступа к legacy PF из Облака

1. Теория

В W15-тенантах Office 365 возможен cross-premise-доступ к Общим Папкам. Можно например оставить существующую иерархию PF на локальных серверах Exchange, и при этом пользователи, смигрировавшие в Облако, будут спокойно подключаться к ней и работать.

Какие конфигурации работы с PF в принципе поддерживаются, а какие нет? См. таблицу:

Сверху: доступ к PFиз… Сбоку: доступ к PFна …

On-Premises Exchange 2007/2010 User Mailbox

On-Premises Exchange 2013 User Mailbox

Exchange Online User Mailbox

On-Premises Exchange 2007/2010 Public Folders

Supported

Not supported

Supported – сейчас разбираем как раз эту ситуацию

On-Premises Exchange 2013 Public Folders

Not supported

Supported

Supported

Exchange Online Public Folders

Not supported

Supported

Supported

Разберём самую, пожалуй, популярную ситуацию. Есть дерево PF на локальных серверах Exchange 2007 или 2010. Требуется: чтобы после перемещения почтовых ящиков ряда пользователей в Облако они могли продолжать использовать эти Общие Папки.

Какие пререквесты существуют для нашего конкретного случая?

  • Тенант O365 должен быть Wave 15
  • Exchange 2007 SP3, Exchange 2010 SP3
  • Чтобы настроить всё, нужно быть в группе Organization Management в Exchange Online. В on-prem Exchange 2010 нужно быть членом ролевой группы Organization Management или Server Management. В on-prem Exchange 2007 нужно иметь права Exchange Organization Administrator или Exchange Server Administrator. Также нужно иметь права Public Folder Administrator и быть в локальной группе Administrators на сервере (серверах) Exchange.
  • Если используется Exchange Server 2007, работающий на Windows Server 2008 x64, нужно провести апгрейд на Windows PowerShell 2.0 и WinRM 2.0 for Windows Server 2008 x64 Edition.
  • На клиенты Outlook у пользователей должны быть установлены следующие апдейты:

2. Создаём специальную локальную базу почтовых ящиков для legacy PF

Итак, у нас есть сервер MBX с базой Общих Папок. Если это ES 2010 - мы должны убедиться, что на нём же исполняется роль CAS (а значит работает нужная в данной процедуре служба Microsoft Exchange RpcClientAccess). Для ES 2007 это замечание можно игнорировать.

New-MailboxDatabase –server <ES c PF> –Name <…> –IsExcludedFromProvisioning $true

clip_image008

Она создаётся отмонтированной. Монтируем. Далее создаём в этой базе служебный почтовый ящик, скрытый из АК:

New-Mailbox –Name <…> –Database <…> –UserPrincipalName <…>

Set-Mailbox –Identity <…> –HiddenFromAddressListEnabled $true

Set-MailboxDatabase <…> –RpcClientAccessServer <ES c PF>

clip_image010

Лучше если данную служебную базу вы не будете использовать для хранения реальных почтовых ящиков пользователей.

3. Подготовка к синхронизации Mail -enabled PF

У нас есть две такие папки:

clip_image011

Так как Dirsync не будет синхронизировать ничего, связанного с mail-enabled-PF (соответствующего пользователя с емейл-адресом-то нет), то на стороне Облака папка как адресат не будет видна в Адресной Книге (АК), и в неё нельзя будет из Облака отправить письмо. При этом сама папка в дереве PF видна будет, и контент тоже будет виден, нельзя будет только в неё написать.

Чтобы нормально работать с такой папкой из Облака, нужны дополнительные действия, описанные ниже. При изменении списка mail-enabled-PF или их свойств эти действия нужно повторять. Или автоматизировать рефреш скриптом по расписанию.

Скачайте комплект скриптов. Сохраните их в локальную папку типа C:\PFSync (как в моём примере).

На локальном Exchange:

.\Export-MailPublicFoldersForMigration.ps1 <…>.xml

image

На облачном Exchange:

.\Import-MailPublicFoldersForMigration.ps1 <…>.xml

clip_image015

Что произошло после выполнения скрипта в Облаке? Просто создались в облачном AD объекты, соответствующие PF, и в АК они появились.

4. Финальное включение

Самая главная команда!

Set-OrganizationConfig -PublicFoldersEnabled Remote –RemotePublicFolderMailboxes ProxyMB01

image

Что поменялось в настройках: поле PublicFoldersEnabled вместо Local стало Remote, и появилась ссылка на RemotePublicFolderMailboxes.

clip_image017

5. Проверка

Спустя некоторое время в Outlook-ах облачных пользователей даже без перезагрузки клиента появились Общие папки:

clip_image019

Теперь проверим работоспособность.

На стороне on-prem

На стороне Облака

Создаю PF из onprem-консоли PFMC (со стандартными правами)

-->

Папка видна в дереве PF

Назначаю конкретные права на работу с Общей Папкой облачному пользователю

-->

Можно делать в Общей Папке все действия в соответствии с назначенными правами

Письмо пришло

<--

Отправил письмо в mail-in-PF

Удаления успешны, видны из Outlook’ов других пользователей

<--

Удалил элемент в PF, саму PF

Если нам нужно создать новую Mail-enabled-PF, не забудем выполнить скрипты из п.3.

На момент написания статьи возможности подключаться к on-prem-PF из облачного веб-интерфейса OWA не было: только из клиента Outlook.

6. Отказоустойчивость и балансировка нагрузки

В разобранном примере у нас фигурировал только один on-prem сервер со служебной базой (MDBFORPRF). Что будет, если он станет недоступен? Облачные пользователи потеряют доступ к Общим Папкам. Чтобы добавить отказоустойчивости нашему решению, можно организовать подобные же служебные базы (и соответствующие им служебные ящики) на нескольких (на всех) серверах с копиями баз Общих Папок. Это решение также позволит распределить нагрузку доступа по нескольким (всем) серверам PF.