Служба Exchange Recipient Update Service

Тонкости обновления получателей

Служба обновления получателей Exchange Server Recipient Update Service (RUS) — это важный компонент системы, определяющий общее состояние среды передачи сообщений. В небольших организациях RUS нередко остается на вторых ролях. Но у тех, кто работает с крупными или сложными системами, наверняка возникают проблемы с политиками получателей или со службой RUS, которая по непонятным причинам ведет себя не так, как ожидалось. Так или иначе, разобравшись с тем, как функционируют политики получателей, в каких случаях нужно, чтобы RUS переформировывала списки адресов, и с какими проблемами, скорее всего, придется столкнуться при эксплуатации этой службы, вам будет проще избегать осложнений в работе.

Политики получателей

Служба обновления получателей выполняет плановые проверки Active Directory (AD) на наличие обновлений в списках и затем принимает меры к тому, чтобы найденные объекты могли получать сообщения электронной почты. Когда администратор редактирует свойства объекта, имеющего адрес электронной почты, и выставляет флажок Automatically update e-mail addresses based on recipient policy (на закладке Email Addresses диалогового окна Properties соответствующего объекта), как показано на экране 1, служба RUS определяет, какую политику получателя следует применять к данному объекту, а затем выполняет команды, содержащиеся в этой политике. Некоторые организации, скажем поставщики услуг доступа к приложениям (application service provider, ASP) или Internet-провайдеры, предпочитают не использовать в своих системах службу обновления получателей для создания почтовых адресов. Во многих таких организациях реализуется мультиплатформенный процесс инициализации и синхронизации каталогов, и они могут использовать программы или утилиты от независимых поставщиков. Этот подход вполне приемлем; главное, чтобы избранная программа передавала в каталог AD обновленную информацию, необходимую для того, чтобы система Exchange могла маршрутизировать и доставлять сообщения.

Экран 1. Настройка службы RUS для автоматического обновления адресов электронной почты

