none
Замена первого и основного DC на WS2008r2 RRS feed

  • Вопрос

  • Всем доброго дня!

    Подскажите, есть DC WS2008r2, со всеми ролями FSMO, GC, DNS. Рядом поднял DC WS2019 с DNS  и GC, протокол репликации поменял на DFSR. Репликация работает без проблем.

    Хочу понизить старый DC до рядового. Некоторые источники говорят что могут быть проблемы, тк старый является первым DC  в лесу и на нем имеются некоторые метаданные которых нет на других DC. Так ли это? инфы об этом не нашел.

    Мой план:

    Передаем все роли FSMO, меняем настройки TCP/IP, что бы старый смотрел на новый, у нового в DNS будет 127.0.0.1. первым. Старый будет смотреть на новый в настройках DNS. Отключаем старый DC например на неделю. Если все ок то понижаем через dcpromo.

    P.S. один домен, есть exchange 2010, SharePoint 2010.

    Есть у кого опыт? Поделитесь пожалуйста.

    16 сентября 2020 г. 6:09

Все ответы


  • Мой план:

    В виртуальной среде:
     - настраиваете тестовый КД 2008 R2
     - настраиваете тестовый Exchange 2010 с последним RU
     - добавляете тестовый КД 2019
     - переносите роли FSMO
     - понижаете КД 2008 R2
     - повышаете уровень леса и домена до 2016
     - проверяете работу Exchange 2010, ибо Microsoft не заявляет о поддержке Exchange 2010 контроллеров домена на 2019 - ссылка.

    Если всё будет работать - повторяете процедуру с рабочими серверами.

    По ДНС - Microsoft не рекомендует выставлять петлевой адрес 127.0.0.1 первым - ссылка

    16 сентября 2020 г. 7:27

  •  - проверяете работу Exchange 2010, ибо Microsoft не заявляет о поддержке Exchange 2010 контроллеров домена на 2019 - ссылка.

    ...

    По ДНС - Microsoft не рекомендует выставлять петлевой адрес 127.0.0.1 первым - ссылка

    Мое мнение: если Microsoft не гарантирует поддержку, то лучше ничего не проверять, а использовать версию ОС, для которой поддержка гарантирована. Потому что проверить самостоятельно всё (действительно всё) может оказаться затруднительным, и проблемы всплывут сильно позже перехода.

    По DNS - порядок адресов серверов DNS реально не важен: главное, чтобы там был адрес другого сервера DNS - КД, начиная со времен Win2003, всегда предпочитают зарегистрировать свои динамически регистрируемые записи не у себя, а на другом сервере DNS.


    Слава России!

    16 сентября 2020 г. 15:57
  • если Microsoft не гарантирует поддержку, то лучше ничего не проверять, а использовать версию ОС, для которой поддержка гарантирована. Потому что проверить самостоятельно всё (действительно всё) может оказаться затруднительным, и проблемы всплывут сильно позже перехода.

    Отнюдь. пример:  MS не гарантирует поддержку MS SQL на GNU Debian (ссылка на поддерживаемые ОС), однако это было "доказано", что это "работает" на Debian (ссылка) (некоторые слова специально пишу в кавычках)

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

    если учитывать тот факт, что интегрированные в AD зоны распределены (синхронизированы) между всеми ДНС в домене AD, то хранение "на другом ДНС" тождественно "у себя", и реально порядок не важен (но вот я читал в книге WS 2008 Unleashed, что перекрёстное назначение DNS уже моветон (не обязательно)). Оно работает в обоих случаях.

    Мое мнение

    если это говорит M.V.V. - значит так оно и есть. Я не знаю человека, который знает AD лучше чем M.V.V. . Без иронии\сарказма! Спасибо, Сэнсэй.

    Высказал своё мнение о проверке, потому что надежда сами знаете на каком месте...

    16 сентября 2020 г. 23:41
  • А если основным сделать DC 2019, вывести 2008-й, но схему и домен поднять до 2012R2 ???

    Далее заменим exchange на 2019 (ему минимум нужен 2012r2), и потом подымаем схему и домен до 2016.

    Рабочий вариант?

    17 сентября 2020 г. 9:36
  • по ссылке выше написано, что контроллер домена 2019 не поддерживается вообще. Порядо такой вижу:

    - понизить контролленр домена 2019 до рядового сервера
    - установить WS 2012 R2 - сделать его вторым контроллером
    - понизить контроллер домена 2008 до рядового сервера
    - обновить Exchange до 2019
    - повысить WS 2019 до контроллера домена

    17 сентября 2020 г. 9:54
  • У нас живут домены, созданные более 20-ти лет назад под Win2000 (причем миграцией с NT4). Конечно же, никаких следов от "первого DC в лесу" давно и близко не осталось, совсем. Ничего работать не перестало. То есть, с точки зрения убиения "первого DC" - никаких проблем.

    План вполне рабочий... только, единственный DC в лесу - категорически неудачная ситуация. Единственным разумным оправданием которой могу считать отсутствие лицензий и строгое соблюдение буквы закона :).

    Касательно работы Exchange 2010 - не поднимайте уровень домена/леса до 2019, когда/если останется только 2019 DC, пусть работает "как есть" (я бы апгрейдом поднял существующий DC 2008R2 -> 2012R2, уровни домена/леса соответственно, и оставил работать).

    На тему указания "127.0.0.1. первым". Вопрос в том, что запускаемые после перезагрузки сервисы, пытаются резольвить доменные имена до того, как полностью стартовал и начал отвечать на запросы DNS на этой же системе. Поэтому, если существует другой доменный DNS, лучше указывать сначала его, это может ощутимо уменьшить время получения полностью рабочего состояния системы после перезапуска. Но это "127.0.0.1. первым" штатное состояние в случае единственного DC (и единственного DNS), ничего страшного в этом нет (эффект единственного DNS Вы можете наблюдать в логах своего DC после перезагрузки - сообщения о невозможности срезольвить что-то-там).


    S.A.

    18 сентября 2020 г. 7:55
  • по ссылке выше написано, что контроллер домена 2019 не поддерживается вообще. Порядо такой вижу:

    - понизить контролленр домена 2019 до рядового сервера
    - установить WS 2012 R2 - сделать его вторым контроллером
    - понизить контроллер домена 2008 до рядового сервера
    - обновить Exchange до 2019
    - повысить WS 2019 до контроллера домена

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

    Во-вторых, миграции Exchange 2010 -> 2019 не бывает. Максимум "через версию". То есть, если 2010, то миграция на 2016.


    S.A.

    18 сентября 2020 г. 8:09
  • по ссылке выше написано, что контроллер домена 2019 не поддерживается вообще. Порядо такой вижу:

    - понизить контролленр домена 2019 до рядового сервера
    - установить WS 2012 R2 - сделать его вторым контроллером
    - понизить контроллер домена 2008 до рядового сервера
    - обновить Exchange до 2019
    - повысить WS 2019 до контроллера домена

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

    Во-вторых, миграции Exchange 2010 -> 2019 не бывает. Максимум "через версию". То есть, если 2010, то миграция на 2016.


    S.A.

    Во-первых, не важно как это назвается - суть одна и таже. Могли бы и догадаться. Никакой трудоёмкости там нет, просто делается намного дольше чем "любые операции с КД". "все свободны на неделю" - после этого нужно искать нового админа, а лучше до.

    Во-вторых, я и не говорил про прямое обновление, а вообще, что автору нужно обновится\мигрировать на 2019, так как он об этом сам и написал.

    единственный DC в лесу - категорически неудачная ситуация

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

    не поднимайте уровень домена/леса до 2019
    такого уровня не существует.
    18 сентября 2020 г. 8:32
  • Во-первых, не важно как это назвается - суть одна и таже. Могли бы и догадаться. Никакой трудоёмкости там нет, просто делается намного дольше чем "любые операции с КД". "все свободны на неделю" - после этого нужно искать нового админа, а лучше до.

    Во-вторых, я и не говорил про прямое обновление, а вообще, что автору нужно обновится\мигрировать на 2019, так как он об этом сам и написал.

    Суть обновления (как правило, синоним апгрейда - "непосредственное обновление") и миграции, существенно разная. Вам реально доводилось, для работающего Exchange, в нормальной организации, переезжать на следующую версию? Судя по написанному, в лучшему случае "лабу делали". Только перемещение почтовых ящиков из старых БД в новые занимает ... достаточно времени, не говоря о многом другом, про что тонны отдельных материалов написано. Тогда как поднять версию контроллера домена - достаточно запустить установку обновления (не забыть роли убрать с обновляемого DC), проверить результат - это для сравнения. Проделать миграцию Exchange дважды, по причине "замены контроллера домена"? Ну, можно поразвлекаться, наверное, если там 10-к почтовых ящиков и БД на пару гигов, для получения опыта. Если заняться больше нечем. А, да, ещё к 2019 Exchange 128 GB RAM в требованиях прописано, не забыть приготовить :).

    Про единственный DC - "а почему должно сломаться?" - патамучта "всё, что может сломаться, обязательно сломается". Не слышали? Поднимать из бекапа единственный погибший DC в "режиме восстановления AD", в реалиях, тоже не доводилось, судя по всему? В действительно работающей организации оно как раз может быть поводом для "после этого нужно искать нового админа". В случае же как минимум двух DC, оно "перехват ролей, ручная чистка AD, поднятие нового DC" - максимум полдня, хотя и торопиться не обязательно. Или отказ в обслуживании на время от нескольких часов (когда процесс восстановления заранее спланирован, ресурсы в наличии) до дней (когда пошли искать, куда бы восстанавливаться), или прозрачная (почти) для пользователей ситуация с возможностью продолжения работы - разницы не ощущаете?

    Про "уровень леса 2019" - сорри, описался, 2016 конечно. А вот вариант 2019 DC (один из), лес/домены 2012R2, Exchange 2010, у нас работал ещё прошлой зимой. Без проблем. Работает оно так.


    S.A.

    18 сентября 2020 г. 10:05
  • Вам реально доводилось, для работающего Exchange, в нормальной организации, переезжать на следующую версию?

    не один раз обновлял\мигрировал на новые версии Exchange. Первый раз 10 лет назад с одного сервера 2007 на 2010 с DAG.

    Только перемещение почтовых ящиков из старых БД в новые занимает ... достаточно времени

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

    Поднимать из бекапа единственный погибший DC в "режиме восстановления AD", в реалиях, тоже не доводилось, судя по всему

    отнюдь, очень даже доводилось. и только в тех команиях, где доменная инфраструктура была настроена изначально неправильно, а так же за ними не следили (устанавливали всякую фигню на КД). Самый сложный случай был в компании, которая использовала SBS 2007. Пришлось отпустить всех сотрудников домой. После этого компания была мигрирована с SBS на нормальный домен.

    А вот вариант 2019 DC (один из), лес/домены 2012R2, Exchange 2010, у нас работал ещё прошлой зимой. Без проблем
    вот, а у меня такого опыта нет, поэтому я предложил ТС провести тесты самому. Спасибо за информацию.

    18 сентября 2020 г. 11:06