Saturday, April 21st, 2018

Устранение неисправностей в применяемых политиках управления почтовыми ящиками

Published on Январь 16, 2009 by   ·   Комментариев нет

Введение

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

Рассмотрим пример, в котором в организации Exchange созданы две политики. Здесь мы будем использовать простые примеры для объяснения процесса устранения неисправностей. Представим, что существует политика по умолчанию, которая очищает папку Inbox (Входящие) от сообщений, объемом большим 50КБ. Данная политика применяется ко всем пользователям. Теперь предположим, что существует другая политика, очищающая папку Inbox (Входящие) от сообщений, которые больше, чем 100КБ. Мы хотим применить последнюю политику к членам группы Managers, имеющих больший лимит размера почтового ящика. Ниже в статье мы расскажем, как данная политика будет применяться к группе Managers, поскольку именно здесь и кроется причина того, почему политики не применяются правильно. На Рисунке 1 показано, как выглядит политика Mailbox Manager – Inbox >100KB. Политика по умолчанию имеет такие же настройки, за исключением того, что значение Size (Размер) равно 50, а не 100 КБ.

Рисунки политика

Рисунок 1: Политика для удаления сообщений, больших 100 КБ

Возможно, вы помните, что политики получателей применяются в порядке приоритета, где наивысшим является приоритет 1. Политика по умолчанию имеет значение приоритета Lowest (Наименьший), что означает, что данная политика оценивается самой последней. После прохождения проверок приоритета ничего не происходит: применяется только одна политика. Например, если политика Mailbox Manager – Inbox >100KB обладает приоритетом 1, а политика Mailbox Manager – Inbox >50KB – приоритетом 2, к любому пользователю, подходящему под требования правил фильтрации, применяется политика Mailbox Manager – Inbox >100KB, а потому сообщения с объемом большим 50, но меньшим 100 КБ удаляться не будут. Другими словами, политика Mailbox Manager – Inbox >50KB применяться к пользователям не будет. На Рисунке 2 показано, как данные политики выглядят в консоли Exchange System Manager.

Применяется несуществующая политика

Рисунок 2: Список политик получателей

Обратите внимание (Рисунок 1), что политика настроена так, что сообщения, к которым она применяется, переносятся в папку Deleted Items (Удаленные), пользователю отсылается соответствующее письмо. Осталось только настроить планировщик данного процесса и после окончания процесса отправить отчет администратору. Эти параметры настраиваются на вкладке Mailbox Management (Управление почтовыми ящиками) свойств объекта сервера в консоли Exchange System Manager (Рисунок 3).

Применяется несуществующая политика

Рисунок 3: Расписание

Пусть в данной организации есть два пользователя, назовем их User1 и User2. User1 – это обычный пользователь, и потому мы ожидаем, что из его папки Inbox (Входящие) будут удаляться сообщения, объемом больше 50КБ. User2 – член группы Managers, поэтому удаляться будут сообщения свыше 100 КБ. У пользователя User2 в настоящий момент есть три непрочитанных письма, а именно, одно сообщение с приложенным файлом журнала, размером 2МБ, другое – в zip-архивом, размером 95 КБ, и маленькое сообщение без вложений, размером 1 КБ. Что произойдет при запуске нашего процесса? Пользователь User2, член группы Managers, зарегистрировавшись в Outlook Web Access, увидит следующую картину (Рисунок 4).

Не применяется политика

Рисунок 4: Неправильная обработка

Как вы видите, сообщение службы System Attendant сообщает, что сообщения, объемом, превышающим 50 КБ, были перенесены в папку Deleted Items (Удаленные). Почему? Пользователь User2 – член группы Managers, поэтому перенесены должны быть только сообщения свыше 100КБ. Очевидно, была применена неверная политика. Ниже я детально рассмотрю метод проверки того, какая политика была задействована. Конечно, в моем примере все просто, однако принципы остаются прежними. В моем методе используется средство LDP.EXE, которое можно найти среди средств Windows 2003 Support Tools, с диска Windows 2003, папка \Support\Tools.

