Управление политиками адресов электронной почты в Exchange Server 2007

Политики адресов электронной почты, известные в Exchange 2000 и 2003 как политики получателя, определяют адреса прокси, которые приписываются объектам получателя в организации Exchange 2007. Политики адресов электронной почты добавляются на уровне организации, то есть они применяются ко всей организации Exchange 2007. В Exchange 2007 политики получателя разделены на две части: допустимые домены и политики адресов электронной почты.

Те из вас, кто работал с Exchange 2000 и/или 2003, знают, что политики получателя контролировали также, какие пространства имен SMTP принимались организацией Exchange. Некоторые, может быть, удивятся, почему эти политики разделены в Exchange 2007. Были, по крайней мере, три причины, почему группа Exchange Product сделала разделение. Во-первых, если некоторый домен был указан для политики адресов электронной почты, но не был настроен как авторитетный домен, электронная почта, отправленная получателям с электронными адресами, определенными политикой, не будет маршрутизирована в организации Exchange для данного домена. И даже хотя это ошибочный сценарий, системный менеджер Exchange 2000 и 2003 позволял такой тип конфигурации. Во-вторых, концепция авторитетных доменов была спрятана под GUI адресов электронной почты политики получателя, что не было интуитивно понятно администраторам. И, наконец, домены для пересылки контролировались через GUI коннектора SMTP, находящийся в совершенно другом месте, откуда контролировались авторитетные домены (политики получателя).

Разделение допустимых доменов и политик адресов электронной почты — не единственное конструктивное изменение, сделанное в Exchange 2007. Печально известная служба Recipient Update Service (RUS), которую многие из нас знают по Exchange 2000 и 2003, уже не является частью продукта Exchange 2007. RUS отвечала за приписывание адресов электронной почты к объектам AD, в добавление к членству в списке адресов, также как за некоторые другие вещи, она не всегда работала согласно ожиданиям, и проблемы с ней было очень трудно решать, когда она барахлила. В Exchange 2007 RUS (и, следовательно, асинхронное поведение, присущее объектам обеспечения) заменена новым синхронным процессом (команда EmailAddressPolicy), используемая для приписывания электронных адресов объектам немедленно! Да, теперь вам не надо ждать несколько минут, чтобы увидеть электронные адреса на ваших объектах, что не было редкостью с антикварной RUS.

Замечание: Детальное объяснение об удалении RUS можно прочитать в этом посте в блоге команды MSExchange..

Допустимые домены

Перед созданием новой политики адресов электронной почты, вы должны сначала добавить соответствующее имя домена в список допустимых доменов. Во вкладке Accepted Domains (Допустимые домены) мы указываем SMTP домены, для которых наша организация Exchange должна быть либо авторитетной, либо пересылать данные на сервер электронной почты в другой лес Active directory внутри организации, либо пересылать данные на сервер электронной почты вне соответствующей организации Exchange. Разница между доменами, пересылающими данные внутри или вне организации, заключается в том, что при внутренней пересылке электронные сообщения просто посылаются напрямую к серверу электронной почты в организации. Сообщения, отправляемые на домен исходящих данных, будут сначала доставлены на пограничный транспортный сервер в граничной сети, и уже отсюда будут отправлены на соответствующий внешний сервер электронной почты в Internet.

Когда первый транспортный сервер-концентратор развертывается в организации Exchange 2007, корневой домен леса Active Directory настроен как авторитетный домен по умолчанию. Так как транспортный сервер-концентратор, используемый в качестве примера в данной статье, был установлен в лес Active Directory под названием exchangedogfood.dk, это доменное имя принадлежит авторитетному домену для данной организации Exchange 2007 по умолчанию (Рисунок 1). Поскольку мы используем установку с разделенным DNS, где имена внутреннего и внешнего доменов совпадают, нам не нужно вносить никаких конфигурационных изменений относительно установленного транспортного сервера-концентратора. Многие организации используют внутреннее доменное имя, отличное от внешнего доменного имени, который, кроме всего прочего, используется для входящей почты. Например, часто используется внутренний домен domain.local. Если это как раз про вашу организацию, вы должны вручную создать допустимый домен, совпадающий с внешним доменным именем.

