Групповые политики: перемычки правил (loopback)
 

Задача: осуществлять с помощью групповой политики установку и настройку ПО, не полностью совместимого с технологией Windows Installer. Т. е. msi есть, но самодельный, работает только с машинной частью установки, а с пользовательской (скопировать файл в профиль, добавить значение в ветку HKCU) - не умеет. Понятно, что можно доделать msi, но... слишком много надо копать.
Появилась мысль использовать перемычки правил. Т. е. перемещаем нужные компьютеры в OU, линкуем к нему несколько GPO, каждое из которых занимается установкой одного приложения. В каждом из этих GPO включаем использование перемычек и определяем нужные пользовательские параметры. Далее создаем группы Deny_App1, Deny_App2 и т. д., добавляем их в ACL соответствующих GPO и запрещаем для них применение политики. Если на некоторый ПК из помещенных в это OU не нужно ставить некоторое приложение, добавляем его в соответствующую deny-группу.
Все логично и довольно красиво, если бы не одно "но": оказалось, что при включенных перемычках пользовательские части политик нельзя отфильтровать настройками безопасности, касающимися компьютеров. Т. е. приложения на "ненужные" машины ставиться-то не будут, но вот пользовательские настройки из соответствующих политик - применятся. А это уже не комильфо. Подробнее результаты исследования - в комментариях здесь.
Может, у кого идеи будут?

Проще это реализовать на основе групп.

А подробнее?

Создаете набор нужных групп, включаете в них учетки компьютеров.
Создаете набор GPO и привязываете его к группам.

Желательно в стартап скрипты запихать некий скрипт который бы проверял наличие установленного приложения при логине (т.е. при перезагрузке) и в случае если приложение не установлено то ставил бы его.

GPO, насколько мне известно, можно привязать к OU, но не к группе.

Если вы про машинную часть GPO, то в этом нет нужды, раз установка через software deployment. Если про пользовательскую - решение не очень красивое: при каждом логине проверять на установленность 10-15 приложений.

По умолчанию оно действует на OU, но если прописать группу то будет действовать и на нее (почитайте про Group policy Security Filtering).

То что можно поставить через software deployment не всегда отрабатывает.
Например вам нужно поставить жутко лохматое :) приложение которое имеет собственный сетап или вообще его не имеет.

Вот и приходится для установки такого По использовать отдельный объект GPO который навязывает скрипт который проверяет ПК на наличие определенных условий и при их отсутствии запускает некий набор действий.

PS я таким методом проверяю наличие и работоспособность SCCm-агента и антивируса.

Security Filtering - это для фильтрации, как следует из названия. Чтобы на некоторые объекты, находящиеся в этом OU или ниже по иерархии, GPO не действовало. Но GPO все равно вешается на OU. Привязать GPO к группе - нельзя. By design.

И я недаром написал - интересует именно software deployment. На моей практике пока не встречалось приложений, которые через software deployment ставятся неправильно. Я даже предположу, что такого не может быть в принципе. А вот как получить msi-файл - другой вопрос. Вернее, вопрос с таким, например, ответом: AppDeploy Repackager.

Вы пробовали?
На уровне верхнего OU создаете политику, настраиваете фильтрацию.
В результате политика действует на все ПК из этого OU с учетом фильтрации по группам.

Вы представляете контору у которой для настройки и установки софта 1500 политик?
Я - да. т.к. недавно был в гостях и у них довольно легкая структура юнитов.

Относительно правильности установки msi я не буду спорить, но вы попробуйте упаковать в него SAP-клиента или еще какого нибудь монстра :)

И что? Вы привязали политику к самому верхнему OU. И отфильтровали по группе. Но это не значит, что вы привязали политику к группе. У меня, кстати, так и сделано - в частности, для всех приложений, где нет "пользовательской" части установки.
Затем. Фильтрация-то действует, но - см. мой первый пост. Как быть с пользовательской частью установки?

Да к группе не привязаны но они на нее действуют.
Посмотрите gpresult /v

С пользовательской установкой сложнее т.е. лучше ее не использовать, ну или только в тех случаях когда что то работает напрямую из профиля и т.п.

PS вы SCCM не рассматривали? Для больших сетях самое то (хотя в 2007 все работает несколько странно... ), для маленьких можно использовать SCCM Essential.
В версии 2012 есть много нового.

Было б можно не использовать - кто бы заморачивался? Но сплошь и рядом это требуется. Например, регистрационный ключ The Bat! пишется в HKCU.
Если смотреть шире, то речь даже не об установке, а о первоначальной настройке приложения. Чтобы пользователь получал настроенное не по дефолту приложение, но при этом имел возможность перенастроить его под себя. Здесь нужен скрипт, который будет проверять, например, наличие определенной ветви в HKCU и при ее отсутствии добавлять в реестр определенные записи. Можно, конечно, заодно проверять, установлено ли приложение в принципе, но - производительность, производительность... Вот если б была возможность не гонять скрипт вообще на машинах, где приложение не установлено, - но, боюсь, средствами групповой политики это не решить.

Про SCCM только слышал мельком (вернее, про предшественника - SMS). Надо бы попробовать, да.

Используйте модуль registry от GPE (Group policy Extensions)

Кстати. На одном из проектов занимался App-V (http://www.microsoft.com/rus/windows...dop/app-v.aspx)
Возможно для вас это будет выходом и решением.
Суть в том что приложение один раз собирается на эталонном ПК, все что ему требуется пакуется в специальный файл и клиент получает виртуализированное приложение т.е. на клиента ничего ставить не надо.

В идеале ПК это тонкий клиент который подключается к терминальной ферме.

Не совсем понимаю, о чем речь. Я добавляю ключ скриптом.

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

Можно вообще абстрагироваться от установки приложений. Речь о тонком использовании перемычек правил.

http://www.techdays.ru/videos/1066.html

GPE это клиентское расширение политик, а управляется все через GPP (Group Policy Preferences)
Это инструмент значительно расширяющий функционал групповых политик.
Только через фильтрацию политик.
1. отключаем стандартное разрешение Everyone - apply. Надо оставить только read.
2. добавляем группу пользователей. Например The Bat Users, тыкаем "применять".

С помощью GPE пожно создать условие
применять политику при условии что на диске или в реестре есть определенный файл или значение.

Можно сделать изврат вплоть до условия что ПК имеет в имени такую то маску или находится в определенной подсети.
Я предпочитаю условие - пользователь входит в группу Х и компьютер входит в группу Y.

Как то так...

Да, надо будет посмотреть GPP. Эх, жалко, все мои недоделанные скриптовые наработки с ее появлением, похоже, теряют смысл :).