Недавно мне представилась возможность проверить политику хранения по умолчанию (именуемую политикой управления записями сообщений) для клиента Office 365. Обнаружив, что политика управления записями сообщений (MRM) в моем клиенте Office 365 пуста, я был уверен, что она лишилась тегов хранения из-за ошибки. Это не могло произойти по моей вине, ведь так? Однако выяснилось, что пустая политика была создана кем-то после назначения исходной политике другого имени. К сожалению, административный аудит Exchange Online оказался бесполезен, так как событие произошло 90 дней назад. Тем не менее служба технической поддержки Office 365 смогла определить причины случившегося, обнаружив некоторые другие ключи к проблеме.

Я запустил команду Get-RetentionPolicy (результаты ее выполнения показаны на на экране 1).

 

Результаты работы команды Get-RetentionPolicy
Экран 1. Результаты работы команды Get-RetentionPolicy

Достаточно одного взгляда, чтобы заметить, что политика управления записями сообщений (MRM) странным образом лишена тегов хранения. На самом деле это даже не политика, так как не предписывает помощнику для управляемых папок (MFA) производить какие-либо действия. Напомню, что политика управления записями сообщений назначается автоматически всем почтовым ящикам, созданным в Exchange Online, поэтому нефункционирующая политика хранения — это не то, что требуется. Если, конечно, вы не хотите отправить помощника для управляемых папок на заслуженный отдых.

Я бы предпочел назначить помощнику для управляемых папок какое-нибудь действие и считаю политику хранения полезной. Политика без тегов выглядит бессмысленной, поэтому я продолжил исследование (см. экран 2).

 

Информация о создании и изменении политик
Экран 2. Информация о создании и изменении политик

Из выходных данных видно, что политика управления записями сообщений по умолчанию создана 11 апреля 2015 года. Мой клиент Office 365 был установлен в середине 2011 года, поэтому относительная «молодость» политики выглядит странно. Мне было необходимо ответить на два вопроса: почему в политике управления записями сообщений по умолчанию нет тегов и почему в столбце WhenCreated стоят недавние даты?

К сожалению, этого нельзя узнать, заглянув в журнал административного аудита. Я выполнил команду Get-AdminAuditLogConfig, чтобы выяснить, как долго хранятся записи журнала аудита. Было подтверждено, что действует 90-дневный лимит, заданный по умолчанию. Очевидно, прошло более 90 дней со времени создания (или обновления) политики, поэтому поиск в журнале аудита не принесет результатов. Команда поиска обновлений для политик хранения и вид возвращаемых данных показаны на экране 3.

 

Команда поиска обновлений для политик хранения и возвращаемые данные
Экран 3. Команда поиска обновлений для политик хранения и возвращаемые данные

Если обнаружено достаточно много записей аудита, то можно направить выходные данные команде Out-GridView, чтобы просмотреть их через графический интерфейс.

Не добившись полезных сведений от аудита, я ввел запрос на обслуживание Office 365, чтобы попытаться получить данные, которые помогут раскрыть загадку. Я выяснил, что Office 365 Exchange Book Retention Policy («Политика хранения книги Exchange Office 365») — это политика по умолчанию для моего клиента, и потому автоматически назначается новым почтовым ящикам при их создании. Расскажу, как мне удалось это определить.

Локальный Exchange позволяет сделать любую политику хранения политикой по умолчанию, присвоив свойству IsDefault значение $True. Для сравнения: в Exchange Online политика, определенная планом почтового ящика, используется для назначения политики хранения новым почтовым ящикам. Если выполнить команду Get-MailboxPlan для формирования списка планов почтовых ящиков, известных клиенту, вы увидите, что каждый план имеет связанную политику хранения. В моем случае этой политикой была Office 365 Exchange Book Retention Policy (см. экран 4).

 

Политика сохранения для плана почтового ящика
Экран 4. Политика сохранения для плана почтового ящика

Судя по всему, первоначальная политика управления записями сообщений по умолчанию в какой-то момент была переименована. Я не могу вспомнить, чтобы я делал это, и не вижу веских причин для переименования политики. Однако политику легко переименовать с помощью команды Set-RetentionPolicy:

Set-RetentionPolicy -Identity “Default MRM
   Policy” -Name “Office 365 Exchange
   Book Retention Policy”

Скорее всего, я мог экспериментировать с PowerShell и переименовать исходную политику по умолчанию, а затем создать новую пустую политику (с помощью New-RetentionPolicy). Я совсем этого не помню, однако программы, как правило, не совершают никаких действий без участия человека. Может быть, я выпил слишком много кофе поздно вечером. Больше мне нечего сказать в свое оправдание.

А что можно сказать о сравнительно недавних датах политик? Один дружелюбный инженер из службы поддержки Office 365 объяснил мне, что это может случиться при перемещении клиента Office 365 между лесами Exchange, которые вместе образуют Exchange Online. Вероятно, такое происходит иногда при обслуживании или балансировке нагрузок. Хотя мой клиент существовал с 2011 года, некоторые его компоненты были обновлены в 2014 году.

Мне всегда хочется знать причины тех или иных событий, особенно если они связаны с программным обеспечением. В первую очередь мне не нравятся необъяснимые события в хорошо известных областях. Конечно, есть более важные вещи, требующие нашего внимания, и не составляет труда переименовать политику хранения, чтобы восстановить ее первоначальное имя. Но, по крайней мере, я узнал, как Exchange Online определяет, какая политика хранения должна быть назначена новым почтовым ящикам.