Сегодня мы живем в бесконечном потоке информации. Наши почтовые ящики забиты сообщениями и нет никакого желания тратить время и силы на наведение в них хоть какого-нибудь порядка. Автоматическая архивация Outlook помогает поддерживать порядок, регулярно перемещая элементы из почтового ящика в файл PST, но это довольно грубый инструмент, поскольку критерием перемещения является дата создания элементов, а не какая-либо гибкая система параметров.

Сервер Microsoft Exchange 2007 представил в качестве почтовой бизнес-стратегии систему управления записями сообщений messaging records management (MRM), которая была призвана помочь пользователям выполнять нормативные и юридические требования. Идея была проста: автоматизировать процесс хранения таким образом, чтобы у пользователей была возможность управлять тем, что находится в их почтовых ящиках, и сохранять те сообщения и вложения, которые обязательны для хранения.

Для реализации этой идеи в Exchange 2007 MRM используется набор управляемых папок с назначенными для них политиками. Помощник по работе с управляемыми папками Managed Folder Assistant (MFA) применяет политики, назначенные для папок. Отмеченные элементы хранятся, сколько необходимо; остальные автоматически удаляются, когда период их хранения истекает. Несмотря на красивую идею, в реальности система MRM сервера Exchange 2007 в целом неэффективна, поскольку пользователи весьма недисциплинированны, когда речь заходит о размещении сообщений в папках. Поэтому компания Microsoft изменила свою тактику, чтобы реализовать реально работающий вариант MRM в Exchange 2010.

Новый подход

Теперь вместо управляемых папок система MRM сервера Exchange 2010 использует теги и политики хранения. Управляемые папки присутствуют и в Exchange 2010, но только для обеспечения обратной совместимости.

Теги хранения. Exchange 2010 поддерживает три типа тегов хранения: теги политики хранения retention policy tags (RPT), теги политики по умолчанию default policy tags (DPT) и личные теги. В таблице 1 описаны эти типы тегов.

 

Таблица 1. Типы тегов хранения

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

Политики хранения. Политики хранения группируют теги хранения таким образом, чтобы администраторы имели возможность применять политики к почтовым ящикам, вместо того, чтобы назначать папкам отдельные теги хранения. Теги и политики хранения — объекты, действительные для всей организации. Они хранятся в AD и после создания могут быть применены к любому почтовому ящику в организации. MFA по-прежнему отвечает за проверку содержимого почтовых ящиков на предмет соответствия политикам и предпринимает указанные действия по отношению к тем элементам, период хранения которых истек.

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

  1. Тег хранения с самым долгим периодом хранения всегда имеет приоритет. Это правило гарантирует, что Exchange никогда не удалит элемент, прежде чем время его хранения действительно истечет.
  2. Тег хранения, примененный непосредственно к какому-либо элементу (или ко всем элементам в папке), имеет приоритет перед тегом, который элемент наследует через политику хранения по умолчанию. Например, если элементу назначен личный тег, определяющий, что этот элемент должен храниться в течение 6 лет, но политика хранения по умолчанию для папки требует его удаления через 12 месяцев, то этот элемент будет храниться в течение 6 лет.

Чтобы использовать Exchange 2010 MRM, необходимо развернуть клиенты, которые имеют соответствующие интеллектуальные возможности и интерфейс пользователя. На момент написания этой статьи единственными клиентами в данной категории были Outlook 2010 и Outlook Web App (OWA). Пользовательский интерфейс Outlook 2010 обеспечивает богатейший набор представлений для политик и тегов хранения. OWA не столь совершенен в этом отношении, но тем не менее весьма удобен.

Разработка политики хранения

В пределах организации может существовать множество тегов политики хранения, что обеспечивает большую гибкость при создании соответствующих политик хранения для различных групп, работающих в компании. Например, финансовому отделу может потребоваться, чтобы Exchange окончательно удалял из «Корзины» все элементы старше трех дней (так называемый «принцип шредера»), в то время как другим подразделениям будет безразлично, если элементы в этой папке хранятся 30 дней и более. Для сотрудников финансового отдела можно применить политику хранения, содержащую RPT, который дает указание MFA окончательно удалять из «Корзины» все элементы по прошествии трех дней. Та же политика может включать личный тег, который позволяет сотрудникам финансового отдела помечать элементы в их основном почтовом ящике, которые должны быть заархивированы через месяц для последующего возможного аудита. Во время обработки почтового ящика MFA переместит элементы с этим тегом в архивный почтовый ящик.

