Налагодження Exchange Recipient Update Service (RUS)

Exchange Recipient Update Service – важливий компонент для правильної роботи структури Exchange. Зазвичай вона працює без проблем у фоновому режимі, але коли проблеми з'являються, то страждають поштові потоки, тому важливо швидко усунути їх!

Вступ

Опис RUS

  • Створіть нову політику для одержувача та призначте їй більш високий пріоритет, ніж редагування політики, створеної за умовчанням.
  • Намагайтеся звести кількість політик для одержувача до мінімуму
  • Відновлюйте RUS з особливою увагою

Усунення основних проблем з RUS

Як згадувалося раніше, Recipient Update Service тихо працює у фоновому режимі і не вимагає особливої ​​підтримки. З появою проблем, необхідно виконати три основні кроки:

  • Увімкнути журнал діагностики (Diagnostic Logging)
  • Вибрати об'єкт чи об'єкти для моніторингу
  • Переглянути прикладний журнал (Application Log) на наявність помилок

Для початку налагодження RUS ми спершу визначимо, чи є у нас більш ніж одна політика одержувача, і якщо є, то встановити для всіх з них, крім однієї, параметр Never Run (просто відключіть все, крім однієї поліки). У випадку, якщо у вас кілька політик, вам може знадобитися повернутися назад і включити інші політики, якщо ви не виявили нічого дивного в роботі першої. Також переконайтеся, що одночасно працює одна політика.

Журнал діагностики (Diagnostic Logging)

Після налаштування розкладу, наступним кроком буде підключення журналу діагностики та встановлення максимальної кількості подій з наступними службами та об'єктами.

Щоб зробити це, відкрийте 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.

exchange

Малюнок 1 : Журнал діагностики

Перевірка роботи 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 Дизайн: Base DC

Після завершення пошуку, відкрийте першу подію у списку, який містить інформацію про останній пошук у RUS.

Перейдіть з рядка(USNChanged>=########)(uSNChanged