Exchange Recipient Update Service – это важный компонент для правильной работы структуры Exchange. Обычно она работает без проблем в фоновом режиме, но когда проблемы появляются, то страдают почтовые потоки, поэтому важно быстро устранить их!
Вступление
Recipient Update Service (RUS) – это компонент Exchange, который отвечает за генерацию почтовых прокси адресов для всех подключенных к почте объектов в структуре Exchange. Обычно этот компонент работает в фоновом режиме и не требует особой настройки и поддержки. Но наступает время, когда появляются проблемы, и решение их должно быть первоочередной задачей, для сохранения почтового потока. Давайте познакомимся поближе с RUS, перед тем, как устранять возникающие с ним проблемы.
Описание RUS
Когда вы выполняете начальную установку Exchange, устанавливается Recipient Update Service, а также создается политика для получателя (default recipient policy). Эта политика отвечает за то, что все почтовые объекты, подключенные к структуре Exchange, имеют правильные SMTP адреса, соответствующие формату [email protected]. Вы можете создать новую политику, которую можно настроить для создания SMTP адресов, соответствующих другому шаблону наименования, например, [email protected]. У Microsoft есть список рекомендаций для создания и/или редактирования политик для получателя:
- Создайте новую политику для получателя и назначьте ей более высокий приоритет, чем редактированию политики, созданной по умолчанию.
- Постарайтесь свести число политик для получателя к минимуму
- Восстанавливайте RUS с особым вниманием
Недопонимание RUS – это причина большинства проблем. Часто администраторы назначают политику, не понимая, что при этом измениться. Exchange не особо предупреждает о влиянии сделанных изменений. К тому же, организации, которые используют приложения сторонних организаций для создания и применения SMTP адресов, к примеру с помощью MIIS, могут еще сильнее навредить в результате слепого применения политик получателя.
Устранение основных проблем с RUS
Как упоминалось ранее Recipient Update Service тихо работает в фоновом режиме и не требует особой поддержки. При появлении проблем, необходимо выполнить три основных шага:
- Включить журнал диагностики (Diagnostic Logging)
- Выбрать объект или объекты для мониторинга
- Просмотреть прикладной журнал (Application Log) на наличие ошибок
Для начала отладки RUS мы сперва определим, имеются ли у нас более чем одна политика получателя, и если имеется, то установить для всех из них, кроме одной, параметр Never Run (попросту отключите все, кроме одной полики). В случае, если у вас несколько политик, вам может потребоваться вернуться назад и включить другие политики, если вы не обнаружили ничего странного в работе первой. Также убедитесь, что в один момент времени работает одна политика.
Журнал диагностики (Diagnostic Logging)
После настройки расписания, следующим шагом будет подключение журнала диагностики, и установки максимального количества событий со следующими службами и объектами.
MSExchangeAL – операции LDAP
MSExchangeAL - Address List Synchronization (синхронизация списка адресов)
MSExchangeSA - Proxy Generation (генерация прокси)
Для того, чтобы сделать это, откройте Exchange System Manager (ESM) и перейдите к Administrative Groups | Servers | Servername, щелкните правой кнопкой мыши на названии сервера, для которого вы хотите настроить журнал, выберите Properties (свойства), а затем перейдите на закладку Diagnostics Logging. В Services выберите MSExchangeAL и установите LDAP Operations и Address List Synchronization на максимум (смотри рисунок 1). Затем выберите службы MSExchangeSA и установите Proxy Generation на максимум. (Обратите внимание: Proxy Generation не доступен для серверов Exchange 2000). Наконец, создайте тестовый объект для RUS.
Проверка работы RUS
После подключения Журнала диагностики (Diagnostic Logging) подождите несколько минут и вы должны увидеть два события, отраженных в прикладном журнале событий (Application event log) с ID 8011 и 8012. Эти события подтверждают, что RUS запущена. Если у вас не появились эти сообщения, перезапустите службу Microsoft Exchange System Attendant. После того, как эта служба запущена, вы увидите несколько новых событий, первое из которых 9006 и 9008, уведомляющих вас, что Abv_dg.dll загружен и запущен.
Если появится событие с ID 9006, но не появляется событие с ID 9008, то значит, вы выполняете эту задачу на front-end сервере. На front-end сервере Abv_dg.dll не существует, а RUS необходимо запускать на back-end сервере.
Проверка запросов RUS
Если в прикладном журнале появились события с ID 8011 и 8012, то следующим шагом будет определение того, посылает ли RUS запросы на изменение, а для этого вам потребуется ADSIEdit. Откройте ADSIEdit и подключитесь к контролеру домена (Domain Controller), на который указывает RUS. Перейдите к Domain NC | DC=domain,DC=com | CN=Users и щелкните правой кнопкой мыши на тестовом объекте и выберите Properties. Перейдите к значению uSNChanged и запишите его. Затем откройте Event Viewer на сервере Exchange, на котором вы подключили журнализацию, и найдите
Event ID: 8011
Description: Base DC
После завершения поиска, откройте первое событие в списке, который содержит информацию о последнем поиске в RUS.
Перейдите с строке (USNChanged>=########)(uSNChanged) и проверьте, удовлетворяет ли записанное вами значение для тестового объекта этому интервалу (смотрите рисунок 2).
Основываясь на этой информации, мы может определить следующее:
- Если параметр uSNChanged выше, чем интервал, указанный в событии, то значит, RUS еще не запрашивал этот объект. Это бывает в том случае, когда вы выбрали восстановить RUS, что, в зависимости от размера домена может занять от нескольких минут до нескольких дней. Когда вы запускаете Rebuild, RUS начинает со значения uSNChanged равным 1 и запрашивает все объекты в домене.
- Если параметр uSNChanged для тестового объекта попадает в интервал в журнале, то RUS запрашивал этот объект. Открывайте следующие события с ID 8011 до тех пор, пока вы не найдете событие, которое попадает в интервал. Если у вас возникли проблемы с поиском, то вы можете изменить тестовый объект и подождать, пока он снова не будет опрошен.
- Если прикладной журнал (Application log) не содержит события с ID 8011 с описанием "Base 'DC", то значит доменная RUS еще на начала работу, или событие было зетерто более новыми событиями.
Вы можете определить, была ли операция восстановления, уменьшив журнал диагностики (Diagnostics Logging) для всех объектов за исключением объекта Address List Synchronization, а затем отфильтровать событие с 8329, которое указывает на начало операции по восстановлению. На интервалах 10% будет записано событие с ID 8332, а после окончания операции восстановления, будет записано событие с ID 8330. Если вы видите 8329 и 8332, но не видите 8330, то операция по восстановлению по-прежнему выполняется, и вы должны дождаться ее завершения.
Проверка результатов запросов RUS
Для этого вы должны найти событие с ID 8011, которое информирует нас, что поиск был выполнен на интервале USN, который включает USN вашего тестового объекта. Теперь мы можем увидеть, были ли получены какие-либо результаты. События 8012 и 8169 предоставляют нам описания результатов.
Event Type: Information
Event Source: MSExchangeAL
Event Category: LDAP Operations
Event ID: 8012
Date: 3/27/2006
Time: 7:56:52 AM
User: N/A
Computer: EX-01
Description: Search of directory DC-01.tlaconsulting.ca at base 'DC=tlaconsulting,
DC=ca' returned 3 objects.
Event Type: Information
Event Source: MSExchangeAL
Event Category: Address List Synchronization
Event ID: 8169
Date: 3/27/2006
Time: 7:53:01 AM
User: N/A
Computer: EX-01
Description: Retrieved all directory changes under: 'DC=tlaconsulting,DC=ca'.
Существует несколько общих сценариев, которые применимы к событию 8012.
- Если событие 8012 не было сформировано после появления события 8011, то Exchange не получил ответ на поиск. Это обычно показывает проблему сети, в которой сервер Exchange не может общаться с Active Directory.
- Если поиск вернет нулевые объекты (а вы уверены, что они должны быть не нулевыми), то это обычно означает ошибку в правах. В этом случае учетная запись на компьютере с сервером Exchange не имеет достаточно прав, необходимых для просмотра пользовательских объектов. Для того, чтобы просмотреть пользовательские объекты, сервер Exchange должен быть частью группы Exchange Enterprise Servers group.
- Если было найдено более чем 20 объектов, то вы увидите несколько событий 8012. Вы должны увидеть одно событие 8012 для каждого из 20 объектов, которые вернул запрос.
Заключение
Recipient Update Service – основной компонент Exchange и гарантия того, что он запущен и работает является гарантией правильной работы всего окружения Exchange. Надеюсь, что эта статья поможет вам в определении и устранении проблем.
Recipient Update Service открыт по http://www.msexchange.org/tutorials/MF017.html