Около года назад я начал заниматься процедурой оформления пакета документов, необходимых с точки зрения нашего государства каждому грудничку. В процессе убедился, что государство работает не так как надо, а так как ему хочется, а хочется ему не часто. Впрочем, это лирика. Ниже небольшое описание самой процедуры. Возможно оно поможет кому-нибудь. Общая процедура, скорее всего будет сходна для всех регионов России. Отличаться (скорее всего) будет список документов.

В качестве отправной точки статья – “Оформить документы на ребенка стало сложнее, чем его родить“.

Оттуда же отличная инфографика про оформление документов:

612394

Приступим. При выписке из роддома мы имеем следующий список документов:

  • Справка о рождении (выписке)
  • Родовой сертификат часть 1
  • Родовой сертификат часть 2

Итак. Прохождение квеста.

1. “Родовой сертификат часть 1” уезжает в женскую консультацию. Этот шаг относительно прост. Врач из женской консультации позвонила сама и поинтересовалась когда ей привезут эту бумажку. Договорились о времени. Подъехал вовремя, передал.

2. “Справка о рождении (выписке)” уезжает в ЗАГС. Получаю там “Свидетельство о рождении”. Необходимый список документов:

  • Справка о рождении
  • Паспорта родителей
  • Свидетельство о браке
  • Заявление

Заявление можно предварительно распечатать и заполнить самому или заполнить его на месте. “Свидетельство о рождении” выдают сразу же + выдают справку на получение единовременного пособия при рождении ребёнка. Приехал в ЗАГС после обеда, проторчал там часа четыре. За полчаса до закрытия пытались начать выгонять желающих оформить “Свидетельство о рождении”, которое требует государство. Пришлось сказать, что я никуда не уйду, пока не получу нужный документ. Итого, минус один документ (Справка о рождении) и плюс два новых (Свидетельство о рождении и справка на получение единовременного пособия). Ходил два раза. Первый раз – узнать расписание работы. Второй раз – собственно за документом.

3. Паспортный стол. Оформление прописки для малыша (с точки зрения государства малыш немедленно начинает потреблять ресурсы ЖКХ, поэтому должен быть прописан, иначе государство в лице ЖКХ недополучит так нужные ему деньги). Список документов:

  • Паспорта родителей
  • Свидетельство о рождении + копия
  • Свидетельство о браке
  • Заявка о том, что второй родитель не против прописать ребёнка

Один из паспортов забрали, выдали справку (привет ППС!) и телефон по которому звонить через неделю. Да, заявку второй родитель должен подписать лично. По умолчанию, действует презумпция виновности. Ходил три раза. В первый раз узнал, что должны присутствовать оба родителя. Второй раз – подача документов на прописку. Третий раз – забирал паспорт и прописку ребёнка. Итого плюс один документ (о прописке).

4. ФМС. Странно, но рождение ребёнка от граждан РФ не считается основанием считать его гражданином РФ. Гражданином РФ его делает оформление в ФМС. Запрошенные документы:

  • Паспорта обоих родителей
  • Копии паспортов обоих родителей (страницы с фотографией и пропиской)
  • Свидетельство о рождении
  • Копия свидетельства о рождении

Попытались забрать оба паспорта. Подтверждение готовят несколько часов (утром сдаёшь документы – вечером забираешь). На просьбу выдать бумажку “Привет ППС” посмотрели на меня как на дурака и сказали, что не имеют прав. В ответ я им оставил только один паспорт и ещё долго потом жалел, что не забрал его с собой. Гражданство подтверждается специальной печатью на свидетельстве о рождении. Кроме этого в паспорта родителей вписывается ребёнок. Ходил два раза. Первый – подавал документы. Второй – забирал документы.

5. Страховая компания. Запрошенные документы:

  • Свидетельство о рождении
  • Паспорт родителя, который подаёт документы

Свидетельство о рождении и паспорт возвращают сразу же. Так же выдают временную справку, по которой предоставляются услуги ОМС. Через месяц можно будет получить постоянный полис ОМС. Итого плюс один документ (полис ОМС). Ходил два раза. Первый – подавал документы. Второй – забирал документы.

6. Детская поликлиника. Туда уезжает “Родовой сертификат часть 2”. Подробностей не знаю. Ездила мама с ребёнком. Судя по последующему общению с поликлиникой та ещё клоака. Итого минус один документ. Ребёнок поставлен на учёт.

