Применимо к: Exchange Server 2010 SP1

Последнее изменение раздела: 2011-01-13

В системе Microsoft Exchange Server 2007 была представлена роль сервера клиентского доступа, которая позволяла обрабатывать входящие клиентские подключения к почтовым ящикам Exchange. Хотя большинство типов клиентских подключений устанавливалось к серверу клиентского доступа, приложение Microsoft Office Outlook по-прежнему подключалось непосредственно к серверу почтовых ящиков, когда оно запускалось внутренним образом по протоколу MAPI.

В системе Exchange Server 2010 была разработана новая служба, которая позволяет обрабатывать эти подключения MAPI с помощью сервера клиентского доступа. Служба клиентского доступа RPC обеспечивает доступ к данным по единому общему пути к серверу клиентского доступа, за исключением запросов к общим папкам, которые по-прежнему делаются непосредственно на сервер почтовых ящиков. Это изменение позволяет применять бизнес-логику по отношению к клиентам более согласованным образом и улучшает производительность при работе с клиентами во время сбоев.

Содержание

Служба клиентского доступа RPC и служба адресной книги

Преимущества службы клиентского доступа RPC

Массив серверов клиентского доступа

Настройка службы клиентского доступа RPC и службы адресной книги

Служба клиентского доступа RPC и служба адресной книги

На сервер клиентского доступа в системе Exchange 2010 переносится не только функция обработки входящих подключений к почтовым ящикам Outlook, но и функция управления доступом к каталогам. Дополнительные сведения о доступе к каталогам см. в разделе Общие сведения о службе адресной книги.

Приложение Microsoft Outlook по-прежнему подключается непосредственно к серверу почтовых ящиков для получения доступа к базам данных общих папок. Если клиент пытается подключиться к серверу почтовых ящиков для получения доступа к общим папкам, то служба клиентского доступа RPC (MsExchangeRpc) отвечает конечной точке RPC. Если конечная точка находится на сервере, на котором установлена роль сервера почтовых ящиков, то служба клиентского доступа RPC будет разрешать только выполнение входа в общие папки и предоставлять ссылку на сервер клиентского доступа или массив таких серверов. Если же конечная точка располагается на сервере клиентского доступа или в массиве подобных серверов, то она будет допускать только выполнение входа в общие папки и предоставлять ссылку на сервер почтовых ящиков для получения доступа к общим папкам.

Преимущества службы клиентского доступа RPC

Служба клиентского доступа RPC имеет ряд преимуществ. В случаях сбоев почтовых ящиков время простоя для клиентов снижается, так как все подключения устанавливаются через серверы клиентского доступа. Когда на сервере Exchange 2007 происходил сбой, клиенты Outlook отключались от сервера почтовых ящиков на период времени, продолжительность которого зависела от их сетевой конфигурации. В системе Exchange 2010 при возникновении сбоя одного сервера клиентского доступа в массиве серверов клиентского доступа клиент будет немедленно перенаправлен на другой сервер в этом массиве. Если происходит сбой на сервере почтовых ящиков, который является частью группы обеспечения доступности баз данных (DAG), то клиент отключается только на тот промежуток времени, который требуется для подключения базы данных для отработки отказа.

Массив серверов клиентского доступа со сбалансированной нагрузкой позволяет равномерно распределять трафик между всеми серверами.

К другим проблемам, решенным благодаря этой новой архитектуре, относятся следующие:

  • Некоторые проблемы с сообщениями, которые по-разному отображаются на разных клиентских компьютерах.

  • Проблемы при загрузке сертификатов в глобальный список адресов.

  • Невозможность создания профилей для скрытых пользователей.

  • Несогласованное применение бизнес-логики к клиентам.

  • Подключение общих папок к службе клиентского доступа RPC на сервере почтовых ящиков вместо сервера клиентского доступа.

Помимо этого, служба DSProxy была удалена, и новая служба адресной книги отвечает за обновление сертификатов и состава списка рассылки, а также обслуживание сведений о делегатах для клиентов Outlook.

Подключения клиентов MAPI

В версии Exchange 2007 приложение Outlook и другие клиенты MAPI устанавливали связь с сервером клиентского доступа для подключений HTTPS, таких как веб-службы Exchange (в том числе служба доступности и параметры отсутствия на рабочем месте), а также загрузки автономных адресных книг, но при этом связь устанавливалась непосредственно с компонентом MAPI RPC на сервере почтовых ящиков и конечной точкой NSPI на серверах глобальных каталогов для запросов службы каталогов.