Рисунок 1. Страница свойств для допустимого домена.

Создание нового допустимого домена

Создание нового допустимого домена — простая задача. Вы просто щелкаете на New Accepted Domain в панели Action. В мастере New Accepted Domain введите имя для новой записи доступных доменов и домен, который должен будет принимать электронную почту.

Замечание: Любой допустимый домен, добавленный в список допустимых доменов, может быть привязан к некоторой политике адресов электронной почты (E-mail Address Policy — EAP) так, что она создаст соответствующие адреса электронной почты для допустимого домена. Вообще-то каждая EAP должна быть привязана к допустимому домену, так чтобы электронные сообщения, отправленные по адресу, указанному в EAP, могли быть маршрутизованы транспортным сервером-концентратором в организации. Вы увидите, что я имею в виду, когда мы обсудим политики адресов электронной почты далее в этой статье.

Как мы уже говорили, транспортный сервер-концентратор может обрабатывать сообщения для конкретного домена несколькими различными образами (Рисунок 2). Выберите желаемую опцию и щелкните New, а затем Finish.

Рисунок 2. Мастер New Accepted Domain.

Если вы предпочитаете создать запись в допустимых доменах через Exchange Management Shell, вы можете сделать это с помощью команды New-AcceptedDomain. К примеру, для создания записи, идентичной показанной на Рисунке 2, нужно выполнить такую команду: New-AcceptedDomain –Name “Exchange-faq” –DomainName “exchange-faq.dk” –DomainType “Authoritative” Как вы видите на Рисунке 3, в нашей организации Exchange 2007 есть несколько политик адресов электронной почты, перечисленные в приоритетном порядке (чем меньше номер, тем выше приоритет), как было и в Exchange 2000 и 2003. Если вы хотите переместить политику выше в списке, выделите эту политику и щелкните Change Priority в панели Action. Необходимо иметь как минимум две EAP помимо политики по умолчанию, чтобы видеть опцию Change Priority в панели Action.

Рисунок 3. Приоритетный список политик адресов электронной почты в организации.

Создание новой политики адресов электронной почты

Создание новой политики адресов электронной почты — простая задача, хотя и отличающаяся от таковой в Exchange 2000 и Exchange 2003. Чтобы осуществить ее, щелкните на New E-mail Address Policy в панели Action. На странице приветствия мастера New E-Mail Address Policy, введите имя для новой политики, и затем укажите, какой тип получателей включать (Рисунок 4), а затем щелкните Next.

Рисунок 4. Страница New E-Mail Address Policy.

Вы теперь можете быть немного избирательнее при определении вашей целевой группы, используя фильтр и выбирая одно или несколько условий (Рисунок 5). Когда вы настроите все условия, которые хотите применять для политики, нажмите Next.

Рисунок 5. Страница условий мастера New E-Mail Address Policy.

Теперь щелкните Add и выберите порт E-mail address local part, который будет использоваться для создания имени пользователя как части электронного адреса, затем выберите домен электронной почты из E-mail address domain в выпадающем меню (Рисунок 6). Когда будете готовы, нажмите OK и Next.

Рисунок 6. Указание локального порта адресов электронной почты и домена адреса электронной почты.

Как вы видите на Рисунке 6, вы можете выбирать из 7 локальных портов адреса электронной почты. Локальный порт электронного адреса — формат имени, появляющийся перед знаком «at» (@). Если ни один из этих 7 портов по умолчанию вам не подходит, вы можете использовать переменные, перечисленные в Таблице 1 ниже.

Таблица 1. Допустимые параметры адреса электронной почты.