Вот как используется LDP для проверки того, какая политика применяется к почтовому ящику.

  1. Запустите LDP.EXE.
  2. В меню Connection (Соединение) выберите Connect (Соединиться).
  3. В появившемся окне введите имя контроллера домена для связи с ним. Все остальные поля оставьте по умолчанию. Нажмите OK.
  4. В главном окне LDP вы увидите, что соединение с контроллером домена было выполнено: в правой части появится соответствующая информация. Снова выберите меню Connection (Соединение), но теперь выберите опцию Bind (Привязать).
  5. В появившемся окне введите учетные данные, необходимые для привязки к контроллеру домена и нажмите OK.
  6. В главном окне LDP в правой части вы увидите, что аутентификация прошла успешно (Рисунок 5).

    Не применяется политика

    Рисунок 5: LDP после успешного соединения и привязки

  7. В меню View (Просмотр) выберите Tree (Дерево). В появившемся окне очистите поле BaseDN и нажмите OK.
  8. В левой части главного окна LDP вы увидите иерархию Active Directory. Раскройте имя домена, нажав на символ «+». Далее раскройте следующие объекты до достижения узла Recipient Policies (Политики получателей): Configuration (Настройки), Services (Службы), Microsoft Exchange, имя вашей организации Exchange, Recipient Policies (Политики получателей) (Рисунок 6).

    Msexchpoliciesincluded

    Рисунок 6: Политики получателей в LDP

  9. Из Рисунка 6 видно, что под контейнером Recipient Policies (Политики получателей) находятся наши две политики, а именно Default Policy (Политика по умолчанию) и Mailbox Manager – Inbox > 100KB. Теперь советую очистить правую часть окна LDP, поскольку оттуда мы будем брать полезную информацию. Для очистки выберите из меню Connection (Соединение) пункт New (Новое).
  10. Теперь по очереди рассмотрим обе политики. Начнем с политики по умолчанию. Дважды щелкните по ней внутри окна LDP. В результате в правой части появится большое количество информации. Ключевой тут является строка, связанная с параметром objectGUID политики (Рисунок 7).

    Exchange system manager очистка очереди

    Рисунок 7: Параметр objectGUID политики по умолчанию

  11. Вы видите, что параметр objectGUID политики по умолчанию равен 9c948cb6-784f-4521-b019-737064461c2a. Сохраните содержимое окна в текстовый файл через меню Connection (Соединение) -> Save As (Сохранить как). Можно создать текстовый файл со всеми objectGUID всех ваших политик.
  12. Повторите пункт 10 для другой политики. В моем случае, параметр objectGUID будет 307656c9-4a80-41c7-ab33-0ca5da6244e3.
  13. Теперь у нас есть значения двух параметров objectGUID и нам нужно узнать, какая политика применяется для почтового ящика пользователя User2. Для этого проверим атрибуты учетной записи User2. В левой части окна LDP найдите организационную единицу (Organization Unit (OU)), где находится эта запись. В моем случае это ‘Exchange Users’.
  14. Выбрав и раскрыв данную организационную единицу, вы увидите список учетных записей пользователей. Как и прежде, очистите правую часть окна через меню Connection (Соединение) -> New (Новое).
  15. Теперь просто дважды щелкните по соответствующей учетной записи и в правой части вы увидите большое количество информации по ней. Нам интересна строка с атрибутом msExchPoliciesIncluded (Рисунок 8).

    Exchange system manager очистка очереди

    Рисунок 8: Атрибут msExchPoliciesIncluded

  16. Обратите внимание, что параметр objectGUID политики Mailbox Manager – Inbox > 100KB (307656c9-4a80-41c7-ab33-0ca5da6244e3) на Рисунке 8 не показан. Единственный показанный GUID относится к политике по умолчанию, что означает, что именно эта политика применяется к пользователю User2.

