Exchange_2010_режим_работы_леса

Заметки на полях

Перед установкой убедимся, что мы правильно создали записи DNS (MX, PTR) для заранее зарегистрированного домена. Если все в порядке, определимся с системными требованиями для сервера(-ов) и какие роли мы будем использовать.
Роли:
Роль сервера почтовых ящиков-отвечает за работу баз данных Exchange конкретного сервера
монтирование и обслуживания.
Роль сервера клиентского доступа — принимает клиентские подключения+аутентиф.
Роль транспортного сервера-концентратора — отвечает за маршрутизацию почты.
Роль пограничного транспортного сервера — принимает, фильтрует и перенаправляет почту(не требует AD, не сочетается с другими ролями, устанавливается обычно в DMZ. По моему мнению, дешевле использовать postfix, exim, sendmail .. т.к. кроме синхронизации других преимуществ не вижу).
Роль сервера единой системы обмена сообщениями.
Использовать в качестве операционной системы будем Win2k8r2, сервер является членом леса, режим работы леса Window server 2008 r2, хозяин схемы тоже Win2k8r2.
Устанавливать будем роли сервера клиентского доступа, транспортного сервера-концентратора, сервера почтовых ящиков.
Подготовим сервер для установки данных ролей( информация взята с http://technet.microsoft.com, другие варианты смотреть там же):
Введем в консоли Power Shell: Import-Module ServerManager

Далее установим нужные компоненты для выбранных ролей и перегрузимся : Add-WindowsFeature NET-Framework,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,NET-HTTP-Activation,Web-Asp-Net,Web-Client-Auth,Web-Dir-Browsing,Web-Http-Errors,Web-Http-Logging,Web-Http-Redirect,Web-Http-Tracing,Web-ISAPI-Filter,Web-Request-Monitor,Web-Static-Content,Web-WMI,RPC-Over-HTTP-Proxy -Restart

Далее запускаем установку MS Exchange 2010 с выбранными ролями, подготовку схемы AD оставим на «совести» инсталлятора.

К стати, дабы в Exchange 2010, оставить полный функционал общих папок, при установке у кажем что в организации присутствуют клиенты с установленным outlook 2003 🙂

Источник

Предварительные условия

• Система DNS для разрешения имен в лесах организации настроена правильно. Чтобы проверить, правильно ли настроена служба DNS, используйте средство проверки связи для проверки соединения с каждым лесом из других лесов организации и с сервера, на котором будет запущен агент синхронизации глобального списка адресов.

Развертывание системы Exchange 2010 в топологии перекрестного леса с помощью пакета обновления 1 (SP1) для диспетчера Identity Lifecycle Manager 2007 с пакетом дополнительных компонентов 1 (FP1)

1. Установите систему Exchange 2010 отдельно в каждом лесу. Чтобы установить Exchange 2010, выполните те же шаги, которые выполняются при установке сервера Exchange 2010 в топологии с одним лесом. Подробное описание выполняемых шагов см. в одном из следующих разделов:

Примечание.
В этом разделе предполагается, что топология Exchange 2007 или Exchange Server 2003 отсутствует. Если существует топология Exchange и ее требуется обновить, см. раздел Общие сведения об обновлении до Exchange 2010.

Настройка агента управления синхронизацией глобального списка адресов с помощью пакета обновления 1 (SP1) для диспетчера Identity Lifecycle Manager 2007 с пакетом дополнительных компонентов 1 (FP1)

Эту процедуру необходимо выполнить для развертывания системы Exchange 2010 в топологии перекрестного леса с помощью пакета обновления 1 (SP1) для диспетчера Identity Lifecycle Manager 2007 с пакетом дополнительных компонентов 1 (FP1). См. шаг 3 в подразделе «Развертывание системы Exchange 2010 в топологии перекрестного леса с помощью пакета обновления 1 (SP1) для диспетчера Identity Lifecycle Manager 2007 с пакетом дополнительных компонентов 1 (FP1)» выше в этом разделе.

В пакете обновления 1 (SP1) для диспетчера Identity Lifecycle Manager 2007 с пакетом дополнительных компонентов 1 (FP1) на панели инструментов выберите пункт Агенты управления, а затем в разделе Действия нажмите кнопку Создать.

Имя леса Имя исходного леса.

Примечание.
Также можно указать имя пользователя в следующем виде: @ и оставить поле «Домен» незаполненным.

Проверка подключения Remote PowerShell

В этом примере выполняется проверка возможности отправки вызова Remote PowerShell на сервер клиентского доступа Exchange 2010 для проверки работоспособности удаленной среды Remote PowerShell. На компьютере с установленным диспетчером Identity Lifecycle Manager 2007 выполните следующую команду:

$rs = new-pssession -conf microsoft.exchange -conn http://CAS_SERVER_NAME/powershell -auth kerberos -cred (get-credential)

Затем выполните следующую команду:

Источник

Exchange 2010 режим работы леса

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

1. Два леса и два корневых домена

Лес А. Режим работы леса Windows server 2008 r2
корневой домен firma1.local. Режим работы домена Windows server 2008 r2
Exchange 2010 SP4. Внешний почтовый домен firma1.ru

Лес В. Режим работы леса Windows server 2003.
корневой домен firma2.local. Режим работы домена Windows server 2003.
Exchange 2003 SP2 если не ошибаюсь. Внешний почтовый домен firma2.ru

Между лесами имеются доверительные отношения: тип доверия — лес, транзитивные. Леса территориально разнесены.

2. В лесе В мигрирую все контроллеры домена на win2k12 r2. Далее повышаю режим работы домена до Windows server 2012 r2, потом повышаю режим работы леса до Windows server 2012 r2.

Миграция с FSR на DFRS. Далее миграция с Exchange 2003 на Exchange 2010.

3. Далее руководством поставлена задача оставить только один домен, а так же один почтовый домен. Проблем с доменом нет, всех мигрируем в Лес В. А вместо леса А — будет выделен сайт NEW со своей подсетью относящийся к Лесу В. В Сайте NEW будет установлен полноценный контроллер домена.

Трудность заключается с почтовым доменом, а именно как спланировать инфраструктуру с Exchange. Пока есть следующие мысли

1. В лесу В (сайт — Default) после миграции будет свой Exchange server 2010 c ролями CAS/HUB/MBX — Exch01, и в сайте NEW так же будет свой Exchange server 2010 c ролями CAS/HUB/MBX — Exch02.

Т.е пользователи Леса В (сайт — Default) будут иметь почтовые ящики на Exch01, пользователи сайта NEW — на Exch02.

Отправка писем пользователей Леса В (сайт — Default) будет через свой HUB -Exch01, пользователей сайта NEW — через HUB — Exch02.

1. Будет ли CAS сервер правильно определять принадлежность Exchange к сайту, и соответственно к свой БД.

2. Как обеспечить 100% доставку писем в БД 2-х серверов Exchange.

Ведь если во внешнем DNS прописать

mail.firma1.ru A 1.1.1.1 — внешний IP адрес расположения Леса В (сайт — Default)

mail.firma1.ru A 2.2.2.2 — внешний IP адрес расположения сайта NEW

firma1.ru mx preference 10 mail.firma.ru

То отправляющий почтовый сервер может «дернуть» DNS, получить первую А-запись, отправить туда, а по факту получателя нет в этой базе данных Exchange. Т.е сообщение не дойдет до получателя, а отправителю придет NDR о том что такого пользователя нет в этой базе данных.

Вот тут у меня ступор. Подскажите как можно все это реализовать!

Источник

Exchange 2010 режим работы леса

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

1. Два леса и два корневых домена

Лес А. Режим работы леса Windows server 2008 r2
корневой домен firma1.local. Режим работы домена Windows server 2008 r2
Exchange 2010 SP4. Внешний почтовый домен firma1.ru

Лес В. Режим работы леса Windows server 2003.
корневой домен firma2.local. Режим работы домена Windows server 2003.
Exchange 2003 SP2 если не ошибаюсь. Внешний почтовый домен firma2.ru

Между лесами имеются доверительные отношения: тип доверия — лес, транзитивные. Леса территориально разнесены.

2. В лесе В мигрирую все контроллеры домена на win2k12 r2. Далее повышаю режим работы домена до Windows server 2012 r2, потом повышаю режим работы леса до Windows server 2012 r2.

Миграция с FSR на DFRS. Далее миграция с Exchange 2003 на Exchange 2010.

3. Далее руководством поставлена задача оставить только один домен, а так же один почтовый домен. Проблем с доменом нет, всех мигрируем в Лес В. А вместо леса А — будет выделен сайт NEW со своей подсетью относящийся к Лесу В. В Сайте NEW будет установлен полноценный контроллер домена.

Трудность заключается с почтовым доменом, а именно как спланировать инфраструктуру с Exchange. Пока есть следующие мысли

1. В лесу В (сайт — Default) после миграции будет свой Exchange server 2010 c ролями CAS/HUB/MBX — Exch01, и в сайте NEW так же будет свой Exchange server 2010 c ролями CAS/HUB/MBX — Exch02.

Т.е пользователи Леса В (сайт — Default) будут иметь почтовые ящики на Exch01, пользователи сайта NEW — на Exch02.

Отправка писем пользователей Леса В (сайт — Default) будет через свой HUB -Exch01, пользователей сайта NEW — через HUB — Exch02.

1. Будет ли CAS сервер правильно определять принадлежность Exchange к сайту, и соответственно к свой БД.

2. Как обеспечить 100% доставку писем в БД 2-х серверов Exchange.

Ведь если во внешнем DNS прописать

mail.firma1.ru A 1.1.1.1 — внешний IP адрес расположения Леса В (сайт — Default)

mail.firma1.ru A 2.2.2.2 — внешний IP адрес расположения сайта NEW

firma1.ru mx preference 10 mail.firma.ru

То отправляющий почтовый сервер может «дернуть» DNS, получить первую А-запись, отправить туда, а по факту получателя нет в этой базе данных Exchange. Т.е сообщение не дойдет до получателя, а отправителю придет NDR о том что такого пользователя нет в этой базе данных.

Вот тут у меня ступор. Подскажите как можно все это реализовать!

Источник