Tw-city.info

IT Новости
0 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Exchange два домена

Exchange два домена

Вопрос

Что бы не путаться с другими моими вопросами спрашиваю отдельно.

Внешний домен принадлежит организации вида abc.ru

Внутренний домен в AD msk.abc.ru

Почта на Exchange 2013cu8 (лицензия стандарт) у сотрудников адреса вида ivanov@abc.ru

Большей части сотрудников офиса (компьютеры все в домене) с определенной даты нужно поменять почту на новый купленный домен newfirma.ru и соответственно меняется почта с ivanov@ abc.ru на ivanov@ newfirma.ru

1/Крупными мазками, какие процедуры настроек необходимы для этого на сервере после правильной настройки mx записей днс нового домена.

2/Как переход на новую почту будет выглядеть в плане настроек у конечного пользователя? на ПК и на смартфонах.

  • Изменено Menhatep7 20 ноября 2015 г. 12:49

Ответы

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

В почтовом ящике, у пользователя есть настройка, которая позволяет отключить обновление емайл адреса в соответсвии с политикой, и тогда можно руками править.

В политику «по умолчанию» можно добавить новый домен и указать его основным, в итоге у всех пользователей будут два имейла и новый будет основным.

Можно в политику «по умолчанию» добавить фильтр и тогда дефолтная политика не будет применять к объектам которых Вы добавите в исключения, а в новой политике наоборот, указать к каким объектам применить.

  • Помечено в качестве ответа Menhatep7 24 декабря 2015 г. 18:45

Сертификат сейчас на сервере дефолтный, самозавереный. Было желание сделать все по человечески но не хватило ресурсов на задачу.

Если на exchange работают два домена возможно заказать в соответствующих организациях валидный мультидоменный сертификат где будут оба домена? или это проблема?

Или ограничится покупкой валидного мультидоменного сертификата только под новый домен? Визуально получится сервер exchange. msk.abc.ru а почта вида ivanov@ newfirma.ru, на сколько это «нормально» для нашего времени?

Мало информации для размышлений.

Один сертификат с несколькими доменными именами. Но начиная с 1 ноября 2015 нельзя вписывать локальные имена типа EX2013 mysuperdomain.lan, .local и так далее. Уже выданные сертификаты с локальными именами продлеваться не будут и их автоматический отзовут 01.11.2016

Зависит, от того, что Вы в итоге хотите получить.

Если для доступа к сервисам будет использоваться только один домен типа newfirma.ru, а *@abc.ru будет использоваться как дополнительный smtp адрес, то список выше можно изменить таким образом:

1. Приобрести сертификат для newfirma.ru (SAN или Wildcard Вам выбирать) SAN Or Wildcard?

2. Убедитесь, что у Вас есть резервная копия всего и вся, и что копия рабочая.

3. Добавьте обслуживаемый домен Newfirma.ru Обслуживаемые домены

4. Создайте политику адресов для Newfirma.ru и примените ее на получателей. Политики адресов электронной почты

5. Добавьте-измените записи в DNS для нового домена: MX, PTR, SPF, CNAME для autodiscover. «A» mail.newdomain.ru.

6. Установите новый сертификат и назначьте его службам.

7. Измените адреса для: OWA, ECP, Autodiscover, Outlook Anywhere и т.д.

8. Добавьте UPN суффикс newfirma.ru и сделайте его дефолтным для пользователей ЕХ, иначе в некоторых случаях придется вводить пароль типа localdomainnamepassword.

9. Проверьте работу всего и вся. В помощь: Microsoft Remote Connectivity Analyzer

10. Подготовьте инструкции для пользователей и сообщите им новые адреса сервисов.

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

Если что-то забыл сильно не ругайте.

  • Предложено в качестве ответа Morozov A. _ 23 ноября 2015 г. 8:56
  • Изменено Zaza Abramov 24 декабря 2015 г. 8:29
  • Помечено в качестве ответа Alexander Rusinov Moderator 24 декабря 2015 г. 18:44

Все ответы

Если меняется только почтовый домен, то есть только адреса пользователей, то сперва нужно:

1. Добавить обслуживаемый домен Newfirma.ru Обслуживаемые домены

2. Cоздать политику адресов для Newfirma.ru и применить на получателей. Политики адресов электронной почты

3. После этого добавлять новые записи MX. (Наверно энное количество времени придется оставить и старый домен, пока все корреспонденты не узнают о смене адресов.)

Скорее всего придется обновить SSL сертификат.

  • Изменено Zaza Abramov 20 ноября 2015 г. 13:02

Сертификат сейчас на сервере дефолтный, самозавереный. Было желание сделать все по человечески но не хватило ресурсов на задачу.

Если на exchange работают два домена возможно заказать в соответствующих организациях валидный мультидоменный сертификат где будут оба домена? или это проблема?

