Я прочитал много документации по переходу с Exchange 2003 на 2010.
Это не кажется слишком сложным, но одна часть, которую я не мог понять, - это то, как клиенты получают доступ к старому серверу 2003 года, в то время как мы все еще работаем с некоторыми людьми в 2010 году, а некоторые в 2003 году.
В настоящее время у меня есть простая установка - один сервер 2003, на котором есть все роли. Он находится за NAT с портами, перенаправленными на него для SMTP и HTTPS. Клиенты получают доступ к нему через веб-почту и просматривают откуда угодно через HTTPS на mail.example.com.
Если я правильно понимаю, когда я развертываю Exchange 2010, mail.example.com должен указывать на сервер 2010 (поэтому я изменяю переадресацию порта NAT, чтобы указывать на новый сервер). Но люди, все еще находящиеся на сервере 2003, должны иметь доступ к legacy.example.com.
Нужен ли legacy.example.com отдельный общедоступный IP-адрес с портами, перенаправленными на сервер 2003?
Мы также никогда не настраивали автоматическое обнаружение в 2003 году. Потребуется ли перенастроить клиентов, использующих Outlook через Outlook, чтобы по-прежнему подключаться к серверу 2003 года?
Прежде всего, прежде чем я начну, могу ли я предложить сокращенную миграцию? Они намного проще, требуют меньше работы и имеют смысл, когда у вас только один почтовый сервер. Обратной стороной является то, что будет отключение электронной почты, сколько времени потребуется, чтобы передать данные (почту) с одного сервера на другой (а затем списать старый сервер и назначить новый IP-адрес и имя хоста старому). Обычно вы можете сделать это отключение длиться не более нескольких минут с помощью подходящих инструментов, если вы перенесете основную часть электронного письма до даты переключения и сделаете разницу в данных, так что вы эффективно переносите только день или так стоит данных, а не всего.
Сказав это ... нет, вам не понадобится общедоступный IP-адрес для вашего нового сервера, потому что вместо этого вы настроили бы текущий / старый сервер для пересылки на него почты. (Увидеть ниже.)
Как правило, при совместной миграции вы настраиваете один почтовый сервер для пересылки почты на другой (если у вас их только 2). Самый простой способ сделать это - создать [поддельные] поддомены, назначить один для одного почтового сервера, а другой - для другого почтового сервера и настроить интеллектуальный хост для обработки маршрутизации почты от одного к другому. Вы бы оставили свой сервер Exchange 2003 как есть и не настраивали общедоступный IP-адрес или NAT для сервера 2010.
Итак, давайте использовать oldmail.company.com и newmail.company.com в качестве поддоменов (для упрощения примера вы, вероятно, не захотите использовать эти фактические имена). Поддомен oldmail будет «назначен» серверу Exchange 2003 (внутри, через системный менеджер Exchange, а не через DNS) и добавлен в список почтовых доменов, на которых этот сервер является полномочным, а поддомен newmail будет добавлен в список список доменов, на которых сервер 2010 является официальным. Затем вы должны настроить параметры промежуточного узла на обоих серверах, чтобы проверить другой почтовый сервер, если получатель не найден локально, и настроить соединители отправки и получения для обработки пересылки почты с одного сервера на другой. (Таким образом, ваш сервер Exchange 2003 будет пересылать любую почту для [получателя] @ newmail.company.com на сервер 2010, а сервер 2010 пересылать любую почту для [получателя] @ noldail.company.com на сервер 2003.)
Таким образом, пользователи обоих почтовых серверов могут отправлять друг другу сообщения внутри (каждый почтовый сервер проверяет другой, чтобы узнать, действителен ли получатель, прежде чем отклонять электронное письмо), и внешние пользователи тоже могут. Почта будет поступать на сервер 2003, как и раньше, и, если получатель не найден, он сверится с сервером 2010, чтобы узнать, находится ли ваш получатель там. Как только все перейдут на сервер Exchange 2010, вы должны запланировать время, чтобы выключить сервер Exchange 2003, поставить 2010 на свое место и удалить правила маршрутизации smarthost и почты. Это, конечно, предполагает, что вы правильно настроили почтовый сервер 2010, и он настроен для приема почты для внешних, а также имеет company.com в качестве одного из своих почтовых доменов.
Три основных недостатка этого:
Вы должны обрабатывать пользователей вручную - у каждого пользователя может быть только одна учетная запись, поэтому вам необходимо удалить их со старого сервера, как только вы переместите их на новый.
Вы должны управлять настройками почтового клиента пользователей - когда они переходят на новый сервер, они должны направлять своих клиентов на него, а затем возвращать их в исходное местоположение, когда вы переходите. (Кроме того, ведение календаря и другие ваши «не почтовые» функции почтовых клиентов, как правило, затрудняют выполнение правильных действий во время сосуществования).
Письма, отправленные с одного или другого сервера, будут отображаться как [отправитель] @ [субдомен] .company.com вместо [отправитель] @ company.com, если вы не перепрыгнете через обручи, чтобы изменить это. Когда сосуществование завершится и один или оба поддомена будут удалены с вашего почтового сервера, это приведет к отказу от ответов на эти старые электронные письма и, возможно, к большему количеству обращений в службу поддержки, чем вы бы хотели, от технически неграмотных пользователей и клиентов.