Как правильно заменить старый Active Directory?

Question

[ffic]

Добрый день.
В учебном заведении поставлена цель своими силами поменять сервер Windows Server 2008 на новое железо с Windows Server 2019 (БЕЗ миграции настроек, из-за большого количества глюков). На текущем сервере установлена AD (домен напр. skolanov18.ru), DNS, файлопомойка. DHCP раздает Mikrotik, он же и шлюз. На другом сервере установлен Debian с функцией веб сервера с внешним доменным именем skolanov18.ru
Вопрос: Как правильно заменить старый сервер на новый, не прерывая работу заведения? Какое доменное имя задать новому серверу чтобы не иметь проблем с https сертификатом на Web сервере? Заранее спасибо.

Answer 1

[meDveD_spb]

Поднимается рядом Windows Server 2022 и настраиваем/повторяем те функции, что нам нужны от сервера.
И переезжаем, вроде всё просто)

Непонятно как связан домен который web-домен и домен AD, как взаимодейтвуют между собой и взаимодействуют ли вообще, этого мы не знаем. И почему у них одинаковые имена.
Чтобы не иметь проблем с сертификатами внутри сети, управляем/выпускаем/распространяем сертификаты винсервером соответствующей ролью. Чтобы не иметь проблем с сертификам для внешки, настраивам автообновление сертификатов letscrypt/acme или подключаем/возлагаем эту функцию, например на cloudflare.

Answer 2

[hint000]

поменять сервер Windows Server 2008 на новое железо с Windows Server 2019 (БЕЗ миграции настроек, из-за большого количества глюков)

Не вполне ясно, что значит "без миграции настроек". Означает ли это, что хотите поднимать новый домен? Если да, то вам придётся заново заводить в домен каждый компьютер, заново заводить каждого пользователя, переносить файлы каждого пользователя на каждом компьютере. Куча работы, и непонятно, есть ли в ней смысл.

Если нет желания такую фигню разгребать, то поднимаете новый сервер, заводите его в имеющийся домен, поднимаете на нём роли DNS и контроллера домена, повышаете его до контроллера домена в своём домене, передаёте новому серверу роли FSMO, выключаете старый и проверяете, как работает домен на новом. Если всё нормально, то включаете старый и понижаете его с контроллера до обычного компьютера. Потом можете и вовсе вывести старый из домена.

Comments

[Harbid Abu Marhamedoff]

А чтобы разрешение имён на клиентах не упало, надо как-то организовать, чтобы у всех клиентов был прописан DNS сервером новый сервер, хотя бы вторым :)

[Harbid Abu Marhamedoff]

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

[zvl]

Harbid Abu Marhamedoff, у клиентов не должно быть статических настроек при наличии в сети DHCP сервера, статика только на серверах (да и то не на всех). При раздаче параметров в динамике проблем замены DNS на клиентах нет.
В службе DNS настраиваются серверы условной пересылки для того чтобы участники каждого домена могли обращаться к ресурсам соседнего домена по имени, а не по адресу. Так же на клиентах групповой политикой или DHCP сервером можно настроить доменные суффиксы для поиска чтобы не прописывать полные FQDN имена.

[Harbid Abu Marhamedoff]

zvl, не бывает такого, чтобы в сети с доменом были только рабочие станции. Ну ладно, бывает, но только в совсем крохотных сетях (впрочем, зачем там тогда домен?!). Поставим контроллер домена с фиксированным ip, клиентские компьютеры, получающие ip от сервера dhcp, перенастроим сервис dhcp в Микротике, но ведь есть наверняка и другие серверы, имеющие статические ip? У них в настройках серверы dhcp надо будет перебивать руками, иначе они не смогут обращаться в Active Directory за информацией.
Другой вариант - ip адреса серверов прописаны в службе Микротика и назначаются их конкретным mac-адресам, так реже, но тоже делают.
Смысл написанного и так должен быть ясен - при выключении старого контроллера домена и оставлении нового, домен должен быть доступен и функционировать штатно.

[zvl]

Harbid Abu Marhamedoff, полностью согласен. Есть серверы которым статика необходима. Тот же контроллер домена хочет статический адрес при настройке, но это не принципиально и ADDS вполне может получать зарезервированный адрес от DHCP сервера в сети (не рекомендуется, но такая схема тоже работает). Есть серверы которым действительно нужна статика, но они находятся под управлением администратора который понимает что делает и может изменить сетевые настройки в соответствии с рабочими процессами. Серверов в сети значительно меньше чем рабочих станций и перебить ручками настройки не составит больших проблем.
Могу сказать за свой опыт, если рядовой сервер в домене, можно зарезервировать ему адрес на DHCP, но лучше при вводе в эксплуатацию какого либо нового сервиса изначально настраивать обращение клиентов к данному сервису по FQDN. На перспективу это упростит обновление сервиса. К примеру ADCS настраиваем на публикацию списков отзыва сертификатов не по имени сервера и не по IP адресу а по имени ca.domain.tld тогда в случае замены сервера CA в DNS потребуется изменить CNAME запись со старого имени сервера на новый (пример очень грубый, на самом деле там много всего что с CA связано).
Так же надо понимать что хочет автор вопроса, на сколько я понял необходимо перевести всех пользователей в новый "чистый" домен с наименьшими потерями времени.
Если резюмировать, то есть серверы которым должны быть назначены статические адреса (Hyper-V или DHCP например), есть серверы которые могут работать как со статическими адресами так и с динамикой (ADDS/DNS/CA), тут надо смотреть по ситуации и оценивать риски, например при отказе сервера DHCP, и есть рядовые серверы которым можно раздавать динамику, обращение к таким серверам всегда будет по доменному имени (например сервер терминалов). На рабочих станциях лучше никогда не использовать статику либо динамика либо резервирование на DHCP.
Тестирование с выключением старого контроллера домена тоже хорошая идея при этом в зависимости от топологии AD надо смотреть события на контроллерах домена находящихся в работе.
Для контроля обращений к старому серверу на его адресе можно поднять другую виртуалку или другой сервер или рабочую станцию с запущенным tcpdump или wireshark для мониторинга обращений сетевых устройств к старому серверу. Когда все устройства которые будут отображаться в логах сетевых сканеров будут перенастроены, освобождаем адрес сервера, запускаем его и корректно выводим из домена с понижением до рядового сервера и удалением служб ADDS.
Домен можно поднимать в сети любых размеров, зависит от бизнеса, кто-то готов пользоваться нелицензионным софтом, кто-то даже при малой численности сотрудников готов финансировать потребности IT и купить им необходимое количество лицензий.

[zvl]

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

Answer 3

[zvl]

Если надо перекинуть всех пользователей в новый домен можно использовать ADMT
https://docs.microsoft.com/ru-ru/troubleshoot/wind...
Поднимается рядом еще один домен, настраиваются доверительные отношения между старым и новым доменом и постепенно пользователи и компьютеры перемещаются на новый домен. Есть некоторые нюансы в именовании доменов, ну и еще некоторые. С вопросом про сайт не совсем понятно что имеется ввиду и к работе домена он особого отношения не имеет если авторизация на сайте не использует доменные сервисы

Answer 4

[Максим Ярошевич]

Ввести новый сервер в старый домен, перенести на него все роли FSMO и сервера, проверить, что всё переехало, и вывести из работы старый сервер. Зачем городить что-то новое, когда всё есть и стоит задача незаметно переехать?