none
Переход на новый сервер Exchange 2013 RRS feed

  • Вопрос

  • Сервер MAILBOX+CAS уже как несколько лет пестрит различными ошибками, на него невозможно установить CU (вылетают различные ошибки). С текущими CU сервера достались от прошлых администраторов.

    Имеется:

    Старые сервера:

    EDGE (Standart) - V 15.0 (Build 1178.4) CU12 (edge.domain.com)

    MAILBOX+CAS (Enterprise) - V15.0 (Build 1104.5) CU9 (post.domain.com)

    Для OWA, ECP используется Letsencrypt сертификат для имен mail.domain.com (для OWA, ECP), post.domain.com, smtp.domain.com, imap.domain.com

    Этот же сертификат используется для для всех служб (IIS, SMTP, IMAP, POP), чтобы почтовые клиенты не ругались на дефолтный самоподписной сертификат. Скриптом сертификат подменяется на сервере в установленные сроки.

    Через proxy nginx запросы к OWA, ECP, RPC прокидываются на сервер post.domain.com (домен, используемый на предприятии для AD и т.д. внешний - domain.com).

    Задача:

    1) Поднять новый сервер Exchange 2013 MAILBOX+CAS с последним доступным CU19 (если это возможно, иметь последний CU на еще не включенном в работу сервере, чтобы не обновлять его, когда он станет рабочим).

    2) Мигрировать всех и вся на новый сервер.

    3) Отключить и удалить старый сервер.

    Итого:

    Какова правильная последовательность действий?

    1) Поднять новый Exchange 2013 (нужно ли подготавливать схему, AD)?

    2) В какой момент накатывать последние CU (до введения в строй нового сервера или только после введения его в строй и отключения старого)?

    3) Можно ли будет относительно безболезненно вернуться к старому имени post.domain.com (у нового сервера будет другое имя, например post2.domain.com)?

    4) Как правильно перенастроить соединители (на EDGE и post2.domain.com), чтобы старый сервер post.domain.com стал просто хранителем старой базы (до окончания переноса всех ящиков в базы на новый сервере), а новый сервер уже занимался обработкой почты.

    Спасибо.

    14 октября 2018 г. 19:30

Ответы

  • Понял.

    Необходимость подготовки AD обусловлена изменениями в схеме и конфигурации. Поскольку один сервер у вас уже есть, то и добавлять ничего не придется. Если будете ставить точно такой же CU, как и на первом сервере, то схему расширять тоже не нужно.

    На всякий случай, тут сможете найти все версии эксча, для которых нужно расширение схемы, а следовательно и подготовка AD:  https://docs.microsoft.com/en-us/exchange/exchange-2013-active-directory-schema-changes-exchange-2013-help

    Гайд по проверке состояния AD: https://docs.microsoft.com/en-us/exchange/prepare-active-directory-and-domains-exchange-2013-help

    И ещё такой момент: непонятно в каком состоянии находится AD в данный момент, поскольку вы упоминали о неудачных попытках установки CU ранее. В любом случае предварительная обкатка на лабе внесет ясность. Успехов в переезде!

    • Помечено в качестве ответа what_i_need 15 октября 2018 г. 9:47
    15 октября 2018 г. 6:24

