У фінальній версії Exchange 2010 з'явилася нова функція створення архіву поштової скриньки. Доступна вона в контекстному меню облікового запису поштового ящика оснащення Exchange Management Console в розділі Recipient Configuration.
Після включення архіву у властивостях поштової скриньки стають доступні деякі властивості пов'язані з архівом. Зокрема, можна поміняти його ім'я і виставити при якому розмірі архіву буде надсилатися попередження про переповнення.
Крім цього, при використанні Outlook 2010 і Outlook Web Access в дереві папок користувача з'являється архівна папка. Користувач може вручну переносити свої повідомлення в архів (на жаль, архівна папка не може бути обрана цільової при стандартному створення резервної копії, яке пропонує Outlook).
Втім, ручне архівування справа вкрай обтяжлива і, в зв'язку з цим, виникає питання - яким чином ми можемо налаштувати автоматичне архівування повідомлень в архів поштової скриньки користувача? Відповідь на це питання є. Для автоматичного архівування, в нашому випадку, використовуються політики зберігання, на основі яких і відбувається автоматичне переміщення в архів повідомлень задовольняють вимогам політики.
Політики зберігання, в свою чергу, працюють на підставі тегів зберігання, які може створити і налаштувати адміністратор поштової організації. Теги використовуються для застосування налаштувань зберігання (не політик!) До папок в ящику і об'єктів всередині папок (повідомлення, записки і контакти). Налаштування зберігання задають період часу протягом якого об'єкт може знаходитися в поштовій скриньці. Після закінчення цього періоду ми можемо зробити ряд дій з об'єктом: видалити, перемістити в архів або відзначити для залучення уваги користувача.
Всього існує три типи тегів зберігання: теги політик зберігання (Retention Policy Tag - RPT), теги дефолтной політики (Default Policy Tag) і призначені для користувача теги.
З назви випливає, що перші використовуються разом з політиками зберігання. Можуть застосовуватися тільки до стандартних папок - Inbox, Sent Items, Deleted Items, Junk Email ітд. Крім цього, після застосування до стандартних папок, настройки зберігання успадковуються вкладеними папками. Що важливо - ми не можемо включити в політику зберігання більше одного тега застосованого до папці. Сама політика може включати в себе кілька таких тегів.
Теги дефолтной політики застосовуються до всіх (повідомлення, записки і контакти) об'єктів поштового ящика, що не були помічені RPT або призначеними для користувача тегами. Політика зберігання може містити тільки один DPT.
Призначені для користувача теги використовуються користувачами для того, щоб позначити папки всередині дефолтних, або якісь окремі повідомлення, щоб виключити їх з політики зберігання.
Усі теги крім об'єкта дії так само мають інформацію про те, що з позначеними даними робити. Дані можна відправити в архів (MoveToArchive), відправити в кошик (MoveToDeletedItems), видалити з можливістю відновлення (DeleteAndAllowRecovery), видалити без можливості відновлення (PermanentDelete) і зазначити, що повідомлення перевищило ліміти зберігання (MarkAsPastRetentionLimit).
З цього невеликого відступу стає приблизно ясно, що нам необхідно зробити для настройки автоматичного переміщення старих повідомлень в архів. По-перше, треба створити тег зберігання (RPT або DPT якщо ми хочемо застосувати політику відразу до всього скриньки, а не до окремій папці). Робиться це Командлети New-RetentionPolic yTag. Для створення RPT з областю застосування тільки папка Inbox і терміном зберігання 30 днів використовуємо:
New-RetentionPolicyTag "Stas-RPT" -Type Inbox -RetentionEnabled $ true -AgeLimitForRetention 30 -RetentionAction MoveToArchive
В даному випадку "Stas-PRT" - назва нашого тега, ключ - Type вказує сферу застосування (папка Inbox), -A geLimitForRetention - вказує, старше якого терміну в днях повинні бути повідомлення, щоб бути поміченими тегом, -Retention Action - вказує, що ми повинні робити з об'єктом, який позначений (нас цікавить переміщення в архів, тому вказуємо MoveToArchive). Для створення дефолтного тега в типі досить вказати All, тобто командлет матиме такий вигляд:
New-RetentionPolicyTag "Stas-DPT" -Type All -RetentionEnabled $ true -AgeLimitForRetention 30 -RetentionAction MoveToArchive
Після створення тега ми повинні створити політику зберігання, до якої прив'язати наш тег. Для цього використовується командлет New- RetentionPolicy. Командлет простий, вимагає лише вказівки імені політики і тега або тегів, які до неї прив'язуються. Виглядає це наступним чином:
New-RetentionPolicy "Stas-RP" -RetentionPolicyTagLinks "Stas-RPT"
Якщо необхідно прив'язати кілька тегів до політики, то в ключі - RetentionPolicyTagLinks через кому вказуємо потрібні теги.
Ну і нарешті, необхідно політику прив'язати до конкретного поштової скриньки. Робиться це через командлет Set-Mailbox:
Set-Mailbox Stas -RetentionPolicy "Stas-RP"
Архівування підключено і налаштовано. Досить почекати поки відпрацює Managed Folder Assistant. Особливо нетерплячі можуть запустити командлет
Start-ManagedFolderAsistant
Після завершення процесу конфігурації архівування засобами Exchange 2010 має сенс вказати на кілька величезних мінусів технології, які не дозволять в її поточному стані бути використаною корпоративними замовниками навіть при середніх впроваджень.
По-перше, створення архівів за допомогою поточний момент підтримується тільки клієнтами Outlook 2010. Що автоматично означає необхідність впровадження Office 2010 для роботи з архівом (нагадаю, що вихід фінальної версії планується тільки в травні поточного року).
По-друге, архів міститься в тій же базі, що й поштову скриньку, при цьому в базі виділяється окреме місце під архів, а не позначається як архів частина ящика (тобто якщо у нас є ящик розміром 1Гб, в якому буде заархівувати 500Мб листів , то розмір бази на ці 500Мб збільшиться). Це суперечить ідеї архівування як зберігання застарілих документів на більш дешевих носіях. Фактично, в поточному вигляді, архів цілком може бути замінений банальним збільшенням розміру скриньки. Правда є і хороша новина - розробники обіцяють з виходом першого сервіс пака цю помилку виправити.
По-третє, ми не можемо створювати складні політики архівування на підставі квот для поштових скриньок. Ця функція вкрай затребувана компаніями, які використовують жорсткі ліміти для розмірів поштових скриньок. Для них використання лімітів за часом проблему виходу за розміри квот ніяк не вирішить.
По-четверте, проблему з автоматичним збором інформації з pst-файлів ми вирішити ніяк не зможемо. У поточному вигляді вихід тільки один - збирати pst-файли вручну.
Ці чотири причини, в принципі, можуть бути вирішені, і тоді технологія архівування засобами Exchange може бути вкрай затребувана. Не дарма після появи Exchange 2010 Symantec вважає основним конкурентом свого рішення з архівування Enterprise Vault саме вбудоване архівування Exchange 2010.
PS Стаття ця була написана до оголошення про плани випуску Exchange 2010 SP1. В кінці поточного року планується випуск першого сервіс-пака для Exchange 2010. У ньому будуть доступні чесний зміни в архівування. Зокрема, архів стане доступний клієнтам Outlook 2007, архів можна буде переміщати в інші бази (тобто сам ящик і архів можна зберігати в різних базах), стане доступна утиліта зі збору персональних архівів (файлів pst) в архів поштової скриньки в Exchange 2010. Крім цього, обіцяють сильно поліпшений механізм пошуку по всіх поштових даних користувача (поштова скринька і архів).
Втім, ручне архівування справа вкрай обтяжлива і, в зв'язку з цим, виникає питання - яким чином ми можемо налаштувати автоматичне архівування повідомлень в архів поштової скриньки користувача?