Exchange в вопросах и ответах: Управление миграцией

Управлять миграцией всегда непросто. Есть несколько приемов, которые позволяют упростить и сделать этот процесс более управляемым.

Хенрик Уолтер

Обновление схемы

Вопрос В качестве инфраструктуры обмена сообщениями мы используем Microsoft Exchange Server 2010 SP1. Мы планируем развернуть Exchange Server 2010 SP2. Мы хотим это сделать как можно раньше, потому планируем использовать новые политики адресной книги.

Мы не совсем уверены, нужно ли в процессе подготовки к обновлению до Exchange 2010 SP2 подготавливать Active Directory командой Setup /PrepareAD. Достаточно ли обновления схемы командой Setup /PrepareSchema? Мы читали вопросы и ответы на странице вики TechNet, но там ничего не говорится о необходимости готовить Active Directory — только о схеме.

В своей тестовой среде мы выполнили только команду Setup /PrepareSchema и смогли без  проблем обновить серверы Exchange 2010 до SP2. Не могли бы вы прояснить ситуацию?

Ответ Перед обновлением сервера Exchange 2010 до SP2 надо расширить схему командой Setup /PrepareSchema. Вы также должны подготовить Active Directory командой Setup /PrepareAD. В небольших средах можно заставить мастер автоматически подготавливать группы для обновления. Это можно сделать, если в учетной записи, используемой для обновления, есть соответствующие разрешения.

В крупных корпоративных средах рекомендуется разносить подготовку схемы и Active Directory на отдельные операции. В большинстве корпоративных сред нужно использовать именно этот подход, так как обычно Active Directory управляется отдельно.

Похоже на то, что вы смогли обновить свои серверы Exchange 2010 в тестовой среде без команды Setup /PrepareAD, потому что использовали учетную запись с достаточными полномочиями.

Управление миграцией

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

Так как мы будем использовать панель управления стороннего производителя, мы хотели бы отключить доступ к функции «Manage My Organization» администраторов Exchange, которые используют Панель управления Exchange (ECP). Мы не хотим совсем закрыть доступ к ECP, а только к функции «Manage My Organization» (рис. 1). Не подскажете, возможно ли это?

Рис. 1. Можно отключить определенные функции

Ответ До Exchange 2010 SP2 это было невозможно, если только вы не использовали Exchange 2010 в режиме хостинга. Это не значит, что надо разворачивать Exchange 2010 в режиме хостинга. Мы как раз этого не советуем, а скорее рекомендуем использовать стороннюю панель управления для выполнения всей работы по подготовке среды и арендаторов.

При использовании Exchange 2010 SP1 в режиме хостинга мы рекомендовали отключить функцию «Manage My Organization» в ECP. Это можно сделать, изменив реестр, как описано в следующей статье: https://technet.microsoft.com/ru-ru/library/ff923250.aspx. Надо создать параметр типа DWORD по имени OMECPDisabled в разделе HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\ExchangeServer\v14. Заметьте, что этому параметру не нужно задавать значение (рис. 2).

Рис. 2. Довольно просто управлять доступом к ECP, используя параметры реестра

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

Рис. 3. После внесения изменений в реестр доступ к административным функциям закрыт

Как вы помните, ответ на вопрос начинался с фразы «До Exchange 2010 SP2». Этот параметр реестра не поддерживается Exchange 2010 не в режиме хостинга, если речь идет о версии Exchange 2010 SP1 или более ранней. Но есть и хорошие новости: в Exchange 2010 SP2 можно использовать этот же параметр для решения этой же задачи в средах с Exchange 2010 не в режиме хостинга.

Порты и миграция

Вопрос В настоящее время мы разворачиваем и конфигурируем среду Exchange 2010, в которую будем переходить с Exchange 2003 через некоторое время в этом году. Электронная почта критически важна для работы компании, поэтому мы развернем массив серверов клиентского доступа и группы доступности базы данных (DAG). Для балансировки нагрузки трафика среди серверов клиентского доступа мы планируем использовать аппаратный балансировщик. Мы слышали, что в такой ситуации неплохо сконфигурировать статические порты удаленного вызова процедур (RPC) на серверах клиентского доступа. Что вы думаете по этому поводу?

Ответ Если коротко, то ответ «да». Настоятельно рекомендуется сконфигурировать статические RPC-порты. Для этого есть несколько причин.

Во-первых, всегда лучше дружить с парнями, которые отвечают за сеть, безопасность и брандмауэр. Бесполезно просить оставлять открытыми целые диапазоны IP-адресов. Вместо этого вам придется попросить открыть всего лишь несколько портов. Если между подсетью клиентов и балансировщиком нагрузки с серверами Exchange 2010 располагается один или несколько брандмауэров и вы не сконфигурируете статические порты на серверах доступа к серверам клиентского доступа, придется попросить открыть огромный диапазон RPC-портов (а точнее, TCP-порт 135 и диапазон динамических портов 6005–59530).

Если же вы сконфигурируете статические RPC-порты, придется попросить открыть только три порта: TCP/135 (сопоставитель конечных точек TCP), порт, назначенный для вызова удаленных процедур на серверах клиентского доступа, и порт, назначенный службе адресной книги Exchange.

Во-вторых, если при использовании аппаратного балансировщика нагрузки не настроить статические RPC-порты, вы заметите, что нагрузка на память больше, чем при наличии статических портов. Кроме того, некоторые балансировщики нагрузки вообще не очень хорошо работают с диапазонами динамических портов. Ну и наконец, всегда проще настроить решение для мониторинга на наблюдение за тремя портами, чем за диапазоном динамических портов.

Подробнее о настройке RPC-портов почитайте в вики TechNet статью «Configure Static RPC Ports on an Exchange 2010 Client Access Server».

Хенрик Уолтер носит звание Microsoft Certified Master, а также MVP по Exchange 2007 и обладает более чем 16-летним опытом работы в ИТ. Занимает должность архитектора технологий в Trifork Infrastructure Consulting (компании, находящейся в Дании и обладающей званием Microsoft Gold Certified Partner), а также работает в качестве технического писателя для Biblioso Corp. (находящейся в США компании, специализирующейся в области услуг по управлению документацией и локализации). Хенрик также работает по контракту в командах различных продуктов (в том числе в командах Exchange и Lync ) в Microsoft. Связаться с Хенриком можно по электронной почте: v-henwal@microsoft.com.