Alexey Dmitriev

1. В 2019 маппинг дисков правильнее делать через GPO Preferences и фильтровать его по item-level targeting там же.
2. Стоит понимать, что в общем и целом за исключением очень исключительных случаев, когда без GPO Loopback никак нельзя - политики из Computer Configuration применяются к OU с компьютерами, User Configuration - к пользователям. Ваши скриншоты не несут понимания, что вы это соблюдаете, так как в одной политике включены обе части - и Computer Configuration и User Configuration (а пустые и неиспользуемые части принято выключать для снижения нагрузки на RSOP).

В результате должна получиться политика GPO, прилинкованная к OU со всеми членами группы "Old_Server", либо на OU уровнями выше, без каких либо фильтров за исключением Item-level targeting.

Что-то типа:
1. Проанализировать текущий DHCP на предмет того, что нужно переносить в новый.
2. Выставить минимальное время аренды для DHCP leases.
3. Настроить и проверить новый DHCP сервер на сервере с отключенной сетью.
4. В нерабочее время после окончания первоначального времени аренды остановить старый и запустить новый.

P.S. Если у вас есть системный администратор, ваш вопрос можно было бы задать ему.

Стандартным и описанным много раз в Интернете способом, который поэтому очень легко гуглится.
Создать в AD группу\группы, добавить для нее\них с помощью GPO запреты на различные нужные типы входов, добавлять сервисные учетные записи при создании в нужную группу\группы.
Вот прямо начиная отсюда https://learn.microsoft.com/en-us/previous-version... и 4 Deny Log On вниз
Можно запрещать разные типы для разных групп, можно комбинировать - одна или парочка.

Локальные зоны, далее stub зоны и conditional forwarders, затем запросы через forwarders и если они пустые то к корневым серверам через root hints.
Вот так и работает и какого черта нельзя было это нагуглить или хотя бы увидеть в настройках dns сервера

Чтобы восстановить "корректную связь между сервером и компьютером", необходимо поднять уровень домена и леса Active Directory хотя бы до минимального по требованиям к Windows 11 24H2.
Ну и не использовать в инфраструктуре ОС, снятые с поддержки 10 лет назад.

Найти, куда вносятся изменения, вероятнее всего в реестр.
И просто разлить ключ реестра политикой.

Как уже ответили выше-единственный способ - это найти, где он залогинен и выключить машину.
А вот чтобы знать эту информацию - можно использовать например startup скрипт в GPO, который будет писать имена машин, где залогинился пользователь, например в любой из пустых extended attributes УЗ пользователя в AD и shutdown скрипт, который будет удалять.

Для nt service\mssqlserver - никак.
Заведите две одинаковые локальные УЗ с одинаковым именем и паролем и от одной запустите SQL сервер, а для второй откройте доступ к шаре.

Политики паролей компьютеров не связаны с политиками паролей пользователей.
Для изменения политик паролей пользователей нужны либо:
1. GPO с политикой паролей пользователей, примененная к OU c пользователями.
2. Fine-Grained Policy, примененная опять таки к пользователям или игруппе с пользователями.

1. Корневой и выпускающий сертификаты должны быть установлены в хранилища ОС на всех машинах, включая веб серверы.
2. Если конвертируете сертификат в PEM для apache\nginx и т.п., используйте полную цепочку, то есть добавляйте в файл сертификата и корневой с выпускающим сертификаты.
3. Проверьте, что CRL доступны и не просрочены.
Если эти три условия соблюдены, остальные ошибки уже на уровне ошибок при выпуске конкретного сертификата.

Компьютерные политики правильнее применять к компьютерам, пользовательские - к пользователям. Только так они работают (исключая включение loopback - но loopback - это очень плохо).
Не важно, если у вас подразделения содержат и тех и других.
Любая фильтрация в GPO, кроме Item-level Targeting - это плохо, использование групп безопасности в качестве фильтров GPO - очень плохо.

Нужно использовать подходящие типы групп - global, universal и domain local, позволяющие иметь членов из другого домена\быть членами групп в другом домене. Доверительные отношения как уже заметили - необходимы.

"Хочу" ? Ну раз хотите - значит делайте, что хотите.
Мне всегде казалось, что системный администратор оперирует терминами - "как нужно, как лучше, как правильнее, как лучше для бизнеса\заказчика".
А правильно при наличии AD DHCP и DNS разворачивать также на инфраструктуре Windows Server, чтобы иметь все бенефиты такого подхода.

Реализовывать бизнес логику на скриптах - не является ни грамотным, ни оптимальным способом.
Для подобных вещей использутся Identity Managers, один из самых используемых сейчас это Keycloak
У 1с для выгрузок есть 1с:Шина

IMHO - неправильный подход к формированию ini файла - что мешает использовать в нем готовые общие переменные?
https://www.urtech.ca/2017/03/solved-common-variab...
Если что-то мешает - то только один вариант - написать скрипт например на powershell, которому можно передавать данные из переменных и который будет формировать нужный вам файл и класть его куда нужно.

Для внесения изменений со стороны стороннего сервиса не нужна интеграция сервиса с AD.
Нужен сервисный аккаунт в AD с необходимым минимумом прав, который будет использовать сторонний сервис для внесения изменений.
Либо нужен промежуточный между сторонним сервисом и AD специализированный Identity Manager - типа MIM, либо Keycloak и.т.п.

Использовать MS Onedrive, он позволяет легко добавлять в облако Рабочий стол и документы. Бесплатный лимит 5GB.

Либо другие облачные хранилища.