При установке в организации первого сервера система Exchange создает принимаемую по умолчанию политику получателя. Поскольку функции базового механизма маршрутизации в системах Exchange выполняет протокол SMTP, данная стандартная политика обеспечивает наличие адреса SMTP у каждого объекта, которому выделен адрес электронной почты, и использует формат mailNickname@domain.com (где вместо domain.com используется часть имени леса AD, в котором размещается данная организация Exchange). Значение атрибута mailNickname для конкретной организации уникально, так что на основании политики можно генерировать уникальные почтовые адреса. Сотрудники небольших организаций могут ничего не менять в предлагаемой по умолчанию политике, однако в большинстве крупных организаций, как правило, используется общепринятый формат адресов SMTP — first_name.last_name@domain. Можно создать новую политику получателя и дать службе обновления получателей команду создавать адреса в этом формате, после чего нужно будет указать, что в первую очередь выполняется новая политика и лишь после этого — стандартная; теперь служба обновления получателей будет первым делом обрабатывать команды новой политики. Отметим, что Microsoft рекомендует не вносить изменения в стандартную политику, а создавать новую (по причинам, которые излагаются в статье Microsoft "How to customize the SMTP e-mail address generators through recipient policies", опубликованной по адресу http://support.microsoft.com/?kbid=285136). Это хороший совет: вы никогда не ошибетесь, проводя четкое разграничение между настройками, характерными для организации, и параметрами, предлагаемыми по умолчанию.

Чтобы создать новую политику получателя, следует открыть диспетчер Exchange System Manager (ESM), правой кнопкой мыши щелкнуть на контейнере Recipient Policies (в разделе Recipients) и в открывшемся контекстном меню выбрать пункт New. Эффективная политика получателя должна включать в себя фильтр на базе облегченного протокола доступа к каталогам LDAP (Lightweight Directory Access Protocol). С его помощью служба обновления получателей будет идентифицировать объекты, на которые воздействует политика, и задавать формат адресов электронной почты, которые RUS будет генерировать для этих объектов.

Теперь создадим фильтр LDAP. Для этого нужно открыть диалоговое окно Properties данной политики, перейти на закладку General и щелкнуть на элементе Modify. После этого можно создать требуемый фильтр. Необходимо выбрать тип объектов, которые он будет обрабатывать, и атрибуты, в соответствии с которыми будет осуществляться сортировка. На экране 2 показан сформированный фильтр LDAP. В этом примере служба обновления получателей будет отыскивать объекты с имеющим то или иное значение атрибутом mailNickname и просматривать все категории объектов; обратите внимание на правила фильтров, которые ссылаются на типы objectClass, такие как user и contact, а также на тип objectCategory msExchDynamicDistributionList (список рассылки на базе запросов). Эта новая политика напоминает стандартную политику, которая тоже выбирает любой объект любого класса, лишь бы у объекта был атрибут mailNickname с заданным значением. Новую политику отличает от стандартной финальное правило фильтра, в котором содержится присваивание department=HQ: новый фильтр применим лишь к тем объектам, у которых атрибут department имеет значение HQ. Надо сказать, что для получения наилучших результатов для фильтров LDAP нужно всегда задавать в качестве критерия поиска полное совпадение с ключевым словом. Если же создать фильтр, в результате применения которого служба обновления получателей будет проверять множество атрибутов на наличие значений, начинающихся с тех или иных символьных строк, производительность сервера снизится.

Экран 2. Фильтр LDAP для политики получателя

Чтобы указать другие форматы почтовых адресов, которые будет создавать служба обновления получателей, следует перейти на закладку E-Mail Addresses (Policy). Как видно на экране 3, на этой закладке перечисляются различные форматы, применимые внутри организации. В данном примере я решил не создавать адресов других форматов для CCMAIL (т. е. Lotus cc: Mail), MS (т. е. Microsoft Mail) и для NOTES (т. е. для Lotus Notes), поскольку пользователи, на действия которых влияет данная политика, не пользуются этими почтовыми системами. Два оставшихся формата — SMTP и X400 (т. е. X.400) — играют важную роль в организациях Exchange. SMTP ныне является стандартным протоколом передачи сообщений для Exchange, а X.400 по-прежнему остается глубоко интегрированным в этот продукт. Как показано на экране, формат SMTP будет создавать адреса вида first_name.last_name@domain. Если объект имеет действительный адрес другого формата, можно в любой момент посылать этому объекту электронные почтовые сообщения по упомянутому адресу. Так, если известно, что новый объект «пользователь» имеет SMTP-адрес user@abc1.net, можно отправлять электронные сообщения по этому адресу и система Exchange обеспечит для них корректную маршрутизацию, даже если этот объект не представлен в глобальном списке адресов (поскольку еще не завершено тиражирование данных AD или пока не установлена автономная адресная книга OAB — Offline Address Book). Это полезная возможность, поскольку, если объект не относится к категории скрытых, он должен присутствовать по крайней мере в одном списке адресов, иначе клиенты Messaging API (MAPI), такие как Outlook, не смогут его обнаружить. Более того, существует возможность отправки сообщений получателям, не представленным в глобальном списке адресов (Global Address List, GAL); достаточно, чтобы эти получатели имели действительные адреса SMTP. Именно таким образом многие администраторы отправляют сообщения получателям, когда знают, что их адреса скрыты. Тем, кто работает в крупной организации, вероятно, придется применять множество политик получателей. Но лучше обходиться как можно меньшим их числом: чем проще система, тем меньше вероятность ошибки. Каждая политика получателя имеет в контейнере Recipient Policies определенный приоритет исполнения. Служба обновления получателей обрабатывает политики в порядке от высшего приоритета к низшему. Чтобы изменить порядок политик, следует правой кнопкой мыши щелкнуть на политике в окне ESM, выбрать элемент All Tasks, а затем — элемент Move Up или Move Down. Предлагаемая по умолчанию политика всегда должна иметь самый низкий приоритет. Ее назначение — выступать в качестве последней линии перехвата и извещать службу обновления получателей о том, каким образом обрабатывать объекты, не охваченные другими политиками.

Экран 3. Выбор почтовых форматов

Когда служба обновления получателей активизирована, она выявляет обновления в каталоге AD (для этого она сравнивает значения USNchanged объектов AD и находит объекты, изменившиеся со времени последней проверки); не изменявшиеся объекты служба игнорирует. Поэтому, создавая новую политику или модифицируя существующую, вы, возможно, исходите из того, что служба обновления получателей достаточно «интеллектуальна», чтобы автоматически перепроверить правильность почтовых адресов во всей организации и обеспечить соответствие всех адресов новой политике. Имейте в виду — это ошибочное представление! Чтобы немедленно активизировать новую или модифицированную политику, следует правой кнопкой мыши щелкнуть на ней в окне ESM и в открывшемся контекстном меню выбрать пункт Apply this policy now. Когда вы будете создавать новую политику или модифицировать существующую, ESM напомнит о том, что нужно выполнить эту операцию (см. экран 4). При этом придется применять не только новую или модифицируемую политику, но и все другие политики, которые могут претерпеть изменения вследствие внесенных модификаций. Поскольку политики получателей хранятся в контейнере на уровне организации, для их применения требуются полномочия Exchange Administrator во всей организации.

Повторное составление списка адресов

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

Когда вы поручаете службе обновления получателей вновь создать списки адресов для домена, она устанавливает значение атрибута USNchanged равным 1; это действие в свою очередь приводит к тому, что служба RUS приступает к обработке всех связанных с электронной почтой объектов домена. Обычно обработка начинается по истечении планового интервала, но если вслед за командой Rebuild ввести команду Update Now, выполнение этой операции начнется немедленно. Логично предположить, что в доменах, содержащих десятки тысяч объектов с адресами электронной почты, на выполнение необходимых LDAP-запросов и других операций уходит довольно много времени. В некоторых системах процедура повторного формирования списков адресов может занять более одного дня — даже в тех случаях, когда задействованные в этой операции сервер Exchange и контроллер домена связаны быстрым соединением. Кроме того, операции повторного формирования списков адресов создают большую нагрузку на соответствующие серверы и на всю сеть, которой приходится передавать LDAP-запрос и репликационный трафик AD, генерируемый в процессе повторного формирования списков. Словом, я не рекомендую выполнять операцию повторного формирования списков адресов, если, конечно, вы не уверены в том, что это единственный способ решить проблему со списком адресов (скажем, в тех случаях, когда раз за разом не удается удалить из глобального списка адресов недействительные или устаревшие данные либо внести в этот список обновленные данные).

В ходе процесса переформирования списка адресов система Exchange определяет для атрибута msExchDoFullReplication службы обновления получателей значение TRUE, а по завершении данного процесса изменяет это значение на FALSE. Таким образом исключается возможность одновременного проведения процедуры повторного формирования списков адресов несколькими администраторами (по той, например, причине, что они не видят явных признаков выполнения этой процедуры кем-то другим). Если же проведение операции повторного формирования списков адресов средствами службы обновления получателей может повлечь за собой неприятные последствия для организации, можно ограничить доступ к этому атрибуту, оставив право на обновление его значения за администратором всего предприятия.

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

Самая элементарная проблема, с которой, вероятно, придется столкнуться, состоит в том, что новые объекты, имеющие адреса электронной почты, не отображаются в глобальном списке или в других списках адресов. Это значит, что служба обновления получателей не смогла обработать данные объекты. Предположительно все дело в ошибочной политике получателя. Возможно, объяснение состоит в том, что указанный в службе обновления получателей контроллер домена по той или иной причине недоступен (это могут быть неполадки с сетью или временная приостановка работы). Еще одна возможная причина рассматриваемой проблемы — задержки с тиражированием данных AD. В этом случае часто бывает, что в рамках одной и той же организации обновленные данные присутствуют в одних местах и отсутствуют в других. Необходимо проверить все указанные возможности и устранить все связанные с ними неполадки, прежде чем приступать к операции повторного формирования списка адресов.

В статье Microsoft «Proxy addresses are not removed when the recipient policy is removed in Exchange Server» (http://support.microsoft.com/?kbid=286302) описывается любопытная проблема. Когда администратор удаляет политику получателя, служба обновления получателей не удаляет адресов других форматов, созданных с помощью этой политики. Проблема, по-видимому, возникает потому, что Microsoft так и не включила в спецификацию службы обновления получателей функции «проверка-удаление». Администратор вынужден удалять эти адреса вручную; в статье рассказывается о том, как это сделать.

Проблемы могут возникнуть и в связи с недостаточной осведомленностью сотрудников в вопросах, касающихся функционирования службы обновления получателей. Если, к примеру, администратор начнет экспериментировать с этой службой и применит какую-либо политику получателя, в результате могут измениться почтовые адреса пользователей. Система Exchange не генерирует предупреждений о возможных последствиях применения новой политики; разъяснений относительно различий между текущей политикой и новой политикой она тоже не предлагает, так что при оценке последствий применения новой политики администратор может опираться только на собственные знания особенностей конкретной организации. Здесь еще будет уместно напомнить, что особую осторожность при изменении политик получателей следует соблюдать администраторам тех организаций, в которых не используется функция RUS по автоматическому генерированию адресов электронной почты; в этой ситуации велика вероятность того, что модифицированная политика получателя будет конфликтовать с процессом, который используется для создания адресов.

И последнее. Планируя разобраться с тем, как функционирует служба обновления получателей в организации и намереваясь черпать данные для анализа из журналов регистрации событий, нужно иметь в виду следующее. Отладка и диагностика службы обновления получателей — дело весьма сложное. В журналах регистрации событий можно найти массу относящейся к делу информации, но интерпретировать ее нелегко. Рекомендую ознакомиться с состоящей из трех частей превосходной статьей на эту тему — «You Had Me at EHLO», опубликованной в сетевом журнале Microsoft Exchange Team по адресу http://blogs.technet.com/exchange/archive/ 2004/07/07/175444.aspx.

Приоритеты и подготовка

Искусство администратора часто сводится к умению правильно расставлять приоритеты, иначе говоря, к умению определять, каким задачам следует уделять время, а какие пока можно оставить без внимания. Если на начальных этапах уделить немного внимания службе обновления получателей, в дальнейшем она, скорее всего, будет проходить по второй категории — прекрасно функционировать без какого-либо вмешательства со стороны администратора. Но и подготовкой — изучением того, какие функции выполняет служба RUS и как она это делает, — тоже нельзя пренебрегать. Разобравшись с этими вопросами, администратор будет во всеоружии, если в системе возникнут проблемы с почтовыми адресами, с доставкой сообщений или новые объекты не будут отображаться в глобальном списке адресов.

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