Клиентский доступ в Exchange: развертывание серверов

. В статье «Клиентский доступ в сервере Exchange: введение» (опубликованной в этом номере журнала) рассматривается общее назначение роли сервера клиентского доступа в Microsoft Exchange Server 2010 и Exchange 2007. В данной статье мы изучим эту тему более подробно, а также поговорим о развертывании и установке сервера клиентского доступа. Основное внимание будет сосредоточено на сервере Exchange 2010, но мы рассмотрим и различия с Exchange 2007. Мы обсудим и ручную (посредством графического интерфейса), и автоматическую установку, а также требования к предустановленному программному обеспечению. И в заключение мы обратимся к теме совместимости и перехода между версиями, включая переход к серверу клиентского доступа Exchange 2010 с предыдущих версий Exchange.

Требования к предустановленному программному обеспечению

Перед установкой роли сервера клиентского доступа необходимо убедиться, что ваш сервер отвечает ряду предварительных условий, которые включают в себя развертывание необходимых программных пакетов. Все необходимое программное обеспечение из списка обязательных требований я предпочитаю устанавливать посредством сценариев, что требует минимального участия администратора. По этой причине мы будем рассматривать установку всех необходимых пакетов в режиме командной строки, а не в графическом интерфейсе. В таблице перечислены программные пакеты, обязательные к установке; обратите внимание, что для Exchange 2007 и Exchange 2010 они различны. Пакеты. NET Framework, Windows PowerShell и Windows Remote Management (WinRM) являются базовыми системными требованиями для установки Exchange. Веб-сервер и удаленный вызов процедур (RPC) через HTTP являются специфическими требованиями для развертывания роли сервера клиентского доступа.

Таблица. Требования к предустановленному программному обеспечению для развертывания сервера клиентского доступа

Устанавливая Exchange 2010 на Windows Server 2008, потребуется также загрузить с сайта компании Microsoft пакет. NET Framework 3.5 SP1 по адресу bit.ly/9aZw и установить его. Установка возможна в автоматическом режиме, для этого надо запустить загруженный установочный файл с ключом /passive. В этом случае диалоговое окно установщика отображает только ход установки, и какого-либо взаимодействия с пользователем не предполагается.

Экран 1. Импорт системных модулей в оболочке PowerShell

Пакет. NET Framework 3.5 SP1 включен в Server 2008 R2 в качестве добавления. Установить его можно либо выбрав вариант Add Features в Server Manager, либо с помощью оболочки PowerShell, которую в свою очередь необходимо открыть с загруженными системными модулями. Для этого нужно щелкнуть по значку PowerShell правой кнопкой мыши и выбрать пункт меню «Импорт системных модулей», как показано на экране 1. Обратите внимание, что этот пункт меню будет недоступен, если вы ни разу не запускали оболочку PowerShell под учетной записью текущего пользователя. После импорта системных модулей необходимо ввести команду

Add-WindowsFeature net-Framework-Core

PowerShell 2.0 и WinRM входят в комплект утилит Server 2008 R2 и полностью работоспособны изначально, однако, если вы используете Server 2008, указанные приложения придется сначала установить. Компания Microsoft предлагает PowerShell 2.0 и WinRM к загрузке в виде единого пакета, называемого Windows Management Framework Core и доступного по адресу support.microsoft.com/kb/968929. На странице загрузки необходимо выбрать только указанный выше пакет. Его установка производится в «тихом» режиме командой

Windows6.0-KB968930-x64.msu/quiet

После установки пакетов. NET Framework и PowerShell надлежащих версий и прежде, чем приступить к установке роли сервера клиентского доступа, необходимо убедиться, что на сервере уже установлены следующие компоненты:

• роль веб-сервера на Server 2008;
• веб-сервер: базовая авторизация;
• веб-сервер: авторизация Windows;
• веб-сервер: digest-авторизация;
• веб-сервер: совместимость с мета­базой Microsoft IIS 6.0;
• веб-сервер: расширения API интернет-сервера (ISAPI);
• веб-сервер: динамическая компрессия контента;
• служба активации процессов Windows, процессная модель;
• инструменты удаленного администрирования сервера (инструменты веб-сервера);
• .NET Framework: активация http;
• прокси-сервер RPC через http.

Устанавливать все эти компоненты по отдельности через интерфейс диспетчера сервера необходимости нет — разработчики Exchange предусмотрели более простой способ. В папке Scripts на DVD c дистрибутивом Exchange имеется набор XML-файлов. Файл Exchange-CAS.xml содержит полный набор пакетов диспетчера сервера, которые потребуются для установки роли сервера клиентского доступа. Установить эти пакеты можно командой

ServerManagerCmd.exe
   -ip d:\scripts\Exchange-CAS.xml

