Как использовать управляемую топологию, реализованную в пакете SP1

Пользователи системы Exchange Server 2003 могут устанавливать соединения клиента Microsoft Office Outlook 2003 с сервером Exchange с помощью удаленного вызова процедур интерфейса Messaging API (MAPI), передаваемого по протоколу HTTP (вместо термина Messaging API Remote Procedure Call over HTTP часто употребляется сокращение RPC over HTTP). Когда корпорация Microsoft выпустила в свет Exchange 2003, пользователи восприняли эту возможность с большим энтузиазмом, поскольку теперь они могли устанавливать соединения Outlook и Exchange практически в любых сетях. Но эта функция была наделена довольно слабыми средствами административного управления. Первоначальная настройка конфигурации требовала больших трудозатрат, и при этом администратору непросто было выполнить ее без ошибок; настройку многих разделов реестра приходилось выполнять на proxy-серверах RPC, на контроллерах доменов (domain controller, DC) и на серверах глобальных каталогов (Global Catalog, GC). Более того, со значительными неудобствами были сопряжены и процедуры оперативного администрирования, особенно при добавлении либо удалении серверов Exchange. Сведения об общих требованиях, а также о том, какие разделы реестра необходимо настраивать для использования технологии RPC over HTTP еще до установки Exchange 2003 Service Pack 1, SP1, можно почерпнуть из опубликованной в журнале Windows IT Pro /RE статьи «Удаленный доступ к Exchange 2003 по каналам HTTP», № 7 за 2003 год. О том, как выявлять неполадки в соединениях RPC по HTTP, рассказано в статье «Поиск неисправностей в соединениях RPC по HTTP», № 6 за 2004 год.

Exchange 2003 SP1 позволяет решить эти проблемы. Теперь для реализации технологии RPC по HTTP можно воспользоваться так называемой управляемой топологией RPC over HTTP, а такие оперативные изменения среды, как добавление или удаление серверов, автоматически отражаются в настройках.

Изменения в архитектуре

До выпуска Microsoft пакета Exchange 2003 SP1 под термином «proxy-сервер RPC» было принято понимать сервер Windows Server 2003 с установленными на нем (обычно с помощью оснастки Add/Remove Windows Components, доступной через модуль панели управления Add or Remove Programs) средствами RPC over HTTP. На proxy-сервере RPC не нужно было устанавливать систему Exchange 2003, — как правило, этого и не делали.

Клиент Outlook 2003 устанавливал соединение с proxy-сервером RPC (который часто располагался по другую сторону брандмауэра), а proxy-сервер связывался с контроллером домена или с сервером глобального каталога, выполнял аутентификацию запроса пользователя на установление соединения, а затем выступал в роли посредника при установлении соединения клиента Outlook 2003 с соответствующим сервером почтовых ящиков Exchange 2003, где и выполнялись последующие операции по аутентификации в системе Exchange. Если операции по аутентификации завершались успешно, все последующее взаимодействие между клиентом Outlook и Exchange на протяжении данного сеанса связи осуществлялось через proxy-сервер RPC. Вместе с первоначальным запросом на установление соединения сервер почтовых ящиков Exchange 2003 предоставлял клиенту Outlook 2003 сформированную на базе глобального списка адресов (Global Address List, GAL) ссылку на сервер глобального каталога. Клиент Outlook не мог связываться с сервером глобального каталога напрямую, поэтому соединение от имени данного клиента Outlook устанавливал proxy-сервер RPC, как показано на рис. 1. При работе в таком режиме администратор должен был конкретно задавать те серверы глобальных каталогов, которые proxy-сервер RPC мог использовать для обеспечения доступа к списку GAL по каналам RPC по HTTP. Для этого требовалось открыть реестр proxy-сервера RPC и внести в раздел HKEY_LOCAL_MACHINESOFTWARE MicrosoftRpcRpcProxyValid Ports детали соединений и портов соответствующих серверов глобального каталога. Затем нужно было создать параметр реестра HKEY_LOCAL_MACHINESYSTEM CurrentControlSetServicesNTDSParametersNSPI Interface Protocol Sequences для серверов глобального каталога и модифицировать его значение так, чтобы обеспечить соединение RPC over HTTP с proxy-сервером RPC.

Администраторам систем Exchange 2003 SP1 с управляемой топологией RPC over HTTP уже не требуется модифицировать эти параметры. Достаточно соблюдения некоторых предварительных условий. Для формирования нужной конфигурации необходимо разместить на внешних серверах Exchange 2003 proxy-компоненты Windows 2003 RPC over HTTP. Тогда изображенный на рис. 1 proxy-сервер RPC, на котором выполняется только система Windows 2003, превращается в сервер, на котором функционируют и Windows 2003, и Exchange2003, как показано на рис. 2.

При использовании управляемой топологии RPC over HTTP раздел ValidPorts внешнего сервера Exchange 2003 (выполняющего функцию proxy-сервера RPC) не содержит каких-либо данных о конфигурации сервера глобального каталога. Когда внешний RPC-proxy-сервер Exchange 2003 от имени клиента Outlook устанавливает соединение с почтовым сервером Exchange 2003, в зависимости от того, какая версия системы Exchange 2003 установлена на почтовом сервере, происходит одно из двух событий.