Прежде чем создавать политику хранения, нужно определить для нее следующие «почему» «когда» и «как».

  • Почему реализуется эта политика? Какой потребности бизнеса она будет отвечать?
  • Когда будет реализована эта политика? К каким почтовым ящикам она будет применена? Как донести эту политику до пользователей так, чтобы они поняли ее предназначение, и каким образом она повлияет на содержимое их почтовых ящиков?
  • Как будет реализована политика? Какие потребуются теги? Какие действия будут производиться посредством использования тегов и какими будут периоды хранения? Существуют ли какие-нибудь ограничения на реализацию политики? Например, если для архивации используется программное обеспечение стороннего производителя, задействовать теги для перемещения элементов в архивный почтовый ящик по истечении обозначенного периода будет невозможно.

Проект политики хранения обычно фиксируется в виде простой таблицы, которая содержит информацию о том, какие теги включены в политику, каково их назначение и к каким папкам они применяются. Помимо прочего, политику, оформленную в виде простой и понятной таблицы, гораздо легче донести до пользователей. В таблице 2 приведен пример политики, которая может использоваться для того, чтобы помочь менеджерам справиться с их «перегруженными» почтовыми ящиками. Логично, что для каждой папки должен существовать только один RPT. Весьма бестолково выглядят два RPT, конкурирующие за одну папку.

 

Таблица 2. Пример политики хранения

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

Создание тегов хранения

Exchange 2010 MRM задуман и реализован весьма неплохо. Единственная проблема заключается в том, что компания Microsoft не поставляет вместе с окончательной версией Exchange 2010 какую-либо графическую оболочку, которую можно было бы использовать для создания и применения тегов и политик хранения. Недостающий инструмент компания Microsoft обещает включить в пакет обновления 1 (SP1) для Exchange 2010. Бета-версия этого кода была опубликована на TechEd в июне 2010 года, а окончательная версия выйдет, как ожидается, чуть позже в этом году. А пока не выпущен SP1, для создания и применения тегов и политик хранения можно воспользоваться оболочкой PowerShell.

Давайте создадим различные теги, необходимые для построения политики хранения, представленной в таблице 2. Для того чтобы создать тег хранения, используется команда New-RetentionPolicyTag. Таким образом, для создания, например, RPT для папки «Входящие» необходимо выполнить следующую команду:

New-RetentionPolicyTag
   -Name 'Manager-Inbox'
   -RetentionAction MoveToDeletedItems
   -AgeLimitForRetention 30
   -Type Inbox
   -Comment 'Inbox items are
      automatically moved to
      Deleted Items after 30 days'
   -RetentionEnabled $True

Хотя здесь команда переносится по строкам, в консоли PowerShell она набирается целиком в одну строку. То же самое правило действует и для других представленных здесь команд. Параметры -Name и -Type задают имя тега и контекст соответственно. В столбце «Возможные значения -Type» таблицы 1 перечисляются другие возможные значения для параметра -Type.

Параметр -RetentionAction определяет действие, которое нужно предпринять для элементов, период хранения которых закончился. В этом примере определено действие -MoveToDeletedItems, которое является для MFA командой для перемещения элемента в папку «Корзина». Другие действия, которые можно определить, перечислены ниже.

  • MarkAsPastRetentionLimit. MFA помечает элемент как исчерпавший срок хранения, но не предпринимает никаких действий. Outlook отображает это состояние, зачеркивая данный элемент в списке.
  • DeleteAndAllowRecovery. MFA перемещает элемент в папку «Корзина», однако пользователь может при желании восстановить данный элемент с помощью функции «Восстановить удаленные элементы».
  • PermanentlyDelete. MFA незамедлительно удаляет элемент таким образом, что он уже не будет доступен для восстановления посредством функции «Восстановить удаленные элементы». Однако если почтовый ящик поставлен на сохранение или на юридическое удержание, элемент сохраняется и все еще будет доступен для поиска методом обнаружения.
  • MoveToArchive. MFA перемещает элемент в папку с аналогичным именем в архивный почтовый ящик. Это возможно, только если у почтового ящика есть персональный архив. В противном случае MFA игнорирует действие. Действие MoveToArchive подобно функции «Автоархивация» Outlook, которая перемещает элементы в файл PST согласно расписанию, чтобы не допустить превышения квоты почтового ящика. Однако, в отличие от функции «Автоархивация», действие MoveToArchive не позволяет пользователям решать, хотят ли они использовать ту возможность. MFA автоматически перемещает элементы в персональный архив, не задавая лишних вопросов. Политики, которые служат для перемещения элементов в архивный почтовый ящик, известны как политики архивации.

