Общие Папки (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
Она создаётся отмонтированной. Монтируем. Далее создаём в этой базе служебный почтовый ящик, скрытый из АК:
New-Mailbox –Name <…> –Database <…> –UserPrincipalName <…>
Set-Mailbox –Identity <…> –HiddenFromAddressListEnabled $true
Set-MailboxDatabase <…> –RpcClientAccessServer <ES c PF>
Лучше если данную служебную базу вы не будете использовать для хранения реальных почтовых ящиков пользователей.
3. Подготовка к синхронизации Mail -enabled PF
У нас есть две такие папки:
Так как Dirsync не будет синхронизировать ничего, связанного с mail-enabled-PF (соответствующего пользователя с емейл-адресом-то нет), то на стороне Облака папка как адресат не будет видна в Адресной Книге (АК), и в неё нельзя будет из Облака отправить письмо. При этом сама папка в дереве PF видна будет, и контент тоже будет виден, нельзя будет только в неё написать.
Чтобы нормально работать с такой папкой из Облака, нужны дополнительные действия, описанные ниже. При изменении списка mail-enabled-PF или их свойств эти действия нужно повторять. Или автоматизировать рефреш скриптом по расписанию.
Скачайте комплект скриптов. Сохраните их в локальную папку типа C:\PFSync (как в моём примере).
На локальном Exchange:
.\Export-MailPublicFoldersForMigration.ps1 <…>.xml
На облачном Exchange:
.\Import-MailPublicFoldersForMigration.ps1 <…>.xml
Что произошло после выполнения скрипта в Облаке? Просто создались в облачном AD объекты, соответствующие PF, и в АК они появились.
4. Финальное включение
Самая главная команда!
Set-OrganizationConfig -PublicFoldersEnabled Remote –RemotePublicFolderMailboxes ProxyMB01
Что поменялось в настройках: поле PublicFoldersEnabled вместо Local стало Remote, и появилась ссылка на RemotePublicFolderMailboxes.
5. Проверка
Спустя некоторое время в Outlook-ах облачных пользователей даже без перезагрузки клиента появились Общие папки:
Теперь проверим работоспособность.
На стороне 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.