В Exchange 2010 эти подключения устанавливаются к точке подключения MAPI RPC на сервере клиентского доступа или массиве серверов клиентского доступа.

Служба адресной книги

В предыдущих версиях системы Exchange DSProxy — справочная служба, которая сообщала клиентам Outlook, где находится конечная точка NSPI, — отвечала за направление приложения Outlook на сервер глобальных каталогов. Служба DSProxy располагалась на сервере почтовых ящиков. В версии Exchange 2010 она была исключена и заменена службой адресной книги.

В настоящее время, когда клиент Outlook делает запрос на сервер клиентского доступа, это приводит к одному из двух возможных действий.

  • Если почтовый ящик пользователя находится на сервере почтовых ящиков Exchange 2010, то запрос обрабатывается сервером клиентского доступа на текущем сайте Служба каталогов Active Directory, или, если почтовый ящик пользователя находится на другом сайте Служба каталогов Active Directory, запрос передается через прокси-соединение на сайт Служба каталогов Active Directory.

  • Если почтовый ящик пользователя находится на сервере почтовых ящиков Exchange, то запрос к каталогу перенаправляется на сервер почтового ящика пользователя. Серверы почтовых ящиков прежних версий не могут взаимодействовать непосредственно с серверами клиентского доступа Exchange 2010 для получения сведений о каталоге.

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

В начало

Массив серверов клиентского доступа

Помимо службы клиентского доступа RPC, в версии Exchange 2010 появилась новая логическая структура для организации Exchange — массив серверов клиентского доступа. Когда на сайте Служба каталогов Active Directory определен массив серверов клиентского доступа, он служит единой точкой контакта для всех клиентских подключений в пределах этого сайта Служба каталогов Active Directory. Массив серверов клиентского доступа может включать в себя один или несколько серверов клиентского доступа.

Каждый сайт Служба каталогов Active Directory может иметь один массив серверов клиентского доступа. Массив серверов клиентского доступа не обеспечивает балансировку нагрузки. Для балансировки нагрузки по-прежнему необходимо отдельное решение. Дополнительные сведения о балансировке нагрузки см. в разделе Общие сведения о балансировке нагрузки в Exchange 2010.

Массив серверов клиентского доступа рекомендуется создать даже в том случае, когда в организации имеется один сервер клиентского доступа. После создания массива серверов клиентского доступа клиенты подключаются через виртуальное имя этого массива, а не напрямую к полному доменному имени (FQDN) одного сервера клиентского доступа. Если один сервер клиентского доступа необходимо заменить в пределах сайта Служба каталогов Active Directory или добавляется второй сервер клиентского доступа, то необходимость в обновлении профилей в клиентах не возникает.

После определения массива серверов клиентского доступа в пределах сайта Служба каталогов Active Directory все серверы клиентского доступа в пределах этого сайта Служба каталогов Active Directory автоматически становятся частью данного массива.

Настройка службы клиентского доступа RPC и службы адресной книги

Чтобы настроить службу клиентского доступа RPC и службу адресной книги, необходимо выполнить следующие действия.

  1. Создание массива серверов клиентского доступа

  2. Настройка балансировки нагрузки

  3. Настройка портов IP

  4. Настройка параметров шифрования RPC

  5. Настройка баз данных почтовых ящиков

  6. Проверка низкого значения задержки и достаточности скорости сети

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

Массив серверов клиентского доступа на сайте Служба каталогов Active Directory можно создать с помощью следующей команды.

Скопировать код
New-ClientAccessArray -Name name -Site site_name -FQDN internal_only_CAS_Array_FQDN
Примечание.
После создания массива серверов клиентского доступа также необходимо создать адрес в службе DNS и сопоставить его с виртуальным IP-адресом, используемым для данного массива.

Важно, чтобы имя FQDN, заданное в команде, можно было разрешить только внутренним образом. Если это имя разрешается также внешним образом, то эти внешние клиенты будут пытаться подключиться к массиву через подключение TCP вместо HTTPS.

Настройка балансировки нагрузки