Или ограничится покупкой валидного мультидоменного сертификата только под новый домен? Визуально получится сервер exchange. msk.abc.ru а почта вида ivanov@ newfirma.ru, на сколько это «нормально» для нашего времени?

2 сертификата вы не повесите.

нужен 1 сертификат на несколько имен.

Сертификат сейчас на сервере дефолтный, самозавереный. Было желание сделать все по человечески но не хватило ресурсов на задачу.

Если на exchange работают два домена возможно заказать в соответствующих организациях валидный мультидоменный сертификат где будут оба домена? или это проблема?

Или ограничится покупкой валидного мультидоменного сертификата только под новый домен? Визуально получится сервер exchange. msk.abc.ru а почта вида ivanov@ newfirma.ru, на сколько это «нормально» для нашего времени?

Мало информации для размышлений.

Один сертификат с несколькими доменными именами. Но начиная с 1 ноября 2015 нельзя вписывать локальные имена типа EX2013 mysuperdomain.lan, .local и так далее. Уже выданные сертификаты с локальными именами продлеваться не будут и их автоматический отзовут 01.11.2016

Зависит, от того, что Вы в итоге хотите получить.

Если для доступа к сервисам будет использоваться только один домен типа newfirma.ru, а *@abc.ru будет использоваться как дополнительный smtp адрес, то список выше можно изменить таким образом:

1. Приобрести сертификат для newfirma.ru (SAN или Wildcard Вам выбирать) SAN Or Wildcard?

2. Убедитесь, что у Вас есть резервная копия всего и вся, и что копия рабочая.

3. Добавьте обслуживаемый домен Newfirma.ru Обслуживаемые домены

4. Создайте политику адресов для Newfirma.ru и примените ее на получателей. Политики адресов электронной почты

5. Добавьте-измените записи в DNS для нового домена: MX, PTR, SPF, CNAME для autodiscover. «A» mail.newdomain.ru.

6. Установите новый сертификат и назначьте его службам.

7. Измените адреса для: OWA, ECP, Autodiscover, Outlook Anywhere и т.д.

8. Добавьте UPN суффикс newfirma.ru и сделайте его дефолтным для пользователей ЕХ, иначе в некоторых случаях придется вводить пароль типа localdomainnamepassword.

9. Проверьте работу всего и вся. В помощь: Microsoft Remote Connectivity Analyzer

10. Подготовьте инструкции для пользователей и сообщите им новые адреса сервисов.

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

Если что-то забыл сильно не ругайте.

  • Предложено в качестве ответа Morozov A. _ 23 ноября 2015 г. 8:56
  • Изменено Zaza Abramov 24 декабря 2015 г. 8:29
  • Помечено в качестве ответа Alexander Rusinov Moderator 24 декабря 2015 г. 18:44

Для внешних подключения SAN сертификат покупать совсем не обязательно. Подойдет самый дешевый, с одним именем DNS. Вот посмотрите статью:

Для внутренних подключений можно либо настроить сертификат, выданный доменным СА, либо добавить в DNS внешние домены (зоны) и указать локальные IP для Exchange.

Вот ссылка на аналогичное обсуждение:

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

Прошу уточнить про переходный период.

Если не покупать сертификат и использовать текущий, создать политику для новых адресов и применить ее.

Создавая новый ящик я уже получу его с адресом нового домена?

А что при этом с политикой для старого домена?