7. Постановка в очередь на дет/сад. В Москве существует “электронная” очередь. Которая по сути выполняет одну функцию – отображать положение ребёнка в очереди в дет/сад. То есть вставать в очередь всё равно придётся ехать ногами. Вот такая вот электронная государственная услуга. Запрошенные документы:

  • Свидетельство о рождении

Ходил один раз. Получил номер в электронной очереди.

8. СОБЕС. Без острой необходимости ездить туда смысла нет. Выхлоп копеечный (+500 рублей в кошелёк + социальная карта москвича), испорченное настроение – гарантировано.

Итого. Если на работе отпрашиваться проблематично, то папаше имеет смысл брать отпуск на 2-3 недели и прокачивать уровень площадной ругани. Если папаши нет – то моё сочувствие мамочке. Так как придётся везде носить с собой ребёнка. А это, во-первых, неудобно, во-вторых, скорее всего не полезно для здоровья малыша.

Шаги 3, 4 придётся выполнять последовательно. Шаг 5, можно выполнять параллельно с шагами 3-4.

Список документов для других людей может отличаться от указанных мной, ибо фантазия наших чиновников безгранична.

Успехов!

PowerShell LogoИлья Сазонов недавно жаловался на проблему массового удаления большого количества объектов из папки RecoverableItems. Решил он эту проблему с помощью редактора MFCMapi. Но, задача так же имеет решение через EWS. При этом необходимо держать в уме Throttling Policy, которые, возможно, необходимо будет подправить для учётной записи, из под которой мы будем удалять объекты. Не растекаясь долго мысью по древу просто выложу скрипт, который удаляет объекты из папки RecoverableItems ящика с адресом user.name@domain.com.

Import-Module -Name "C:Program FilesMicrosoftExchangeWeb Services2.0Microsoft.Exchange.WebServices.dll"
$FromMailbox = "user.name@domain.com"

$service = New-Object Microsoft.Exchange.WebServices.Data.ExchangeService([Microsoft.Exchange.WebServices.Data.ExchangeVersion]::Exchange2010_SP2)
# Impersonation
$service.ImpersonatedUserId = New-Object Microsoft.Exchange.WebServices.Data.ImpersonatedUserId([Microsoft.Exchange.WebServices.Data.ConnectingIdType]::SmtpAddress,$FromMailbox)
# Адрес CAS-сервера получаем через службу автообнаружения
$service.AutodiscoverUrl($FromMailbox)

# Размер страницы вывода (количество объектов, возвращаемых за один раз)
$pageSize = 50
$Offset = 0
do {
$ItemView = new-object Microsoft.Exchange.WebServices.Data.ItemView($pageSize,$Offset,[Microsoft.Exchange.WebServices.Data.OffsetBasePoint]::Beginning)
# Получаем объекты из папки RecoverableItemsRoot, параметры вывода берём из переменной $ItemView
$FindItems = $service.FindItems([Microsoft.Exchange.WebServices.Data.WellKnownFolderName]::RecoverableItemsRoot, $ItemView)
foreach ($Item in $FindItems.Items){
# Операция жёсткого удаления объекта
$Item.Delete([Microsoft.Exchange.WebServices.Data.DeleteMode]::HardDelete) }
$Offset += $pageSize }
# Продолжаем перебор объектов, пока остаются непросмотренные
while ($FindItems.MoreAvailable)

Полезные ссылки:
EWS throttling in Exchange
WellKnownFolderName enumeration
ExchangeService.FindItems method (FolderId, ViewBase)
DeleteMode enumeration
ItemView constructor (Int32, Int32, OffsetBasePoint)
OffsetBasePoint enumeration
Configuring Exchange Impersonation

PowerShell LogoВ Outlook пользователь на конкретные папки может достаточно гибко раздавать права доступа другим пользователям организации. Обычно этот сценарий используется руководителями, которые делегируют часть прав на свой ящик секретарю. И в некоторый момент может понадобиться сделать простейший аудит прав. Права на конкретную папку в почтовом ящике пользователя можно получить с командлетом Get-MailboxFolderPermission. Например:

[PS] C:>Get-MailboxFolderPermission stbul:calendar | fl User, AccessRights

User         : Default
AccessRights : {AvailabilityOnly}

User         : Anonymous
AccessRights : {None}