Балансировка нагрузки рекомендуется для обеспечения высокой доступности, отработки отказов и распределения трафика между несколькими серверами в целях повышения производительности. При выборе решения балансировки нагрузки необходимо учитывать следующее:

  • Балансировка нагрузки в сети Windows не поддерживается на серверах отказоустойчивого кластера Windows.

  • Невозможно использовать массив серверов клиентского доступа на нескольких сайтах Служба каталогов Active Directory. Вместо этого следует создать два массива серверов клиентского доступа и выровнять нагрузку по отдельности внутри сайтов.

  • Аппаратные подсистемы балансировки нагрузки обычно отслеживают обратный трафик, доступность порта или службы. Благодаря этому тем серверам, которые не могут отвечать на запросы клиентов, не предоставляются сетевые подключения.

  • Некоторые решения для балансировки нагрузки, например ISA 2006 или TMG 2010, не могут выполнять балансировку нагрузки RPC или отслеживать службы RPC. Эти решения не рекомендуются, если только все клиенты не подключаются через приложение Outlook Anywhere, а весь трафик не инкапсулируется внутри HTTP.

Дополнительные сведения о балансировке нагрузки см. в разделе Общие сведения о балансировке нагрузки в Exchange 2010.

Настройка портов IP

Порт IP — это канал, через который может передаваться информация с исходного компьютера на компьютер назначения. По умолчанию динамический диапазон портов для исходящих подключений на сервере Windows Server 2008 R2 имеет такие пределы: 49152–65535. Сервер клиентского доступа Exchange 2010 изменяет пределы этого диапазона следующим образом: 6005–59530. Диапазон расширялся для обеспечения достаточного масштабирования для крупных развертываний. Это широкий диапазон портов для балансировки через брандмауэр между клиентом и серверами клиентского доступа или массивом таких серверов.

Путем фиксации конечных точек протокола MAPI и каталогов можно существенным образом снизить число портов, которые требуют балансировки нагрузки. Конечную точку протокола MAPI можно статически настроить в реестре, а конечную точку каталогов можно зафиксировать в файле конфигурации.

Чтобы зафиксировать конечную точку MAPI, используйте следующий параметр реестра.

HKLM\SYSTEM\CurrentControlSet\ Services\MSExchangeRPC\ParametersSystemTCP/IP Port [DWORD] — это значение, которое следует использовать для IP-порта.

Чтобы зафиксировать конечную точку служб каталогов, измените значение RpcTcpPort в файле конфигурации Microsoft.Exchange.AddressBook.Service.Exe.config.

Примечание.
Изменять значения по умолчанию для портов приложения Outlook Anywhere не рекомендуется.

В начало

Настройка параметров шифрования RPC

В окончательной первоначальной версии (RTM) Exchange 2010 конечная точка RPC по умолчанию шифруется. Тем не менее, в приложении Outlook 2003 не обеспечиваются зашифрованные подключения MAPI. При обновлении организации до окончательной первоначальной версии (RTM) Exchange 2010 для клиентов, использующих приложение Outlook 2007 или последующих версий, автоматически обеспечивается совместимость с измененным клиентским доступом RPC, так как они поддерживают шифрование RPC по умолчанию. В приложении Outlook 2003 шифрование RPC не используется, но оно необходимо по умолчанию для клиентского доступа RPC. Если шифрование RPC не отключено, что не рекомендуется, то пользователям потребуется настроить его в приложении Outlook 2003, иначе администратору придется использовать групповую политику для принудительного включения шифрования RPC в Outlook 2003.

Признаками этой неполадки являются следующие сообщения об ошибках:

  • Не удалось запустить Microsoft Office Outlook. Не удалось открыть окно Office. Не удается открыть набор папок.

  • Не удалось открыть папки электронной почты по умолчанию. Не удается открыть банк данных.

Если пользователи работают в режиме кэширования Exchange, Office не будет отображать сообщение об ошибке, но запустится в отключенном режиме.

По умолчанию в системе Exchange 2010 с пакетом обновления 1 (SP1) конечная точка RPC не шифруется. Если установка системы Exchange 2010 с пакетом обновления 1 (SP1) в организации завершена, то клиенты Outlook 2003 смогут подключаться к серверу Exchange без дальнейшей настройки.

Дополнительные сведения об этой неполадке, а также об путях решения, см. в разделе Проблемы с подключением Outlook в почтовых ящиках Exchange 2010.

В начало

Настройка Outlook 2003 для использования шифрования RPC

Чтобы настроить Outlook 2003 для использования шифрования RPC, выполните следующие шаги. 

  1. Нажмите Сервис > Учетные записи электронной почты > Просмотр или изменение существующей учетной записи.

  2. Выберите учетную запись и нажмите кнопку Другие параметры.

  3. Откройте вкладку Безопасность.

  4. Выберите пункт Шифровать данные между Microsoft Office Outlook и Microsoft Exchange Server.

  5. Нажмите кнопку ОК.  