Параметр -AgeLimitForRetention определяет период хранения. Exchange использует дату и время создания элемента (даже изменяемого элемента, такого как сообщение) в качестве точки отсчета для вычисления возраста этого элемента. В случае с RPT Manager-Inbox период в 30 дней означает, что элементы будут перемещены в папку «Корзина» через 30 дней после того, как будут доставлены в папку «Входящие».

Можно создать тег, который даст MFA команду никогда не обрабатывать элемент. При этом значение параметра -AgeLimitForRetention не задается, а параметру -RetentionEnabled присваивается значение $False. Если же значение параметра -AgeLimitForRetention задается, то параметру -RetentionEnabled всегда присваивается значение $True.

Во время обработки почтового ящика MFA игнорирует элементы, которые старше, чем период хранения. Например, если период хранения для папки «Входящие» составляет 30 дней, то MFA пометит все элементы с возрастом до 30 дней, выполнит действия для элементов с возрастом 30 дней и проигнорирует все более старые элементы. Этот странный на первый взгляд подход на самом деле весьма логичен, поскольку период хранения не может быть отрицательным. В свою очередь это может привести к некоторому беспорядку в пользовательских почтовых ящиках, поскольку самые новые элементы в папках (младше периода хранения) будут помечены, а все более старые — проигнорированы. Таким образом, при реализации политики хранения отсчет ведется от вполне конкретной точки, а не от «начала времен».

После создания тега можно проверить его свойства при помощи команды Get-RetentionPolicyTag. Например, чтобы проверить тег Manager-Inbox, нужно запустить команду:

Get-RetentionPolicyTag
   -id ‘Manager-Inbox’

В отличие от управляемых папок, теги хранения не включают понятие разделения элементов. Другими словами, нельзя создать тег хранения, который применяется только к элементам определенного класса в папке (например, политика применяется только к элементам класса IPM. Note, но игнорирует элементы класса IPM.Contact). Точно так же нельзя определить различные действия для разных классов элементов, например перемещение просроченных сообщений в архивную папку и одновременное удаление элементов другого типа. Некоторые полагают, что эти недостатки — шаг назад для MRM.

С помощью команды New-Reten­tionPolicyTag можно создать остальные пять тегов, перечисленные в таблице 2. Не потребуется делать ничего отличного от описанного выше для создания личного тега (например, тега Manager-Retain) или DPT (например, тега Manager-General).

Дабы убедиться, что в наличии есть все теги, необходимые для создания политики хранения, нужно выполнить следующую команду:

Get-RetentionPolicyTag |
   Format-Table Name, Type,
   RetentionAction, RetentionEnabled,
   AgeLimitForRetention -AutoSize

Создание политики хранения

Теперь, когда созданы шесть тегов, призванные помочь менеджерам навести порядок в их почтовых ящиках, можно создать новую политику хранения, используя команду New-RetentionPolicy. При создании политики с ней связываются ее теги при помощи параметров -RetentionPolicyTagLinks, как показано в следующей команде:

New-RetentionPolicy
-Name 'Management retention policy'
-RetentionPolicyTagLinks
'Manager-Inbox', 'Manager-SentItems',
'Manager-Deleted', 'Manager-JunkMail'
'Manager-General', 'Manager-Retain'

Можно воспользоваться командой Get-RetentionPolicy чтобы посмотреть детали новой политики хранения. Для нашего примера запустим следующую команду:

Get-RetentionPolicy
   -id 'Management retention policy'

