Exchange и ответы на вопросы: Мобильный Outlook и IPv6, анализатор возможности удаленного подключения и многое другое

Q Мы только что завершили в нашей организации развертывание Exchange 2007 на серверах, работающих под управлением Windows Server 2008. Все работает прекрасно за одним исключением. Хотя мы настроили мобильный Outlook (известный ранее как RPC по HTTP), следуя указаниям из документации по Exchange 2007, представленной в журнале Microsoft TechNet, мы не можем подключиться по сети Интернет к серверам клиентского доступа Exchange 2007 из клиента Outlook 2007, как бы мы ни пытались это сделать. Мы убедились, что сертификат пользуется доверием клиента и что на брандмауэре, подключенном к серверам клиентского доступа, открыт 443-ый порт TCP. Знакомы ли вам неполадки такого типа?

A По существу, да. Вы упомянули, что Exchange 2007 установлен на серверах, работающих под управлением Windows Server 2008. Когда сервер клиентского доступа устанавливается на сервере Windows Server 2008, важно помнить, что мобильный Outlook не будет работать надлежащим образом, если на сервере активирован IPv6. Поскольку IPv6 активируется по умолчанию, когда на Windows Server 2008 устанавливается Exchange 2007 SP1, его необходимо отключить. Мне известно несколько случаев, когда этим действием устранялась данная неполадка.

Подробнее о том, почему мобильный Outlook и IPv6 плохо сочетаются на Windows Server 2008, и о том, как надлежащим образом отключить IPv6 на серверах Windows 2008, не нарушив работу Exchange 2007, рекомендую почитать в записи блога группы Exchange корпорации Майкрософт, находящемся по адресу msexchangeteam.com/archive/2008/06/20/449053.aspx. Эта неполадка должна быть устранена в Exchange 2007 с пакетом обновлений 1 (SP1) с накопительным пакетом обновлений 4.

Q В настоящее время я занимаюсь внедрением мобильного Outlook и Exchange ActiveSync в среде обмена сообщениями на базе Exchange 2007. Интересно, существует ли какая-нибудь возможность проверить, будет ли мобильный Outlook работать, как ожидается, по другую сторону нашей периферийной сети. Кроме того, мне требуется убедиться, что в нашей среде надлежащим образом настроена служба автообнаружения. Не могли бы вы дать мне какие-нибудь рекомендации?

A Да, возможность проверить, работает ли мобильный Outlook надлежащим образом, существует. Два сотрудника Майкрософт (Шон Мак-Грат (Shawn McGrath) из группы продуктов Exchange и Брэд Хьюз (Brad Hughes) из службы поддержки) создали веб-инструмент с именем Exchange Server Remote Connectivity Analyzer (ExRCA) (анализатор возможности удаленного подключения к серверу Exchange). Пока этот инструмент (на рис. 1) следует рассматривать как прототип, но я не сталкивался с какими-либо ошибками или странностями в его поведении. Этот инструмент выполняет тестирование автообнаружения Outlook 2007 и возможности подключения RPC/HTTP; кроме этого, предусмотрена проверка правильности работы Exchange ActiveSync и входящего потока почты SMTP. Хотя в настоящее время ExRCA не поддерживается Майкрософт, я настойчиво рекомендую его для любых проверок возможности удаленного подключения к Exchange 2007.

Рис. 1. Начальная страница анализатора возможности удаленного подключения к серверу Exchange

Q Наша организаци, использующая Exchange Server 2007, занимается планированием развертывания резервной непрерывной репликации (SCR). Мы собираемся для каждой базы данных почтовых ящиков держать на другой площадке второй набор данных, созданный на некластеризованных серверах почтовых ящиков Exchange 2007 с пакетом обновления 1. Мы много читали о SCR в документации по Exchange 2007, представленной в Microsoft TechNet, но у нас все еще остался вопрос, на который нам не удалось получить ответ в этом журнале: если мы активируем целевой объект SCR, будет ли результат таким же, как от работы командлета Move-Mailbox параметром –ConfigurationOnly, заданным для всех пользовательских почтовых ящиков в конкретной базе данных почтовых ящиков? Другими словами, только изменение местонахождения сервера Exchange в Active Directory.

A Так как вы используете некластеризованные серверы почтовых ящиков (или автономный сервер почтовых ящиков) в качестве исходных серверов SCR, вы правильно понимаете ситуацию. Поскольку вы будете активировать копию SCR на другом сервере, будет использоваться переносимость базы данных. Это означает, что изменится местонахождение сервера Exchange в Active Directory для пользовательских почтовых ящиков в соответствующей базе данных почтовых ящиков.

Если на исходных серверах SCR в вашей среде Exchange 2007 использовалась либо постоянная кластерная репликация (CCR — clustered continuous replication), либо кластер с единым хранилищем (SCC — single copy cluster), и вы использовали пассивный узел в отказоустойчивом кластере в качестве целевого объекта SCR, вы активируете целевой объект SCR с тем же именем, и местонахождение Exchange Server в Active Directory не изменяется.

Q Мы только что полностью завершили развертывание Exchange Server 2007 в рабочей среде нашего предприятия, и нас интересует вопрос, поддерживается ли перемещение шести групп безопасности Exchange 2007, созданных программой установки Exchange 2007 при подготовке леса и доменов для установки Exchange 2007, в другое подразделение организации вместо подразделения Microsoft Exchange Security Groups, созданного в корневом домене.