Главная сложность в том, что в качестве основного параметра в этот командлет необходимо передавать имя/идентификатор папки. И в ответ мы получаем не конкретные значения, а объекты, которые нам интересны не полностью, а только некоторые их свойства (User и AccessRights). То есть необходимо получить полный список папок ящика пользователя и по каждой из них получить набор пар User-AccessRights. Полный список папок ящика пользователя проще всего получить через командлет Get-MailboxFolderStatistics, который вернёт как имена папок, так и их идентификаторы (которые использовать проще, чем имена папок). Итоговый скрипт выглядит примерно так:

. 'C:Program FilesMicrosoftExchange ServerV14binRemoteExchange.ps1'
Connect-ExchangeServer -auto sleep 5

$Mailbox = Get-Mailbox mailbox.name
$MbxStat = Get-MailboxFolderStatistics $Mailbox

foreach ($item in $MbxStat){
    $folder = $Mailbox.Name + ":" + $item.FolderId
    $FolderPerms = Get-MailboxFolderPermission $folder
    foreach ($FolderPerm in $FolderPerms){
        Write-Host $item.FolderPath " | " $FolderPerm.User " | " $FolderPerm.AccessRights }
}

Полезные ссылки:
Get-MailboxFolderPermission
Get-MailboxFolderStatistics

PowerShell LogoПериодически приходится писать крипты, автоматизирующие те или иные действия администратора. Иногда это бывает обычный сбор информации. Иногда это внесение изменений в конфигурацию/учётные записи, связанные с наступлением тех или иных событий. Тонкость возникает там, где необходимо работать с объектами Exchange. обычно, для этого достаточно в скрипте импортировать оснастку PS Microsoft.Exchange.Management.PowerShell.E2010 (Excahnge 2010):

Add-PSSnapin Microsoft.Exchange.Management.PowerShell.E2010

Однако, в случае, когда нам в скрипте необходимо использовать командлет Get-MailboxStatistics получаем следующую ошибку:

PS C:> Get-Mailbox user | Get-MailboxStatistics
Get-MailboxStatistics : Failed to commit the change on object "MB-DATABASE" because access is denied.
At line:1 char:45
+ Get-Mailbox buldakov | Get-MailboxStatistics <<<<
+ CategoryInfo          : NotSpecified: (0:Int32) [Get-MailboxStatistics], MapiAccessDeniedException
+ FullyQualifiedErrorId : 46BEBAF0,Microsoft.Exchange.Management.MapiTasks.GetMailboxStatistics

Проверка прав для учётки, из под которой запускается скрипт показала, что права на запуск есть. Тем более странной стала выглядеть ситуация.

PS C:>Get-ManagementRoleEntry "*Get-MailboxStatistics" | ? {$_.Role -like "Mail  Recipients"} | fl Name,Role
Name : Get-MailboxStatistics
Role : Mail Recipients

PS C:>Get-ManagementRoleAssignment -Role "Mail Recipients" -GetEffectiveUsers | ? {$_.EffectiveUserName -like "svc_Name"} | fl Role,EffectiveUserName
Role              : Mail Recipients
EffectiveUserName : svc_Name

Нашёлся следующий workaround. Для подключения к Exchange используем стандартный скрипт RemoteExchange.ps1:

. 'C:Program FilesMicrosoftExchange ServerV14binRemoteExchange.ps1'
Connect-ExchangeServer -auto

Точку с пробелом в начале ставить обязательно.

e2010Следующий сценарий родился в процессе миграции пользователей с одного из сторонних почтовиков. Итак, у нас имеется набор почтовых ящиков, которые созданы для миграции со стороннего почтового решения. В некоторый момент времени к стандартным smtp-адресам (например, domain.com) добавляются smtp-адреса, которые находятся у пользователей во внешней почтовой системе (например, домен domain.net). Так как изначально процесс не сильно автоматизирован, то в некоторый момент времени оказывается, что не все почтовые ящики имеют smtp-адрес из домена domain.net. А час X (когда мы добавим домен domain.net в авторизованные) приближается и необходимо выяснить какие-же почтовые ящики мы не охватили. То есть необходимо найти те почтовые ящики (предположим, что мы их пока складируем в отдельных почтовых базах), которые примут пользователей при миграции, но при этом старый smtp-адрес для них не прописан.