Поимо требования шифрования RPC, из системы Exchange 2010 исключена поддержка уведомлений по протоколу UDP. В результате в приложении Outlook 2003 можно использовать только уведомления опроса в оперативном режиме. Из-за этого происходит незначительная задержка обновления состояния элемента (в среднем — от 30 секунд до одной минуты) при выполнении изменений элементов в почтовом ящике, к которому Outlook 2003 выполняет доступ. Существует два пути решения этой неполадки.

  • Используйте Outlook 2003 в режиме кэширования Exchange.

  • Настройка интервала опроса на сервере клиентского доступа. Она оказывает влияние на производительность сервера клиентского доступа.

Дополнительные сведения об этой неполадке см. в разделе Задержка отправки и получения сообщений электронной почты.

Настройка базы данных почтовых ящиков

Каждая база данных почтовых ящиков содержит значение RPCClientAccessServer. Это значение устанавливается при создании базы данных, и оно определяет сервер клиентского доступа или массив таких серверов, который будет использоваться клиентами с почтовыми ящиками на этом сервере почтовых ящиков. Это значение также определяет расположение конечной точки RPC. Для клиентов Outlook 2007 и Outlook 2010 это значение извлекается из службы автообнаружения.

Значение RPCClientAccessServer по умолчанию определяется следующими правилами:

  • Если массив серверов клиентского доступа настроен на сайте Служба каталогов Active Directory, то будет использован адрес этого массива.

  • Если на сайте Служба каталогов Active Directory массив отсутствует, а на одном физическом сервере имеются роли сервера клиентского доступа и сервера почтовых ящиков, то значение свойства RPCClientAccessServer для отдельного сервера почтовых ящиков будет таким же, как и для данного сервера клиентского доступа.

  • В противном случае в качестве значения свойства RPCClientAccessServer для отдельного сервера почтовых ящиков будет установлен случайным образом выбранный сервер клиентского доступа на сайте Служба каталогов Active Directory.

    Примечание.
    Не рекомендуется устанавливать все роли сервера на один компьютер, который также является контроллером домена. Несмотря на то что эта конфигурация поддерживается, это не рекомендуется.
  • Если база данных почтовых ящиков была создана перед созданием массива серверов клиентского доступа или установки сервера клиентского доступа на сайте Служба каталогов Active Directory, то потребуется перенастроить значение свойства RPCClientAccessServer. Если при создании базы данных почтовых ящиков сервер клиентского доступа на сайте Служба каталогов Active Directory отсутствует, то в качестве значения свойства RPCClientAccessServer будет установлено имя FQDN сервера почтовых ящиков. Чтобы настроить значение свойства RPCClientAccessServer, используйте следующую команду.

    Скопировать код
    Set-MailboxDatabase <name> -RPCClientAccessServer <internal_only_CAS_Array_FQDN>
    

Требования к значениям задержки и пропускной способности

Для пользователей, использующих приложение Outlook без режима кэширования Exchange, высокие промежутки задержки между клиентом и сервером непосредственно влияют на частоту случаев, когда приложение Outlook не отвечает. В общем случае задержка более чем в 200 миллисекунд (мс) на основном сервере почтовых ящиков будет приводить к снижению производительности клиента.

Так как задержка между сервером клиентского доступа и почтовым ящиком должна быть менее 10 мс, то в качестве значения свойства RPCClientAccessServer должен всегда настраиваться массив серверов клиентского доступа на активном сайте базы данных почтовых ящиков.

Примечание.
Изменение значения свойства RPCClientAccessServer приводит к повторному подключению всех клиентов.

Настройка службы адресной книги

Служба адресной книги настраивается через файл Microsoft.Exchange.AddressBook.Service.config. Этот файл позволяет настроить следующие параметры.

  • Количество одновременных подключений на одного пользователя (ограничение по умолчанию равно 50).

  • Отключение или включение ведения журнала.

  • Расположение, размер и период хранения файлов журнала.

Чтобы установить максимальное количество сеансов на одного пользователя, используйте следующее значение: <add key=“MaxSessionsPerUser” value=“50” />

Чтобы включить ведение журнала, используйте следующее значение: <add key="ProtocolLoggingEnabled" value="true" />