Конечно, в данном случае вопрос состоит в том, почему применяется именно политика по умолчанию. Ответ прост: правило фильтрации для политики Mailbox Manager – Inbox > 100KB не настроено на использование имени группы Managers – то, о чем порой забывают. Другими словами, для правильного применения политики вы должны убедиться, что вы не просто ввели имя группы, а добавили полностью определенное имя. Поэтому, в моем примере, в правиле фильтрации атрибут Member Of (Членство в) должен в точности соответствовать следующему имени:

CN=Managers,OU=Exchange Users,DC=ngh,DC=net

На Рисунке 9 показано, как все должно выглядеть.

Не применяются политики exchange 2007

Рисунок 9: Правильные настройки фильтра

После изменений политики будет применяться правильно, что можно проверить через LDP, атрибут msExchPoliciesIncluded пользователя User2. Результат показан на Рисунке 10, где выделен текст с параметром objectGUID правильной политики.

Не применяются политики exchange 2007

Рисунок 10: Правильный атрибут msExchPoliciesIncluded

Резюме

Устранение неисправностей в применении политик может и должно быть проведено с путем проверки применяемого фильтра. Также может помочь использование средства LDP для проверки различных атрибутов применяемых политик, что и объяснено в данной статье.

Источник  http://www.msexchange.org


Смотрите также:

Tags: ,

Readers Comments (Комментариев нет)




Да человек я, человек! =)

Exchange 2007

Проведение мониторинга Exchange 2007 с помощью диспетчера System Center Operations Manager 2007 (часть 3)

Если вы хотите прочитать предыдущие части этой серии статей, перейдите по ссылкам: Проведение мониторинга Exchange 2007 с помощью диспетчера System ... [+]

Практическое рассмотрение перехода с Exchange 2003 на Exchange 2007 (часть 1)

Введение В этой статье из нескольких частей я хочу показать вам процесс, который недавно использовал для перехода с существующей среды Exchange 2003 ... [+]

Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (часть 2)

Если вы пропустили первую часть этой серии, пожалуйста, прочтите ее по ссылке Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (Часть ... [+]

Мониторинг Exchange 2007 с помощью диспетчера System Center Operations Manager 2007 (часть 2)

Если вы пропустили предыдущую часть этой серии статей, перейдите по ссылке Мониторинг Exchange 2007 с помощью диспетчера System Center Operations ... [+]

Подробное рассмотрение подготовки Active Directory для Exchange 2007 (часть 5)

Если вы пропустили предыдущие части этой серии статей, перейдите по ссылкам: Подробное рассмотрение подготовки Active Directory для Exchange 2007 (часть 1) ... [+]

Установка и настройка Exchange 2007 из командной строки (Часть 3)

If you missed the previous parts in this article series please read: Exchange 2007 Install and Configuration from the command line (Part ... [+]

Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (часть 1)

Инструмент ExRCA Текущий выпуск инструмента предоставляется только в целях тестирования и оснащен 5 опциями: Тест подключения Outlook 2007 Autodiscover Тест подключения Outlook 2003 RPC ... [+]

Развертывание сервера Exchange 2007 Edge Transport (часть 5)

Если вы хотите прочитать предыдущие части этой серии статей, перейдите по ссылкам: Развертывание сервера Exchange 2007 Edge Transport (часть 1) Развертывание ... [+]

Установка и настройка Exchange 2007 из командной строки (часть 2)

Если вы пропустили первую статью данного цикла, пожалуйста, перейдите по ссылке: Exchange 2007 Install and Configuration from the command line (Part ... [+]

Использование интегрированных сценариев Using Exchange Server 2007 – часть 2: генерирование отчетов агента Transport AntiSpam Agent

Если вы пропустили предыдущую часть этой серии статей, перейдите по ссылке Использование интегрированных сценариев Using Exchange Server 2007 – часть ... [+]