Следует отметить, что команда ServerManagerCmd.exe не пользуется большой популярностью в Server 2008 R2 и, возможно, в последующих версиях этого продукта мы ее уже не увидим. Для установки указанных выше пакетов без использования команды ServerManagerCmd можно задействовать команду оболочки PowerShell Add-WindowsFeature:

Add-WindowsFeature NET-Framework,
   NET-HTTP-Activation,
   RPC-Over-HTTP-Proxy, RSAT-ADDS,
   Web-Server, Web-Basic-Auth,
   Web-Windows-Auth, Web-Metabase,
   Web-Net-Ext, Web-Lgcy-Mgmt-Console,
   WAS-Process-Model, RSAT-Web-Server,
   Web-ISAPI-Ext, Web-Digest-Auth,
   Web-Dyn-Compression –Restart

Также для функционирования роли сервера клиентского доступа необходимо, чтобы служба. NET TCP Port Sharing запускалась в автоматическом режиме. Назначение этой службы — обеспечить нескольким выполняющимся на сервере процессам использование одного и того же порта. Она добавляет логический слой между сетевыми службами и приложением. В Exchange 2010 служба репликации почтовых ящиков использует службу TCP Port Sharing для координации запросов на перемещение, приходящих сразу от множества клиентов. Включить автоматический запуск службы. NET TCP Port Sharing можно либо воспользовавшись оснасткой «Службы», либо набрав в командной строке Windows следующую команду:

sc config nettcpportsharing start=auto

Также для этой цели в оболочке PowerShell можно использовать команду

Set-Service nettcpportsharing
   -startuptype Automatic

Установка с использованием графического интерфейса

После того как все необходимые программные пакеты установлены, можно приступать к развертыванию роли сервера клиентского доступа при помощи мастера установки. Роль сервера клиентского доступа может быть одной из многих ролей, развернутых на сервере, но в данном примере мы рассмотрим установку этой роли как единственной.

Установите носитель с дистрибутивом Exchange 2010. Если функция AutoPlay не запустит программу установки автоматически, это можно сделать, запустив файл setup.exe из корневого каталога диска DVD. Обратите внимание, что на DVD присутствует две версии программы установки — setup.exe и setup.com. Файл setup.com является вариантом программы установки для командной строки, о котором я расскажу позже. Запускаем файл setup.exe. В нашем примере шаги 1 и 2 будут неактивны, поскольку все необходимые пакеты мы установили заранее. Выбираем шаг 3 и указываем язык, который будем использовать во время установки. В этом примере ограничимся теми языками, которые доступны на установочном диске.

Далее для запуска мастера установки необходимо выбрать шаг 4. После этого последовательно появятся экран с приветствием, текст лицензионного соглашения, которое необходимо принять, и подтверждение автоматической отправки ошибок в компанию Microsoft. Затем на экране выбора типа установки выбираем «Пользовательская установка сервера Exchange» и нажимаем «Далее». После этого появится экран выбора роли сервера. На данном экране выбираем вариант установки с ролью клиентского доступа в качестве роли сервера. При этом автоматически будет выбран пункт «Инструменты управления». Поскольку мы устанавливаем только роль сервера клиентского доступа, выбором этих двух пунктов и ограничимся, как показано на экране 2.

Экран 2. Разворачиваем только роль сервера клиентского доступа

Следующий экран — настройка внешнего домена сервера клиентского доступа. Этот экран есть только в Exchange 2010 и он позволяет определить (во время установки) внешнее пространство имен, которое сервер клиентского доступа будет обслуживать. Согласно этому пространству имен будут автоматически настроены виртуальные каталоги, и делать это вручную после установки не потребуется. Следует отметить, что определить внешнее пространство имен можно как во время установки, так и после ее завершения, причем сделать это требуется только для внешних серверов клиентского доступа, подключенных непосредственно к Интернету.

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

Экран 3. Пример экрана с удачным завершением развертывания

Автоматическая установка

Использование мастера установки значительно упрощает развертывание сервера клиентского доступа, однако при наличии необходимости развернуть значительное количество серверов Exchange c ролью сервера клиентского доступа можно воспользоваться менее сложным инструментом. Помимо прочего, дистрибутив Exchange включает вариант установщика Exchange для командной строки — файл setup.com, который позволяет произвести развертывание в автоматическом режиме.

Запустить файл setup.com можно либо с параметрами командной строки, либо указав файл ответов. Файлы ответов незаменимы, если при установке требуется указать значительное количество параметров, однако, если не предполагается развертывания никаких дополнительных ролей, кроме роли сервера клиентского доступа, использование файла ответов может быть излишним. В этом случае развертывание сервера клиентского доступа производится следующей командой