Первым делом давайте посмотрим в каком виде у нас хранятся smtp-адреса. Все они находятся в свойстве EmailAddresses почтового ящика. Свойство это многозначное, то есть фактически представляет собой некий массив разнородных данных (помним, что кроме smtp-адресов в этом свойстве могут записываться и другие типы адресов, например, sip или X400). При обращении к нему выведется набор объектов, каждый из которых представляет определённый адрес, прописанный в свойствах ящика:

[PS] C:>(Get-Mailbox stbul).EmailAddresses

SmtpAddress        : stbul@domain.com
AddressString      : stbul@domain.com
ProxyAddressString : SMTP:stbul@domain.com
Prefix             : SMTP
IsPrimaryAddress   : True
PrefixString       : SMTP

AddressString      : C=RU;A= ;P=DOMAIN;O=DOMAIN;S=Buldakov (Test);G=Stanislav;
ProxyAddressString : X400:C=RU;A= ;P=DOMAIN;O=DOMAIN;S=Buldakov (Test);G=Stanislav;
Prefix             : X400
IsPrimaryAddress   : True
PrefixString       : X400

Очевидно, что работать мы будем не со всеми адресами, а только с smtp. Поэтому имеет смысл фильтровать по свойству ProxyAddressString, и выбирать только те объекты-адреса, у которых это свойство начинается с SMTP. Простейший вариант поиска только smtp-адресов будет выглядеть следующим образом:

$mailbox = Get-Mailbox somemailbox
for ($i=0; $i -lt $mailbox.EmailAddresses.Count; $i++){
    if ($mailbox.EmailAddresses[$i].ProxyAddressString -like "smtp:*"){
        $mailbox.EmailAddresses[$i]}
}

В нашем случае процесс усложняется тем, что перед нами стоит обратная задача. То есть надо собрать не все почтовые ящики с адресами в определённом домене, а те, у которых адресов из нужного нам домена нет. Один из вариантов решения данной проблемы – использование специального счётчика, который будет увеличиваться при нахождении в свойствах ящика нужного нам smtp-адреса. А в итоге, выводить будем те объекты, значение счётчика для которых будет равно нулю (то есть он не будет содержать нужного нам smtp-адреса). Итоговый скрипт получается примерно следующий:

$mailboxes = Get-MailboxDatabase new-db* | Get-Mailbox
foreach ($mailbox in $mailboxes){
    $i = 0
    $count = 0
    for ($i=0; $i -lt $mailbox.EmailAddresses.Count; $i++){
    if ($mailbox.EmailAddresses[$i].ProxyAddressString -like "smtp:*domain.net"){
        $count = $count + 1}
    }
    if ($count -eq 0){
        $mailbox.Name}
}

Аналогично, можно искать, например, группы распространения. В этом случае в переменную $mailboxes помещается набор нужных нам групп.

e2010В предыдущей статье я обзорно пробежался по процедуре переключения почтового сервиса на резервный дата центр в случае сбоя основного. Есть ещё один сценарий, который возникает в случае, если наш DAG растянут между двумя и более дата центрами. Речь идёт о так называемом Database Failover – который отрабатывает в случае сбоя базы и переводит активную базу в другой дата центр. Картинка с технета прекрасно показывает данную ситуацию:

untitled1

В данном сценарии интересен момент с поведением клиента, в случае когда активная база перемещается в другой дата центр. Получается, что для клиента доступны конечные точки в обоих дата центрах. Но, сразу же после переезда активной базы, клиент будет подключаться к конечной точке в основном дата центре. Разделим клиентов по их типам:

e2010В Exchange 2010 появилась возможность достаточно просто собрать отказоустойчивую конфигурацию для почтовой системы организации на базе нескольких дата центров, которые физически разнесены друг от друга. Для данной конфигурации существует одна неразрешимая проблема, которую не совсем получается логически описать, а следовательно автоматизировать. Эта проблема – какой дата центр считать выжившим после сбоя? В связи с наличием данной проблемы и существует процедура переключения активного дата центра (Datacenter Switchover), которую должен выполнять администратор почтовой системы в случае глобального сбоя, приведшего к недоступности одного из дата центров, который использовался пользователями почтовой системы.

Процедура переключения дата центра хорошо описана. Так что я перенесу её, немного сократив.

Стандартный список действий при переключении дата центра:

  • Остановка вышедшего из строя основного дата центра.
  • Проверка готовности резервного дата центра.
  • Активация серверов почтовых ящиков в резервном дата центре.
  • Активация остальных серверных ролей в резервном дата центре.