Не совсем пока понятно, нужно быстро в не рабочее время всех перекинуть в новый домен или можно постепенно не спеша переводить? (будут при этом у новых пользователей работать почта в новом домене а у «старых» старая?

> Создавая новый ящик я уже получу его с адресом нового домена?

Да — при условии, что новая политика будет применяться ко всем ящикам (состояние по умолчанию).

> А что при этом с политикой для старого домена?

Ничего. Останется и будет прекрасно создавать адреса для ящиков, если только вы ее не удалите. Если удалите, новые ящики не будут получать эти адреса, но старые адреса на уже существующих ящиках никуда не денутся.

При наличии нескольких действующих политик следует аккуратно выбрать новый домен/политику по умолчанию. Именно адреса этого домена будут указываться в качестве обратных в исходящих письмах. Собственно, достаточно сделать адрес в новом домене адресом по умолчанию, и через какое-то время у всех внешних адресатов, пользующихся кнопкой Reply, будут новые адреса старых корреспондентов.

> Не совсем пока понятно, нужно быстро в не рабочее время всех перекинуть в новый домен или можно постепенно не спеша переводить?

Нет никаких «перекинуть» и «переводить». Есть адреса на почтовых ящиках и почтовые/Интернет-домены, которые прекрасно могут существовать параллельно. Добавление нового в вашем случае вовсе не означает необходимости убивать старое. Более того, это строго противопоказано — что, если у вашей фирмы есть ключевой заказчик, которому захочется написать письмо на старый адрес на следующий день после того, как вы ликвидируете старый домен?

Evgeniy Lotosh // MCSE: Server infrastructure, MCSE: Messaging

Обслуживаемые домены Exchange 2013

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

Читать еще:  Как добавить домен в список разрешенных

Эта статья является третьей из цикла, в котором освещены вопросы обязательных задач по настройке сервера Exchange 2013 сразу после его установки. Если вам интересны другие задачи, рекомендую обратиться к головной статье по настройке — Настройка Exchange 2013 или основной статье тематики — Exchange 2013 — Установка, настройка, администрирование.

При установке Exchange 2013 автоматически создается один единственный обслуживаемый домен 1 , он же является и основным:

По умолчанию при развертывании новой организации Exchange 2013 в лесу Active Directory Exchange использует имя домена Active Directory, в котором была выполнена команда Setup /PrepareAD. Если необходимо, чтобы получатели получали и отправляли сообщения пользователям в другом домене, необходимо добавить его в качестве обслуживаемого. Этот домен также добавляется в качестве основного SMTP-адреса электронной почты по умолчанию политики адресов в следующем действии.

Поскольку я выполнял установку Exchange в домене corp.bissquit.com (подробнее об установке читайте в моей статье Exchange 2013 — Установка на Windows Server 2012 R2), то и единственным автоматически созданным доменом организации у меня будет именно corp.bissquit.com. Скажу прямо, что это не тот домен, с/на который я бы хотел отправлять/получать почту по умолчанию. Идти в EAC и удалять этот домен совсем не обязательно, лучше создать дополнительный обслуживаемый домен. В моем случае это будет bissquit.com. Если в будущем вы решите добавить возможность приема почты на созданный по умолчанию домен (благо в моем случае это вполне реально, поскольку домен AD совпадает с реальным публичным доменом), это можно будет реализовать с минимальными трудозатратами 2 .

Тем не менее есть ряд случаев, когда одного домена недостаточно, вот некоторые из них:

  • Слияние организаций, когда несколько почтовых серверов разных компаний объединяются в один, а лишние удаляются;
  • В некоторых случаях используются технические домены третьего уровня для отправки служебных данных, а сотрудники отправляют почту с основного домена второго уровня;
  • В организации идет переезд с одного на другой основной домен и некоторое время (или всегда) будет требоваться поддерживать возможность приема/отправки почты на оба домена организации.

В таких ситуациях нужно подключать дополнительные обслуживаемые домены.

Дополнительные обслуживаемые домены Exchange 2013

Итак, через EAC добавить дополнительный обслуживаемый домен Exchange 2013 можно следующим образом:

Поток обработки почтыОбслуживаемые домены — Создать (значок «+»):

Как можно видеть на скриншоте выше, существуют несколько типов обслуживаемых доменов 3 . Домены ретрансляции пока нам не нужны, поэтому оставляем по умолчанию пункт — «Заслуживающий доверия домен».

Аналогичные действия через Powershell выполняются с помощью командлета New-AcceptedDomain 4 , результат проверяется с помощью Get-AcceptedDomain 5 :

[PS] C:Windowssystem32>New-AcceptedDomain -Name bissquit.com -DomainName bissquit.com -DomainType Authoritative
[PS] C:Windowssystem32>Get-AcceptedDomain

На данный момент мы имеем уже два домена. Допустим в будущем я планирую организовать отправку/прием почты с доменов третьего уровня — tech.bissquit.com, corp.bissquit.com. Второй домен уже создан по умолчанию, а вот первый надо создать вручную. Выполним аналогичную команду:

[PS] C:Windowssystem32>New-AcceptedDomain -Name tech.bissquit.com -DomainName tech.bissquit.com -DomainType Authoritative

У внимательного читателя, знакомого немного с Exchange 2013, может возникнуть вопрос — «а почему бы не создать один домен и включить в него все домены третьего уровня?». Действительно, так можно сделать — нужно просто при создании дополнительного домена «включить» в него также все поддомены. Запись домена будет иметь вид — *.bissquit.com. Однако если вы точно знаете какие домены третьего уровня у вас будут использоваться, лучше так не делать вот почему:

  1. Во-первых, вы лишитесь гибкого управления адресами через политики адресов электронной почты;
  2. Во-вторых, вы не получите никакого выигрыша в администрировании — создать доп. обслуживаемые домены Exchange 2013 проще простого и трогать его в будущем вероятнее всего не придется (это вам не администрирование БД);
  3. В-третьих, если вы хотите принимать почту на поддомены, вам все равно придется создавать для них необходимый набор DNS-записей, что тоже само по себе значительно более трудоемко, чем выполнить одну команду для создания доп. домена в Exchange.

Кстати, есть одна интересная вещь:

Если выполнить команду…

[PS] C:Windowssystem32>Get-AcceptedDomain -Identity tech.bissquit.com | Format-List

. то мы получим подробную информацию о конкретном обслуживаемом домене. При этом свойств домена будет значительно больше, чем можно задать через командлет New-AcceptedDomain. Можно обратиться к информации о Set-AcceptedDomain 6 , чтобы лучше узнать какой параметр что означает. Кстати, там же вы найдете информацию о том, чем отличается «домен по умолчанию» от других:

Обслуживаемый домен по умолчанию используется в адресах электронной почты отправителей, у которых нет SMTP-адресов (например, адреса X.400). Адреса электронной почты, не являющиеся адресами SMTP, инкапсулируются в SMTP-адресах с помощью метода инкапсуляции Internet Mail Connector Encapsulated Address (IMCEA). В методе инкапсуляции IMCEA используется значение домена по умолчанию в SMTP-адресе электронной почты.

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

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

Настройка двух серверов Exchange для приема почты на своих старых доменах при отправке и получении с использованием того же нового домена

Сцена: слияние двух компаний. Один из запущенных Exchange 2010, другой Exchange 2003, оба имеют схемы Active Directory на сервере 2003, SP 2.

Краткосрочная цель: установить доверие между обоими доменами, чтобы каждая компания могла получить доступ к глобальному списку адресов (GAL) друг друга и к данным Free / Busy. Затем найдите способ отправки / получения почты с использованием того же имени домена.

Долгосрочная цель: перенести обе компании в третий домен и среду Exchange 2010.

Вопрос: Как настроить два текущих сервера Exchange не только на получение почты на своих старых доменах, но и на отправку и получение почты с использованием нового домена? Трюк, когда почта отправляется между ними, должна оставаться внутри внутренней сети.

Бонусный вопрос: Как это сделать, если оба сервера Exchange были в 2010 году?

2 ответа

Внутренняя маршрутизация

Внутренне серверы Exchange с помощью Active Directory будут обрабатывать детали маршрутизации и передавать сообщения без SMTP.

Получение внешней почты SMTP

Чтобы сохранить старые домены:

Чтобы добавить новый домен:

Документация Exchange 2003:

Дополнительная информация

Да, те статьи, которые вы упомянули, в значительной степени позаботятся о том, что вам нужно будет сделать. Как вы отправляете / получаете электронную почту извне? Вы используете сервер Exchange Edge или что-то еще? Недавно мне пришлось сделать что-то подобное, потому что я переезжаю свою компанию на Exchange 2010 из сторонней системы электронной почты, и оба они должны существовать одновременно в течение некоторого времени. У меня есть спам-фильтр Barracuda для внешней почты, но вы должны быть в состоянии сделать то же самое с тем, что используете. Это также будет зависеть от того, сервер Exchange 2010 сможет обрабатывать почту для обеих сторон, потому что я знаю, что Exchange 2010 имеет функции, которые мне нужно использовать.

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

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

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

Exchange два домена

Войти

Как я переводил юзеров и их почту из домена windows 2003 на новый домен windows 2008 r2

«Небольшую» заметку я начал еще писать во вторник, когда проводил подготовку к миграции пользователей со старого домена на новый. Главное тут хороший план и понимание чего вы делаете и к чему стремитесь. Мой план все время дополнялся, все время всплывали какие то мелочи которые нужно будет учесть после «разъезда», надо было уже сейчас решить кто заберет «холодильник» и как другая сторона его заменит, разорватьраспилить «холодильник» как понимаете не возможно, для этого и создается план.

Удобно делать переезд на одинаковую структуру сети и сервисов, но когда надо их раздублировать, или переехать и часть сети уничтожить – это другой вопрос, так же процесс будет чуточку другой когда в процессе переезда хочется проапгрейдить софтовую часть, использовать более новые версии ПО и железа.

Читать еще:  Настройка доменного имени

Для обеспечения миграции пользователей (с их паролями и SID данными) нам поможет утилитка ADMT 3.2, по этой теме есть много статей, но чтот все они с косяками. Значится я буду описывать свой путь:

Повторюсь, миграция у нас происходит из домена под управлением Windows 2003 на Windows 2008 R2. Задача:

· перенести пользователей из домена win2k3 в домен win2k8r2

· перенести почтовое хранилище exchange 2007 на exchange 2010 (ящики пользователей)

· запомнить их разрешения в старой сети

· сохранить профили пользователей на рабочих компьютерах

Часть то как поднять новый домен на windows 2008 R2 мы конечно же опустим, зачем нам тут рассписывать и так понятные вещи.

Чтобы выполнить первый пункт поставленных задач, нам нужно настроить трасты между доменами. В этом поможет вам AD Domain and Trusts. Открываем, выбираем свой домен, выбираем Properties, вкладка Trusts, кнопка New trust. Вводим имя домена с которым мы собираемся установить доверительные отношения, обязательно выбираем в следующем окне – Two way transitive, и Both for this domain and the specified domain. После добавления и проверки трастов, нам нужно подготовить сервера к миграции по средствам ADMT 3.2

1. Если в исходном домене присутствуют ПК, под управлением ОС Windows XP, Vista (до SP1), 2000, а КД целевого домена под управлением ОС Windows 2008 и выше, то необходимо на каждом контроллере целевого домена создать ключ реестра:

тип : REG_DWORD (32 бит )

2. Включение политики аудита. Так же необходимо настроить политику аудита в обоих доменах. Для этого править групповую политику Default Domain Controller Policy: Computer Configuration-Polices-Windows settings-Security-Local-Audit. Устанавливаем политики «Audit account management» в Success и Failure, а «Audit directory service access» в Success.

3. Выключение фильтрации SID: Выполняется в обоих доменах, во избежании возможных проблем при переносе истории SID.

Netdom trust target.local /domain: source.local /quarantine:No /userD:administrator/passwordD:Pass

Следует заметить что эта команда врятли у вас сразу заработает (у меня все время писало Access Denied), решение оказалось очень простым. Пользователь под которым выполняется данная команда, должен быть добавлен в Build-inAdministrators обоих доменов. Т.е. для win2k3 домена пользователя administrator добавляем в Build-inAdministrators домена win2k8 и наоборот.

  1. Установим PES ( Password Export Server ) в домене win 2 k 3 (т.е. из которого мы будем пользователей в новый домен переносить). PES нужна для того чтобы пользователи перенеслись с их существующими паролями.

Подготовка к установке Password Export Server проста, на win2k8 (на который вы установили ADMT 3.2), нужно выполнить следующую команду:

admt key /option:create /sourcedomain: /keyfile: /keypassword:

в SourceDomain надо вписать NetBios или FQDN имя домена на windows 2003 из которого будут переноситься пользователи в новый домен.

Далее создастся файлик по адресу KeyFilePath который нужно будет при установке PES на win2k3 указать.

На самом деле ADMT 3.2 нам понадобится позже, когда будет выполнена миграция пользователей с их ящиками из old forest в котором стоит exchange 2007 sp2 (у меня стоял sp3) в new forest в котором стоит exchange 2010 sp 1.

Сейчас же мы займемся подготовкой к переносу почтовых ящиков из 2007 в 2010 excha n ge.
Microsoft уже о нас позаботилась и создала powerShell скрипт который обеспечит подготовку для осуществления нормального переноса почтовых ящиков.

Открываем Exchange Management Shell

$localcredential = Get-Credential (вводим имя и пароль админа в новом лесудомене)

$remotecredential = Get-Credential (вводим имя и пароль админа в старом лесудомене)

Сразу хочу обратить внимание, что у данного юзера должны быть полные права на работу с Exchange сервером. Желательно пользователя из нового доменалеса прописать на Exchange 2007 сервере в администраторах системы (и добавить в доменные администраторы домена), а пользователя из старого доменалеса прописать на Exchange 2010 сервере и администраторах системы (так же добавить в доменные администраторы нового доменалеса), не забываем про группы Exchange Server итд.

Далее выполняем скрипт который находится по адресу — C:Program FilesMicrosoftExchange ServerV14Scripts

[PS] C:Program FilesMicrosoftExchange ServerV14Scripts>.Prepare-MoveRequest.p s1 -Identity test1@old.domain.ru –RemoteForestDomainController dc.old.domain.ru –RemoteForestCredential $remotecredential -LocalForestDomainController dc.new.domain.ru -LocalForestCredential $localcredential

RemoteForestDomainController dc.old.domain.ru контроллер домена в старом лесу

RemoteForestCredential $remotecredential — логин пароль для подключения к старому лесу (смотрим выше)

LocalForestCredential $localcredential логин пароль для подключения к новому лесу (смотрим выше)

После выполнения команды видим:

Appending x500:/o=old_domain /ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=test1 to proxyAddresses of New Object in Local forest.

Appending x500:/o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=test1 89572ff4 to proxyAddresses of Object(CN=test1,OU=TEST,DC=dik,DC=udm,DC=r u) in Source forest.

Preparation for test1@dik.udm.ru done.

1 mailbox(s) ready to move.

Через какое то время после тестов у меня началось вываливание ошибки вот такой:

Appending x500:/o=old_domain/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=test4 to proxyAddresses of New Object in Local forest.

Could not find the default Administrative Group ‘Exchange Administrative Group (FYDIBOHF23SPDLT)’.

+ CategoryInfo : NotSpecified: (0:Int32) [Update-Recipient], DefaultAdminist. tFoundException + FullyQualifiedErrorId : 277BF097,Microsoft.Exchange.Management.R ecipientTasks.UpdateRecipient

Preparation for test4@dik.udm.ru done.

1 mailbox(s) ready to move.

Очень прискорбно и не понятно откуда растут ноги, придется еще и апдейтить только что перенесенного юзера, командой Update-Recipient test1

Далее переносим его ящик.

[PS] C:Program FilesMicrosoftExchange ServerV14Scripts> New-MoveRequest -Identity test1@old.domain.ru -RemoteLegacy -TargetDatabase «WG Hight availability» -RemoteGlobalCatalog dc.old.domain.ru -RemoteCredential $remotecredential -TargetDeliveryDomain new.domain.ru

-Identity test1@old.domain.ru — пользователь

-RemoteLegacy — команда говорит о том что в старом лесу нет Client Access Server Exchange 2010

-TargetDatabase «WG Hight availability» — в какую базу сохранить перетаскиваемый ящик пользователя

-RemoteGlobalCatalog dc.old.domain.ru — сервер на котором находится домен

-RemoteCredential $remotecredential — имя пользователя и пароль для подключения к старому доменулесу

-TargetDeliveryDomain new.domain.ru — имя нового домена для использовании его в smtp для только что перенесенного пользователя

Возможно вы захотите поставить лимит на количество багнутых элементов при переносе ящика, тогда нужно использовать ключ BadItemLimit. Сразу хочу сказать, что поврежденные элементы не скопируются.

После данной команды мы видим:

DisplayName Status TotalMailboxSize TotalArchiveSize PercentComplete

test4 Queued 0 B (0 bytes) 0

наблюдать за процессом выполнения можно в EMC, открываем ее, далее Recipient Configuration, там выбираем Move Request и смотрим как выполняется задача.

После завершения данной процедуры у нас появился новый пользователь из старого домена, и перенеслась вся его почта, но зайти мы пока туда не можем J

Пользователь не активен т.к. у него нет пароля, а раз нет пароля то система не даст его активировать потому что пароль не удовлетворяет политике безопасности.

Самый простой вариант чтобы ничего не сломать, это запустить ADMT в новом домене и перенести пользователей из старого, чем мы собственно и займемся сейчас.

Запускаем ADMT, выбираем User Account Migration.

  1. Source – старый домен и Domain Controller

Target – новый домен и Domain Controller

  1. Select users from domain
  2. Выбираем пользователей

4. Указываем куда мы их будем переноситьсохранять в новом домене

5. Выбираем Migrate passwords, сервер уже по умолчанию выбран как old_domain, обязательно на данном сервере включите службу Password Export Server Service – после установки PES эта служба ставится в ручной запуск.

6. В Target Accont State выбираем – Enable target account, так же надо поставить галочку Migrate users SIDs to target domain, остальное «по вкусу».

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

8. Тут я использовал только Fix users group membership

9. Ставим Exclude specific object properties from migration, выбираем object type – User, и добавляем все поля в сторону Excluded Properties, потом выбираем InetOrg Person и делаем то же самое. Для чего делаем, чтобы у нас профиль не сломался, т.к. при совмещении текущего (нового профиля без пароля) и старого профиля произойдет переписание его прав и параметров, что в конечном счете навредит настройкам в Exchange 2010 и ящик предется переподключать (нахера нам лишняя работа). В общем щелкаем Next

10. Выбираем migrate and merge conflict objects, при этом галки не ставим (снимаем)

11. Next и Finish, пользователю успешно был добавлен пароль.

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

Далее остается только в AD Users and Computers подправить разрешения на смену пароля, добавить не достающие группы пользователям (группы я не переносил, т.к. структуру мы полностью изменили). Так же в свойствах всех перенесенных пользователях в AD Users and Computers нужно поставить галки по вкусу типа — сменить пароль при первом входе, срок действия пароля итд. Т.к. при переносе пользователя и переносе его старого пароля, галка «сменить пароль при первом входе в систему — СТОИТ» — чтобы пользователь не мучался, ее лучше убрать (хотя все зависит от политики внутри вашей компании).

Рекомендуется это все проделывать как в виртуальной среде, так и на рабочей структуре с только что созданными для теста пользователями, проверить лучше несколько раз, пока не поймете где какие проблемы могут вас поджидать. Переносить пользователей и почту на горячую голову – не стоит, убить процесс и дойти до point of no return в этом деле очень легко.

Все это показывалось на примере с 1 пользователем, а как обстоят дела со множеством?

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

Читать еще:  Понизить контроллер домена до рядового сервера

[PS] C:Windowssystem32>get-user | where <$_.Company -ilike "WG">| Export-Csv -notypeinformation c:users.csv

Обратно запихать при помощи:

Import-Csv Test.csv | Prepare-MoveRequest.ps1 -RemoteForestDomainController DC001.Fabrikam.com -RemoteForestCredential $UserCredentials

ну и если надо то

Import-csv test.csv | update-recipients

далее запускаем команду New-MoveRequest по аналогии

Напоследок скажу:
сеть между двумя exchange 2007 и exchange 2010 серверами — Gigabit на Cisco 3750
пользователей было 150 (если не изменяет память)
Общее кол-во ГБ информации

200
Переносилось все на протяжении 3,5 суток.
В общем долго,нудно, это тоже нужно учитывать!

В общем как то так! Удачи в этом не легком деле! J

Для системного администратора

Разделение пространства имен Exchange 2007

В этой статье я покажу вам, как разделить ваше пространство имен Exchange Server 2007 SMTP с другой системой для обмена сообщениями. Разделение пространства имен SMTP namespace может понадобиться в том случае, когда возникла необходимость слияния, или если вы хотите использовать его совместно с другой системой. Я также покажу вам, как создать внешние и внутренние почтовые домены (relay domain).

Давайте предположим, что у вас две различные структуры Exchange, которые работают на Exchange Server 2007. Эти две структуры должны найти друг друга в результате слияния или поглощения, поэтому возникает необходимость разделения пространства имен SMTP namespace не неопределенный период времени, пока обе системы не будут интегрированы в единую структуру Exchange Server 2007. В другой части этой статьи мы поговорим о настройке внешних и внутренних почтовых доменах (mail relay domain), а также предположим, что одна из структур Exchange отвечает за передачу электронной почты для обеих доменов (A.DOM и B.DOM).

Обычные домены (Accepted Domain)

Когда вы создаете обычный новый домен в Exchange Server 2007, вы должны выбрать один из следующих типов доменов:

  • Authoritative domain (управляющий)
  • Internal relay domain (внутренний почтовый)
  • External relay domain (внешний почтовый)

Обычный домен – это любое пространство имен SMTP namespace, за которое отвечает ваша структура Exchange Server 2007, и в рамках которого вы будете отправлять и получать электронную почту. Microsoft называет этот процесс “authoritative” (управление). Вы должны создать управляющие домены с помощью консоли управления Exchange Management Console или управляющей оболочки Exchange Management Shell.

Настройка обычных доменов

Обычные домены настраиваются с помощью параметров в консоли управления Exchange Management Console (EMC), которые требуют прав администратора структуры Exchange (Exchange Organization administrator). Обычные домены создаются для всей структуры Exchange на транспортных серверах Hub Transport Server или Edge Transport Server. Если вы реализовали роль транспортного сервера Edge Transport server, то компания Microsoft рекомендует вам синхронизовать все обычные домены в вашей внутренней структуре Exchange с помощью Edge Sync, чтобы вам необходимо было создавать обычные домены только один раз. Каждый вновь созданный обычный домен будет скопирован на транспортный сервер Edge Transport server.

Управляющий домен (Authoritative domain)

Exchange Server 2007 создает новый обычный домен в процессе установки первого транспортного сервера Hub Transport Server. Управляющий домен (authoritative domain) создается с внутренним именем домена Active Directory, а не с зарегистрированным доменным именем SMTP, которое используется в Internet для отправки и получения электронных писем. Например, если ваше внутреннее доменное название в Active Directory – A.DOM, а зарегистрированное доменное название SMTP – A.COM, то обычный управляющий домен будут создан под именем A.DOM, и вы должны будете создать дополнительный управляющий домен SMTP для зарегистрированного домена SMTP.

Примечание:Если установлен сервер Exchange Server 2007 с серверной ролью Edge server role, то автоматически не будет создано ни одного обычного домена. Вы должны будете создать управляющие домены вручную, или синхронизовать эти обычные домены с вашей внутренней структурой Exchange с помощью Edge.

Разделение пространства имен SMTP

Разделение пространства имен SMTP namespace sharing в Exchange Server 2007 гораздо проще, чем в предыдущих версиях Exchange Server. Все, что вам необходимо сделать, это создать новый обычный домен с типом Internal relay domain (внутренний почтовый домне) для пространства имен SMTP namespace, которое вы хотите разделить. На втором этапе вы должны создать коннектор SMTP connector с адресным пространством для внутреннего домена SMTP. Конечным почтовым сервером должен быть транспортный сервер Hub Transport Server. Конечная почтовая система отвечает за формирование отчетов о доставке NDR (Non Delivery Reports).


Рисунок 1: Разделение пространства имен SMTP (namespace sharing)

Как вы можете увидеть из рисунка выше, Exchange принимает сообщения от A.DOM (запись MX указывает на шлюз SMTP). Транспортный сервер Microsoft Edge Transport server передает электронные письма на внутренний транспортный сервер Hub Transport Server, который в свою очередь доставляет электронные сообщения адресатам. Если получатель не является локальным, то Exchange обращается к коннектору SMTP connector с соответствующим адресным пространством (если домен существует в качестве внутреннего почтового домена) и передает сообщения в этот домен.

Почтовые домены

Если Exchange Server 2007 не отвечает за определенный домен, а запись DNS MX указывает на транспортный сервер Hub Transport или Edge Transport server, то передающий почтовый сервер посылает электронную почту в структуру Exchange. Если домен SMTP не является частью управляющего домена, то отсылающий сервер пытается передать через сервер Exchange. Exchange Server 2007 получает это сообщение и передает его на внешний почтовый домен или внутренний почтовый домен.

Внутренний почтовый домен (Internal Relay Domain)

Если вы настраиваете внутренний почтовый домен (internal relay domain), то вы будете передавать все электронные сообщения, которые не имеют соответствующего почтового ящика в структуре Exchange, но которые имеют контакты в этой структуре Exchange. Контакты имеют электронный адрес в других системах для обмена сообщениями. Электронные письма из Интернет предаются в этот домен с помощью транспортных серверов Hub Transport server в этой структуре Exchange.

Если в вашей организации есть два леса с установленным Exchange Server 2007 и вы хотите разделить электронные письма, или подключить поток сообщений SMTP message flow между этими двумя структурами Exchange, то вы должны использовать систему, которая синхронизирует оборот между этими двумя лесами. Например, вы можете использовать IIFP (Identity Integration Feature Pack), бесплатный продукт Microsoft, или его большого брата MIIS (Microsoft Identity Integration Server). Электронные сообщения из интернет, которые адресованы получателям во внутреннем почтовом домене, передаются и обрабатываются транспортным сервером Edge Transport server (если это реализовано), а затем передаются на транспортные сервера Hub Transport server в той же самой структуре Exchange. Транспортный сервер Hub Transport, который отвечает за маршрутизацию электронных сообщений, передает сообщение на транспортный сервер Hub Transport server в другой структуре Exchange. Все, что вам необходимо сделать – это создать коннектор для отправки (send connector) в структуре Exchange, который передает сообщения в структуру Exchange и обычный домен типа Internal relay.


Рисунок 2: Внутренний почтовый домен (Internal relay domain)

Внешний почтовый домен (External Relay Domain)

Внешний почтовый домен немного отличается от внешнего почтового домена. Когда вы настраиваете внешний почтовый домен (external relay domain), сообщения будут пересылаться на почтовый сервер за пределами вашей структуры Exchange. Сообщения, адресуемые внешнему почтовому домену, передаются с помощью транспортного сервера Exchange Server 2007 Edge Transport Server. Этот сценарий достаточно прост. МХ запись (Mail Exchanger) на внешнем почтовом домене настраивается на передачу писем в структуру Exchange 2007. Сервер Exchange Server принимает электронные сообщения для этого домена с помощью коннектора отправки SMTP send connector, который вы должны настроить. Коннектор отправки (send connector) отправляет сообщение на внешний почтовый сервер.


Рисунок 3: Внешний почтовый домен (External relay domain)

Обычные домена и адресные политики

Перед тем, как появится возможность получать электронную почту для вашей структуры Exchange, вы должны создать адресное пространство SMTP address space и почтовую адресную политику (e-mail address policy). Когда вы создаете обычный домен, вы можете использовать шаблонный символ в качестве адресного пространства, что будет означать, что все дочерние домены в адресном пространстве SMTP address space, также входят в структуру Exchange Server 2007. Например, если вы хотите настроить домен msexchange.org и все его дочерние домены в качестве обычных доменов, то задайте *.msexchange.org в качестве адресного пространства SMTP address space.

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


Рисунок 4: Новый обычный домен

Вы, как минимум, должны создать одну адресную политику (address policy) для вашего внутреннего доменного пространства имен SMTP domain name space, которое используется для доставки почтовых объектов в Exchange Server 2007

Создание доменов с помощью управляющей оболочки Exchange Management Shell (EMS)

Создание нового обычного управляющего домена:

New-AcceptedDomain -Name “MSExchangeORG” -DomainName msexchange.org -DomainType Authoritative

Создание нового внутреннего почтового домена:

New-AcceptedDomain -Name “IT Training Grote” -DomainName it-training-grote.de -DomainType InternalRelay

Создание нового внешнего почтового домена:

New-AcceptedDomain -Name “ISAServerORG” -DomainName isaserver.org -DomainType ExternalRelay

Заключение

В этой статье я показал вам, как разделять пространство имен для двух различных структур Exchange, и как настроить и использовать внешние и внутренние почтовые SMTP домены. По сравнению с Exchange Server 2003, в Exchange Server 2007 гораздо проще разделить пространство имен SMTP namespace.
Автор: Марк Гроут(Mark Grote)
Иcточник: MSexchange.ru

Этот пост January 19, 2008 at 11:50 am опубликовал molse в категории Microsoft Exchange. Желающие могут оформить RSS подписку на комменты. Both comments and trackbacks are currently closed.

Ссылка на основную публикацию
Adblock
detector