none
Задачка с подзадачками ...

    Вопрос

  • Всем доброго времени суток !

    Имеется старый домен domain1.local с двумя серверами и сетью 192.168.1.0 . Один - DC с расшаренными папками, другой - Exchange 2013.

    Также имеется удалённый офис с подсетью 192.168.3.0 с соединением с основным офисом через IPsec на роутерах - там тоже есть файл-сервер на Windows Server 2012R2, состоящий в этом же домене domain1.local .

    Почта приходит к провайдеру, от которого её забирает MDaemon и пересылает в Exchange (т.к. сам Exchange собирать почту не умеет). Отсылает почту Exchange уже сам. Да, Exchange обслуживает почту 3 доменов (domain1.ru, domain2.ru и domain3.com). Юзеров около 100.

    Купили новый сервер и меня посетила идея перевести domain1.local в domain1.ru, а также виртуализировать существующие сервера (контроллер домена и почтовик), а из одного из освободившихся серверов + новый сервер сделать отказоустойчивую систему из двух серверов с виртуалками.

    Да, ещё. Старый контроллер домена и почтовик на Windows Server 2008R2, а для нового - куплены Windows Server 2016 и Exchange 2016. Не спрашивайте почему всё так - сложилось исторически ещё до меня :)

    Как бы всё это склеить ?

    • Изменено _STAS_ 8 ноября 2017 г. 15:28
    8 ноября 2017 г. 15:24