Continue Reading »

Последние 5 лет с завидной периодичностью встречаю вопросы может ли Exchange использовать RODC (Read-Only Domain Controller) и, в частности, ROGC – RODC, которые содержат глобальный каталог. Ответ на этот вопрос уже давно дан:

  • Нет, Exchange не может использовать RODC/ROGC
  • Нет, Exchange не запустится в том сайте, где находятся только RODC/ROGC
  • Да, нужен полноценный контроллер домена, с правом на запись

Следующий вопрос, который может возникнуть – а почему нельзя использовать RODC/ROGC?

Здесь немного придётся погрузиться в историю. Exchange 2000/2003 использовал специальный компонент DSAccess, который отвечал за доступ к Active Directory (чтение конфигурации, внесение изменений итд). Кроме этого, DSAccess отвечал за составление списка контроллеров домена и серверов глобального каталога, который мог бы в дальнейшем использовать Exchange. Механизм построения списка выглядел следующим образом:

  • DSAccess обращался к DS Locator Service
  • Через него (через ldap-запрос к разделу конфигурации) получал список DC и GC локального сайта AD, в котором находился сервер Exchange
  • Пытался подключиться к каждому из серверов из полученного списка
  • Кешировал 10 доступных DC и 10 доступных GC
  • Перестраивал список таким образом, что в верх списка попадали GC, из того же домена, членом которого являлся сервер Exchange

Отсюда следуют достаточно очевидные выводы:

  • Как минимум один GC должен находиться в сайте, где расположен сервер Exchange
  • GC должен находиться достаточно близко к серверу Exchange. Если имеются две физические локации в одном сайте, то лучше бы сервер GC разместить в той же локации, где находится сервер Exchange
  • Для обеспечения высокой доступности имеет смысл держать 2 или больше GC в сайте, где находится сервер Exchange

В Excahnge 2007 компонент разбили на две части – AD Provider и AD Driver (оба работают в рамках одного сервиса – Active Directory Topology). Функциональность не изменилась. Они так же отвечали за работу с Active Directory. AD Provider отвечал за обращение к AD и поддержку работы кэша (с результатом обращений к AD). AD Driver отвечал за построение топологии DC.

Возвращаясь к нашему вопросу про ROGC. И AD Provider и DSAccess получают список контроллеров домена (включая GC) через специальный ldap-запрос в контейнере с сайтами в разделе конфигурации (CN=Sites,CN=Configuration,DC=domain, DC=local). Запрос для Exchange 2010 выглядит следующим образом:

(|(&(objectCategory=CN=NTDS-DSA,CN=Schema,CN=Configuration,DC=domain,DC=local)
(objectCategory=CN=NTDS-DSA-RO,CN=Schema,CN=Configuration,DC=domain,DC=local))
(&(objectCategory=CN=NTDS-DSA,CN=Schema,CN=Configuration,DC=domain,DC=local)
(objectCategory=CN=NTDS-DSA,CN=Schema,CN=Configuration,DC=domain,DC=local)))

Если внимательно посмотреть, то запрос возвращает только объекты, которые являются экземплярами класса NTDS-DSA (который представляет DSA на конкретном контроллере домена). И тут есть небольшая тонкость. RODC представлены другим классом – NTDS-DSA-RO, а следовательно, в процессе запроса списка контроллеров домена в этот список не попадают. То есть, Exchange вообще ничего не знает про контроллеры домена только для чтения. А следовательно, пользоваться RODC/ROGC в качестве контроллеров домена не умеет (что не исключает возможности их использования в качестве серверов DNS, например).

Полезные ссылки:
How DSAccess Builds the List of Cached Servers
Exchange 2000 SP2’s DSAccess Component
The AD Administrator’s Guide to Exchange 2007
AD Integration – from 2003 to 2007….
Windows 2008 Read Only Domain Controllers and Exchange 2007…

Протокол Kerberos достаточно хорошо описан в документе «How the Kerberos Version 5 Authentication Protocol Works». Реализация протокола Kerberos в Windows Server 2003 компанией Microsoft достаточно близка к стандарту RFC 1510. С тех пор прошло 10 лет. Успели выйти Windows Server 2008, 2008 R2, 2012, готовится к выходу Windows Server 2012 R2. Сам стандарт обновился до версии RFC 4120, к которому уже согласовано большое количество дополнений. К сожалению, я нигде не видел (возможно плохо искал) документа, описывающего изменения произошедшие в протоколе Kerberos и в его реализации компанией Microsoft. Поэтому попробую восполнить этот пробел.

