Exchange Mailbox Manager. Часть 1

Возьмите под контроль "безразмерные" почтовые ящики

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

Утилита Mailbox Manager, впервые предложенная корпорацией Microsoft в составе Exchange Server 5.5 Service Pack 3 (SP3), дает возможность удалять и перемещать объекты, хранящиеся в почтовых ящиках пользователей, и тем самым очищать эти ящики. Позднее специалисты компании переписали исходный код Messaging API (MAPI) - теперь в нем используются объектная модель доступа к данным ADO и технология OLE DB - и интегрировали графический пользовательский интерфейс Mailbox Manager в диспетчер Exchange System Manager (ESM). Кроме того, они осуществили реинжиниринг кода утилиты так, чтобы она выполнялась в качестве потока внутри Exchange System Attendant. Компания Microsoft включила обновленную версию Mailbox Manager в пакет Exchange 2000 Server SP1, а затем постепенно совершенствовала ее в последующих пакетах обновлений и в системе Exchange Server 2003. По своим возможностям и набору функций такой используемый без предварительной настройки инструмент, как Mailbox Manager, уступает продуктам независимых поставщиков, но на первых порах его можно с успехом применять для управления размещенными на сервере Exchange пользовательскими почтовыми ящиками. Для начала рассмотрим, как создаются политики получателей (recipient policy), позволяющие управлять работой утилиты Mailbox Manager в почтовой организации.

Mailbox Manager и политики получателей

Политики получателей используются утилитой Mailbox Manager для работы с почтовыми ящиками. В системах Exchange политики получателей хранятся в виде объектов в контейнере Recipient Policies (элемент Recipients) вместе с другими имеющими отношение к почтовым ящикам административными параметрами, такими, как те, что управляют работой службы пользовательских обновлений Recipient Update Service (RUS). Как и другие используемые системой Exchange параметры конфигурации, эти политики хранятся в контексте именования конфигурации службы Active Directory (AD). В политиках получателей реализованы базовые фильтры LDAP, с помощью которых они устанавливают круг объектов AD, обрабатываемых этими политиками, однако администратор может создавать сложные фильтры, ориентированные на конкретные группы. Возможно, потребуется, чтобы Mailbox Manager обрабатывал содержимое всех почтовых ящиков сервера или всех почтовых ящиков, относящихся к определенному отделу либо региональному офису.

Политики получателей обычно используются в организациях Exchange для того чтобы следить за созданием proxy-адресов объектов, оснащенных средствами обработки электронной почты. Эти политики можно модифицировать таким образом, чтобы они управляли и работой Mailbox Manager, однако я (по целому ряду причин) рекомендую читателям использовать для этих целей другие политики. Приведу такой пример: если вы начнете использовать одну и ту же политику получателя как для контроля за созданием proxy-адресов, так и для управления утилитой Mailbox Manager, в ходе обновления настроек Mailbox Manager это может обернуться непреднамеренным изменением адресов электронной почты и в результате может возникнуть ситуация, в которой системе Exchange придется обновлять каждый почтовый адрес организации. То есть начнется полная репликация, и на каналы связи AD обрушится целая лавина данных.

Экран 1. Просмотр политик получателей в окне ESM

На Экране 1 показан набор политик получателей, отображаемый в окне ESM. Каждая политика обозначается в соответствии с соглашением об именовании, т.е. с четким указанием на ее цель. В данном случае организация Exchange невелика по масштабам, поэтому политики делятся на две категории. Политики первой категории обрабатывают учетные записи пользователей, входящих в корпоративные группы, а политики второй категории - учетные записи пользователей из других департаментов. ESM отображает политики получателей в порядке распределения приоритетов. Чтобы переместить политику на другую позицию в этом списке, нужно правой клавишей мыши щелкнуть на элементе All Tasks и выбирать элемент Move Up (или Move Down) до тех пор, пока данная политика не займет в списке требуемую позицию. Более подробные сведения о том, как политики получателей контролируют proxy-адреса электронной почты, содержатся в статье "Служба Exchange Recipient Update Service", опубликованной в шестом номере Windows IT Pro/RE за 2005 год.