На странице Schedule укажите, когда политики адресов электронной почты должны применяться, и максимальное количество времени, разрешенное для запуска (Рисунок 7). Затем щелкните Next.

Рисунок 7. Страница расписания мастера New E-Mail Address Policy.

На странице Configuration Summary щелкните New. Если вы выбрали применить политики немедленно, адрес прокси будет применен ко всем получателям, попадающим в фильтр. Когда задание завершено, щелкните Finish на странице завершения.

Подсказка:Для создания новой политики адресов электронной почты через Exchange Management Shell нужно использовать команду New-EmailAddressPolicy К примеру, для создания политики, идентичной созданной через GUI мастера, нужно выполнить такую команду:

New-EmailAddressPolicy -Name “Exchangedogfood.dk” -IncludedRecipients “MailboxUsers” -ConditionalCompany “Exchange Dogfood Corporation” -Priority “Lowest” -EnabledEmailAddressTemplates “SMTP:%g.%s@exchangedogfood.dk”

Когда новая политика адресов электронной почты создана и применена ко всем получателям, вы можете проверить, был ли адрес прокси приписан соответствующим пользовательским объектам в списке E-Mail Addresses на странице свойств объектов получателя, как на Рисунке 8 ниже.

Рисунок 8. Список адресов электронной почты на странице свойств почтового ящика пользователя.

Когда у пользователя включено “Automatically update e-mail addresses based on email address policy”, все основные адреса электронной почты (адреса для ответов по умолчанию) типов адресов электронной почты всегда будут устанавливаться из политики адресов электронной почты. Это означает, что если вы делаете первичный адрес другим адресом электронной почты, он всегда будет возвращен назад согласно политике адресов электронной почты.

Прощай LDAP! Здравствуй OPATH

Вместо LDAP, который был фильтром получателей, использовавшимся в Exchange 2000 и 2003, теперь Exchange использует OPATH для фильтрации получателей, адресных списков и т.д. Синтаксис, используемый в OPATH, намного менее сложный, чем в LDAP фильтрах, то есть в Exchange 2007 проще создавать фильтры, чем в предыдущих версиях Exchange Server. Углубление в сложности фильтрации с OPATH выходит за рамки этой статьи, вместо этого я порекомендую почитать эту запись в блоге команды MS Exchange Team, которая великолепно описывает, как начать работу с фильтрацией с OPATH.

Управление SMTP прокси-адресами вручную

В некоторых сценариях вам может потребоваться управлять STMP прокси-адресами через отдельное средство обеспечения, используемое в секции обслуживания IT. В этом случае вам может понадобиться отключить опцию Automatically update e-mail addresses based on email address policy, находящуюся на вкладке E-Mail Addresses на странице свойств пользовательского почтового ящика Exchange 2007 (Рисунок 8). Если ваша организация состоит из нескольких тысяч пользовательских почтовых ящиков, вы, конечно же, не хотите проделывать это через Exchange Management Console (EMC), так как EMC не позволяет применить такой тип изменения ко всем пользовательским почтовым ящикам сразу. Итак, что же я делаю в данной ситуации? Просто обращайтесь к Exchange Management Shell и запускайте команду в одну строчку. К примеру, если вы хотите отключить эту опцию для всех пользовательских почтовых ящиков Exchange 2007, можно использовать следующую команду:

Get-Mailbox | Set-Mailbox -EmailAddressPolicyEnabled $False

Если же вы предпочитаете сделать это для сервера почты, вам надо использовать:

Get-Mailbox –Server “Mailbox Server” | Set-Mailbox -EmailAddressPolicyEnabled $False

Или, может быть, вы хотите сделать так для пользователей из некоторой OU:

Get-Mailbox –OrganizationalUnit “Name of OU” | Set-Mailbox -EmailAddressPolicyEnabled $False

Это все на этот раз, надеюсь, вы почерпнули для себя что-нибудь новое!