A В отличие от Exchange 2000/2003, не позволявшего перемещать группы Exchange в другое подразделение в пределах леса, Exchange 2007 действительно поддеживает эту операцию. Видно, что шесть групп безопасности Exchange 2007 (см. рис. 2), созданные когда выполнялась подготовка леса для Exchange 2007, отмечены двумя уникальными свойствами; первое — это хорошо известнвый GUID, а второе — различающееся имя, которое может изменяться.

Рис 2. Группы безопасности Exchange Server 2007

Эти два свойства и тот факт, что они добавляются к соответствующему атрибуту леса OtherWellKnownObjects во время установки, гарантируют, что Exchange будет в состоянии отыскать группы безопасности в любом месте леса. Поэтому можно двигаться дальше и перемещать группы куда требуется, даже в другой домен леса! Дополнительные подробные сведения можно найти в превосходной подборке вопросов и ответов Росса Смита (Ross Smith), посвященной правам доступа в Exchange 2007 (technet.microsoft.com/bb310792), включенной в документацию по Exchange 2007 в журнале Microsoft TechNet.

Q Вследствие некоторой реструктуризации среды обмена сообщениями на базе Exchange 2007 нам требуется переместить файловый ресурс-свидетель для каждого из серверов почтовых ящиков Exchange 2007 CCR на другой транспортный сервер-концентратор. Нельзя ли получить указания относительно того, как это выполняется в режиме поддержки?

A Перемещение файлового ресурса-свидетеля с одного транспортного сервера-концентратора Exchange 2007 на другой выполняется крайне просто. Достаточно следовать той процедуре, которая использовалась при начальной настройке файлового ресурса-свидетеля для кластерных серверов почтовых ящиков. Единственное отличие состоит в том, какой задается путь к серверу. Соответствующую последовательность действий можно найти в разделе How to Configure the File Share Witness (Как настроить файловый ресурс-свидетель) в документации по Exchange 2007, представленной в журнале Microsoft TechNet (см. technet.microsoft.com/bb124922).

Между прочим, следует знать, что при использовании записи CNAME для указания транспортного сервера-концентратора во время настройки фалового ресурса-свидетеля задача станет просто вопросом выбора полного доменного имени (FQDN) целевого узла, на который указывает псевдоним в соответствующей записи CNAME (см. рис. 3).

Рис 3 Запись CNAME, указывающая на целевой узел для файлового ресурса-свидетеля

Тем не менее помните, что для случая, когда узлы кластера находятся на разных веб-узлах, указания от группы разработчиков Exchange относительно устойчивости узла изменились (см. msexchangeteam.com/archive/2008/04/03/448615.aspx). По существу, группа разработчиков Exchange больше не рекомендует использовать записи CNAME в рабочих средах Exchange 2007 Geo-Cluster.

Q Мы планируем усовершенствовать настройки безопасности для серверов обмена сообщениями Exchange 2007. Часть нашего плана оптимизации безопасности состоит в шифровании томов, на которых находятся базы данных Exchange. Мы хотели бы узнать, рекомендуется или даже поддерживается или нет хранение файлов базы данных Exchange на томе, зашифрованном с использованием системы шифрования EFS (Encrypting File System).

A Ответ совершенно отрицательный. Размещение баз данных Exchange 2007 на томе, зашифрованном с использованием EFS, не поддерживается Майкрософт. Фактически, это не поддерживается для файлов .edb, .log, .stm (Exchange 2000/2003), .dat, .eml, и .chk. Основная причина заключается в том, что этот тип шифрования приводит к дополнительным затратам ресурсов, что значительно сказывается на производительности.

Для дальнейшего улучшения защиты файлов данных Exchange 2007 следует предотвращать несанкционированный доступ к компьютеру Exchange и использовать для шифрования данных сообщений формат S/MIME. Кроме этого, если Exchange 2007 устанавливается на Windows Server 2008, обдумайте возможность использования BitLocker для защиты томов.

Q Я только что установил Exchange 2007 с пакетом обновления 1 на сервере Windows Server 2008, который является также контроллером домена. Поскольку в этой среде я не использую IPv6, я отключил его в разделе «Сетевые подключения» после установки Exchange 2007 с пакетом обновлений 1, а затем перезагрузил сервер. Когда он вернулся в оперативный режим, перестали запускаться службы Exchange 2007. Ошибка 214, внесенная в журнал приложений, сопровождается следующей информацией.

Process MSEXCHANGEADTOPOLOGYSERVICE.EXE (PID=1712). 
Topology discovery failed, error 0x80040a02 (DSC_E_NO_SUITABLE_CDC).

A Я знаю несколько сообщений о таком поведении. Хотя практика установки какой-либо из серверных ролей Exchange 2007 на сервере Windows Server 2008, который выступает также в качестве контроллера домена, не является разумной, конфигурация с одной или нескольких серверных ролей на контроллере домена с отключенным IPv6 должна работать, в особенности потому, что это распространенная ситуация в среде тестовых лабораторий и других местах. Решение заключается в повторном активировании IPv6 на сервере. По слухам, эта неполадка будет устранена в Exchange 2007 с пакетом обновлений 1 (SP1) с накопительным пакетом обновлений 4.