Вариант первый: если на почтовом сервере выполняется система Exchange 2003 SP1, этот сервер определяет, что соединение с клиентом Outlook строится на основе технологии RPC over HTTP, поскольку запрос на соединение поступает от расположенного на внешнем сервере Microsoft IIS на конечную точку ncacn_http, расположенную на почтовом сервере. В этом случае почтовый сервер не направляет клиента Outlook непосредственно на сервер глобального каталога, а дает ему команду обратиться к размещенному на почтовом сервере proxy-серверу службы каталога Directory Service (DS), который от имени Outlook установит соединение с сервером глобального каталога. Эта новая функция системы Exchange 2003 SP1 изменяет систему приоритетов, в соответствии с которыми серверы глобальных каталогов назначаются клиентам RPC over HTTP.

Вариант второй: если на почтовом сервере работает система Exchange 2003 и модернизация до уровня SP1 пока не производилась, сервер вначале пытается в соответствии с обычной практикой направить клиента Outlook непосредственно на сервер глобального каталога. Клиент Outlook пытается связаться с сервером глобального каталога через размещенный на внешнем сервере Exchange 2003 proxy-сервер RPC, но, поскольку внешний сервер не имеет сведений о конфигурации, которые позволили бы установить соединение RPC over HTTP с каким-либо сервером глобального каталога, попытка установить соединение оказывается неудачной. Клиент Outlook вновь обращается к почтовому серверу с запросом об установлении соединения с сервером глобального каталога, но, поскольку почтовый сервер понимает, что первая попытка не увенчалась успехом, он приводит в действие посреднический механизм DS и обеспечивает доступ к серверу глобального каталога. Итак, оба описанных механизма позволяют получить нужный результат, однако второй механизм предполагает некоторую задержку, связанную с первой попыткой соединения. Поэтому наилучшее решение состоит в том, чтобы модернизировать до уровня SP1 сервер Exchange 2003, внешний сервер, почтовый сервер и внутренний сервер.

Управляемая топология RPC over HTTP

Обязательным условием использования реализованных в пакете SP1 обновлений средств автоматической настройки соединений по каналам RPC over HTTP является установка SP1 на внешнем сервере Exchange 2003. Запускать SP1 на почтовом сервере или на внутреннем сервере необязательно (однако не забывайте о том, что при использовании внутренних систем, не модернизированных до уровня SP1, после неудачной первой попытки установить соединение приводятся в действие посреднические механизмы).

На экране 1 показана новая закладка RPC-HTTP. Чтобы перейти на эту закладку из диалогового окна Properties сервера Exchange, нужно воспользоваться программой Exchange System Manager (ESM), установленной на сервере или рабочей станции Exchange 2003 SP1, где имеются средства административного управления Exchange2003 SP1.

Экран 1. Настройка свойств RPC over http

На первом этапе процедуры настройки нужно отметить все внутренние серверы организации, которые предстоит включить в управляемую топологию RPC over HTTP, и выбрать для каждого из этих серверов свойство RPC-HTTP back-end server. При этом нужно устанавливать в 0x20000000 атрибут Heuristics соответствующего почтового сервера Exchange 2003 в каталоге Active Directory (AD). Кроме того, нужно будет установить значение атрибута ServerRole почтового сервера равным 0, поскольку это внутренний сервер. Данную операцию необходимо выполнить для каждого почтового сервера, который вы хотите включить в управляемую топологию RPC over HTTP.

После настройки всех внутренних серверов можно переходить к внешним серверам, которые будут включены в управляемую топологию RPC over HTTP. Для выбора сервера, который решено использовать в качестве внешнего сервера Exchange и на который будет возложена функция посредника RPC, следует использовать диспетчер ESM. На этом сервере должна быть установлена система Exchange 2003 SP1 и он должен быть предварительно настроен как обычный внешний сервер; в противном случае вариант настройки в качестве внешнего сервера на закладке RPC-HTTP будет недоступным, как показано на экране 1. На закладке RPC-HTTP нужно выставить флажок RPC-HTTP front-end server и повторить эти действия для всех внешних серверов, которые будут использоваться в качестве proxy-серверов RPC. При выполнении перечисленных операций в атрибут Heuristics внешнего сервера будут внесены те же изменения, но атрибут ServerRole внешнего сервера будет иметь значение, равное 1.

После установки на внешних и внутренних серверах соответствующих атрибутов AD подготовка управляемой топологии RPC over HTTP, в сущности, завершена. Система Exchange 2003 SP1 включает в себя обновленную функцию System Attendant. Раз в 15 минут эта функция проверяет каталог AD на внешних серверах Exchange 2003, входящих в управляемую топологию RPC over HTTP, с тем чтобы обнаружить внутренние серверы со значением атрибута Heuristics, обеспечивающим их включение в управляемую топологию. На внешнем сервере функция System Attendant обновляет раздел ValidPorts для каждого обнаруженного ею внутреннего сервера, который является частью топологии. Изящество этого подхода становится очевидным при добавлении в среду новых внутренних серверов Exchange 2003. Как только вы выставите соответствующий флажок, указывающий на то, что данный сервер включается в управляемую топологию RPC over HTTP, внешние серверы автоматически обнаруживают этот внутренний сервер и обновляют конфигурацию. Подобным же образом, если подключать к сети новые внешние серверы и указывать в настройках, что они входят в структуру управляемой топологии, эти машины автоматически выявляют все входящие в данную структуру внутренние серверы.