Для того чтобы создавать или редактировать политики получателей, необходимо иметь полномочия администратора на уровне организации. В процессе создания новой политики диспетчер ESM обеспечивает возможность включения страниц свойств для объектов E-Mail Addresses и Mailbox Manager Settings. Более старые политики, созданные в среде Exchange 2000, позволяют отображать лишь базовые страницы свойств, используемые для сбора административных данных (Details), для назначения имен политик и целевых объектов (General) и для управления процессом создания адресов электронной почты (E-Mail Addresses). В этом случае можно добавлять страницы свойств, щелкнув на соответствующей политике правой клавишей мыши и выбрав в контекстно-зависимом меню пункт Change Property Page. Система Exchange хранит подробные сведения обо всех страницах свойств, которые активизируются для каждой политики в атрибуте msExchPolicyOptionList соответствующей политики. Этот атрибут представляет собой 8-байтовую строку; исходные данные можно просматривать с помощью утилиты ADSI Edit. Большинству администраторов Exchange уже приходилось сталкиваться с этими данными; когда мы видим строку, которая начинается с символов 0xfc, это означает, что данная политика имеет страницу свойств почтовых proxy-адресов, а строка, начинающаяся с символов 0xec, указывает на то, что политика имеет страницу свойств Mailbox Manager, как показано на Экране 2.

Экран 2. Просмотр страниц свойств политики с помощью утилиты ADSI Edit

Экран 3. Просмотр почтовых адресов и LDAP-запроса политики получателя

На Экране 3 мы видим, как следует указывать в политиках получателей почтовые адреса (левое окно), а также идентифицировать целевые объекты с помощью LDAP-запросов (правое окно). В правом окне показан LDAP-запрос, который система Exchange использует для идентификации объектов AD в ходе применения соответствующей политики. В данном случае LDAP-запрос идентифицирует все почтовые ящики, принадлежащие тем пользователям, которые работают в указанном департаменте (department = Corporate). Синтаксис LDAP-запроса достаточно сложен, но его необязательно формировать вручную. Можно просто щелкнуть мышью на элементе Modify; после этого на экране откроется диалоговое окно с параметрами поиска. Чтобы убедиться в том, что в ходе поиска будут найдены нужные объекты, можете протестировать запрос, нажав на кнопку Find Now, как показано на Экране 4. Убедившись, что все работает корректно, вы можете сохранить LDAP-запрос (для этого нужно нажать на кнопку OK) и вернуться к модифицируемой политике получателя.

Экран 4. Формирование запроса на поиск

Exchange сохраняет LDAP-запрос в атрибуте Search объекта соответствующей политики, который размещается в каталоге AD. Если пользовательский интерфейс запроса, представленный на Экране 4, не позволяет идентифицировать требуемые объекты, можно с помощью утилиты ADSI Edit создать собственный запрос LDAP и модифицировать соответствующий объект политики. Но здесь необходимо проявлять осторожность; дело в том, что синтаксис LDAP-запросов совсем не прост, и вы можете получить запрос, который либо вовсе не работает, либо работает неэффективно. В лучших LDAP-запросах в качестве условий поиска используются формулы точных совпадений с атрибутами, такие, как формула Is (exactly), указанная против атрибута Department на Экране 4. Нужно иметь в виду, что данный запрос обнаружит объекты, у которых атрибут Department имеет значение Corporate (прописная C) и corporate (строчная c). В своих запросах (сказанное относится к любому запросу AD) не используйте трафаретные символы и не начинайте их с выражений; эффективность таких запросов невысока.

Экран 5. Формирование политики Mailbox Manager

Формирование политики управления почтовым ящиком

После создания LDAP-запроса можно приступать к формированию политики, которую вы намерены реализовать. Как показано на Экране 5, политика управления почтовым ящиком состоит из следующих четырех компонентов:

• Действие, которое Mailbox Manager выполняет при обработке почтового ящика. Первый вариант: вы можете сгенерировать отчет и направить его владельцу почтового ящика и далее не предпринимать каких-либо действий по удалению объектов почтового ящика. Второй вариант: перемещать объекты, отвечающие определенным критериям, в папку Deleted Items, где эти объекты будут либо сохранены, либо удалены оттуда при следующем выходе пользователя из почтового ящика (конкретные действия программы зависят от настроек клиента). Третий вариант: вы можете переместить объекты, соответствующие заданным критериями удаления, в одну из папок, размещенных в корневой папке System Cleanup (позднее пользователи могут просмотреть эти объекты и - если какие-то из объектов представляют для них интерес - переместить эти объекты в свои папки). Наконец, четвертый вариант: можете сразу удалить объекты, соответствующие критериями удаления. При этом удаленные объекты будут оставаться в кэше Deleted Items, и пользователи будут иметь возможность восстанавливать их.
• Критерии удаления (purge criteria), которыми Mailbox Manager руководствуется в процессе проверки объектов каждой папки. Администратор может назначать критерии удаления для набора стандартных папок, которые появляются в почтовом ящике каждого пользователя (таких, как Inbox, Tasks, Calendar), а также добавлять дополнительные папки. При обработке всех остальных папок Mailbox Manager применяет "всеохватывающую" настройку и не обрабатывает подпапки, если пользователь не выбирает настройку All Other Mail Folders.
• Извещение, которое Mailbox Manager направляет каждому владельцу почтового ящика по завершении обработки содержимого данного почтового ящика.
• Параметр, который Mailbox Manager использует для исключения из процесса обработки определенных сообщений. Настройку Exclude specific message classes следует выбирать лишь в тех случаях, когда используются специализированные формы сообщений для таких приложений, как отчеты о расходах или о затраченном времени. Список действительных классов сообщений представлен в Таблице 1; для исключения классов из процесса обработки средствами Mailbox Manager вместо имен Outlook Type используйте имена IPM Type.

В Таблице 2 перечисляются атрибуты политики Mailbox Manager, которые Exchange модифицирует в каталоге AD после того как администратор создает или модифицирует политику. После введения политики в действие служба RUS ассоциирует данную политику с почтовыми ящиками пользователей, которые фильтр LDAP выделил в процессе отбора. Однако будьте осторожны: система Exchange может применять к одному ящику лишь одну политику Mailbox Manager, но если вы создадите несколько политик с помощью фильтров LDAP, которые могут находить одни и те же почтовые ящики, может случиться так, что служба RUS применит к ящику не предназначенную для него политику. Когда вы создаете политики описанным образом, RUS применяет политику с самым высоким приоритетом, а это, возможно совсем не та политика, которую хотели бы применить вы. В системе Exchange 2003 SP1 имеется ошибка, вследствие которой служба RUS может применить к одному почтовому ящику две политики Mailbox Manager. Эта ошибка описана в подготовленной специалистами Microsoft статье, размещенной по адресу http://support.microsoft.com/?kbid=883351; там же можно загрузить и модуль коррекции.

Чтобы понять, применила ли служба RUS новую политику к интересующему вас почтовому ящику, можете воспользоваться утилитой ADSI Edit. В окне этой программы проверьте атрибут msExchPoliciesIncluded учетной записи AD, которой принадлежит почтовый ящик. Данный атрибут содержит указатели на все политики получателей, которые применены к этой учетной записи. Если политика Mailbox Manager применена к почтовому ящику, она будет отображена в списке ADSI Edit рядом с глобальным уникальным идентификатором (globally unique identifier, GUID) объекта данной политики, и за ней будет следовать общий идентификатор GUID, определяющий все политики Mailbox Manager. В моей учетной записи отображены три политики, показанные на Экране 6. Верхнюю запись можно идентифицировать как политику Mailbox Manager, поскольку определяющий ее идентификатор GUID начинается с символов {3B6813EC. Две другие записи представляют собой политики proxy-адресов; их идентификаторы GUID начинаются с символов {26491CFC. Служба RUS наделила мою учетную запись двумя политиками: одна из них явным образом выбрала мою учетную запись в ходе выполнения LDAP-запроса, а вторая относится к категории стандартных "всеохватных" политик, которые имеют все организации Exchange.

Экран 6. Просмотр политик учетной записи AD с помощью утилиты ADSI Edit

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

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

Таблица 1: типы IPM

Таблица 2: Атрибуты политик Mailbox Manager