С момента своего появления в Exchange 2007 служба автообнаружения используется в Outlook по известному заранее сценарию:

  1. Outlook пытается подключиться к AD и получить список SCP для своего сайта
  2. Если п.1 не выполнен, то идёт обращение по адресу https://<SMTP-address-domain>/autodiscover/autodiscover.xml
  3. Если п.2 не выполнен, то идёт обращение по адресу https://autodiscover.<SMTP-address-domain>/autodiscover/autodiscover.xml
  4. Если п.3 не выполнен, то идёт попытка редиректа, настроенного для http://autodiscover.<SMTP-address-domain>/autodiscover/autodiscover.xml
  5. Если п.4 не выполнен, то идёт обращение к SRV-записи _autodiscover._tcp.<SMTP-address-domain>

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

Все настройки выполняются в ветке реестра HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover. Доступны следующие ключи:

"ExcludeScpLookup"=dword:00000001
"ExcludeHttpsRootDomain"=dword:00000001
"ExcludeHttpsAutoDiscoverDomain"=dword:00000001
"ExcludeHttpRedirect"=dword:00000001
"ExcludeSrvRecord"=dword:00000001

Полезные ссылки:
Autodiscover for Exchange
Autodiscover service
Outlook 2016 Implementation of Autodiscover
Plan to automatically configure user accounts in Outlook 2010

Задача: нужно сменить расширение всех файлов в определённой директории, скажем с .txt на .log.

Задача имеет простое решение в PoSh:

Get-ChildItem -Path <SomePath> -Filter '*.txt' | Rename-Item -NewName {$_.name 
-replace '.txt','.log'}

Полезные ссылки:
Use PowerShell to Rename Files in Bulk

Active Directory предоставляет штатный механизм изменения типа группы (Distribution ↔ Security).

В случае, если у нас имеется Exchange, этого недостаточно. Необходимо так же на стороне Exchange запустить процесс обновления типа группы. В общем то это совсем не новость, так как механизм автоматической конвертации группы распространения в группу безопасности пропал в Exchange 2007 и с тех пор назад не возвращался. Поэтому, если изменение Distribution ↔ Security было выполнено на стороне Active Directory необходимо после этого запустить следующий командлет:

Set-Distributiongroup –identity <DistributionGroupId> –MemberDepartRestriction Closed

Если этого не сделать, то все операции назначения прав доступа для новоиспечённой группы безопасности на стороне Exchange будут давать сбои: нельзя будет назначать на группу права на ящики, на группы рассылок, на календари итд. итп.

Полезные ссылки:
Modify Group Type or Group Scope
How to change a UDG to a USG in Exchange 2010
Automatic converison of UDG in USG in Exchange 2007
EXCHANGE 2010 – ADD OUTLOOK CALENDAR PERMISSIONS FOR ALL MEMBERS OF A GROUP

Достаточно давно, почти сразу после появления, я делал обзор функции онлайн-архива, которая позволяла перемещать в архивный ящик письма, старше определённого возраста. С тех пор прошло достаточно много времени. Саму функциональность переименовали в In-Place Archive. Научились работать со стандартными папками Tasks и Calendar.

Недавно столкнулся с одним странным случаем. Имеется политика хранения, которая содержит DPT для архивирования, RPT для папки Tasks и несколько пользовательских тэгов. RPT для папки Tasks настроен на бессрочное хранение задач (Never Delete), DPT переносит в архив объекты старше некоторого срока (предположим, старше одного года). Согласно документации DPT применяется только к объектам, которые не помечены другими тэгами. Поэтому, вроде бы, под действие этого тэга не должны попадать задачи (помечены RPT для папки Tasks) и все папки и письма, которые помечены пользователем с помощью пользовательских тэгов.

На самом деле это не так. Задачи из папки Tasks будут попадать под действие DPT и уезжать в архив, согласно настройкам дефолтного тэга.

Кто виноват?

Предполагаю, что дело в следующем. Известно, что весь процесс работы политик хранения построен на MAPI-аттрибутах RetentionPeriod/PR_RETENTION_PERIOD, RetentionDate/PR_RETENTION_DATE, PolicyTag/PR_POLICY_TAG, ArchivePeriod/PR_ARCHIVE_PERIOD, ArchiveDate/PR_ARCHIVE_DATE и ArchiveTag/PR_ARCHIVE_TAG. Первые три связаны с настройками политик хранения (период хранения, дата истечения хранения и применённый тэг хранения), последние три с настройками архивирования (период хранения до запуска процесса архивирования, дата истечения хранения перед перемещением в архив и применённый тэг архивирования). На основании этих аттрибутов соответствующий ассистент (робот) на почтовом сервере обрабатывает объекты в почтовом ящике. Для новых объектов согласно применённым тэгам проставляются сроки хранения и время истечения сроков хранения. Для уже помеченых объектов принимается решение нужно ли с ними что-то делать, если срок хранения истёк.

С нашим странным случаем получается забавная ситуация. Ассистент видит, что существует DPT с действием MoveToArchive. Для задач из папки Tasks архивные MAPI-аттрибуты не проставлены, так как архивирование для папок Tasks и Calendar недоступно. На основании этого ассистент принимает(моё предположение) решение, что задачи попадают под действие DPT и начинает их перемещать в архив согласно настройкам DPT.

Что делать?

MS предлагает в данной ситуации один вариант – отключить для ассистента возможность обрабатывать объекты из папок Tasks/Calendar. Делается это нашим любимым способом – через пятую точкуреестр. Нужен следующий ключ на всех почтовых серверах, где хранятся базы с ящиками пользователей:

Path: HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeMailboxAssistants\Parameters
Name: ELCAssistantCalendarTaskRetentionEnabled
Type: DWORD
Value: 0 (Do not process Calendar and Task folders)

Полезные ссылки:
Retention tags and retention policies in Exchange 2016
Prevent archiving of items in a default folder in Exchange 2010
Calendar and Tasks Retention Tag Support in Exchange 2010 SP2 RU4
Retention policy on Calendar and Task folders. Confused ?
DPT with move to archive action takes precedence over RPT.
Default folders that support Retention Policy Tags
Архивирование в Exchange 2010 SP1