Необходим совет по переносу общих ресурсов с контроллера домена 2003 года на новый 2012 года: как избежать нарушения объектов групповой политики установки программного обеспечения?

Я, наконец, виртуализировал всю нашу серверную инфраструктуру и готов начать миграцию на наш купленный Windows Server 2019. Поскольку наша текущая установка основана на Windows Server 2003, нам, очевидно, придется выполнить шаг миграции посредством промежуточной установки, скажем, 2012 R2. (AFAIK 2016 тоже подойдет).

Моя проблема заключается в следующем. Наш DC 2003 содержит несколько файловых ресурсов. Некоторые из них очень легко скопировать в установку 2019 года и просто изменить мои существующие объекты групповой политики, чтобы они ссылались на имя сервера 2019 года вместо 2003 года.

Моя проблема связана с определенными объектами групповой политики для установки программного обеспечения, для которых соответствующие установочные пакеты MSI находятся не на SYSVOL, а на общем ресурсе, доступном как \srv2003\установщики. Очевидно, что это закончится как \srv2019\установщики\ но как перейти от одного к другому? Если я «изменю» наши задачи установки GPO, чтобы они ссылались на новые пути установки, я вызову бурю установки для всех наших клиентов...

Можете ли вы дать какие-либо советы о том, как я могу выполнить эту задачу? И, возможно, лучший способ подготовить наш GPO msi к установке (возможно, в SYSVOL вместо другого общего ресурса)?

РЕДАКТИРОВАТЬ: Поскольку мой вопрос был закрыт и чтобы не загромождать ОП тем, почему его следует открыть повторно, проверьте мое объяснение того, почему это должно остаться.

Поскольку это обновление включает в себя промежуточную установку Windows Server 2012R2, я подумал о возможном пути. Предостережение заключается в том, что нет никаких погрешностей, поскольку весь процедура должна выполняться в один шаг. Таким образом, необходимо планировать, например, приспособиться к переходу на DFS-R. И вся эта процедура должна выполняться в нерабочее время.

Предположим, что текущими серверами AD являются srv1 и srv2 (Windows Server 2003R2), и что первый предоставляет общий ресурс для установки программного обеспечения на основе GPO.

Сначала сделайте резервную копию акций где-нибудь. Затем ввести в домен два (а не один, так как если что-то пойдет не так, то мы обречены) серверов Windows 2012R2 в домен. Избегайте использования Server 2016 для этого шага, я так думаю. прекратил поддержку ФРС.

Переместите роли и сделайте все необходимое, чтобы повысить один из двух новых серверов, передать роли и т. д., а затем понизить роль srv1 и srv2. Удалите оба сервера 2k3 из домена. Поднимите функциональный уровень до 2008 R2 (например), замените FRS на DFS. Наконец, сделайте две новые установки сервера 2019 года, позаботившись о:

• назовите первый именем первого старого сервера 2к3, то есть srv1, а второй сервер как срв2
• настроить IP-адреса этих двух новых серверов, чтобы они соответствовали старым (необязательный шаг, но я бы сделал это на всякий случай)

Повторите путь миграции, на этот раз с временных серверов на новые srv1 и srv2 и, наконец, понизьте/удалите промежуточные серверы. Повторно создайте общие ресурсы на srv1 и заполните их.

Не очень чистое решение, но оно позволит мне сохранить мои установочные объекты групповой политики без изменения имени/переустановки.

РЕДАКТИРОВАТЬ: я только что закончил эту процедуру.Он работал безупречно, новые клиентские системы загружали установочные пакеты GPO. Все счастливы!

Первое важное замечание: крайне не рекомендуется использовать какие-либо серверные роли на контроллерах домена, кроме «DNS-сервера» и «Доменных служб Active Directory».

Если вы выполняли миграцию с файлового сервера 2003 года на файловый сервер 2019 года, я бы рекомендовал использовать мастер миграции хранилища, включенный в Windows Server 2019. Он помогает с переносом общих ресурсов, а также может перенаправлять пользователей на новый сервер после перехода с оригинальный файловый сервер. В этом случае я не думаю, что этот подход можно рекомендовать (миграция с контроллера домена).

Мое первое желание состояло в том, чтобы поместить оба из них в качестве комментариев вместо ответа, но на данный момент действительно было бы «правильным» решением создать файловый сервер, скопировать установочные файлы в новый общий ресурс на нем (вы даже можете используйте то же имя общего ресурса), а затем отредактируйте объекты групповой политики, заменив имя контроллера домена новым именем файлового сервера в UNC установщика.

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

Используйте для этой цели конкретное имя, например install.your.domain, и установите DNS-запись srv2019 с этим именем. В следующий раз, когда вы переместите свой установочный ресурс, просто измените эту запись DNS.

Для вашей текущей проблемы что-то вроде этого может быть значительным:

• Убедитесь, что srv2003 больше используется только для этой папки.
• Отразить общий ресурс на srv2019
• Измените запись DNS для srv2003 на IP-адрес srv2019.
• Списание srv2003
• Создайте новые объекты групповой политики для только что установленных клиентов и нового программного обеспечения, используйте конкретное имя, упомянутое выше здесь.

Когда старые клиенты заменяются или полностью настраиваются новые, использование вашего старого объекта групповой политики уменьшается до тех пор, пока в какой-то момент его нельзя будет удалить.

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

• Добавьте сервер 2012 R2 в домен в качестве контроллера домена.
• Отражайте свои акции
• Списание srv2003
• Добавьте свой сервер 2019 в домен
• Создайте псевдоним DNS srv2003, указывающий на srv2019.
• Продвижение 2019

Там будут шаги по повышению функционального уровня домена, но главное — сделать DNS-псевдоним srv2003, чтобы он указывал на новые общие ресурсы, как только вы выведете из эксплуатации старый сервер.

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

Удачи!