setup.com/mode: install/roles: clientaccess

Возможно, при развертывании роли сервера потребуется задействовать параметр NoSelfSighnedCertificates. Этот параметр развертывает роль без создания собственного сертификата, что весьма полезно, если в будущем планируется удалить собственный сертификат по умолчанию и использовать вместо него сторонний сертификат, полученный из доверенного источника. Не используйте этот параметр, если не собираетесь применять сторонний сертификат. Также нужно заранее определиться, задействовать ли параметр ExternalCASServerDomain. Например, так:

setup.com/mode: install/roles: clientaccess
   /externalCAsserverDomain:
   mail.contoso.com

Этот параметр позволяет определить имя внешнего домена для внешних серверов клиентского доступа, подключенных к Интернету, о чем упоминалось выше, когда мы рассматривали использование мастера установки. После того как вы определитесь с параметрами и запустите на исполнение файл setup.com, установка произойдет полностью в автоматическом режиме.

Сосуществование и переход между версиями

Обеспечить сосуществование сервера Exchange 2010 с серверами предыдущих версий, как, впрочем, и перенести на него их функции, относительно несложная задача, если следовать нескольким основным правилам. Нужно помнить, что серверы клиентского доступа Exchange 2010 не могут взаимодействовать с серверами почтовых ящиков Exchange 2003 или Exchange 2007 посредством MAPI. Внешним серверам предыдущих версий необходимо иное внешнее пространство имен, нежели внешнему серверу клиентского доступа Exchange 2010. Также вам могут потребоваться новые сертификаты — у серверов предыдущих версий будет другое пространство имен, поэтому, если вы не располагаете универсальным сертификатом, потребуется запросить новый сертификат SAN. И запомните, что переходить на новую версию должны сначала внешние серверы клиентского доступа, и лишь затем внутренние.

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

Например, если для уже существующих серверов Exchange 2007 или Exchange 2003 определено пространство внешних имен mail.contoso.com, логично предположить, что вы захотите использовать его же для Exchange 2010. Сохранение этого пространства имен позволит пользователям продолжать применять привычный URL для доступа к Outlook Web App (OWA; ранее Outlook Web Access), а также им не потребуется перенастраивать клиенты IMAP/POP в своих мобильных телефонах. Если в вашей сети остаются действующие серверы-мосты Exchange 2003 или серверы клиентского доступа Exchange 2007 (неважно, на временной или постоянной основе), то в некоторых случаях сервер клиентского доступа Exchange 2010 должен будет перенаправить внешнего клиента на эти серверы. Чтобы такое перенаправление было возможным, серверы предыдущих версий должны иметь другое внешнее пространство имен, например legacy.contoso.com.

Когда подготовка к переходу произведена, развертывание серверов клиентского доступа Exchange 2010 можно производить без опасения повредить существующую инфраструктуру Exchange. Необходимо помнить, что в структуру DNS рабочего внешнего пространства имен (например, mail.contoso.com) не должны вноситься никакие изменения до тех пор, пока не будет настроено дополнительное пространство имен для серверов преды­дущих версий и внешние пользователи не смогут задействовать серверы клиентского доступа Exchange 2010. Настройка дополнительного пространства имен для серверов предыдущих версий различается для Exchange 2007 и Exchange 2003.

Создание дополнительного пространства имен для серверов интерфейса Exchange 2003

1. Создайте записи DNS для дополнительного пространства имен (например, legacy.contoso.com) и укажите их для ваших внешних серверов-мостов Exchange 2003.

2. Используйте команду Set-OwaVirtualDirectory оболочки управления Exchange, чтобы сообщить OWA Exchange 2010 адрес для перенаправления пользователей. Параметр Exchange2003 URL для OWA должен быть определен на всех серверах клиентского доступа, к которым подключены серверы почтовых ящиков Exchange 2003. Например:

Set-OwaVirtualDirectory
   "CONTOSO-CAS01\owa*"
   -Exchange2003 URL
   https://legacy.contoso.com/exchange

3. Если вы используете ActiveSync, убедитесь, что на сервере почтовых ящиков Exchange 2003 для ActiveSync включена встроенная авторизация Windows. Это необходимо для того, чтобы сервер Exchange 2003, на котором запущен ActiveSync, мог принимать удостоверения Kerberos от сервера клиентского доступа Exchange 2010.

4. Обновите сертификаты на своих серверах интерфейса Exchange 2003, чтобы включить в них дополнительное пространство имен.

5. Когда вы будете готовы предоставить пользователям доступ к серверам клиентского доступа Exchange 2010, измените записи DNS рабочего пространства имен таким образом, чтобы указать на серверы Exchange 2010.