Все ответы

  • Добрый вечер.

    1. В идеальном варианте вам надо поднять новый эксч с точно таким же CU, иначе в теории могут быть проблемы. Сценарий сосуществования эксчей с разными версиями поддерживается только для целей обновления и не рассчитан на что-либо другое, а у вас миграция со старого битого сервера на новый. Никто вам не даст гарантий, что все пройдет хорошо, учитывая состояние вашего текущего сервера.

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

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

    4. Не понимаю о какой "старой базе" идет речь. Соединители настраиваются автоматически, если вы использовали подписку. Обновите подписку и все будет хорошо.

    __________________________________________________________

    Лично я посоветовал бы вам разобраться с вашей текущей инфраструктурой. От кого она вам досталась совершенно неважно, в любом случае вы как админ должны уметь траблшутить. Разберитесь сначала с существующим сервером - устраните ошибки, накатите CU - иначе переезд на новый вам может не помочь, а может и вообще не состояться в крайнем случае.

    Да и судя по подходу - отдельный эдж, нормальный сертификат, обратный прокси - предыдущие админы как раз настроили все очень даже грамотно. Аккуратно предположу, что в текущем состоянии и в проблемах с CU виноваты скорее вы, раз он у вас в таком состоянии уже несколько лет. Ошибки на сервере - обычное дело и теперь это ваша проблема. Что будете делать, когда на вашем новом сервере тоже начнут сыпаться ошибки, развернете ещё один? Это не вариант, поэтому учитесь сейчас.


    • Изменено Egor Vasilev 14 октября 2018 г. 20:25
    14 октября 2018 г. 20:24
  • Добрый вечер.

    1. В идеальном варианте вам надо поднять новый эксч с точно таким же CU, иначе в теории могут быть проблемы. Сценарий сосуществования эксчей с разными версиями поддерживается только для целей обновления и не рассчитан на что-либо другое, а у вас миграция со старого битого сервера на новый. Никто вам не даст гарантий, что все пройдет хорошо, учитывая состояние вашего текущего сервера.

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

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

    4. Не понимаю о какой "старой базе" идет речь. Соединители настраиваются автоматически, если вы использовали подписку. Обновите подписку и все будет хорошо.

    __________________________________________________________

    Лично я посоветовал бы вам разобраться с вашей текущей инфраструктурой. От кого она вам досталась совершенно неважно, в любом случае вы как админ должны уметь траблшутить. Разберитесь сначала с существующим сервером - устраните ошибки, накатите CU - иначе переезд на новый вам может не помочь, а может и вообще не состояться в крайнем случае.

    Да и судя по подходу - отдельный эдж, нормальный сертификат, обратный прокси - предыдущие админы как раз настроили все очень даже грамотно. Аккуратно предположу, что в текущем состоянии и в проблемах с CU виноваты скорее вы, раз он у вас в таком состоянии уже несколько лет. Ошибки на сервере - обычное дело и теперь это ваша проблема. Что будете делать, когда на вашем новом сервере тоже начнут сыпаться ошибки, развернете ещё один? Это не вариант, поэтому учитесь сейчас.


    Егор, добрый вечер.

    1,2 Понятно.

    3. Я об этом не беспокоюсь, этот вопрос не принципиален.

    4. На текущем сервере хранится база с ящиками (на самом сервере, а не на какой-то шаре). Почтовые ящики должны быть перенесены на новый сервер и хранится на нем.

    Нормальный сертификат - это уже делал я. Отдельный edge и post сервер довольно тревиальная структура.

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

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

    14 октября 2018 г. 20:58
  • Я лишь предположил, не принимайте на свой счет.

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

    По теме - у вас остались ещё какие-то вопросы?

    p.s. Если у вас виртуализованная инфраструктура, вы запросто можете раскатать бэкапы виртуалок на отдельном хосте в изолированной сети и прогнать весь сценарий переезда.

    15 октября 2018 г. 4:58
  • Нужно ли при установке нового сервера ex2013 каким-либо образом готовить ad? Это пожалуй был главный вопрос для меня, т.к. про все остальное либо уже читал, либо достаточно очевидно. Ну и нужно разобраться с коннекторами.

    Прогнать все в тестлабе - довольно очевидное решение  и инфраструктура тестлаба уже формируется.

    Вопрос был лишь в чётком порядке действий по обозначенному предложению (в первом посте), минуя дискуссии по компетентности, талантам и прочему.

    P.S. Если ОС умирает, я не говорю коллегам идти убивать ее ибо так проще. Сначала идёт попытка решения возникающих проблем. Однако хочется иметь план по безболезненному переводу почтового сервера на новую машину.

    Спасибо.

    15 октября 2018 г. 5:56
  • Понял.

    Необходимость подготовки AD обусловлена изменениями в схеме и конфигурации. Поскольку один сервер у вас уже есть, то и добавлять ничего не придется. Если будете ставить точно такой же CU, как и на первом сервере, то схему расширять тоже не нужно.

    На всякий случай, тут сможете найти все версии эксча, для которых нужно расширение схемы, а следовательно и подготовка AD:  https://docs.microsoft.com/en-us/exchange/exchange-2013-active-directory-schema-changes-exchange-2013-help

    Гайд по проверке состояния AD: https://docs.microsoft.com/en-us/exchange/prepare-active-directory-and-domains-exchange-2013-help

    И ещё такой момент: непонятно в каком состоянии находится AD в данный момент, поскольку вы упоминали о неудачных попытках установки CU ранее. В любом случае предварительная обкатка на лабе внесет ясность. Успехов в переезде!

    • Помечено в качестве ответа what_i_need 15 октября 2018 г. 9:47
    15 октября 2018 г. 6:24
  • Егор, спасибо.

    Из того, что нашел по старым заметкам, проблема с учеткой Exchange_Online-ApplicationAccount@domain.com (из-за проблем с этой учеткой когда-то споткнулось обновление до CU12)

    Есть проблема с Ящиком обнаружения, который вроде бы и есть, и в консоли можно посмотреть все о нем, но ECP неуклонно говорит о том, что ящик обнаружения отсутствует.

    Ну и собственно препарирование серверов будет проводиться в тестовой среде, учитывая, что проблемы, вероятно, есть и в AD.

    15 октября 2018 г. 9:47
  • Хорошо.

    По учетке надо видеть саму ошибку.

    Ящик можно пересоздать: https://docs.microsoft.com/ru-ru/exchange/security-and-compliance/in-place-ediscovery/delete-and-re-create-default-discovery-mailbox

    Если будут какие-то сложности по траблшутингу - создавайте новые топики, будем смотреть.

    15 октября 2018 г. 10:11