Задний план:
У меня есть домен (функциональный уровень 2003), в котором используются клиенты Windows XP и Windows 7. Мы использовали групповую политику для управления нашими рабочими станциями.
Теперь я в ситуации, когда мне нужно применить другой GPO Политики (не Предпочтения) на основе какой-то сложной логики. Я мог бы создать несколько объектов групповой политики и выполнить фильтрацию безопасности / WMI, но это будет беспорядочно. Сценарий был бы для нас более чистым подходом (особенно PowerShell).
Что я хочу сделать:
Я хочу использовать сценарии запуска для включения политик GPO. Похоже, что мои сценарии входа в систему могли редактировать содержимое HKEY_LOCAL_MACHINE \ SOFTWARE \ Policies и HKEY_CURRENT_USER \ SOFTWARE \ Policies. Эти записи реестра хорошо задокументированы и установить их довольно просто. Я видел множество случаев, когда люди делали это в Интернете, но я хочу убедиться, что это разумная идея, прежде чем делать это.
Компьютеры по-прежнему будут присоединены к домену, и в нем все еще будут присутствовать некоторые объекты групповой политики (по крайней мере, политика домена по умолчанию). Таким образом, возможны конфликты с существующими политиками. Я ожидаю, что произойдет следующее:
Итак, я правильно понимаю? Это нормально?
Ваше понимание правильное.
Когда ваша компания достигнет размера, необходимого для привлечения специального системного администратора Windows, они будут недовольны тем, что вы это сделали.
Я не могу представить, чтобы ваша логика была настолько сложной, что ее нельзя было бы решить с помощью встроенных функций в групповой политике. Фильтрация группы безопасности, фильтрация WMI (которая требует больших затрат производительности, но гибкость) и таргетинг на уровне элементов в настройках групповой политики - все это обеспечивает большую гибкость таблицы. Использование стандартных функций операционной системы означает, что вы можете получить поддержку от Microsoft и квалифицированных сторонних организаций. Расскажите нам подробнее о своих логических потребностях, если вы так склонны.
С точки зрения функциональности вы многое теряете. Первые несколько элементов, которые приходят на ум, включают фоновое обновление, осведомленность о сайте, избыточность SYSVOL, а также инструменты для управления ОС, ведения журналов и отчетов. Я уверен, что есть еще много чего, о чем я не думаю.
С точки зрения ремонтопригодности: когда вы катите свою вещь, а она ломается, вы можете сохранить обе части. Когда вы покидаете компанию, вы оставляете их «сухо и сухо» с тем, что вам может показаться чем-то простым и самодокументируемым, но для следующего человека это потребует некоторой степени обучения (особенно если ваша логика такова). сложный).
Чтобы поговорить с вашим комментарием re: управление версиями - я бы сказал, что вы жестяная банка "версия и различия" параметры объекта групповой политики довольно легко с помощью командлета Powershell Get-GPOReport, который может выводить XML-файл, содержащий настройки GPO.
Вы понимаете правильно, но когда компьютер запускается, вы можете закончить тем, что изменения вашего скрипта не будут работать в случае конфликта и настроек приоритета (например, GPO, у которого есть сценарий запуска, запускается первым, а затем есть другой GPO, который изменяет это стоимость)
Моделирование GPO дает вам единое представление о том, какая конфигурация используется. Когда вы уберете некоторые настройки, выполнение RSOP на клиенте расскажет вам только половину истории. Если люди, обслуживающие рабочие станции, не знают, что вы вставляете эти ключи и это влияет на машины, устранение неполадок будет немного сложнее.