Необходим совет по переносу общих ресурсов с 2003 DC на новый 2012: как избежать нарушения GPO установки программного обеспечения?
Я наконец виртуализировал всю нашу серверную инфраструктуру и готов начать миграцию на наш купленный Windows server 2019. Поскольку наша текущая установка основана на Windows Server 2003, мы, очевидно, должны сделать шаг миграции через промежуточную установку, скажем, 2012 R2 (AFAIK 2016 тоже подойдет).
Моя проблема заключается в следующем. На нашем 2003 DC расположено несколько общих файловых ресурсов. Некоторые из них очень легко скопировать на установку 2019 и просто изменить существующие GPO, чтобы они ссылались на имя сервера 2019, а не 2003.
Моя проблема связана с некоторыми GPO установки программного обеспечения, для которых соответствующие установочные пакеты MSI находятся не на SYSVOL, а на общем ресурсе, доступном как \\\srv2003\installers. Очевидно, что в конечном итоге это будет \\\srv2019\installers\, но как перейти от одного к другому? Если я "модифицирую" наши задачи установки GPO, чтобы они ссылались на новые пути установки, я вызову шторм установки у всех наших клиентов...
Можете ли вы предложить какой-нибудь совет о том, как я могу решить эту задачу? И, возможно, лучший способ иметь наши GPO msi's готовыми к установке (в SYSVOL, возможно, вместо другого ресурса)?
EDIT: Поскольку мой вопрос был закрыт, и чтобы не загромождать OP вопросами о том, почему его нужно открыть снова, проверьте мое объяснение, почему это должно остаться.
Первое, на что следует обратить внимание: настоятельно рекомендуется не использовать какие-либо роли сервера на контроллерах домена, кроме «DNS-сервера» и «доменных служб Active Directory».
Если вы выполняли миграцию с файлового сервера 2003 на файловый сервер 2019, я бы порекомендовал использовать мастер миграции хранилища, который входит в состав Windows Server 2019. Он помогает с переносом общих ресурсов, а также может перенаправлять пользователей на новый сервер после переключение с исходного файлового сервера. В данном случае я не думаю, что этот подход можно рекомендовать (переход с контроллера домена).
Моей первой мыслью было поместить оба эти пункта в качестве комментариев вместо ответа, но в настоящее время это действительно было бы «правильным» решением для создания файлового сервера, копирования установочных файлов в новый общий ресурс на нем ( вы даже можете использовать то же имя общего ресурса), а затем отредактируйте объекты групповой политики, чтобы заменить имя контроллера домена новым именем файлового сервера в UNC установщика.
Поскольку это обновление включает в себя промежуточную установку Windows Server 2012R2, я подумал о возможном пути. Предостережение заключается в том, что нет никаких допусков на погрешность, поскольку вся процедура должна выполняться за один шаг. Таким образом, следует провести планирование, например, для адаптации к DFS-R. И всю эту процедуру нужно проводить в нерабочее время.
Предположим, что текущие серверы AD - это srv1 и srv2 (Windows Server 2003R2), и что первый предоставляет общий ресурс для установки программного обеспечения на основе GPO.
Сначала сделайте резервную копию общих ресурсов.Затем введите два (а не один, поскольку, если дела пойдут не так, мы обречены) сервера Windows 2012R2 в домен. Избегайте использования Server 2016 для этого шага, я считаю, что он больше не поддерживает FRS .
Переместите роли и сделайте все необходимое для продвижения одного из двух новых серверов, передачи ролей и т. Д., А затем понизьте уровни srv1 и srv2. Удалите из домена оба сервера 2k3. Поднимите функциональный уровень до 2008 R2 (например), замените FRS на DFS. Наконец, сделайте две новые установки сервера 2019, следя за тем, чтобы:
- назовите первый именем первого старого сервера 2k3, то есть srv1 , а второй сервер - srv2
- настроить IP-адреса этих двух новых серверов так, чтобы они соответствовали старым (необязательный шаг, но я бы сделал это на всякий случай)
Повторите путь миграции, на этот раз с временных серверов на новые srv1 и srv2 и наконец, понизьте / удалите временные серверы. Повторно создайте общие ресурсы на srv1 и заполните их.
Не очень чистое решение, но оно позволит мне сохранить установленные GPO без изменения имени / переустановки.
РЕДАКТИРОВАТЬ: Я только что закончил эту процедуру. Он работал безупречно, когда новые клиентские системы загружали установочные пакеты GPO.Все довольны!
Я не знаю чистого решения вашей текущей проблемы. Но я могу предложить вам подсказку на будущее:
Используйте для этой цели определенное имя, например install.your.domain, и установите DNS-запись srv2019 с этим именем. В следующий раз, когда вы переместите свой установочный ресурс, просто измените эту DNS-запись.
Для вашей текущей проблемы может быть важно что-то вроде этого:
- Убедитесь, что srv2003 больше используется только для этого общего ресурса.
- Зеркальное копирование общего ресурса на srv2019
- Измените DNS-запись для srv2003 на IP-адрес srv2019.
- Decommission srv2003
- Создайте новые объекты GPO для недавно установленных клиентов и нового программного обеспечения, используйте конкретное имя, упомянутое здесь выше
По мере замены старых клиентов или полной настройки новых использование старого объекта GPO сокращается до тех пор, пока оно не станет возможным. быть удаленным в какой-то момент.
Я согласен со SturdyErde в том, что вам следует избегать общих файловых ресурсов на вашем DC, но я перенес свою компанию с SBS08 пару лет назад и понимаю, что иногда это так. Высокоуровневое описание моего предлагаемого пути обновления::
- Добавьте сервер 2012 R2 в домен в качестве контроллера домена
- Отразите свои общие ресурсы
- Списание srv2003
- Добавьте свой сервер 2019 в домен
- Создать DNS-псевдоним srv2003, указывающий на srv2019
- Продвижение 2019
Здесь будут повышаться уровни функционального домена, но главное — сделать DNS-псевдоним srv2003, чтобы он указывал на новые общие ресурсы, как только вы выводите из эксплуатации старый сервер.
Я также согласен со SturdyErde в том, что вам следует обратиться к мастеру миграции хранилища. Я считаю, что есть вариант, который переименовывает новый сервер в имя старого сервера, но я немного нервничаю при мысли о том, чтобы сделать это с контроллером домена.
Удачи!