В действительности используются только три коннектора для соединения групп маршрутизации.
Коннектор Routing Group Connector (RGC). Коннектор Routing Group Connector (RGC) является главным коннектором, используемым для соединения групп маршрутизации, и он наиболее прост в настройке. Этот коннектор использует протокол SMTP как транспортный механизм по умолчанию, однако при необходимости используется удаленный вызов процедур (RPC).
Коннектор SMTP. Коннектор SMTP требует выполнения несколько большего объема работ при установке, нежели коннектор RGC, и обеспечивает некоторые другие возможности. Как правило, этот коннектор используется для соединения групп маршрутизации, в которых необходимо принудительно использовать SMTP в качестве механизма передачи данных. Коннектор SMTP применяется также для соединения организации Exchange с внешней системой обмена сообщениями (такой как интернет) с помощью SMTP.
Коннектор X.400. Коннектор X.400 предназначен для соединения групп маршрутизации и для подключения к внешним системам. При соединении групп маршрутизации главным преимуществом этого коннектора является возможность его работы на крайне ненадежных каналах связи с очень низкой пропускной способностью. Коннектор X.400 описывается в лекции 1 "Функциональность, безопасность и поддержка Exchange Server 2003" .
Коннектор Routing Group Connector
В большей части информационных сред коннектор Routing Group Connector наилучшим образом подходит для соединения групп маршрутизации, так как обладает высокими скоростными характеристиками, высокой степенью надежности и, в то же время, прост в установке. Коннектор RGC использует протокол Simple Mail Transport Protocol (SMTP), поэтому может работать даже при наличии низкоскоростного канала связи или ненадежного соединения.
Коннектор Routing Group Connector представляет собой однонаправленное соединение одного сервера в одной группе маршрутизации с другим сервером в другой группе маршрутизации. Следовательно, если необходимо использование двунаправленного соединения (как правило, так оно и есть), потребуется создать два коннектора для формирования логической двунаправленной связи между двумя группами маршрутизации.
К счастью, программа System Manager (Диспетчер системы) позволяет автоматически настраивать противоположный конец соединения при создании первого коннектора. Если использовать эту возможность, коннектор, созданный Exchange в удаленной группе маршрутизации, наследует параметры, установленные для локального коннектора, за исключением двух важных моментов.
Первое исключение показано на вкладке General (Общие) окна свойств коннектора Routing Group Connector (см. рис 13.1). Если удаленная группа маршрутизации содержит несколько серверов, Exchange Server включает опцию These Servers Can Send Mail Over This Connector (Эти серверы могут передавать почту через данный коннектор), после чего выбирает каждый сервер SMTP для данной конфигурации. Если какой-либо из виртуальных серверов, созданных на конечных серверах, является несовместимым с передачей сообщений через данный коннектор, потребуется либо вручную удалить эти серверы из списка, либо вручную настроить другой коннектор.
Второе исключение, относящееся к наследуемым параметрам, отображается на вкладке Remote Bridgehead (см. рис 13.2). Exchange Server выводит все виртуальные серверы SMTP в качестве конечных серверов. Если виртуальный сервер SMTP не должен являться конечным сервером, потребуется либо удалить этот сервер из списка вручную, либо вручную же настроить коннектор.
Примечание. Если рассматриваемая организация Exchange содержит серверы Exchange 5.5, и эти серверы расположены внутри отдельного домена Microsoft Windows NT 4, можно подключить коннектор Routing Group Connector как учетную запись в домене NT 4. Помните, что коннектор Routing Group Connector выглядит как коннектор сайта в организации Exchange 5.x, и что он функционирует таким же образом.
(рис 13.2) Указание серверов, которые могут отправлять электронную почту через рассматриваемый коннектор(рис 13.1) Указание конечных серверов для рассматриваемого коннектораКоннектор Routing Group Connector использует сервер-мост, выступающий в роли шлюза, через который сообщения входят и выходят из группы маршрутизации. Коннектор RGC обеспечивает определенный уровень отказоустойчивости, разрешая использовать несколько исходных и конечных серверов-мостов. Серверы-мосты используются одним из трех способов.
Сервер-мост не назначается, и все серверы в группе маршрутизации функционируют в качестве серверов-мостов для передачи сообщений.
Назначается один сервер-мост, и вся электронная почта, направленная в другие группы маршрутизации, проходит через этот сервер. Это позволяет администратору осуществлять тщательный контроль над конфигурацией обмена сообщениями.
Используются несколько серверов-мостов, и вся электронная почта проходит через один из назначенных серверов. Такая конфигурация обеспечивает преимущества, заключающиеся в распределении нагрузки и отказоустойчивости. Если один сервер-мост недоступен для передачи сообщений, то эту функцию сможет выполнять другой доступный сервер.
Примечание. В Microsoft рекомендуют наличие канала связи с пропускной способностью не менее 64 Кбит/с, обеспечиваемого коннектором Routing Group Connector. Кроме того, в настоящий момент невозможно использовать шифрование между серверами-мостами.
Пример из практики.Обработка IP-адресов конечного сервера для серверов-мостов
Когда сервер-мост (BHS), на котором расположен коннектор Routing Group Connector, принимает сообщение, направленное на сервер в другой группе маршрутизации, сервер BHS предпринимает некоторые действия для обработки IP-адреса конечного сервера BHS. Сервер BHS соединяется с DNS и осуществляет попытку обработки IP-адреса адресной записи (A) конечной машины. При наличии нескольких записей DNS учитывает значения предпочтений при выборе BHS для обработки. При использовании Windows DNS все Windows-серверы автоматически регистрируют А-записи в DNS. Если А-записи не существует, сервер BHS пытается обработать IP-адрес с помощью процедуры разрешения имен NetBIOS.
Дополнительная информация. Чтобы узнать больше о системе DNS и Windows Server 2003, обратитесь к книгам "Microsoft Windows Server 2003. Справочник администратора" авторов Чарли Рассела, Шарон Кроуфорд и Джейсона Джеренд (издательство "Эком", 2004 г.) и "Active Directory для Microsoft Windows Server 2003. Справочник администратора" авторов Стейна Реймера и Майка Малкера (издательство "Эком", 2004 г.).
Создание коннектора группы маршрутизации
Чтобы создать новый коннектор Routing Group Connector, щелкните правой кнопкой мыши на контейнере Connectors (Коннекторы), расположенном под контейнером группы маршрутизации в оснастке Exchange System, наведите указатель мыши на пункт New (Создать), а затем выберите Routing Group Connector (Коннектор группы маршрутизации). На вкладке General (Общие) введите имя коннектора, после чего выберите группу маршрутизации, с которой необходимо соединить данный коннектор (см. рис 13.3).
(рис 13.3) Вкладка General (Общие) окна свойств коннектора Routing Group ConnectorКроме этого, можно выбрать опцию Any Local Server Can Send Mail Over This Connector (Любой локальный сервер может отправлять почту через этот коннектор) или опцию These Servers Can Send Mail Over This Connector (Эти серверы могут отправлять почту через данный коннектор). Первая опция используется по умолчанию и позволяет любому серверу в группе маршрутизации использовать коннектор для отправки сообщений, направленных на сервер в другой группе маршрутизации. Вторая опция позволяет зарезервировать коннектор для определенных виртуальных серверов в группе маршрутизации. Выбор этой опции позволяет указать виртуальные серверы в группе маршрутизации, которые могут использовать данный коннектор.
Совет. Не забудьте выбрать виртуальный сервер, который будет отправлять электронную почту в конечную группу маршрутизации. Предположим, что имеется группа внешних пользователей, отправляющих свои сообщения в организацию с использованием технологии Transport Layer Security (TLS), и что администратор настроил виртуальный сервер SMTP для принятия электронной почты по второму IP-адресу через порт 25. Этот виртуальный сервер SMTP требует сертификат для аутентификации. Теперь предположим, что в рассматриваемой локальной сети такие настройки для локальных пользователей отсутствуют. Если данный виртуальный сервер будет выбран в качестве единственного сервера, осуществляющего отправку электронной почты через создаваемый коннектор Routing Group Connector, то сообщения, отправляемые локальными пользователями, будут отклоняться, так как каждое сообщение будет возвращаться на второй IP-адрес сервера, и SMTP-сервер
будет ожидать использования TLS и сертификатов. В этой ситуации необходимо убедиться, что данный виртуальный сервер не выбран для коннектора Routing Group Connector.
Вкладка Remote Bridgehead (Удаленный сервер-мост)
На вкладке Remote Bridgehead (см. рис 13.2) указывается один или несколько серверов в удаленной группе маршрутизации, функционирующих в качестве серверов-мостов. Коннектор будет пытаться установить соединение с каждым целевым сервером перед отправкой сообщений. Соединение с серверами осуществляется упорядоченно, начиная с сервера, находящегося вверху списка. Кроме того, если на конечном сервере настроено несколько виртуальных серверов SMTP, понадобится выбрать тот виртуальный сервер, который позволит отправлять сообщения через настраиваемый коннектор.
Вкладка Delivery Restrictions (Ограничения доставки)
Вкладка Delivery Restrictions (см. рис 13.4) позволяет указать, кто может использовать данный коннектор. Здесь есть два варианта: либо указать необходимость отклонения всех сообщений, за исключением тех, что получены от пользователей, входящих в список избранных пользователей, либо указать, что следует принимать все сообщения, за исключением элементов, полученных от членов списка избранных пользователей. Вместо этого можно указать только пользователей и контакты с доступом к почте.
(рис 13.4) Вкладка Delivery Restrictions (Ограничения доставки) окна свойств коннектора Routing Group ConnectorСовет. Чтобы выбрать нескольких пользователей из Active Directory, выделите первого пользователя в списке Select Recipient (Выбор пользователей), после чего с помощью клавиш "вверх" и "вниз" выберите группу смежных пользователей. Чтобы выбрать группу несмежных пользователей в списке, удерживайте клавишу Ctrl, после чего с помощью мыши выделите всех пользователей, которых необходимо добавить в список.
Пример из практики.Присвоение приоритета сообщениям, получаемым от определенных пользователей
При использовании совместно со стоимостью, присвоенной коннектору, вкладка Delivery Restrictions (Ограничения доставки) позволяет присваивать более высокий приоритет сообщениям, отправляемым через коннектор Routing Group Connector определенной группой пользователей, по сравнению с сообщениями, отправляемыми другими пользователями. Предположим, что сотрудники отдела продаж и подразделение предпродажной поддержки находятся в двух различных городах, которые представляют собой две различные группы маршрутизации. Также предположим, что большая часть заказов в организации поступает по телефону, и что при возникновении у сотрудника отдела продаж вопроса технического характера о том или ином продукте ему нужно отправлять свой вопрос по электронной почте сотрудникам предпродажной поддержки. В этой ситуации настраиваются два коннектора Routing Group Connector. Первый из них будет коннектором со стоимостью 100, предназначенным для приема сообщений
от любого пользователя и дальнейшей их передачи соответствующим образом, однако он будет отклонять сообщения, поступающие от сотрудников отдела продаж. Второй коннектор будет иметь стоимость, равную 1, и будет отклонять всех пользователей, за исключением сотрудников отдела продаж, указанных на вкладке Delivery Restrictions (Ограничения доставки). Такой подход к передаче сообщений обеспечит более быструю отправку сообщений в другую группу маршрутизации от сотрудников отдела продаж по сравнению с сообщениями от других пользователей.
Вкладка Delivery Options (Параметры доставки)
Вкладка Delivery Options (Параметры доставки), показанная на рис 13.5, позволяет указывать, когда сообщения могут проходить через коннектор. Эта возможность особенно полезна при использовании коннектора на низкоскоростном или ненадежном канале связи WAN, либо в соединении, стоимость использования которого варьируется в зависимости от времени дня. Выбрав опцию Use Different Delivery Times For Oversize Messages (Использовать другое время для доставки больших сообщений), можно удерживать сообщения большого размера до установленного времени, когда через коннектор проходит небольшой объем трафика.
(рис 13.5) Вкладка Delivery Options (Параметры доставки) окна свойств коннектора Routing Group Connector
Вкладка Content Restrictions (Ограничения содержания)
На вкладке Content Restrictions (Ограничения содержания), показанной на рис 13.6, указываются приоритеты, тип и размеры сообщений, которые могут проходить через данный коннектор RGC. Область Allowed Priorities (Разрешенные приоритеты) позволяет выбрать приоритет сообщения для передачи через соединение. Это прекрасный способ настройки коннекторов, специально предназначенных, например, для передачи сообщений с высоким приоритетом. В области Allowed Types (Разрешенные типы) опция System Messages (Системные сообщения) позволяет осуществлять передачу всех не пользовательских сообщений, включая репликацию каталогов, репликацию общих папок, мониторинг сети, а также сообщения об успешной или неудачной доставке. В области Allowed Sizes (Разрешенные размеры) задается ограничение размера передаваемых сообщений.
(рис 13.6) Вкладка Content Restrictions (Ограничения содержания) окна свойств коннектора Routing Group ConnectorПример из практики.Сравнение коннекторов Routing Group Connector и Exchange 5.5 Site Connector
Коннектор Routing Group Connector использует SMTP в качестве транспортного протокола, что обеспечивает больший уровень отказоустойчивости, нежели в случае с коннектором Exchange Server 5.x при работе в средах с низкоскоростным каналом связи и высоким уровнем задержек. Коннектор Site Connector использует TCP для инициирования и поддержки соединения с целевым сервером-мостом, после чего использует удаленные вызовы процедур для запуска функций коннектора. Удаленные вызовы процедур (RPC) вызывают большой объем трафика и требуют высокую пропускную способность и степень постоянства соединения для выполнения своих задач. Напротив, несмотря на то что коннектор Routing Group Connector передает команды SMTP через сеанс TCP, команды не отправляют удаленные вызовы процедур на целевой сервер. Вместо этого SMTP передает последовательность небольших команд, устойчивых к более низким скоростям передачи данных и уровню непостоянности соединения по сравнению с удаленным
вызовом процедур. Для получения более подробной информации об SMTP обратитесь к лекции 7 курса "Переход к Microsoft Exchange Server 2003 и поддержка Outlook".
При обновлении сервера-моста Exchange 5.5, использующего коннектор Site Connector, станет видно, что коннектор в процессе обновления сменится на коннектор Routing Group Connector, осуществляющий через RPC соединение с серверами 5.x, но по-прежнему использующий SMTP для соединения с другими серверами Exchange 2003.
Коннектор Routing Group Connector обеспечивает две возможности, отсутствующие в коннекторе Site Connector в Exchange Server 5.5. Во-первых, возможность создания расписания для определения того, когда сообщения передаются через коннектор, во-вторых, назначение передачи сообщений по их размеру (например, всех сообщений, чей размер превышает 2 Мб), чтобы эти сообщения передавались в то время, когда канал связи используется наименее активно.
Коннектор SMTP
Хотя RGC использует SMTP в качестве собственного механизма передачи, Exchange Server 2003 также предоставляет коннектор SMTP, используемый для связи групп маршрутизации. Коннектор SMTP можно использовать вместо RGC, принимая во внимание три следующих момента.
Коннектор SMTP обладает более гибкими настройками, нежели RGC, и обеспечивает больше возможностей для тонкой настройки соединения. Коннектор SMTP также обеспечивает возможность выполнения аутентификации перед отправкой электронной почты, шифрования TLS и удаления электронной почты из очередей на удаленных серверах.
Коннектор SMTP всегда использует протокол SMTP. При соединении сервера Exchange 2003 с сервером Exchange 5.5 Server коннектор Routing Group Connector использует для связи удаленный вызов процедур, так как ему не известно, настроен ли сервер Exchange 5.5 Server на работу с SMTP, в отличие от ситуации с предыдущими версиями Exchange, где эта информация предоставлялась службой Internet Mail Service. Нельзя заставить RGC работать через SMTP, поэтому вместо него можно использовать коннектор SMTP.
Коннектор SMTP также позволяет соединять независимые леса внутри организации для обеспечения передачи сообщений.
Даже несмотря на то что коннектор SMTP можно использовать для соединения групп маршрутизации в определенных обстоятельствах, его основным назначением в Exchange Server 2003 является обеспечение связи с внешними средами (соединение с интернетом либо другой средой, отличной от Exchange). Как и коннектор Routing Group Connector, данный коннектор является однонаправленным, поэтому его необходимо настраивать по обе стороны соединения.
При подключении к интернету коннектор SMTP использует узел диспетчеризации (smart-host) (еще один сервер SMTP, на который передаются сообщения для маршрутизации) или MX-записи в DNS для маршрутизации в следующем сегменте. При внутреннем конфигурировании между двумя группами маршрутизации данный коннектор передает информацию о состоянии связи между группами маршрутизации, но попрежнему зависит от MX-записей в DNS для получения информации по следующему сегменту.
Коннектор SMTP отличается от Routing Group Connector тем, что он может использовать шифрование и аутентификацию. Если для некоторых сообщений требуется шифрование, то следует использовать SMTP Connector. Еще одним свойством этого коннектора является аутентификация в удаленном домене перед отправкой в него сообщения. Подобно Routing Group Connector, SMTP Connector позволяет задавать время отправки сообщений, чтобы использовать периоды неактивного использования пропускной способности.
SMTP Connector позволяет создавать области действия коннектора (Connection scope), посредством которых только определенные серверы организации Exchange смогут использовать данный коннектор. Вместо ограничения коннектора серверами, указанными в определенной области действия, теперь существует возможность выбора между использованием этого коннектора всеми серверами организации или только серверами локальной группы маршрутизации (см. рис 13.7).
И, наконец, SMTP Connector потребуется, если пропускная способность меньше 64 Кбит/с и больше 16 Кбит/с. Если единственной причиной выбора SMTP Connector является нежелание использовать протокол SMTP между группами маршрутизации, то лучше выбрать коннектор Routing Group Connector. Этот коннектор использует SMTP в качестве своего транспортного протокола.
Создание коннектора SMTP Connector
Создание коннектора SMTP происходит таким же образом, как и создание коннектора Routing Group Connector: щелкните правой кнопкой мыши на соответствующей группе маршрутизации, укажите пункт New (Создать) и выберите пункт SMTP Connector. После этого на экране появится страница свойств данного коннектора с окном вкладки General (см. рис 13.8), где указывается имя коннектора и определяются опции, относящиеся к использованию системы DNS. Опция Use DNS To Route To Each Address Space On This Connector (Использовать DNS для маршрутизации в каждое адресное пространство через этот коннектор) позволяет коннектору работать с DNS, чтобы выполнять прямые соединения с целевым сервером SMTP, основываясь на MX-записях и значениях предпочтений. Но если нужно направить почту через центральный узел по той причине, что несколько прямых соединений занимают слишком много времени или требуют слишком больших затрат, тогда следует выбрать
опцию Forward All Mail Through This Connector To The Following Smart Host (Направлять всю почту через этот коннектор на следующий узел диспетчеризации). Здесь вводится либо полностью определенное доменное имя (FQDN) этого узла диспетчеризации, либо его IP-адрес. Если принято решение ввести IP-адрес, то нужно поместить его в прямоугольные скобки, например [192.168.2.200]. Кроме того, указанное значение заменит значение параметра Smart Host (Узел диспетчеризации) в диалоговом окне Advanced Delivery (Дополнительные параметры доставки), которое можно отобразить, нажав кнопку Advanced (Дополнительно) на вкладке Delivery (Доставка) страницы свойств виртуального сервера SMTP.
(рис 13.8) Настройка области действия коннектора SMTP Connector(рис 13.7) Вкладка General (Общие) страницы свойств коннектора SMTP ConnectorВкладка Delivery Options (Параметры доставки)
Вкладка Delivery Options страницы свойств коннектора SMTP содержит одно средство, которого нет на странице свойств RGC-коннектора: Queue Mail For Remote Triggered Delivery (Направлять сообщения в очередь для запускаемой удаленной доставки). Это свойство позволяет клиентам периодически подсоединяться к рассматриваемому серверу Exchange и загружать с него сообщения. Чтобы сделать этот процесс защищенным, клиенты организации осуществляют подключение с помощью учетной записи в рассматриваемом домене. После нажатия кнопки Add (Добавить) для указания учетных записей, авторизованных для использования команд TURN/ATRN, станет видно, что доступны только локальные учетные записи домена. Это ограничение возникает из-за того, что именно рассматриваемый сервер Exchange содержит почту для чтения другими пользователями, и поэтому они должны быть аутентифицированы в данном домене. Поэтому необходимо указать, какие учетные записи Active Directory
позволяют загружать сообщения электронной почты. Чтобы запустить загрузку с сервера Exchange Server 2003, клиент должен выполнить команду TURN.
Вкладка Advanced (Дополнительно)
На рисунке 13.9 показана вкладка Advanced страницы свойств коннектора SMTP с важными параметрами конфигурирования, которые необходимо учесть при установке данного коннектора. Во-первых, здесь настраивается коннектор на отправку команды HELO вместо EHLO. Традиционно первой командой, которую отправляет клиент SMTP при подсоединении к серверу SMTP, является команда HELO. Эта команда выполняет запуск сеанса и идентифицирует отправителя предстоящего сообщения. По умолчанию Exchange Server 2003 отправляет команду EHLO, которая не только выполняет запуск, но также указывает, что данный сервер Exchange может использовать расширенный набор команд SMTP (ESMTP). Не все серверы SMTP поддерживают обмен информацией с использованием расширенного набора команд. Если нужно подключаться к серверу SMTP, который не воспринимает команды ESMTP, включите эту опцию, чтобы Exchange Server отправлял команду запуска HELO.
Список команд SMTP приведен в лекции 7 курса "Переход к Microsoft Exchange Server 2003 и поддержка Outlook".
(рис 13.9) Вкладка Advanced страницы свойств коннектора SMTPКроме того, на вкладке Advanced есть кнопка Outbound Security (Внешняя безопасность), предназначенная для представления аутентификационных данных в удаленном домене. Опция Do Not Send ETRN/TURN (Не отправлять ETRN/TURN) запрещает коннектору запрашивать вывод из очереди удаленного сервера. Эта опция включена по умолчанию. Она позволяет использовать коннектор только для базовых операций отправки и приема сообщений через протокол SMTP; запросы удаленного вывода из очереди не допускаются. Скорее всего, эту опцию потребуется использовать в большинстве случаев.
Если требуется отправить сообщение о выводе из очереди вместе с другими сообщениями, передаваемыми на сервер SMTP, выберите опцию Request ETRN/TURN When Sending Messages (Запрос ETRN/TURN при отправке сообщений). Используя эту опцию, можно также запрашивать вывод из очереди в определенные моменты времени, для чего нужно включить опцию Additionally Request Mail At Specified Times (Дополнительно запрашивать почту в указанные моменты времени) и затем выбрать время вывода из очереди в поле Connection Time (Время соединения). Эти параметры применяются, например, при подключении рассматриваемого сервера Exchange к другому серверу Exchange через телефонные линии. После соединения сервер Exchange будет отправлять любую почту, предназначенную для принимающего сервера. В течение одного сеанса на другой сервер Exchange будет отправлен запрос вывода из очереди любых сообщений, которые направлены в почтовые ящики, находящиеся в рассматриваемой среде Exchange.
Чтобы запросить вывод из очереди на сервере, отличном от сервера, на который было отправлено сообщение, выберите опцию Request ETRN/TURN From Different Server (Запрос ETRN/TURN с другого сервера) и затем введите имя этого сервера. Используйте эту опцию, если имеется один сервер, который будет работать с исходящими сообщениями, и другой сервер, который будет работать с входящими сообщениями в рассматриваемой организации.
Если нужно, чтобы вывод из очереди происходил в определенные моменты времени, щелкните на ниспадающем списке Connection Time (Время соединения) и выберите одну из принятых по умолчанию (стандартных) опций или нажмите кнопку Customize (Настроить) и укажите нужный временной график. Этот параметр, например, используется в том случае, если рассматриваемый сервер Exchange не имеет постоянного соединения с интернетом, но существует надобность периодически считывать почту, поступающую от поставщика услуг интернета (ISP), посредством телефонного соединения.
И, наконец, в области Specify How To Request That Remote Servers Dequeue Mail (Выберите запрос, чтобы удаленные серверы выполняли вывод почты из очереди) выберите опцию Issue ETRN (Передать команду ETRN) или опцию Issue TURN (Передать команду TURN). Для использования ETRN необходимо наличие статического IP-адреса, в то время как при использовании TURN IP-адрес не обязательно должен быть статическим. Кроме того, для ETRN требуется указание домена для вывода из очереди, поэтому, нажав кнопку Domains (Домены), следует при необходимости указать имя локального домена, в котором требуется выполнить вывод из очереди.
Вкладка Address Space (Адресное пространство)
Подсоединяясь к внешней системе, необходимо определить адресное пространство, используемое рассматриваемым коннектором. Адресное пространство – это набор связанной с коннектором или шлюзом адресной информации, где указываются домены, в которые этот коннектор будет передавать сообщения. Как правило, адресное пространство – это подмножество пространства полных адресов; обычно это просто имя домена.
Адресное пространство определяется в окне вкладки Address Space страницы свойств данного коннектора (см. рис 13.10). Если данный коннектор SMTP будет использоваться для интернет-почты организации, укажите "*" в качестве адресного пространства. Это означает, что допускается любая строка символов, и что сообщения можно направлять через этот коннектор в любой домен.
(рис 13.10) Вкладка Address Space (Адресное пространство) страницы свойств коннектора SMTPАдресные пространства могут указываться для адресов SMTP, X.400, Lotus cc:Mail, Microsoft Mail, Lotus Notes и Novell GroupWise. Если используемое адресное пространство не относится к одному из этих типов, выберите опцию Other (Другой) и введите описание адресного пространства.
Передачу сообщений можно запретить, если не включить опцию Allow Messages To Be Relayed To These Domains (Разрешить передачу сообщений в эти домены). Тем самым незапрашиваемые сообщения электронной почты не будут направлены через рассматриваемый сервер SMTP в интернет. Однако если данный коннектор SMTP используется как некая точка диспетчеризации между двумя внешними системами SMTP, следует отметить эту опцию и добавить к адресному пространству целевое имя домена, в который должны передаваться сообщения.
Наконец, если требуется ограничить использование коннектора только теми серверами, которые входят в одну группу маршрутизации, выберите опцию Routing Group (Группа маршрутизации) в области Connector Scope (Область действия коннектора). По умолчанию все серверы организации могут использовать данный коннектор. Поскольку предполагается, что между серверами, не входящими в одну группу маршрутизации, существует либо медленное, либо ненадежное соединение, то имеет смысл активизировать опцию, чтобы серверы удаленных маршрутных групп не направляли сообщения в интернет или во внешние почтовые системы через этот коннектор.
Пример из практики.Настройка сервера SMTP как сервера диспетчеризации
Предположим, что рассматриваемая организация известна на рынке под двумя различными именами trainsbydave.com и contoso.com. Кроме того, все сообщения должны поступать в организацию через SMTP Connector на сервер, который является членом домена oaktree.com. Следующие шаги позволят обеспечить правильность маршрутизации всех сообщений по обоим доменным именам.
Введите A-запись в DNS для имени узла и IP-адрес данного сервера.
Введите две MX-записи в DNS, по одной для каждого домена, причем каждая запись должна указывать IP-адрес данного сервера.
Создайте коннектор SMTP Connector для домена trainsbydave.com.
Введите contoso.com как допустимое адресное пространство.
Включите опцию Allow Messages To Be Relayed To These Domains (Разрешить ретрансляцию сообщений на эти домены).
Создайте MX-запись и A-запись во внутренних таблицах DNS, которые указывают внутренний сервер SMTP, обслуживающий домен contoso.com.
Теперь сообщения, адресованные в домен contoso.com или trainsbydave.com, будут направляться на один и тот же сервер, а сообщения, адресованные в sugarmaple.com, будут передаваться на сервер Exchange contoso.com.
Вкладка Connected Routing Groups (Подсоединенные группы маршрутизации)
Если адресное пространство не настроено в окне вкладки Address Space, то следует использовать вкладку Connected Routing Groups для указания групп маршрутизации, подключаемых к локальной группе маршрутизации. Это нужно для информирования коннектора о том, какие группы маршрутизации к нему примыкают, чтобы включить внутреннюю маршрутизацию сообщений. Группы маршрутизации записаны в составе групп администрирования, поэтому всегда необходимо выбрать соответствующую группу администрирования. Если рассматривается небольшая организация с одной группой маршрутизации и одной группой администрирования, введите информацию об адресном пространстве в окне вкладки Address Space и не заполняйте эту вкладку.
Администрирование состояния связи
В этом параграфе будет рассказано о том, как управлять информацией о состоянии связи в системе Exchange. (О работе протокола состояния связи см. в лекции 3.)
Администрирование информации о состоянии связи выполняется внутри контейнера Queues (Очереди) сервера и заключается, в основном, в выполнении функций управления очередями. Мы сконцентрируем внимание на протоколе SMTP (см. рис 13.11), поскольку он используется и коннектором Routing Group Connector (RGC), и коннектором SMTP.
(рис 13.11) Очереди SMTP в окне оснастки Exchange SystemПрежде чем начать обсуждение, рассмотрим топологию сети, которая будет использоваться в качестве примера. На рисунке 13.12 показано, что наша вымышленная компания hr.trainsbydave.com имеет офисы в четырех городах: Folsom, Tucson, Minneapolis и Indianapolis. Здесь также видно, что в каждом городе имеется по одному пользователю, которые будут использоваться нами для иллюстрации обмена сообщениями и соединений. Предполагается, что значение стоимости для каждого коннектора равно 1. Кроме того, коннекторам групп маршрутизации присвоены имена соответствующих штатов, например, California Arizona RGC для канала связи между городами Folsom (шт. Калифорния) и Tucson (шт. Аризона). И, наконец, серверы именуются по их местонахождению, то есть имеются четыре сервера: Tucson, Folsom, Minneapolis и Indianapolis.
Важно отметить, что вид общей топологии маршрутизации для каждого сервера будет различным, поскольку не все маршруты или коннекторы отображаются в окне оснастки Exchange System для любого заданного сервера. Прежде чем продолжить чтение, ознакомьтесь с этой топологией.
Когда пользователь ssmith отправляет сообщение пользователю benglish, оно должно пройти через сервер Folsom. Сообщение не проходит через Minneapolis потому, что суммарная стоимость данного маршрута не является минимальной. По умолчанию используется маршрут с минимальной стоимостью, то есть из Indianapolis в Folsom и далее в Tucson, с суммарной стоимостью, равной 2.
(рис 13.12) Топология маршрутизации для hr.trainsbydave.comТеперь, когда вы ознакомились с данной вымышленной компанией, рассмотрим работу протокола состояния связи (Link State) при отключении какого-либо канала. Мы рассмотрим четыре различных сценария и покажем, как происходит администрирование протокола Link State.
Сценарий 1: недоступен первый канал связи
Сообщение, отправленное пользователем benglish пользователю ssmith, должно пройти через два отдельных канала (Indianapolis/Folsom и Folsom/Tucson) и через три различных сервера (Tucson, Folsom и Indianapolis). Однако предположим, что сервер Folsom отключен от сети по какой-либо причине, и что benglish отправляет сообщение ssmith. Как видно из рисунка 13.13, это сообщение сначала поступает в исходящую очередь коннектора RGC.
Управление сообщениями в исходящих очередях
В Microsoft разработан удобный способ, позволяющий узнавать о проблемах, связанных с очередью, – значки. Как показано на рисунке 13.13, значок в области результатов (область справа) очереди группы маршрутизации California Arizona сменился для отображения того, что очередь находится в состоянии повтора (небольшая синяя стрелка на значке).
(рис 13.13) Сообщение в исходящей очереди California Indiana RGC (Routing Group Connector)Управление очередями и сообщениями, которые в них находятся, можно осуществлять несколькими способами. Во-первых, можно "заморозить" (задержать) очередь, щелкнув на ней правой кнопкой мыши и выбрав команду Freeze (Задержать). Если выполнить это действие, то все сообщения так и останутся в очереди, даже если канал связи снова начнет работать. Задержание очереди может стать хорошим способом отключения попыток доставки сообщения во время разрешения каких-либо возникших проблем. Если дважды щелкнуть на очереди, чтобы отобразить находящиеся в ней сообщения, станет понятно, что можно задерживать и отдельные сообщения. Замораживание сообщения пригодится в том случае, если известно, что конкретное сообщение в очереди имеет достаточно большой размер или маленькую важность, и что его можно отложить до тех пор, пока не будут отправлены все остальные сообщения. Очередь или отдельное сообщение размораживаются посредством щелчка правой кнопкой мыши
на объекте и выбора команды Unfreeze (Разморозить). При размораживании очереди или сообщения немедленно возобновляется доставка сообщений.
Кроме этого, существует возможность удаления любого отдельного сообщения в исходящей очереди. Для этого щелкните правой кнопкой мыши на данном сообщении и выберите команду Delete (Удалить) (либо просто щелкните на сообщении и нажмите клавишу [Delete]). При этом можно указать, требуется или не требуется отправка создателю сообщения отчета о невозможности доставки.
Возобновление нормальной работы
Один лишь тот факт, что сообщения отправлялись, не означает, что информация о состоянии связи снова отражает нормальное состояние. После того как сервер снова подсоединен и начал работу, может начаться передача сообщений, но значок коннектора все еще будет указывать, что канал находится в состоянии повторения попыток. Здесь не о чем беспокоиться. Подождите несколько минут и снова проверьте очередь; после этого обычно значок указывает, что очередь находится в нормальном состоянии.
Сценарий 2: канал получателя недоступен
Мы разобрались, что происходит с сообщением, если становится недоступным первый сегмент. Теперь рассмотрим, что произойдет, если станет недоступным последний сегмент. В этом сценарии пользователь benglish отправляет сообщение пользователю ssmith, но на этот раз нет доступа к серверу Indianapolis.
Когда benglish отправляет сообщение, оно маршрутизируется из Tucson в Folsom, где ожидает, пока не заработает сервер Indianapolis или пока не истечет срок годности сообщения; в последнем случае автору будет отправлен отчет о невозможности доставки (NDR).
Сценарий 3: доступен альтернативный маршрут с более высокой стоимостью
Одной из возможностей протокола состояния связи является его способность определять, что часть полного маршрута неисправна, и перенаправлять сообщение через канал с большей стоимостью. Однако, как говорилось в лекции 3, усовершенствования в протоколе состояния связи в Exchange Server 2003 обуславливают тот факт, что связи не помечаются как недоступные, если конкретная связь является единственной связью между двумя местоположениями, или если состояние связи постоянно изменяется.
Для данного сценария увеличим до 100 единиц стоимость коннектора между серверами Folsom и Indianapolis. На рисунке 13.14 показана новая топология. Теперь предположим, что пользователь benglish в Tucson отправляет сообщение пользователю ssmith в Indianapolis.
При заданных стоимостях коннекторов обычный маршрут этого сообщения будет проходить через Minneapolis. Предположим, что канал между серверами Minneapolis и Folsom отключен. В результате сообщения будут маршрутизироваться через канал с более высокой стоимостью – между Indianapolis и Folsom.
Примечание. Если вы не знаете, по какому маршруту направлено сообщение, отследите путь этого сообщения. Подробнее об этом рассказывается в лекции 6 "Функциональность, безопасность и поддержка Exchange Server 2003"
(рис 13.14) Новая топология для hr.trainsbydave.com
Сценарий 4: сообщение имеет несколько получателей
Если сообщение направлено как внутренним, так и внешним получателям, то создается временная очередь для каждого внешнего доменного имени, а также для каждого внутреннего сервера Exchange Server 2003, на котором находится получатель данного сообщения. Предположим, что сообщение отправлено в группу вымышленных доменных имен. При отправке сообщения расширенный механизм очередей создает необходимые очереди. Протокол состояния связи не используется для этих выходных очередей SMTP к внешним серверам. Он должен только поддерживать текущую информацию о состоянии связи для внутренних серверов.
Заключение
В этой лекции рассказывалось о том, как осуществляется администрирование и управление коннекторами Routing Group Connector и SMTP Connector. Кроме этого, показано, как информация о состоянии связи позволяет осуществлять маршрутизацию сообщений в различных ситуациях. Например, было показано, что протокол состояния связи может определять, когда канал связи находится в нерабочем состоянии, и удерживать сообщения до тех пор, пока канал вновь не заработает.
Протокол состояния связи является одной из наиболее мощных возможностей Exchange Server 2003. Еще одной важной особенностью Exchange Server 2003 является возможность сосуществования с серверами Exchange 5.x. Если в организации используется операционная система Windows NT 4 и Exchange 5.5, необходимо разрешить вопросы, связанные с обновлением и сосуществованием с Windows Server 2003 и Exchange Server 2003, в процессе перехода к более новым версиям продуктов. Эти вопросы обсуждаются в курсе "Переход к Microsoft Exchange Server 2003 и поддержка Outlook".
В действительности используются только три коннектора для соединения групп маршрутизации.
Коннектор Routing Group Connector (RGC). Коннектор Routing Group Connector (RGC) является главным коннектором, используемым для соединения групп маршрутизации, и он наиболее прост в настройке. Этот коннектор использует протокол SMTP как транспортный механизм по умолчанию, однако при необходимости используется удаленный вызов процедур (RPC).
Коннектор SMTP. Коннектор SMTP требует выполнения несколько большего объема работ при установке, нежели коннектор RGC, и обеспечивает некоторые другие возможности. Как правило, этот коннектор используется для соединения групп маршрутизации, в которых необходимо принудительно использовать SMTP в качестве механизма передачи данных. Коннектор SMTP применяется также для соединения организации Exchange с внешней системой обмена сообщениями (такой как интернет) с помощью SMTP.
Коннектор X.400. Коннектор X.400 предназначен для соединения групп маршрутизации и для подключения к внешним системам. При соединении групп маршрутизации главным преимуществом этого коннектора является возможность его работы на крайне ненадежных каналах связи с очень низкой пропускной способностью. Коннектор X.400 описывается в лекции 1 "Функциональность, безопасность и поддержка Exchange Server 2003" .
Коннектор Routing Group Connector
В большей части информационных сред коннектор Routing Group Connector наилучшим образом подходит для соединения групп маршрутизации, так как обладает высокими скоростными характеристиками, высокой степенью надежности и, в то же время, прост в установке. Коннектор RGC использует протокол Simple Mail Transport Protocol (SMTP), поэтому может работать даже при наличии низкоскоростного канала связи или ненадежного соединения.
Коннектор Routing Group Connector представляет собой однонаправленное соединение одного сервера в одной группе маршрутизации с другим сервером в другой группе маршрутизации. Следовательно, если необходимо использование двунаправленного соединения (как правило, так оно и есть), потребуется создать два коннектора для формирования логической двунаправленной связи между двумя группами маршрутизации.
К счастью, программа System Manager (Диспетчер системы) позволяет автоматически настраивать противоположный конец соединения при создании первого коннектора. Если использовать эту возможность, коннектор, созданный Exchange в удаленной группе маршрутизации, наследует параметры, установленные для локального коннектора, за исключением двух важных моментов.
Первое исключение показано на вкладке General (Общие) окна свойств коннектора Routing Group Connector (см. рис 13.1). Если удаленная группа маршрутизации содержит несколько серверов, Exchange Server включает опцию These Servers Can Send Mail Over This Connector (Эти серверы могут передавать почту через данный коннектор), после чего выбирает каждый сервер SMTP для данной конфигурации. Если какой-либо из виртуальных серверов, созданных на конечных серверах, является несовместимым с передачей сообщений через данный коннектор, потребуется либо вручную удалить эти серверы из списка, либо вручную настроить другой коннектор.
Второе исключение, относящееся к наследуемым параметрам, отображается на вкладке Remote Bridgehead (см. рис 13.2). Exchange Server выводит все виртуальные серверы SMTP в качестве конечных серверов. Если виртуальный сервер SMTP не должен являться конечным сервером, потребуется либо удалить этот сервер из списка вручную, либо вручную же настроить коннектор.
Примечание. Если рассматриваемая организация Exchange содержит серверы Exchange 5.5, и эти серверы расположены внутри отдельного домена Microsoft Windows NT 4, можно подключить коннектор Routing Group Connector как учетную запись в домене NT 4. Помните, что коннектор Routing Group Connector выглядит как коннектор сайта в организации Exchange 5.x, и что он функционирует таким же образом.
(рис 13.2) Указание серверов, которые могут отправлять электронную почту через рассматриваемый коннектор(рис 13.1) Указание конечных серверов для рассматриваемого коннектораКоннектор Routing Group Connector использует сервер-мост, выступающий в роли шлюза, через который сообщения входят и выходят из группы маршрутизации. Коннектор RGC обеспечивает определенный уровень отказоустойчивости, разрешая использовать несколько исходных и конечных серверов-мостов. Серверы-мосты используются одним из трех способов.
Сервер-мост не назначается, и все серверы в группе маршрутизации функционируют в качестве серверов-мостов для передачи сообщений.
Назначается один сервер-мост, и вся электронная почта, направленная в другие группы маршрутизации, проходит через этот сервер. Это позволяет администратору осуществлять тщательный контроль над конфигурацией обмена сообщениями.
Используются несколько серверов-мостов, и вся электронная почта проходит через один из назначенных серверов. Такая конфигурация обеспечивает преимущества, заключающиеся в распределении нагрузки и отказоустойчивости. Если один сервер-мост недоступен для передачи сообщений, то эту функцию сможет выполнять другой доступный сервер.
Примечание. В Microsoft рекомендуют наличие канала связи с пропускной способностью не менее 64 Кбит/с, обеспечиваемого коннектором Routing Group Connector. Кроме того, в настоящий момент невозможно использовать шифрование между серверами-мостами.
Пример из практики.Обработка IP-адресов конечного сервера для серверов-мостов
Когда сервер-мост (BHS), на котором расположен коннектор Routing Group Connector, принимает сообщение, направленное на сервер в другой группе маршрутизации, сервер BHS предпринимает некоторые действия для обработки IP-адреса конечного сервера BHS. Сервер BHS соединяется с DNS и осуществляет попытку обработки IP-адреса адресной записи (A) конечной машины. При наличии нескольких записей DNS учитывает значения предпочтений при выборе BHS для обработки. При использовании Windows DNS все Windows-серверы автоматически регистрируют А-записи в DNS. Если А-записи не существует, сервер BHS пытается обработать IP-адрес с помощью процедуры разрешения имен NetBIOS.
Дополнительная информация. Чтобы узнать больше о системе DNS и Windows Server 2003, обратитесь к книгам "Microsoft Windows Server 2003. Справочник администратора" авторов Чарли Рассела, Шарон Кроуфорд и Джейсона Джеренд (издательство "Эком", 2004 г.) и "Active Directory для Microsoft Windows Server 2003. Справочник администратора" авторов Стейна Реймера и Майка Малкера (издательство "Эком", 2004 г.).
Создание коннектора группы маршрутизации
Чтобы создать новый коннектор Routing Group Connector, щелкните правой кнопкой мыши на контейнере Connectors (Коннекторы), расположенном под контейнером группы маршрутизации в оснастке Exchange System, наведите указатель мыши на пункт New (Создать), а затем выберите Routing Group Connector (Коннектор группы маршрутизации). На вкладке General (Общие) введите имя коннектора, после чего выберите группу маршрутизации, с которой необходимо соединить данный коннектор (см. рис 13.3).
(рис 13.3) Вкладка General (Общие) окна свойств коннектора Routing Group ConnectorКроме этого, можно выбрать опцию Any Local Server Can Send Mail Over This Connector (Любой локальный сервер может отправлять почту через этот коннектор) или опцию These Servers Can Send Mail Over This Connector (Эти серверы могут отправлять почту через данный коннектор). Первая опция используется по умолчанию и позволяет любому серверу в группе маршрутизации использовать коннектор для отправки сообщений, направленных на сервер в другой группе маршрутизации. Вторая опция позволяет зарезервировать коннектор для определенных виртуальных серверов в группе маршрутизации. Выбор этой опции позволяет указать виртуальные серверы в группе маршрутизации, которые могут использовать данный коннектор.
Совет. Не забудьте выбрать виртуальный сервер, который будет отправлять электронную почту в конечную группу маршрутизации. Предположим, что имеется группа внешних пользователей, отправляющих свои сообщения в организацию с использованием технологии Transport Layer Security (TLS), и что администратор настроил виртуальный сервер SMTP для принятия электронной почты по второму IP-адресу через порт 25. Этот виртуальный сервер SMTP требует сертификат для аутентификации. Теперь предположим, что в рассматриваемой локальной сети такие настройки для локальных пользователей отсутствуют. Если данный виртуальный сервер будет выбран в качестве единственного сервера, осуществляющего отправку электронной почты через создаваемый коннектор Routing Group Connector, то сообщения, отправляемые локальными пользователями, будут отклоняться, так как каждое сообщение будет возвращаться на второй IP-адрес сервера, и SMTP-сервер
будет ожидать использования TLS и сертификатов. В этой ситуации необходимо убедиться, что данный виртуальный сервер не выбран для коннектора Routing Group Connector.
Вкладка Remote Bridgehead (Удаленный сервер-мост)
На вкладке Remote Bridgehead (см. рис 13.2) указывается один или несколько серверов в удаленной группе маршрутизации, функционирующих в качестве серверов-мостов. Коннектор будет пытаться установить соединение с каждым целевым сервером перед отправкой сообщений. Соединение с серверами осуществляется упорядоченно, начиная с сервера, находящегося вверху списка. Кроме того, если на конечном сервере настроено несколько виртуальных серверов SMTP, понадобится выбрать тот виртуальный сервер, который позволит отправлять сообщения через настраиваемый коннектор.
Вкладка Delivery Restrictions (Ограничения доставки)
Вкладка Delivery Restrictions (см. рис 13.4) позволяет указать, кто может использовать данный коннектор. Здесь есть два варианта: либо указать необходимость отклонения всех сообщений, за исключением тех, что получены от пользователей, входящих в список избранных пользователей, либо указать, что следует принимать все сообщения, за исключением элементов, полученных от членов списка избранных пользователей. Вместо этого можно указать только пользователей и контакты с доступом к почте.
(рис 13.4) Вкладка Delivery Restrictions (Ограничения доставки) окна свойств коннектора Routing Group ConnectorСовет. Чтобы выбрать нескольких пользователей из Active Directory, выделите первого пользователя в списке Select Recipient (Выбор пользователей), после чего с помощью клавиш "вверх" и "вниз" выберите группу смежных пользователей. Чтобы выбрать группу несмежных пользователей в списке, удерживайте клавишу Ctrl, после чего с помощью мыши выделите всех пользователей, которых необходимо добавить в список.
Пример из практики.Присвоение приоритета сообщениям, получаемым от определенных пользователей
При использовании совместно со стоимостью, присвоенной коннектору, вкладка Delivery Restrictions (Ограничения доставки) позволяет присваивать более высокий приоритет сообщениям, отправляемым через коннектор Routing Group Connector определенной группой пользователей, по сравнению с сообщениями, отправляемыми другими пользователями. Предположим, что сотрудники отдела продаж и подразделение предпродажной поддержки находятся в двух различных городах, которые представляют собой две различные группы маршрутизации. Также предположим, что большая часть заказов в организации поступает по телефону, и что при возникновении у сотрудника отдела продаж вопроса технического характера о том или ином продукте ему нужно отправлять свой вопрос по электронной почте сотрудникам предпродажной поддержки. В этой ситуации настраиваются два коннектора Routing Group Connector. Первый из них будет коннектором со стоимостью 100, предназначенным для приема сообщений
от любого пользователя и дальнейшей их передачи соответствующим образом, однако он будет отклонять сообщения, поступающие от сотрудников отдела продаж. Второй коннектор будет иметь стоимость, равную 1, и будет отклонять всех пользователей, за исключением сотрудников отдела продаж, указанных на вкладке Delivery Restrictions (Ограничения доставки). Такой подход к передаче сообщений обеспечит более быструю отправку сообщений в другую группу маршрутизации от сотрудников отдела продаж по сравнению с сообщениями от других пользователей.
Вкладка Delivery Options (Параметры доставки)
Вкладка Delivery Options (Параметры доставки), показанная на рис 13.5, позволяет указывать, когда сообщения могут проходить через коннектор. Эта возможность особенно полезна при использовании коннектора на низкоскоростном или ненадежном канале связи WAN, либо в соединении, стоимость использования которого варьируется в зависимости от времени дня. Выбрав опцию Use Different Delivery Times For Oversize Messages (Использовать другое время для доставки больших сообщений), можно удерживать сообщения большого размера до установленного времени, когда через коннектор проходит небольшой объем трафика.
(рис 13.5) Вкладка Delivery Options (Параметры доставки) окна свойств коннектора Routing Group Connector
Вкладка Content Restrictions (Ограничения содержания)
На вкладке Content Restrictions (Ограничения содержания), показанной на рис 13.6, указываются приоритеты, тип и размеры сообщений, которые могут проходить через данный коннектор RGC. Область Allowed Priorities (Разрешенные приоритеты) позволяет выбрать приоритет сообщения для передачи через соединение. Это прекрасный способ настройки коннекторов, специально предназначенных, например, для передачи сообщений с высоким приоритетом. В области Allowed Types (Разрешенные типы) опция System Messages (Системные сообщения) позволяет осуществлять передачу всех не пользовательских сообщений, включая репликацию каталогов, репликацию общих папок, мониторинг сети, а также сообщения об успешной или неудачной доставке. В области Allowed Sizes (Разрешенные размеры) задается ограничение размера передаваемых сообщений.
(рис 13.6) Вкладка Content Restrictions (Ограничения содержания) окна свойств коннектора Routing Group ConnectorПример из практики.Сравнение коннекторов Routing Group Connector и Exchange 5.5 Site Connector
Коннектор Routing Group Connector использует SMTP в качестве транспортного протокола, что обеспечивает больший уровень отказоустойчивости, нежели в случае с коннектором Exchange Server 5.x при работе в средах с низкоскоростным каналом связи и высоким уровнем задержек. Коннектор Site Connector использует TCP для инициирования и поддержки соединения с целевым сервером-мостом, после чего использует удаленные вызовы процедур для запуска функций коннектора. Удаленные вызовы процедур (RPC) вызывают большой объем трафика и требуют высокую пропускную способность и степень постоянства соединения для выполнения своих задач. Напротив, несмотря на то что коннектор Routing Group Connector передает команды SMTP через сеанс TCP, команды не отправляют удаленные вызовы процедур на целевой сервер. Вместо этого SMTP передает последовательность небольших команд, устойчивых к более низким скоростям передачи данных и уровню непостоянности соединения по сравнению с удаленным
вызовом процедур. Для получения более подробной информации об SMTP обратитесь к лекции 7 курса "Переход к Microsoft Exchange Server 2003 и поддержка Outlook".
При обновлении сервера-моста Exchange 5.5, использующего коннектор Site Connector, станет видно, что коннектор в процессе обновления сменится на коннектор Routing Group Connector, осуществляющий через RPC соединение с серверами 5.x, но по-прежнему использующий SMTP для соединения с другими серверами Exchange 2003.
Коннектор Routing Group Connector обеспечивает две возможности, отсутствующие в коннекторе Site Connector в Exchange Server 5.5. Во-первых, возможность создания расписания для определения того, когда сообщения передаются через коннектор, во-вторых, назначение передачи сообщений по их размеру (например, всех сообщений, чей размер превышает 2 Мб), чтобы эти сообщения передавались в то время, когда канал связи используется наименее активно.
Коннектор SMTP
Хотя RGC использует SMTP в качестве собственного механизма передачи, Exchange Server 2003 также предоставляет коннектор SMTP, используемый для связи групп маршрутизации. Коннектор SMTP можно использовать вместо RGC, принимая во внимание три следующих момента.
Коннектор SMTP обладает более гибкими настройками, нежели RGC, и обеспечивает больше возможностей для тонкой настройки соединения. Коннектор SMTP также обеспечивает возможность выполнения аутентификации перед отправкой электронной почты, шифрования TLS и удаления электронной почты из очередей на удаленных серверах.
Коннектор SMTP всегда использует протокол SMTP. При соединении сервера Exchange 2003 с сервером Exchange 5.5 Server коннектор Routing Group Connector использует для связи удаленный вызов процедур, так как ему не известно, настроен ли сервер Exchange 5.5 Server на работу с SMTP, в отличие от ситуации с предыдущими версиями Exchange, где эта информация предоставлялась службой Internet Mail Service. Нельзя заставить RGC работать через SMTP, поэтому вместо него можно использовать коннектор SMTP.
Коннектор SMTP также позволяет соединять независимые леса внутри организации для обеспечения передачи сообщений.
Даже несмотря на то что коннектор SMTP можно использовать для соединения групп маршрутизации в определенных обстоятельствах, его основным назначением в Exchange Server 2003 является обеспечение связи с внешними средами (соединение с интернетом либо другой средой, отличной от Exchange). Как и коннектор Routing Group Connector, данный коннектор является однонаправленным, поэтому его необходимо настраивать по обе стороны соединения.
При подключении к интернету коннектор SMTP использует узел диспетчеризации (smart-host) (еще один сервер SMTP, на который передаются сообщения для маршрутизации) или MX-записи в DNS для маршрутизации в следующем сегменте. При внутреннем конфигурировании между двумя группами маршрутизации данный коннектор передает информацию о состоянии связи между группами маршрутизации, но попрежнему зависит от MX-записей в DNS для получения информации по следующему сегменту.
Коннектор SMTP отличается от Routing Group Connector тем, что он может использовать шифрование и аутентификацию. Если для некоторых сообщений требуется шифрование, то следует использовать SMTP Connector. Еще одним свойством этого коннектора является аутентификация в удаленном домене перед отправкой в него сообщения. Подобно Routing Group Connector, SMTP Connector позволяет задавать время отправки сообщений, чтобы использовать периоды неактивного использования пропускной способности.
SMTP Connector позволяет создавать области действия коннектора (Connection scope), посредством которых только определенные серверы организации Exchange смогут использовать данный коннектор. Вместо ограничения коннектора серверами, указанными в определенной области действия, теперь существует возможность выбора между использованием этого коннектора всеми серверами организации или только серверами локальной группы маршрутизации (см. рис 13.7).
И, наконец, SMTP Connector потребуется, если пропускная способность меньше 64 Кбит/с и больше 16 Кбит/с. Если единственной причиной выбора SMTP Connector является нежелание использовать протокол SMTP между группами маршрутизации, то лучше выбрать коннектор Routing Group Connector. Этот коннектор использует SMTP в качестве своего транспортного протокола.
Создание коннектора SMTP Connector
Создание коннектора SMTP происходит таким же образом, как и создание коннектора Routing Group Connector: щелкните правой кнопкой мыши на соответствующей группе маршрутизации, укажите пункт New (Создать) и выберите пункт SMTP Connector. После этого на экране появится страница свойств данного коннектора с окном вкладки General (см. рис 13.8), где указывается имя коннектора и определяются опции, относящиеся к использованию системы DNS. Опция Use DNS To Route To Each Address Space On This Connector (Использовать DNS для маршрутизации в каждое адресное пространство через этот коннектор) позволяет коннектору работать с DNS, чтобы выполнять прямые соединения с целевым сервером SMTP, основываясь на MX-записях и значениях предпочтений. Но если нужно направить почту через центральный узел по той причине, что несколько прямых соединений занимают слишком много времени или требуют слишком больших затрат, тогда следует выбрать
опцию Forward All Mail Through This Connector To The Following Smart Host (Направлять всю почту через этот коннектор на следующий узел диспетчеризации). Здесь вводится либо полностью определенное доменное имя (FQDN) этого узла диспетчеризации, либо его IP-адрес. Если принято решение ввести IP-адрес, то нужно поместить его в прямоугольные скобки, например [192.168.2.200]. Кроме того, указанное значение заменит значение параметра Smart Host (Узел диспетчеризации) в диалоговом окне Advanced Delivery (Дополнительные параметры доставки), которое можно отобразить, нажав кнопку Advanced (Дополнительно) на вкладке Delivery (Доставка) страницы свойств виртуального сервера SMTP.
(рис 13.8) Настройка области действия коннектора SMTP Connector(рис 13.7) Вкладка General (Общие) страницы свойств коннектора SMTP ConnectorВкладка Delivery Options (Параметры доставки)
Вкладка Delivery Options страницы свойств коннектора SMTP содержит одно средство, которого нет на странице свойств RGC-коннектора: Queue Mail For Remote Triggered Delivery (Направлять сообщения в очередь для запускаемой удаленной доставки). Это свойство позволяет клиентам периодически подсоединяться к рассматриваемому серверу Exchange и загружать с него сообщения. Чтобы сделать этот процесс защищенным, клиенты организации осуществляют подключение с помощью учетной записи в рассматриваемом домене. После нажатия кнопки Add (Добавить) для указания учетных записей, авторизованных для использования команд TURN/ATRN, станет видно, что доступны только локальные учетные записи домена. Это ограничение возникает из-за того, что именно рассматриваемый сервер Exchange содержит почту для чтения другими пользователями, и поэтому они должны быть аутентифицированы в данном домене. Поэтому необходимо указать, какие учетные записи Active Directory
позволяют загружать сообщения электронной почты. Чтобы запустить загрузку с сервера Exchange Server 2003, клиент должен выполнить команду TURN.
Вкладка Advanced (Дополнительно)
На рисунке 13.9 показана вкладка Advanced страницы свойств коннектора SMTP с важными параметрами конфигурирования, которые необходимо учесть при установке данного коннектора. Во-первых, здесь настраивается коннектор на отправку команды HELO вместо EHLO. Традиционно первой командой, которую отправляет клиент SMTP при подсоединении к серверу SMTP, является команда HELO. Эта команда выполняет запуск сеанса и идентифицирует отправителя предстоящего сообщения. По умолчанию Exchange Server 2003 отправляет команду EHLO, которая не только выполняет запуск, но также указывает, что данный сервер Exchange может использовать расширенный набор команд SMTP (ESMTP). Не все серверы SMTP поддерживают обмен информацией с использованием расширенного набора команд. Если нужно подключаться к серверу SMTP, который не воспринимает команды ESMTP, включите эту опцию, чтобы Exchange Server отправлял команду запуска HELO.
Список команд SMTP приведен в лекции 7 курса "Переход к Microsoft Exchange Server 2003 и поддержка Outlook".
(рис 13.9) Вкладка Advanced страницы свойств коннектора SMTPКроме того, на вкладке Advanced есть кнопка Outbound Security (Внешняя безопасность), предназначенная для представления аутентификационных данных в удаленном домене. Опция Do Not Send ETRN/TURN (Не отправлять ETRN/TURN) запрещает коннектору запрашивать вывод из очереди удаленного сервера. Эта опция включена по умолчанию. Она позволяет использовать коннектор только для базовых операций отправки и приема сообщений через протокол SMTP; запросы удаленного вывода из очереди не допускаются. Скорее всего, эту опцию потребуется использовать в большинстве случаев.
Если требуется отправить сообщение о выводе из очереди вместе с другими сообщениями, передаваемыми на сервер SMTP, выберите опцию Request ETRN/TURN When Sending Messages (Запрос ETRN/TURN при отправке сообщений). Используя эту опцию, можно также запрашивать вывод из очереди в определенные моменты времени, для чего нужно включить опцию Additionally Request Mail At Specified Times (Дополнительно запрашивать почту в указанные моменты времени) и затем выбрать время вывода из очереди в поле Connection Time (Время соединения). Эти параметры применяются, например, при подключении рассматриваемого сервера Exchange к другому серверу Exchange через телефонные линии. После соединения сервер Exchange будет отправлять любую почту, предназначенную для принимающего сервера. В течение одного сеанса на другой сервер Exchange будет отправлен запрос вывода из очереди любых сообщений, которые направлены в почтовые ящики, находящиеся в рассматриваемой среде Exchange.
Чтобы запросить вывод из очереди на сервере, отличном от сервера, на который было отправлено сообщение, выберите опцию Request ETRN/TURN From Different Server (Запрос ETRN/TURN с другого сервера) и затем введите имя этого сервера. Используйте эту опцию, если имеется один сервер, который будет работать с исходящими сообщениями, и другой сервер, который будет работать с входящими сообщениями в рассматриваемой организации.
Если нужно, чтобы вывод из очереди происходил в определенные моменты времени, щелкните на ниспадающем списке Connection Time (Время соединения) и выберите одну из принятых по умолчанию (стандартных) опций или нажмите кнопку Customize (Настроить) и укажите нужный временной график. Этот параметр, например, используется в том случае, если рассматриваемый сервер Exchange не имеет постоянного соединения с интернетом, но существует надобность периодически считывать почту, поступающую от поставщика услуг интернета (ISP), посредством телефонного соединения.
И, наконец, в области Specify How To Request That Remote Servers Dequeue Mail (Выберите запрос, чтобы удаленные серверы выполняли вывод почты из очереди) выберите опцию Issue ETRN (Передать команду ETRN) или опцию Issue TURN (Передать команду TURN). Для использования ETRN необходимо наличие статического IP-адреса, в то время как при использовании TURN IP-адрес не обязательно должен быть статическим. Кроме того, для ETRN требуется указание домена для вывода из очереди, поэтому, нажав кнопку Domains (Домены), следует при необходимости указать имя локального домена, в котором требуется выполнить вывод из очереди.
Вкладка Address Space (Адресное пространство)
Подсоединяясь к внешней системе, необходимо определить адресное пространство, используемое рассматриваемым коннектором. Адресное пространство – это набор связанной с коннектором или шлюзом адресной информации, где указываются домены, в которые этот коннектор будет передавать сообщения. Как правило, адресное пространство – это подмножество пространства полных адресов; обычно это просто имя домена.
Адресное пространство определяется в окне вкладки Address Space страницы свойств данного коннектора (см. рис 13.10). Если данный коннектор SMTP будет использоваться для интернет-почты организации, укажите "*" в качестве адресного пространства. Это означает, что допускается любая строка символов, и что сообщения можно направлять через этот коннектор в любой домен.
(рис 13.10) Вкладка Address Space (Адресное пространство) страницы свойств коннектора SMTPАдресные пространства могут указываться для адресов SMTP, X.400, Lotus cc:Mail, Microsoft Mail, Lotus Notes и Novell GroupWise. Если используемое адресное пространство не относится к одному из этих типов, выберите опцию Other (Другой) и введите описание адресного пространства.
Передачу сообщений можно запретить, если не включить опцию Allow Messages To Be Relayed To These Domains (Разрешить передачу сообщений в эти домены). Тем самым незапрашиваемые сообщения электронной почты не будут направлены через рассматриваемый сервер SMTP в интернет. Однако если данный коннектор SMTP используется как некая точка диспетчеризации между двумя внешними системами SMTP, следует отметить эту опцию и добавить к адресному пространству целевое имя домена, в который должны передаваться сообщения.
Наконец, если требуется ограничить использование коннектора только теми серверами, которые входят в одну группу маршрутизации, выберите опцию Routing Group (Группа маршрутизации) в области Connector Scope (Область действия коннектора). По умолчанию все серверы организации могут использовать данный коннектор. Поскольку предполагается, что между серверами, не входящими в одну группу маршрутизации, существует либо медленное, либо ненадежное соединение, то имеет смысл активизировать опцию, чтобы серверы удаленных маршрутных групп не направляли сообщения в интернет или во внешние почтовые системы через этот коннектор.
Пример из практики.Настройка сервера SMTP как сервера диспетчеризации
Предположим, что рассматриваемая организация известна на рынке под двумя различными именами trainsbydave.com и contoso.com. Кроме того, все сообщения должны поступать в организацию через SMTP Connector на сервер, который является членом домена oaktree.com. Следующие шаги позволят обеспечить правильность маршрутизации всех сообщений по обоим доменным именам.
Введите A-запись в DNS для имени узла и IP-адрес данного сервера.
Введите две MX-записи в DNS, по одной для каждого домена, причем каждая запись должна указывать IP-адрес данного сервера.
Создайте коннектор SMTP Connector для домена trainsbydave.com.
Введите contoso.com как допустимое адресное пространство.
Включите опцию Allow Messages To Be Relayed To These Domains (Разрешить ретрансляцию сообщений на эти домены).
Создайте MX-запись и A-запись во внутренних таблицах DNS, которые указывают внутренний сервер SMTP, обслуживающий домен contoso.com.
Теперь сообщения, адресованные в домен contoso.com или trainsbydave.com, будут направляться на один и тот же сервер, а сообщения, адресованные в sugarmaple.com, будут передаваться на сервер Exchange contoso.com.
Вкладка Connected Routing Groups (Подсоединенные группы маршрутизации)
Если адресное пространство не настроено в окне вкладки Address Space, то следует использовать вкладку Connected Routing Groups для указания групп маршрутизации, подключаемых к локальной группе маршрутизации. Это нужно для информирования коннектора о том, какие группы маршрутизации к нему примыкают, чтобы включить внутреннюю маршрутизацию сообщений. Группы маршрутизации записаны в составе групп администрирования, поэтому всегда необходимо выбрать соответствующую группу администрирования. Если рассматривается небольшая организация с одной группой маршрутизации и одной группой администрирования, введите информацию об адресном пространстве в окне вкладки Address Space и не заполняйте эту вкладку.
Администрирование состояния связи
В этом параграфе будет рассказано о том, как управлять информацией о состоянии связи в системе Exchange. (О работе протокола состояния связи см. в лекции 3.)
Администрирование информации о состоянии связи выполняется внутри контейнера Queues (Очереди) сервера и заключается, в основном, в выполнении функций управления очередями. Мы сконцентрируем внимание на протоколе SMTP (см. рис 13.11), поскольку он используется и коннектором Routing Group Connector (RGC), и коннектором SMTP.
(рис 13.11) Очереди SMTP в окне оснастки Exchange SystemПрежде чем начать обсуждение, рассмотрим топологию сети, которая будет использоваться в качестве примера. На рисунке 13.12 показано, что наша вымышленная компания hr.trainsbydave.com имеет офисы в четырех городах: Folsom, Tucson, Minneapolis и Indianapolis. Здесь также видно, что в каждом городе имеется по одному пользователю, которые будут использоваться нами для иллюстрации обмена сообщениями и соединений. Предполагается, что значение стоимости для каждого коннектора равно 1. Кроме того, коннекторам групп маршрутизации присвоены имена соответствующих штатов, например, California Arizona RGC для канала связи между городами Folsom (шт. Калифорния) и Tucson (шт. Аризона). И, наконец, серверы именуются по их местонахождению, то есть имеются четыре сервера: Tucson, Folsom, Minneapolis и Indianapolis.
Важно отметить, что вид общей топологии маршрутизации для каждого сервера будет различным, поскольку не все маршруты или коннекторы отображаются в окне оснастки Exchange System для любого заданного сервера. Прежде чем продолжить чтение, ознакомьтесь с этой топологией.
Когда пользователь ssmith отправляет сообщение пользователю benglish, оно должно пройти через сервер Folsom. Сообщение не проходит через Minneapolis потому, что суммарная стоимость данного маршрута не является минимальной. По умолчанию используется маршрут с минимальной стоимостью, то есть из Indianapolis в Folsom и далее в Tucson, с суммарной стоимостью, равной 2.
(рис 13.12) Топология маршрутизации для hr.trainsbydave.comТеперь, когда вы ознакомились с данной вымышленной компанией, рассмотрим работу протокола состояния связи (Link State) при отключении какого-либо канала. Мы рассмотрим четыре различных сценария и покажем, как происходит администрирование протокола Link State.
Сценарий 1: недоступен первый канал связи
Сообщение, отправленное пользователем benglish пользователю ssmith, должно пройти через два отдельных канала (Indianapolis/Folsom и Folsom/Tucson) и через три различных сервера (Tucson, Folsom и Indianapolis). Однако предположим, что сервер Folsom отключен от сети по какой-либо причине, и что benglish отправляет сообщение ssmith. Как видно из рисунка 13.13, это сообщение сначала поступает в исходящую очередь коннектора RGC.
Управление сообщениями в исходящих очередях
В Microsoft разработан удобный способ, позволяющий узнавать о проблемах, связанных с очередью, – значки. Как показано на рисунке 13.13, значок в области результатов (область справа) очереди группы маршрутизации California Arizona сменился для отображения того, что очередь находится в состоянии повтора (небольшая синяя стрелка на значке).
(рис 13.13) Сообщение в исходящей очереди California Indiana RGC (Routing Group Connector)Управление очередями и сообщениями, которые в них находятся, можно осуществлять несколькими способами. Во-первых, можно "заморозить" (задержать) очередь, щелкнув на ней правой кнопкой мыши и выбрав команду Freeze (Задержать). Если выполнить это действие, то все сообщения так и останутся в очереди, даже если канал связи снова начнет работать. Задержание очереди может стать хорошим способом отключения попыток доставки сообщения во время разрешения каких-либо возникших проблем. Если дважды щелкнуть на очереди, чтобы отобразить находящиеся в ней сообщения, станет понятно, что можно задерживать и отдельные сообщения. Замораживание сообщения пригодится в том случае, если известно, что конкретное сообщение в очереди имеет достаточно большой размер или маленькую важность, и что его можно отложить до тех пор, пока не будут отправлены все остальные сообщения. Очередь или отдельное сообщение размораживаются посредством щелчка правой кнопкой мыши
на объекте и выбора команды Unfreeze (Разморозить). При размораживании очереди или сообщения немедленно возобновляется доставка сообщений.
Кроме этого, существует возможность удаления любого отдельного сообщения в исходящей очереди. Для этого щелкните правой кнопкой мыши на данном сообщении и выберите команду Delete (Удалить) (либо просто щелкните на сообщении и нажмите клавишу [Delete]). При этом можно указать, требуется или не требуется отправка создателю сообщения отчета о невозможности доставки.
Возобновление нормальной работы
Один лишь тот факт, что сообщения отправлялись, не означает, что информация о состоянии связи снова отражает нормальное состояние. После того как сервер снова подсоединен и начал работу, может начаться передача сообщений, но значок коннектора все еще будет указывать, что канал находится в состоянии повторения попыток. Здесь не о чем беспокоиться. Подождите несколько минут и снова проверьте очередь; после этого обычно значок указывает, что очередь находится в нормальном состоянии.
Сценарий 2: канал получателя недоступен
Мы разобрались, что происходит с сообщением, если становится недоступным первый сегмент. Теперь рассмотрим, что произойдет, если станет недоступным последний сегмент. В этом сценарии пользователь benglish отправляет сообщение пользователю ssmith, но на этот раз нет доступа к серверу Indianapolis.
Когда benglish отправляет сообщение, оно маршрутизируется из Tucson в Folsom, где ожидает, пока не заработает сервер Indianapolis или пока не истечет срок годности сообщения; в последнем случае автору будет отправлен отчет о невозможности доставки (NDR).
Сценарий 3: доступен альтернативный маршрут с более высокой стоимостью
Одной из возможностей протокола состояния связи является его способность определять, что часть полного маршрута неисправна, и перенаправлять сообщение через канал с большей стоимостью. Однако, как говорилось в лекции 3, усовершенствования в протоколе состояния связи в Exchange Server 2003 обуславливают тот факт, что связи не помечаются как недоступные, если конкретная связь является единственной связью между двумя местоположениями, или если состояние связи постоянно изменяется.
Для данного сценария увеличим до 100 единиц стоимость коннектора между серверами Folsom и Indianapolis. На рисунке 13.14 показана новая топология. Теперь предположим, что пользователь benglish в Tucson отправляет сообщение пользователю ssmith в Indianapolis.
При заданных стоимостях коннекторов обычный маршрут этого сообщения будет проходить через Minneapolis. Предположим, что канал между серверами Minneapolis и Folsom отключен. В результате сообщения будут маршрутизироваться через канал с более высокой стоимостью – между Indianapolis и Folsom.
Примечание. Если вы не знаете, по какому маршруту направлено сообщение, отследите путь этого сообщения. Подробнее об этом рассказывается в лекции 6 "Функциональность, безопасность и поддержка Exchange Server 2003"
(рис 13.14) Новая топология для hr.trainsbydave.com
Сценарий 4: сообщение имеет несколько получателей
Если сообщение направлено как внутренним, так и внешним получателям, то создается временная очередь для каждого внешнего доменного имени, а также для каждого внутреннего сервера Exchange Server 2003, на котором находится получатель данного сообщения. Предположим, что сообщение отправлено в группу вымышленных доменных имен. При отправке сообщения расширенный механизм очередей создает необходимые очереди. Протокол состояния связи не используется для этих выходных очередей SMTP к внешним серверам. Он должен только поддерживать текущую информацию о состоянии связи для внутренних серверов.
Заключение
В этой лекции рассказывалось о том, как осуществляется администрирование и управление коннекторами Routing Group Connector и SMTP Connector. Кроме этого, показано, как информация о состоянии связи позволяет осуществлять маршрутизацию сообщений в различных ситуациях. Например, было показано, что протокол состояния связи может определять, когда канал связи находится в нерабочем состоянии, и удерживать сообщения до тех пор, пока канал вновь не заработает.
Протокол состояния связи является одной из наиболее мощных возможностей Exchange Server 2003. Еще одной важной особенностью Exchange Server 2003 является возможность сосуществования с серверами Exchange 5.x. Если в организации используется операционная система Windows NT 4 и Exchange 5.5, необходимо разрешить вопросы, связанные с обновлением и сосуществованием с Windows Server 2003 и Exchange Server 2003, в процессе перехода к более новым версиям продуктов. Эти вопросы обсуждаются в курсе "Переход к Microsoft Exchange Server 2003 и поддержка Outlook".