Так как меня интересует реализация конкретного вендора, то изменения прежде всего будут привязаны к операционным системам Windows. Continue Reading »

e2010В очередной раз натолкнулся на проблему некорректной отработки RBAC в случае работы с общими папками. Стоит задача – делегировать права на заведение mail-enabled общих папок. То есть по факту, на командлет Enable-MailPublicFolder. Право на запуск этого командлета делегировано всего одной роли:

[PS] C:Windowssystem32>Get-ManagementRoleEntry '*Enable-MailPublicFolder' | fl Name, Role

Name : Enable-MailPublicFolder
Role : Mail Enabled Public Folders

По идее, достаточно назначить эту роль группе ролей, в которую будет входить нужный нам делегат и дело в шляпе. В итоге получаем:

[PS] C:Windowssystem32>Enable-MailPublicFolder -Identity 'Public Folder'
MapiExceptionNoAccess: Unable to set properties on object. (hr=0x80070005, ec=-2147024891)
...
+ CategoryInfo          : NotSpecified: (0:Int32) [Enable-MailPublicFolder], MapiExceptionNoAccess
+ FullyQualifiedErrorId : 1CA8E050,Microsoft.Exchange.Management.MapiTasks.EnableMailPublicFolder

Самая вкуснятина в конце предпоследней строки: MapiExceptionNoAccess. Оказывается, чтобы создавать mail-enabled общие папки штатного механизма RBAC не достаточно. В Exchange 2000/2003 за процедуру создания mail-enabled общих папок отвечало специальное разрешение ms-Exch-Mail-Enabled-Public-Folder. Назначалось оно на уровне конкретной организации Exchange в разделе конфигурации в AD. Что интересно, в Exchange 2010 оно там же и осталось. Более того, этим разрешением обладают две группы – Organization Management и Public Folder Management:

[PS] C:Windowssystem32>Get-ADPermission -Identity "CN=OrgName,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=o365test,DC=pro" | ? {$_.ExtendedRights -like 'ms-Exch-Mail-Enabled-Public-Folder'} | select User

User
----
Organization Management
Public Folder Management

Ради интереса привожу полный список разрешений группы Public Folder Management на контейнер почтовой организации:

[PS] C:Windowssystem32>Get-ADPermission -Identity "CN=OrgName,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=0365test,DC=pro" | ? {$_.User -like '*Public Folder Management'} | select AccessRights, ExtendedRights

AccessRights                                                ExtendedRights
------------                                                --------------
{GenericRead}
{ExtendedRight}                                             {ms-Exch-Create-Public-Folder}
{ExtendedRight}                                             {ms-Exch-Modify-Public-Folder-Deleted-Item-Retention}
{ExtendedRight}                                             {ms-Exch-Modify-Public-Folder-Replica-List}
{ExtendedRight}                                             {ms-Exch-Modify-Public-Folder-Expiry}
{ExtendedRight}                                             {ms-Exch-Modify-PF-Admin-ACL}
{ExtendedRight}                                             {ms-Exch-Modify-Public-Folder-Quotas}
{ExtendedRight}                                             {ms-Exch-Mail-Enabled-Public-Folder}
{ExtendedRight}                                             {ms-Exch-Modify-PF-ACL}
{ExtendedRight}                                             {ms-Exch-Store-Create-Named-Properties}
{ExtendedRight}                                             {ms-Exch-Store-Admin}
{ExtendedRight}                                             {ms-Exch-Store-Visible}
{ExtendedRight}                                             {ms-Exch-Create-Top-Level-Public-Folder}

Дело осталось за малым – назначить соответствующие разрешения для нашего делегата:

Add-ADPermission -Identity "CN=OrgName,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=0365test,DC=pro" -User "Public Folders Delegates" -AccessRights GenericRead

Add-ADPermission -Identity "CN=OrgName,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=0365test,DC=pro" -User "Public Folders Delegates" -ExtendedRights ms-Exch-Mail-Enabled-Public-Folder 

Интересные ссылки:
Beyond RBAC: Delegating the ‘Mail-enable Public Folders’ right
Permissions Available in Exchange