6. Перенастройте автономную адресную книгу (OAB). Если в вашей организации используются почтовые клиенты Outlook 2007 или Outlook 2010, имеет смысл переместить OAB на сервер почтовых ящиков Exchange 2010. Это позволит использовать более эффективный, в том числе и с точки зрения нагрузки на сеть, веб-доступ к OAB (в отличие от распространения OAB через общие папки). Ко всему прочему, формируется OAB и на сервере почтовых ящиков, хотя доступ к ней обеспечивается посредством сервера клиентского доступа. По этой причине, прежде чем активировать веб-доступ, необходимо перенести процесс формирования OAB на сервер почтовых ящиков Exchange 2010. Делается это посредством использования команды Move-OfflineAddressBook. Следует помнить, что Outlook 2003 и более старые клиенты могут загрузить OAB только из общих папок, поэтому, если в вашей организации все еще используются эти почтовые клиенты, убедитесь, что распространение OAB через общие папки по-прежнему активировано. По умолчанию виртуальный каталог для распространения OAB посредством сети создается на сервере клиентского доступа, однако сама OAB также нуждается в настройке путем добавления виртуального каталога в качестве точки распространения по сети. Воспользуйтесь командой Set-OfflineAddressBook в Exchange 2010, чтобы добавить виртуальный каталог OAB сервера клиентского доступа в список виртуальных каталогов, доступных для ваших автономных адресных книг. При этом нужно убедиться, что на момент внесения изменений формируются адресные книги версии 4. Также убедитесь, что в список добавлены все существующие виртуальные каталоги. Не указанные (намеренно или случайно) виртуальные каталоги будут исключены из списка. Ваши команды должны выглядеть примерно таким образом:

Move-OfflineAddressBook
   "Default Offline Address Book"
   -Server CONTOSO-MBX01
Set-OfflineAddressBook
   "Default Offline Address Book"
   -VirtualDirectories
   "CONTOSO-CAS01\oab*"

7. Если вы используете RPC через HTTP, перенесите точку подключения на Exchange 2010 и отключите RPC через HTTP на серверах Exchange 2003.

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

1. Создайте записи DNS для дополнительного пространства имен (например, legacy.contoso.com) и укажите их для своих внешних серверов клиентского доступа Exchange 2007.

2. Обновите внешние ссылки URL на ваших серверах клиентского доступа Exchange 2007 таким образом, чтобы ими использовалось дополнительное пространство имен.

3. Когда вы будете готовы предоставить пользователям доступ к серверам клиентского доступа Exchange 2010, измените записи DNS рабочего пространства имен таким образом, чтобы указать на серверы Exchange 2010. Не забудьте при этом изменить запись службы автоматического обнаружения AutoDiscover.

4. Перенастройте OAB. Восполь­зуйтесь командой Set-Offline­Address­Book, чтобы активировать распространение OAB вашими серверами клиентского доступа Exchange 2010. Указанная команда модифицирует OAB и добавляет веб-службу Exchange в список виртуальных каталогов. Как и в описанном выше случае перехода с Exchange 2003, необходимо убедиться, что используются OAB версии 4. Аналогичным же образом при использовании команды Set-OfflineAddressBook все существующие виртуальные каталоги должны быть указаны в ее параметре VirtualDirectories во избежание их исключения из списка. Например:

Set-OfflineAddressBook
"Default Offline Address Book"
-VirtualDirectories
"CONTOSO-CAS01\oab*"

5. Отключите функцию Outlook Anywhere на серверах клиентского доступа Exchange 2007 и включите ее на серверах клиентского доступа Exchange 2010.

Процесс перехода между версиями на разных системах и версиях Exchange может происходить по-разному. Моей задачей было объяснить этот процесс в целом. А вам в свою очередь предстоит вдумчиво оценить и протестировать все возможные сценарии перехода и то, каким образом будут сосуществовать разные версии продукта во время его выполнения, прежде чем запустить Exchange 2010 в качестве рабочего сервера.

Сервер развернут. Что дальше?

Полагаю, теперь развертывание роли сервера клиентского доступа не составит для вас особого труда. И это лишь верхний слой пирога под названием «сервер клиентского доступа». В следующей статье цикла мы рассмотрим вопросы обеспечения избыточного резервирования и высокой доступности серверов клиентского доступа. А пока предлагаю ознакомиться со статьей «Переносим клиентский доступ на сервер Exchange 2010» в блоге команды разработчиков Exchange, доступной по адресу msexchangeteam.com/archive/2009/11/20/453272.aspx.

Кен Сен-Сир (ken.stcyr@microsoft.com) — архитектор решений компании Microsoft с более чем 10-летним опытом работы. Имеет сертификат Microsoft Certified Master in Directory Services