Политика с шестью тегами — довольно простая политика хранения. Компания Microsoft рекомендует включать в политику не более 10 тегов, чтобы не сбивать с толку пользователей и системных администраторов, и это весьма неплохой совет. Время от времени вам, возможно, понадобится включить в политику больше тегов, чтобы удовлетворить специфические потребности бизнеса. У более сложной политики для какого-либо подразделения могут быть отдельные RPT для всех папок по умолчанию, ряд личных тегов, разработанных особым образом, чтобы удовлетворить специфические потребности в хранении, и DPT для всего остального.

Применение политики хранения

Для применения политики хранения к почтовым ящикам используется команда Set-Mailbox. Почтовый ящик может иметь только одну политику хранения, поэтому, назначая ему новую политику, мы тем самым перезаписываем любую другую действующую в его отношении политику. Новая политика будет применена к почтовому ящику во время следующего запуска MFA.

Команда для применения политики хранения может выглядеть следующим образом:

Set-Mailbox -id 'JSmith'
   -RetentionPolicy
   'Management retention policy'

Exchange предупредит вас, что клиенты старше Outlook 2007 не поддерживают политики хранения. Ни один клиент до Outlook 2010 и OWA 2010 не имеет пользовательского интерфейса, необходимого для отображения информации о политике хранения и изменения тегов хранения на элементах или папках.

Если политика устанавливается для группы пользователей, то сделать это можно одной командой, выбрав почтовые ящики с помощью команды Get-Mailbox и передав результаты командой Set-Mailbox, как показано ниже:

Get-Mailbox -Filter
   {CustomAttribute7-eq 'Management'} |
Set-Mailbox -RetentionPolicy
   'Management retention policy'

Делать это будет намного легче в Exchange 2010 с пакетом обновления SP1, когда станет доступен графический интерфейс. Появится возможность выбрать группу почтовых ящиков и применить к ним политику хранения, используя консоль управления Exchange (EMC). С помощью EMC также можно будет применить политику хранения к отдельному почтовому ящику.

Чтобы обнаружить почтовые ящики, к которым применены политики хранения, можно использовать следующую команду:

Get-Mailbox -Filter
   {RetentionPolicy -ne $Null} |
   Format-Table Name, RetentionPolicy
   -AutoSize

После начала развертывания политик хранения необходимо продумать, как интегрировать назначение политик хранения почтовым ящикам с общим процессом настройки учетных записей пользователей компании. У Exchange нет политики хранения по умолчанию, которая может быть присвоена автоматически, поэтому администратору придется самостоятельно выполнить определенное действие, чтобы присвоить политику хранения почтовому ящику. Как было показано выше, эту задачу несложно выполнить при помощи PowerShell, однако она должна решаться в рамках единого плана развертывания.

Переход от управляемых папок

Управляемую папку можно модернизировать до тега хранения, используя ее как шаблон для нового тега. Это можно сделать при помощи параметра -ManagedFolderToUpgrade команды New-RetentionPolicyTag. Предполо­жим, что у нас есть управляемая папка с именем «Никогда не удалять», которая служит хранилищем для элементов, которые пользователи никогда не захотят удалить из почтового ящика, поскольку они очень важны. Можно обсудить с ними вариант хранения подобных элементов в архивном почтовом ящике. Однако в Exchange 2007 еще не было архивных почтовых ящиков, а пользователям порой требуется значительное время, чтобы изменить свою точку зрения. Лучше всего будет создать новый тег хранения, основанный на управляемой папке «Никогда не удалять», посредством использования команды:

New-RetentionPolicyTag
   -Name 'Mark item to never expire'
   -ManagedFolderToUpgrade 'Never Delete'
   -Comment 'Tag created from old Never
Delete managed folder'

Как можно видеть, когда используется параметр ManagedFolderTo

Upgrade, нет необходимости указывать параметры -Type, -Reten­tionAction, -AgeLimitForRetention, и -RetentionEnabled. Эта информация будет автоматически получена от указанной управляемой папки.

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

Будьте готовы к большему

Тема политик хранения Exchange 2010 слишком обширна, чтобы раскрыть ее за один раз. О том, как изменять и удалять политики хранения, а также как помочь пользователям понять их, я расскажу в следующих статьях.

Тони Редмонд (exchguru@windowsitpro.com) — редактор журнала Windows IT Pro, старший технический редактор Exchange & Outlook Administrator, вице-президент и главный технолог HP Services