Все ответы

  • Почта приходит к провайдеру, от которого её забирает MDaemon и пересылает в Exchange (т.к. сам Exchange собирать почту не умеет)

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

    Как бы всё это склеить ?
    просто:
    - делаете резервные копии
    - обновляете домен до 2016
    - переименовываете домен в domain1.ru
    - настраиваете новый Exchange 2016
    • Изменено Anahaym 8 ноября 2017 г. 15:33
    8 ноября 2017 г. 15:33
  • Не получится просто, ибо вижу в условии "Имеется старый домен domain1.local с двумя серверами и сетью 192.168.1.0 . Один - DC с расшаренными папками, другой - Exchange 2013."

    установленный в организации Exchange сервер, а значит поддерживаемый путь только один: миграция в новый лес domain1.ru.

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

    8 ноября 2017 г. 17:15
  • Всем доброго времени суток !

    Имеется старый домен domain1.local с двумя серверами и сетью 192.168.1.0 . Один - DC с расшаренными папками, другой - Exchange 2013.

    Также имеется удалённый офис с подсетью 192.168.3.0 с соединением с основным офисом через IPsec на роутерах - там тоже есть файл-сервер на Windows Server 2012R2, состоящий в этом же домене domain1.local .

    Почта приходит к провайдеру, от которого её забирает MDaemon и пересылает в Exchange (т.к. сам Exchange собирать почту не умеет). Отсылает почту Exchange уже сам. Да, Exchange обслуживает почту 3 доменов (domain1.ru, domain2.ru и domain3.com). Юзеров около 100.

    Купили новый сервер и меня посетила идея перевести domain1.local в domain1.ru, а также виртуализировать существующие сервера (контроллер домена и почтовик), а из одного из освободившихся серверов + новый сервер сделать отказоустойчивую систему из двух серверов с виртуалками.

    Да, ещё. Старый контроллер домена и почтовик на Windows Server 2008R2, а для нового - куплены Windows Server 2016 и Exchange 2016. Не спрашивайте почему всё так - сложилось исторически ещё до меня :)

    Как бы всё это склеить ?

    Добрый день, коллега!

    Ну объясните мне почему чем меньше организация, тем сложнее там инфраструктура?) 

    Зачем убогая (извините, но это так) связка провайдерского почтового сервера с MDaemon и эксчем? Убирайте её нафиг, как вам и посоветовали. 

    У меня на домашней!!! тестовой инфраструктуре был поднят полноценный эксч с AD, сам принимал и отправлял почту без всяких проблем. И это при том, что мне даже ptr-запись нельзя было создать в силу ограничений домашних провайдеров. Зачем вам связка из нескольких почтовых серверов? 

    По поводу старого домена: посмотрите на задачу с другой стороны - может быть легче привести домен к современному технического состоянию? Это не так сложно как может показаться.

    - для начала посмотрите в сторону уровня леса и домена, повысьте при необходимости;

    - потом мигируйте с frs на dfsr;

    - на всякий случай проверьте зону _msdcs, возможно придется её пересоздать (этот процесс подробно описан в официальной документации)

    Имя домена вообще не играет никакого значения. Нужно domain.ru - не проблема, создайте дополнительный upn-суффикс и пользуйтесь им. Логиньтесь на ПК по адресу почты и не нужна вам миграция на новый домен.

    Следующий момент: я могу только гадать что за отказоустойчивую систему вы собрались делать и насколько она вам вообще нужна. Случайно это не "откзоустойчивый" кластер с двумя узлами и одной!!! хранилкой? Если да, то не заморачивайтесь. Проблем получите больше, чем профита.

    9 ноября 2017 г. 7:21
  • Ну объясните мне почему чем меньше организация, тем сложнее там инфраструктура?) 

    Егор, это классика жанра. Как сказал когда-то давно мой друг Сергей, чем меньше контора, тем больше у нее требования к высокой доступности (с). Это после сотен ТЗ для 10 серверов и чтобы все было "у нас отказоустойчиво".

    9 ноября 2017 г. 7:36

  • Как сказал когда-то давно мой друг Сергей, чем меньше контора, тем больше у нее требования к высокой доступности (с). 

    До слез! Я запомню эту фразу))
    9 ноября 2017 г. 7:43
  • Не ради красивого имени, а приведения в норму для.

    Одна из проблем - некоторые сервера ругаются и делают отлуп почты, т.к. хоть Exchange и отвечает HELO mail.domain1.ru, в путях сообщения всё же куча mail.domain1.local . Хотя и MX и PTR в порядке, но иногда встречаются такие отлупы. Я не знаю, как они это делают, но бывает.

    Вторая проблема в том, что не все почтовые клиенты при настройке аккаунта понимают такую связку, когда domain1.ru и MX-записи у провайдера, а сервер mail.domain1.ru - у нас в локальной сети. Они просто спрашивают, как сейчас модно, почтовый адрес и пароль, а там уже сами пытаются разобраться, что где лежит. И не всегда успешно.

    Ну а плюсы перевода серверов в виртуальную среду, думаю, очевидны для всех - это уже классика жанра.

    • Изменено _STAS_ 9 ноября 2017 г. 8:33
    9 ноября 2017 г. 8:13
  • Одна из проблем - некоторые сервера ругаются и делают отлуп почты, т.к. хоть Exchange и отвечает HELO mail.domain1.ru, в путях сообщения всё же куча mail.domain1.local . Хотя и MX и PTR в порядке, но иногда встречаются такие отлупы. Я не знаю, как они это делают, но бывает.

    Вторая проблема в том, что не все почтовые клиенты при настройке аккаунта понимают такую связку, когда domain1.ru и MX-записи у провайдера, а сервер mail.domain1.ru - у нас в локальной сети. Они просто спрашивают, как сейчас модно, почтовый адрес и пароль, а там уже сами пытаются разобраться, что где лежит. И не всегда успешно.

    всё это решается. в отдельных темах.
    9 ноября 2017 г. 8:19
  • Надо признаться, т.к. задач сразу несколько и они связаны друг с другом, я никак не мог найти поначалу раздел для размещения. Вот, решил в этом.
    9 ноября 2017 г. 8:27
  • Надо признаться, т.к. задач сразу несколько и они связаны друг с другом, я никак не мог найти поначалу раздел для размещения. Вот, решил в этом.
    я имел ввиду, если у вас подобные проблемы с Exchange - то они все решаются. Но каждая в отдельной теме - не в этой. По этому вы можете решать их и дальше использовать старое доменное имя, или переименовывать домен.
    9 ноября 2017 г. 8:30
  • Объясняю: чем больше фирма, тем медленнее в ней процессы. Чем меньше - тем быстрее. А чем быстрее процессы - тем больше требования к отказоустойчивости ... Как-то так :)

    Насчёт связки провайдер-MDaemon-Exchange - это началось ещё до меня. Но тут, кстати сказать, есть и свои плюсы: пока у нас не налажена "отказоустойчивость", в те моменты, когда наш почтовый сервер в Дауне - почта временно копится у провайдера. Иначе просто был бы отлуп отправителю. Плюс дополнительная фильтрация спама - я отрубил на Exchange внешний SMTP.

    DFS вообще пока не юзаем.

    По поводу "кластера": я планирую сделать два сервера и перенести КД и Exchange на виртуалки на этих серверах. Но для меня пока есть несколько вопросов:

    1. Если создание резервного КД в принципе, ситуация для меня лично теоретически понятная, то создание "резервного" Exchange не понимаю. Есть возможность создать DAG на виртуалках двух серверов, но для меня непонятно, каким образом это будет выглядеть извне. Допустим, юзер обычно залезает на mail.domain1.ru через Outlook или через OWA. Если этот сервер будет в дауне, откуда юзер узнает, что работает второй по адресу mail2.domain1.ru на резервном сервере и теперь надо туда лезть за почтой ?

    • Изменено _STAS_ 9 ноября 2017 г. 8:50
    9 ноября 2017 г. 8:35
  • Не ради красивого имени, а приведения в норму для.

    Одна из проблем - некоторые сервера ругаются и делают отлуп почты, т.к. хоть Exchange и отвечает HELO mail.domain1.ru, в путях сообщения всё же куча mail.domain1.local . Хотя и MX и PTR в порядке, но иногда встречаются такие отлупы. Я не знаю, как они это делают, но бывает.

    Вторая проблема в том, что не все почтовые клиенты при настройке аккаунта понимают такую связку, когда domain1.ru и MX-записи у провайдера, а сервер mail.domain1.ru - у нас в локальной сети. Они просто спрашивают, как сейчас модно, почтовый адрес и пароль, а там уже сами пытаются разобраться, что где лежит. И не всегда успешно.

    Ну а плюсы перевода серверов в виртуальную среду, думаю, очевидны для всех - это уже классика жанра.

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

    Ещё раз повторюсь: нет никаких реальных барьеров (только в голове) использовать локальные домены. Плохо если используется Single-label domain, но это не ваш случай вроде как.

    По поводу виртуализации: плюсы для всех очевидны, ровно как и минусы, главный из которых на мой субъективный взгляд - недостаточная квалификация администраторов виртуализованной инфраструктуры. Нужно обязательно этот вопрос прорабатывать, потому как что кд, что эксч имеют очень много нюансов при работе в виртуализованной среде, есть даже отдельные огромные гайды а-ля best practice for virtualizing exchange.

    9 ноября 2017 г. 8:46
  • Я по-другому могу со своей стороны объяснить, не в обиду, хорошо? Чем меньше фирма, тем больше непонимание процессов и из взаимосвязи с деньгами и стоимостью простоя сервиса. Отсюда и "давайте нам и двух провайдеров, и кластеры, и все на свете". А по факту выясняем, что стоимость простоя- никакая, т.е. ничего не изменится, если фирма простоит три дня. И нет взаимосвязи между финансами и ИТ, а есть перетягивание одеяла и вечная борьба.

    Что касается основного вопроса.

    Одна из проблем - некоторые сервера ругаются и делают отлуп почты, т.к. хоть Exchange и отвечает HELO mail.domain1.ru, в путях сообщения всё же куча mail.domain1.local . Хотя и MX и PTR в порядке, но иногда встречаются такие отлупы. Я не знаю, как они это делают, но бывает.

    Ну, ок, представился сервер Ваш HELO mail.domain1.ru, как Вы приказали ему на коннекторе. Что в смтп сессии с заголовками внутренними никого не волнует, поверьте. Давайте тогда куски лога в студию, раз у нас уж тут такой тёплый консилиум, поглядим и потыкаем палкой. С трудом верится что корень зла в имени .локал домена. По крайней мере, мне.

    Вторая проблема в том, что не все почтовые клиенты при настройке аккаунта понимают такую связку, когда domain1.ru и MX-записи у провайдера, а сервер mail.domain1.ru - у нас в локальной сети. Они просто спрашивают, как сейчас модно, почтовый адрес и пароль, а там уже сами пытаются разобраться, что где лежит. И не всегда успешно.

    2016 аутлук имеете ввиду? Да, вот такая у него настройка. Используйте 2013 и рулите ей сами. Опять же и 2016 можно приголубить ключами реестра и прочими локальными файликами настроек.

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

    9 ноября 2017 г. 8:47
  • Объясняю: чем больше фирма, тем медленнее в ней процессы. Чем меньше - тем быстрее. А чем быстрее процессы - тем больше требования к отказоустойчивости ... Как-то так :)

    Если честно, то я в корне не согласен. Но оставим эту тему для отдельных холиваров


    9 ноября 2017 г. 8:52
  • Я не пытаюсь решить эти проблемы с Exchange - они решатся сами собой при переводе домена из .local в .ru . А решать это я думаю при помощи, в том числе, виртуализации. Поэтому тема выбрана "Виртуализация". И я не пытаюсь решить - просто объясняю ситуацию, для чего мне нужен домен .ru

    =STAS=

    • Изменено _STAS_ 9 ноября 2017 г. 9:03
    9 ноября 2017 г. 8:58

  • 1. Если создание резервного КД в принципе, ситуация для меня лично теоретически понятная, то создание "резервного" Exchange не понимаю. Есть возможность создать DAG на виртуалках двух серверов, но для меня непонятно, каким образом это будет выглядеть извне. Допустим, юзер обычно залезает на mail.domain1.ru через Outlook или через OWA. Если этот сервер будет в дауне, откуда юзер узнает, что работает второй по адресу mail2.domain1.ru на резервном сервере и теперь надо туда лезть за почтой ?

    КД должно быть ДВА на РАЗНЫХ физических серверах.

    Если разворачиваете DAG на двух эксчах, то эксчи должны быть на РАЗНЫХ физических серверах.

    Предлагаю не оперировать понятиями основной/резерный, это уже давно как неактуально что для КД, что для эксча.

    Если юзер залезает на mail.domain1.ru, то пусть так и залезает. Пока что у вас будет один проброс на "основной" (который был поднят раньше) эксч. Как соберетесь, так можете поднимать балансировщик нагрузки - можно на железке это сделать (микротики в студию), можно отдельную виртуалку поднять с HAproxy/squid/nginx и сделать её отказоустойчивой той же Hyper-v Replica - затраты на железо почти нулевые, а все будет работать.

    Балансировать smtp-подключения не нужно, просто создайте две записи mx.

    9 ноября 2017 г. 9:02
  • Я не пытаюсь решить эти проблемы с Exchange - они решатся сами собой при переводе домена из .local в .ru . А решать это я думаю при помощи виртуализации. Поэтому тема выбрана "Виртуализация". И я не пытаюсь решить - просто объясняю ситуацию, для чего мне нужен домен .ru

    =STAS=

    пока непонятно для чего
    9 ноября 2017 г. 9:03
  • Повторюсь, наверное, но я не видел таких проблем за более чем 10 летнюю возню с фирмами, живущими припеваючи в доменах .локал. Не было у них отбойников из-за домена .локал, а были по другим причинам.

    Логи в студию.

    9 ноября 2017 г. 9:03
  • КД должно быть ДВА на РАЗНЫХ физических серверах.

    И(плюс)одина физике, дабы исключить SPOF виртуализации, которая может и даже доставляет в другом случае: вся площадка выключена, связи нет, запускаем сервисы.


    Ну и по пододу эксчей добавить особо нечего разве что как Вы сами сказали выше- не надо это все складывать на Р2000 одну и кричать что мы молодцы. Лучше уж тогда физика пусть и старая и больная.
    9 ноября 2017 г. 9:06
  • Да, почитав в интернете на форумах о проблемах, связанных с переименованием, всё больше склоняюсь к мысли о заведении нового домена domain1.ru и переводе всего туда. Чтобы не тащить всякое-разное вместе со старым доменом .local, что там накопилось лет за 12.

    Вопрос в том, чтобы это сделать постепенно и мягко для юзеров. К примеру, один из вопросов: смогут ли сосуществовать .local и .ru в одной сети и что для этого надо будет сделать ?


    =STAS=

    9 ноября 2017 г. 9:12
  • Да, почитав в интернете на форумах о проблемах, связанных с переименованием, всё больше склоняюсь к мысли о заведении нового домена domain1.ru и переводе всего туда. Чтобы не тащить всякое-разное вместе со старым доменом .local, что там накопилось лет за 12.

    Вопрос в том, чтобы это сделать постепенно и мягко для юзеров. К примеру, один из вопросов: смогут ли сосуществовать .local и .ru в одной сети и что для этого надо будет сделать ?


    =STAS=

    а вы хоть в курсе, что вам придется поднимать ещё и эксч на втором домене? В курсе, что придется настраивать доверительные отношения между доменами?

    Мне кажется вы просто изначально настроены именно на переименование домена и не слышите других аргументов. Вам интересно переименование домена ради переименования домена. Но не ради удобства пользователей, корректной работы инфраструктуры, оптимизации затрат на ИТ и прочего.

    Переименовывать домен не надо, просто создайте дополнительный upn-суффикс и протестируйте на паре юзеров. Отличий - ноль!

    Кстати, ещё до развертывания нового домена я могу сказать что проблем вы огребете массу уже с доменом domain.ru. Как минимум используйте corp.domain.ru, но никак не domain.ru, на котором может висеть например корпоративный сайт.

    9 ноября 2017 г. 9:23
  • Коллеги, давайте не будет отвлекаться от "основной" темы Автора - Виртуализация )
    Я уже настраиваю виртуальный стенд под это дело (самому интересно стало)

    К примеру, один из вопросов: смогут ли сосуществовать .local и .ru в одной сети и что для этого надо будет сделать ?

    Смогут. Ничего делать не надо.

    КД должно быть ДВА на РАЗНЫХ физических серверах

    неактуально. Не "должно", а "рекомендуется".
    Спросите - "а если единственный контроллер домена выйдет из строя?".
    Отвечаю - "с чего бы ему выйти из строя? Надо правильно спланировать (всё), настроить и мониторить".

    а вы хоть в курсе, что вам придется поднимать ещё и эксч на втором домене? В курсе, что придется настраивать доверительные отношения между доменами?
    А что, этого никто никогда не делал? при этом межлесовая миграция Exchange не требует доверий.
    • Изменено Anahaym 9 ноября 2017 г. 9:27
    9 ноября 2017 г. 9:24
  • Да, Егор, как я и говорил, будет 2 разных физических сервера, на которых будут виртуалки. С юниксом не знаком. А вот по поводу сосуществования двух доменов в одной сети можно поподробнее ? То есть выделяем в старом DHCP в той же подсети 1.0, скажем, пространство с 1.200 по 1.250, и там делаем новый КД ? В новом домене ведь тоже будет свой DHCP, DNS - как-то это надо прописывать ... Доверие между доменами надо опять же. Да, ещё на виртуальном КД написано надо отключать синхронизацию времени. И как потом юзеров переносить из старого домена в новый ?

    =STAS=

    • Изменено _STAS_ 9 ноября 2017 г. 9:39
    9 ноября 2017 г. 9:36
  • По поводу domain1.ru я уже думал и советовался с провайдером. Они сказали, проблем не будет. Сайт висит у них на хостинге. К тому же, если сделать corp.domain1.ru, то почтовик, который я заведу в этом домене, будет уже называться mail.corp.domain1.ru

    =STAS=

    • Изменено _STAS_ 9 ноября 2017 г. 9:45
    9 ноября 2017 г. 9:44
  • В новом домене ведь тоже будет свой DHCP, DNS - как-то это надо прописывать ...

    напомните, сколько копьютеров?

    Доверие между доменами надо опять же.

    доверия между 2008 и 2012

    И как потом юзеров переносить из старого домена в новый ?

    Миграция ADMT

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


    К тому же, если сделать corp.domain1.ru, то почтовик, который я заведу в этом домене, будет уже называться mail.corp.domain1.ru
    так будет называваться почтовик по умолчанию только в пределах локальной сети. Как его будут видеть пользователи - всё это перенастраиватся. Хоть vasya.pupkin.ru назовите его - будет работать!
    Я бы рекомендовал вам назвать домен так:
    domain.domain.ru
    domainXXX.domain.ru - где ХХХ - ZAO, OOO, OAO или какая у вас форма организции компании? Плюс (для меня, и для мои пользователей) - они видят к какой компании подключаются, а не просто общее и не понятное CORP.
    • Изменено Anahaym 9 ноября 2017 г. 9:51
    9 ноября 2017 г. 9:47
  • Да, реально получается не переименование, а миграция. Не хочется всяко-разно старые глюки, накопившиеся за 12 лет, тащить за собой на новый сервер.

    =STAS=

    9 ноября 2017 г. 9:50
  • Да, реально получается не переименование, а миграция. Не хочется всяко-разно старые глюки, накопившиеся за 12 лет, тащить за собой на новый сервер.

    =STAS=

    это верно.
    9 ноября 2017 г. 9:52
  • Будет два физических сервера с двумя виртуалками на каждом - для DC и Exchange. Юзеров около 100. Живых. Доверие между 2008R2 и 2016.

    =STAS=

    • Изменено _STAS_ 9 ноября 2017 г. 9:55
    9 ноября 2017 г. 9:53
  • Доверие между 2008R2 и 2016

    ничем не отличается от 2008R2 и 2012
    Пользователи используют какие-либо сертификаты, например для клиент-банков?

    идеально, если домены разнести по разным сетям (VLAN).

    • Изменено Anahaym 9 ноября 2017 г. 10:06
    9 ноября 2017 г. 10:05
  • Пользователи используют какие-либо сертификаты, например для клиент-банков?

    идеально, если домены разнести по разным сетям (VLAN).

    Да, используют для банков и сайтов с тендерами, но локально, на флешках. Есть ещё, правда контейнеры VipNET на файл-сервере.

    Обязательно VLAN ? Или можно в одной подсети всё провести ?


    =STAS=

    9 ноября 2017 г. 10:18
  • Если бы всё было так просто, я не залезал бы в ТехНет за ответами на эти вопросы. Просто хочется, чтобы всё было "правильно и чётко" и работало как часы. Может, я идеалист или, как сейчас модно "перфекционист". Но очень хочется :) И потом, ребята, помилуйте, посмотрите на количество баллов под вашими фото и моим. Разница как между академиком и первокурсником :)

    =STAS=

    9 ноября 2017 г. 10:23
  • Дима, не хочу я в логах копаться. Хочу перенести всё в новый "правильный" домен, чтоб таких проблем не возникало больше и забыть о логах вообще. По крайней мере, я буду уже точно знать, что с доменами-ДНС-МХ у меня всё нормально.

    =STAS=

    • Изменено _STAS_ 9 ноября 2017 г. 10:26
    9 ноября 2017 г. 10:25
  • Дима, не хочу я в логах копаться. Хочу перенести всё в новый "правильный" домен, чтоб таких проблем не возникало больше и забыть о логах вообще. По крайней мере, я буду уже точно знать, что с доменами-ДНС-МХ у меня всё нормально.

    =STAS=

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

    Есть best practice, но это именно лучшие рекомендуемые практики, но никак не обязательные к исполнению предписания. То же вам написал и Anahaym на счет двух кд - не обязательное, но рекомендуемое требование.

    Дак вот, в вашем случае правильным можно попробовать назвать тот домен и окружение в целом, с которым пользователям комфортно работать и они не испытывают проблем. Именно пользователи, но не вы, поскольку ваша работа - делать чтобы юзерам было хорошо.

    Все ваши проблемы с почтовиком якобы из-за "неправильного" домена не имеют к ситуации никакого отношения. (может быть у вас мх указывает на сервер провайдера, а когда почта уходит с вашего адреса, то ip у принимающей стороны светится уже другой и ваши письма попадают в спам. Дак это решается не переездом. Более того, я вам точно могу сказать, что вы очень разочаруетесь встретив аналогичные проблемы на новом домене. Создайте spf в конце концов).

    9 ноября 2017 г. 10:36
  • Пользователи используют какие-либо сертификаты, например для клиент-банков?

    идеально, если домены разнести по разным сетям (VLAN).

    Да, используют для банков и сайтов с тендерами, но локально, на флешках. Есть ещё, правда контейнеры VipNET на файл-сервере.

    Обязательно VLAN ? Или можно в одной подсети всё провести ?


    =STAS=

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

    По поводу сетей тут вот какое дело - какой первый DHCP ответит - такие насройки клиент и получит. По этому в идеальном варианте два DHCP лучше развести по разным VLAN.

    И потом, ребята, помилуйте, посмотрите на количество баллов под вашими фото и моим. Разница как между академиком и первокурсником :)
    это фигня. некоторые баллы ставят за просто так.
    • Изменено Anahaym 9 ноября 2017 г. 10:38
    9 ноября 2017 г. 10:37
  • Есть аж 3 МХ-а - с приоритетом 100 - на прова, 200 - на Ексч и 300 - на Мдаемон. И SPF есть. И 2 ПТРа. Даже с Гугл-почтой проблем нет, хотя у них там требования вы знаете какие жёсткие. И всё равно иногда приходят отлупы. Да и мне в логах Эксча смотреть просто класс: mail.domain1.local перенаправил письмо mail.domain1.local, после чего mail.domain1.local перенаправил mail.domain1.local. Сидишь и думаешь - ху из ху тут? Вот насчёт разочарований в новом домене поподробнее можно ?

    =STAS=

    • Изменено _STAS_ 9 ноября 2017 г. 10:48
    9 ноября 2017 г. 10:46
  • По поводу сетей тут вот какое дело - какой первый DHCP ответит - такие настройки клиент и получит. По этому в идеальном варианте два DHCP лучше развести по разным VLAN.

    А если, к примеру, сначала ужать сеть с 192.168.1.0-250 до 192.168.1.0-150, а при заведении домена поставить там в DHCP 192.168.1.151-250, а сам DHCP-2 зарегить на первом DHCP ?

    =STAS=

    • Изменено _STAS_ 9 ноября 2017 г. 11:05
    9 ноября 2017 г. 11:01
  • Дима, не хочу я в логах копаться. Хочу перенести всё в новый "правильный" домен, чтоб таких проблем не возникало больше и забыть о логах вообще. По крайней мере, я буду уже точно знать, что с доменами-ДНС-МХ у меня всё нормально.

    =STAS=


    Я на все пункты согласен, кроме первого про HELO и отбойники. Не верю, что есть проблема здесь. Поэтому и предлагаю разобраться, ибо вторая проблема с аутлуками и виртуализация и приведение в порядок- здесь возражений нет. А по первому пункту решительно не согласен, не может быть никакой связи с локалом. Да вообще без домена можете сидеть, или на самбе поднять локал, пихнуть туда почтовик и людей. И никто Вам не будет ничего запрещать, ибо RFC SMTP наше всё.
    9 ноября 2017 г. 11:05
  • По поводу сетей тут вот какое дело - какой первый DHCP ответит - такие настройки клиент и получит. По этому в идеальном варианте два DHCP лучше развести по разным VLAN.

    А если, к примеру, сначала ужать сеть с 192.168.1.0-250 до 192.168.1.0-150, а при заведении домена поставить там в DHCP 192.168.1.151-250, а сам DHCP-2 зарегить на первом DHCP ?

    =STAS=

    что значит "а сам DHCP-2 зарегить на первом DHCP" ?
    9 ноября 2017 г. 11:14
  • ну там же в настройках DHCP есть список авторизованных серверов. возможно, после налаживания доверия между доменами можно будет туда добавить DHCP из нового домена ?

    =STAS=

    • Изменено _STAS_ 9 ноября 2017 г. 11:27
    9 ноября 2017 г. 11:19
  • установленный в организации Exchange сервер, а значит поддерживаемый путь только один: миграция в новый лес domain1.ru

    ну почему же только один? А как вам путь через резервные копии баз данных?
    - сделать копию базы
    - снести 2013
    - переименовать домен
    - установить 2013
    - восстановить копию базы
    - внедряем 2016

    Наверное, при сносе 2013 останусться какие-либо следы, но ведь их же можно вычистить? Если они будут критичными.

    9 ноября 2017 г. 13:15
  • ну там же в настройках DHCP есть список авторизованных серверов. возможно, после налаживания доверия между доменами можно будет туда добавить DHCP из нового домена ?

    =STAS=

    я такое не пробовал. всё равно - если клиент domain.local подключится к dhcp.domain.ru - он получит в DNS адрес другого контроллера домена.
    9 ноября 2017 г. 13:17
  • Хм ... верно ...

    А без DHCP новый домен, конечно же не может ? Ну то есть просто будет получать адреса от старого DHCP, а после переноса уже поставить свой DHCP ?


    =STAS=

    9 ноября 2017 г. 14:27
  • Хм ... верно ...

    А без DHCP новый домен, конечно же не может ? Ну то есть просто будет получать адреса от старого DHCP, а после переноса уже поставить свой DHCP ?


    =STAS=

    во время переноса компьютерам можно прописать статику, а потом разом удалённо включить диначеские адреса. Вот по этому, я всё ещё рассматриваю вариант не миграции, а обновления с переименованием домена.
    9 ноября 2017 г. 14:32
  • Что там с тестовым стендом ? Какие результаты ?

    =STAS=

    10 ноября 2017 г. 14:50
  • ну я пока настроил 2013, читаю как чистить домен от следов почтового сервера, потом буду делать резервную копию (надо будет делать копию не только баз, но и всяких правил и прочих настроек). Может за выходные успею ещё что-нить сделать.
    10 ноября 2017 г. 15:09
  • - удалил Exchange 2013 из панели управления
    - почистил следы по этому видео
    - переименовал домен по этой статье
    - поставил новый Exchange 2013 на старом сервере (базы на котором я не удалял):

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

    11 ноября 2017 г. 16:36
  • хех... а вот и первый косяк всплыл. И ещё не понятно, откуда взялся net.framework 4.7??? Он же не поддерживается Exchange-ми...

    13 ноября 2017 г. 9:13
  • Так видимо поставил с обновлениями Windows. Там же как: если обновление отменяешь, то после восстановления системы оно опять появляется - вот и поставил наверное.

    =STAS=

    • Изменено _STAS_ 13 ноября 2017 г. 9:47
    13 ноября 2017 г. 9:27
  • вернул в зад 4.6.2, теперь немного другая ошибка:

    + Powershell, где фигурирует старое имя (где бы его в AD найти и поменять?):

             Welcome to the Exchange Management Shell!
    
    Full list of cmdlets: Get-Command
    Only Exchange cmdlets: Get-ExCommand
    Cmdlets that match a specific string: Help *<string>*
    Get general help: Help
    Get help for a cmdlet: Help <cmdlet name> or <cmdlet name> -?
    Exchange team blog: Get-ExBlog
    Show full output for a command: <command> | Format-List
    
    Show quick reference guide: QuickRef
    Tip of the day #43:
    
    Do you have a user who has network access but maintains an external mail account outside your Exchange organization? Wit
    h Exchange 2013, you can now create mail-enabled users that are regular Active Directory accounts, but also behave like
    mail-enabled contacts. By using the Enable-MailUser cmdlet, you can add email contact attributes to any existing Active
    Directory user who doesn't already have a mailbox on an Exchange server. Users in your Exchange organization will then b
    e able to send email messages to that user's external mail account. Type:
    
     Enable-MailUser -Identity <Active Directory Alias> -ExternalEmailAddress <Destination SMTP Address>
    
    VERBOSE: Connecting to EX13.exonix.ru.
    New-PSSession : [ex13.exonix.ru] Connecting to remote server ex13.exonix.ru failed with the following error message :
    The WinRM client cannot process the request. It cannot determine the content type of the HTTP response from the
    destination computer. The content type is absent or invalid. For more information, see the
    about_Remote_Troubleshooting Help topic.
    At line:1 char:1
    + New-PSSession -ConnectionURI "$connectionUri" -ConfigurationName Microsoft.Excha ...
    + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        + CategoryInfo          : OpenError: (System.Manageme....RemoteRunspace:RemoteRunspace) [New-PSSession], PSRemotin
       gTransportException
        + FullyQualifiedErrorId : -2144108297,PSSessionOpenFailed
    VERBOSE: Connecting to EX13.domain.local.
    New-PSSession : [ex13.domain.local] Connecting to remote server ex13.domain.local failed with the following error
    message : WinRM cannot process the request. The following error occurred while using Kerberos authentication: Cannot
    find the computer EX13.domain.local. Verify that the computer exists on the network and that the name provided is
    spelled correctly. For more information, see the about_Remote_Troubleshooting Help topic.
    At line:1 char:1
    + New-PSSession -ConnectionURI "$connectionUri" -ConfigurationName Microsoft.Excha ...
    + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        + CategoryInfo          : OpenError: (System.Manageme....RemoteRunspace:RemoteRunspace) [New-PSSession], PSRemotin
       gTransportException
        + FullyQualifiedErrorId : NetworkPathNotFound,PSSessionOpenFailed
    VERBOSE: Connecting to EX13.domain.local.
    New-PSSession : [ex13.domain.local] Connecting to remote server ex13.domain.local failed with the following error
    message : WinRM cannot process the request. The following error occurred while using Kerberos authentication: Cannot
    find the computer EX13.domain.local. Verify that the computer exists on the network and that the name provided is
    spelled correctly. For more information, see the about_Remote_Troubleshooting Help topic.
    At line:1 char:1
    + New-PSSession -ConnectionURI "$connectionUri" -ConfigurationName Microsoft.Excha ...
    + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        + CategoryInfo          : OpenError: (System.Manageme....RemoteRunspace:RemoteRunspace) [New-PSSession], PSRemotin
       gTransportException
        + FullyQualifiedErrorId : NetworkPathNotFound,PSSessionOpenFailed
    VERBOSE: Connecting to EX13.domain.local.
    New-PSSession : [ex13.domain.local] Connecting to remote server ex13.domain.local failed with the following error
    message : WinRM cannot process the request. The following error occurred while using Kerberos authentication: Cannot
    find the computer EX13.domain.local. Verify that the computer exists on the network and that the name provided is
    spelled correctly. For more information, see the about_Remote_Troubleshooting Help topic.
    At line:1 char:1
    + New-PSSession -ConnectionURI "$connectionUri" -ConfigurationName Microsoft.Excha ...
    + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        + CategoryInfo          : OpenError: (System.Manageme....RemoteRunspace:RemoteRunspace) [New-PSSession], PSRemotin
       gTransportException
        + FullyQualifiedErrorId : NetworkPathNotFound,PSSessionOpenFailed
    VERBOSE: Connecting to EX13.domain.local.
    New-PSSession : [ex13.domain.local] Connecting to remote server ex13.domain.local failed with the following error
    message : WinRM cannot process the request. The following error occurred while using Kerberos authentication: Cannot
    find the computer EX13.domain.local. Verify that the computer exists on the network and that the name provided is
    spelled correctly. For more information, see the about_Remote_Troubleshooting Help topic.
    At line:1 char:1
    + New-PSSession -ConnectionURI "$connectionUri" -ConfigurationName Microsoft.Excha ...
    + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        + CategoryInfo          : OpenError: (System.Manageme....RemoteRunspace:RemoteRunspace) [New-PSSession], PSRemotin
       gTransportException
        + FullyQualifiedErrorId : NetworkPathNotFound,PSSessionOpenFailed
    Failed to connect to an Exchange server in the current site.
    Enter the server FQDN where you want to connect.:
    
    

    Кстати, старый домен ещё присутсвует в DNS, но там нет записи для EX13... создал алиас, указывающий на новый домен... всё равно ругань на WinRM:

    [PS] C:\Windows\system32>New-PSSession -ComputerName ex13.domain.local
    New-PSSession : [ex13.domain.local] Connecting to remote server ex13.domain.local failed with the following error
    message : WinRM cannot process the request. The following error occurred while using Kerberos authentication: Cannot
    find the computer ex13.domain.local. Verify that the computer exists on the network and that the name provided is
    spelled correctly. For more information, see the about_Remote_Troubleshooting Help topic.
    At line:1 char:1
    + New-PSSession -ComputerName ex13.domain.local
    + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        + CategoryInfo          : OpenError: (System.Manageme....RemoteRunspace:RemoteRunspace) [New-PSSession], PSRemotin
       gTransportException
        + FullyQualifiedErrorId : NetworkPathNotFound,PSSessionOpenFailed

    • Изменено Anahaym 13 ноября 2017 г. 10:18
    13 ноября 2017 г. 10:14
  • А на 4.5 не откатить ?

    =STAS=

    13 ноября 2017 г. 11:27
  • 4.6 поддерживается. сейчас установил ещё один тестовый домен, буду сравнивать настройки IIS
    13 ноября 2017 г. 11:46
  • Насколько я понял, 4.7 не поддерживается даже в последнем CU для Ексча 2016, который я планирую поставить. Вот думаю, подождать немного ещё или ставить всё-таки с 4.62 ?

    =STAS=

    14 ноября 2017 г. 11:35
  • да, я писал что 4.7 никем не поддерживается. 4.6.2 норм. я ещё недельку побадаюсь с этой ошибкой, если ничего не получится - значит не судьба.
    14 ноября 2017 г. 11:44
  • А есть какой-то мануал в инете по добавлению второго DC на Windows Server 2016, если первый DC на Windows Server 2008R2 ?

    =STAS=

    15 ноября 2017 г. 12:24
  • - переименовать 2016 в нормальное имя
    - добавить 2016 в домен
    - установить роль AD DS
    - выбрать:

    - всё остальное по умолчанию
    - выставляем сетевые настройки в DNS: сам на себя, на партнёра, 127.0.0.1
    - перезагружаем

    15 ноября 2017 г. 12:33
  • О, спасибо ! а то пишет dcpromo перенесён в диспетчер серверов, а где там его искать ... в DNS рекомендуют первым другой сервер ставить, а вторым уже текущий.

    =STAS=

    15 ноября 2017 г. 13:15
  • О, спасибо ! а то пишет dcpromo перенесён в диспетчер серверов, а где там его искать ... 

    сразу после установки AD DS можно будет выбрать "promote this server to a domain controller":

    Если уже закрыли это окно, то запустите его из "Server Manager":

    в DNS рекомендуют первым другой сервер ставить, а вторым уже текущий.
    это рекомендуют те, кто остался жить в 2000 году. начиная с Window Server 2003 необходимости в перекрёстных DNS нет
    • Изменено Anahaym 15 ноября 2017 г. 13:26
    15 ноября 2017 г. 13:21
  • А такой ещё вопрос: с 12 принтерами серверными на порту 9100, развёрнутыми через групповые политики, что делать ? Как их дублировать на новый DC ?

    =STAS=

    • Изменено _STAS_ 16 ноября 2017 г. 12:52
    16 ноября 2017 г. 12:49
  • А такой ещё вопрос: с 12 принтерами серверными на порту 9100, развёрнутыми через групповые политики, что делать ? Как их дублировать на новый DC ?

    =STAS=

    по принтерам помочь не смогу (не мигрировал сам), но есть статья по этому поводу у MS. А так 12 принтером можно и вручную настроить.
    16 ноября 2017 г. 13:09
  • Настроить-то можно, я не об этом. Я не совсем понимаю процесс ... скажем, когда один DC с принт-сервером ушёл в даун, как второй DC с таким же с принт-сервером его подхватит ? Ну это не в этой ветке, я думаю. Спасибо вам за ответы. На выходных попробую реализовать.

    =STAS=

    16 ноября 2017 г. 13:42
  • Настроить-то можно, я не об этом. Я не совсем понимаю процесс ... скажем, когда один DC с принт-сервером ушёл в даун, как второй DC с таким же с принт-сервером его подхватит ? Ну это не в этой ветке, я думаю. Спасибо вам за ответы. На выходных попробую реализовать.

    =STAS=к

    это либо делать кластер, либо вроде есть ещё фишка, как создать отказоустойчивость для принтеров.  К сожалению, не помню сейчас. но лучше создать новую тему.
    16 ноября 2017 г. 13:56