Модернизация существующей конфигурации

Если вы уже пользуетесь средствами RPC over HTTP системы Exchange 2003 и при этом один из внешних серверов Exchange 2003 наделен функциями proxy-сервера RPC, после обновления внешних или внутренних серверов до уровня SP1 ваша конфигурация не изменится. Управляемая топология RPC over HTTP начинает функционировать лишь тогда, когда администратор выбирает и настраивает серверы с помощью свойств RPC-HTTP, как показано на экране 1.

Чтобы задействовать управляемую топологию RPC over HTTP, сначала нужно настроить все внутренние серверы и дождаться, пока атрибуты AD Heuristics будут растиражированы. В зависимости от сложности и топологии среды AD этот процесс может занять от 15 минут до нескольких часов. Но как бы то ни было, к настройке внешних серверов Exchange 2003 SP1, которые решено наделить функциями внешних серверов RPC over HTTP, можно приступать лишь после того, как репликация изменений будет завершена. При изменении настроек все существующие параметры, которые вы, возможно, вручную ввели в разделе ValidPorts внешнего сервера, будут заменены автоматически определяемыми значениями. При этом исходное состояние ValidPorts будет записано в файл, размещенный в каталоге system32 на системном накопителе внешнего сервера, а вы увидите сообщение, показанное на экране 2.

Экран 2. Извещение от ESM об уже проведенной настройке RPC over HTTP

Операции по подготовке управляемой топологии RPC over HTTP нужно выполнять в определенном порядке: сначала следует настроить внутренние серверы, затем дождаться завершения тиражирования данных службой AD и только после этого приступать к настройке внешних серверов. При несоблюдении указанной последовательности действий может возникнуть такая ситуация: внешние серверы будут искать в каталоге AD внутренние серверы, а когда убедятся, что их там нет, в разделе ValidPorts будет прописан параметр со значением «null», что приведет к сбою в работе службы. Более того, если вы решите вручную изменить раздел ValidPorts на включенном в структуру управляемой топологии внешнем сервере, имейте в виду, что эти изменения будут действительны в среднем в течение 7,5 минуты; в ходе следующей проверки внешних серверов функцией System Attendant взамен внесенных значений будут введены новые.

Автоматизация процедуры настройки

Если вы еще не провели модернизацию системы до уровня SP1 и при этом располагаете полнофункциональной средой RPC over HTTP, то у вас есть возможность частично автоматизировать настройку управляемой топологии RPC over HTTP. Эта возможность особенно порадует тех администраторов, которым приходится обслуживать множество внутренних серверов Exchange 2003 и которых не вдохновляет перспектива подключать их к структуре управляемой топологии один за другим. Можно написать собственный сценарий и с его помощью сформировать соответствующую битовую маску для атрибута Heuristics, а затем просто подключить внешние серверы, которые обнаружат только что настроенные внутренние серверы.

Есть и другая возможность: загрузить сценарий Microsoft Exchange2003 SP1 RPC-HTTP Topology Manager, опубликованный по адресу http://www.gotdotnet.com/community/ workspaces/workspace.aspx?id=4a0c34b7-d3dd- 478991b7-6880ecc5f910. Этот сценарий выполняется в трех режимах.

В режиме Registry считывает существующие внутренние серверы, уже указанные в разделе ValidPorts внешнего сервера, и устанавливает значение атрибута Heuristics внутренних серверов таким образом, чтобы их можно было немедленно обнаружить при активизации внешних серверов.

В режиме Server List считывает подготовленный пользователем текстовый файл и определяет, какие серверы следует добавить или удалить из структуры управляемой топологии RPC over HTTP.

В режиме Scan выявляет в каталоге AD все внешние и внутренние серверы, атрибуты Heuristics которых настроены в соответствии с требованиями управляемой топологии RPC over HTTP.

Безусловно, реализованный в пакете Exchange 2003 набор функций RPC over HTTP представляет собой замечательное нововведение. Благодаря усовершенствованиям, внесенным в управляемую топологию RPC over http разработчиками пакета обновлений SP1, сегодня администраторы имеют больше оснований для применения данной технологии доступа, чем когда-либо прежде. Это решение не связано с большими затратами; в худшем случае, если у вас еще нет подходящих внешних серверов Exchange 2003, вам придется приобрести дополнительные аппаратные компоненты и лицензии. Если вы откладывали развертывание технологии RPC over HTTP в ожидании, когда специалисты Microsoft исправят ошибки в коде и доработают свой продукт, знайте, что это время настало.

Главный консультант подразделения HP Advanced Technology Group в Ирландии. kieran. mccorry@hp.com