Exchange Recipient Update Service – это важный компонент для правильной работы структуры Exchange. Обычно она работает без проблем в фоновом режиме, но когда проблемы появляются, то страдают почтовые потоки, поэтому важно быстро устранить их!
Recipient Update Service (RUS) – это компонент Exchange, который отвечает за генерацию почтовых прокси адресов для всех подключенных к почте объектов в структуре Exchange. Обычно этот компонент работает в фоновом режиме и не требует особой настройки и поддержки. Но наступает время, когда появляются проблемы, и решение их должно быть первоочередной задачей, для сохранения почтового потока. Давайте познакомимся поближе с RUS, перед тем, как устранять возникающие с ним проблемы.
Когда вы выполняете начальную установку Exchange, устанавливается Recipient Update Service, а также создается политика для получателя (default recipient policy). Эта политика отвечает за то, что все почтовые объекты, подключенные к структуре Exchange, имеют правильные SMTP адреса, соответствующие формату username@domain.com. Вы можете создать новую политику, которую можно настроить для создания SMTP адресов, соответствующих другому шаблону наименования, например, Firstname.Lastname@domain.com. У Microsoft есть список рекомендаций для создания и/или редактирования политик для получателя:
Недопонимание RUS – это причина большинства проблем. Часто администраторы назначают политику, не понимая, что при этом измениться. Exchange не особо предупреждает о влиянии сделанных изменений. К тому же, организации, которые используют приложения сторонних организаций для создания и применения SMTP адресов, к примеру с помощью MIIS, могут еще сильнее навредить в результате слепого применения политик получателя.
Как упоминалось ранее Recipient Update Service тихо работает в фоновом режиме и не требует особой поддержки. При появлении проблем, необходимо выполнить три основных шага:
Для начала отладки RUS мы сперва определим, имеются ли у нас более чем одна политика получателя, и если имеется, то установить для всех из них, кроме одной, параметр Never Run (попросту отключите все, кроме одной полики). В случае, если у вас несколько политик, вам может потребоваться вернуться назад и включить другие политики, если вы не обнаружили ничего странного в работе первой. Также убедитесь, что в один момент времени работает одна политика.
После настройки расписания, следующим шагом будет подключение журнала диагностики, и установки максимального количества событий со следующими службами и объектами.
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.
Рисунок 1: Журнал диагностики
После подключения Журнала диагностики (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 сервере.
Если в прикладном журнале появились события с 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).
Рисунок 2: USNChanged
Основываясь на этой информации, мы может определить следующее:
Вы можете определить, была ли операция восстановления, уменьшив журнал диагностики (Diagnostics Logging) для всех объектов за исключением объекта Address List Synchronization, а затем отфильтровать событие с 8329, которое указывает на начало операции по восстановлению. На интервалах 10% будет записано событие с ID 8332, а после окончания операции восстановления, будет записано событие с ID 8330. Если вы видите 8329 и 8332, но не видите 8330, то операция по восстановлению по-прежнему выполняется, и вы должны дождаться ее завершения.
Для этого вы должны найти событие с 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.
Recipient Update Service – основной компонент Exchange и гарантия того, что он запущен и работает является гарантией правильной работы всего окружения Exchange. Надеюсь, что эта статья поможет вам в определении и устранении проблем.
Recipient Update Service открыт по http://www.msexchange.org/tutorials/MF017.html
Источник http://www.msexchange.org