Показать полную графическую версию : Групповые политики: перемычки правил (loopback)
Raistlin
10-08-2011, 19:39
Задача: осуществлять с помощью групповой политики установку и настройку ПО, не полностью совместимого с технологией Windows Installer. Т. е. msi есть, но самодельный, работает только с машинной частью установки, а с пользовательской (скопировать файл в профиль, добавить значение в ветку HKCU) - не умеет. Понятно, что можно доделать msi, но... слишком много надо копать.
Появилась мысль использовать перемычки правил. Т. е. перемещаем нужные компьютеры в OU, линкуем к нему несколько GPO, каждое из которых занимается установкой одного приложения. В каждом из этих GPO включаем использование перемычек и определяем нужные пользовательские параметры. Далее создаем группы Deny_App1, Deny_App2 и т. д., добавляем их в ACL соответствующих GPO и запрещаем для них применение политики. Если на некоторый ПК из помещенных в это OU не нужно ставить некоторое приложение, добавляем его в соответствующую deny-группу.
Все логично и довольно красиво, если бы не одно "но": оказалось, что при включенных перемычках пользовательские части политик нельзя отфильтровать настройками безопасности, касающимися компьютеров. Т. е. приложения на "ненужные" машины ставиться-то не будут, но вот пользовательские настройки из соответствующих политик - применятся. А это уже не комильфо. Подробнее результаты исследования - в комментариях здесь (http://gamelton.wordpress.com/2011/06/27/gpo-loopback/).
Может, у кого идеи будут?
Проще это реализовать на основе групп.
Raistlin
10-08-2011, 20:50
А подробнее?
Создаете набор нужных групп, включаете в них учетки компьютеров.
Создаете набор GPO и привязываете его к группам.
Желательно в стартап скрипты запихать некий скрипт который бы проверял наличие установленного приложения при логине (т.е. при перезагрузке) и в случае если приложение не установлено то ставил бы его.
Raistlin
10-08-2011, 21:18
GPO, насколько мне известно, можно привязать к OU, но не к группе.
Желательно в стартап скрипты запихать некий скрипт который бы проверял наличие установленного приложения при логине »
Если вы про машинную часть GPO, то в этом нет нужды, раз установка через software deployment. Если про пользовательскую - решение не очень красивое: при каждом логине проверять на установленность 10-15 приложений.
По умолчанию оно действует на OU, но если прописать группу то будет действовать и на нее (почитайте про Group policy Security Filtering).
То что можно поставить через software deployment не всегда отрабатывает.
Например вам нужно поставить жутко лохматое :) приложение которое имеет собственный сетап или вообще его не имеет.
Вот и приходится для установки такого По использовать отдельный объект GPO который навязывает скрипт который проверяет ПК на наличие определенных условий и при их отсутствии запускает некий набор действий.
PS я таким методом проверяю наличие и работоспособность SCCm-агента и антивируса.
Raistlin
10-08-2011, 21:28
Security Filtering - это для фильтрации, как следует из названия. Чтобы на некоторые объекты, находящиеся в этом OU или ниже по иерархии, GPO не действовало. Но GPO все равно вешается на OU. Привязать GPO к группе - нельзя. By design.
И я недаром написал - интересует именно software deployment. На моей практике пока не встречалось приложений, которые через software deployment ставятся неправильно. Я даже предположу, что такого не может быть в принципе. А вот как получить msi-файл - другой вопрос. Вернее, вопрос с таким, например, ответом: AppDeploy Repackager (http://www.appdeploy.com/tools/repackager/download.asp).
Привязать GPO к группе - нельзя. By design. »
Вы пробовали?
На уровне верхнего OU создаете политику, настраиваете фильтрацию.
В результате политика действует на все ПК из этого OU с учетом фильтрации по группам.
Вы представляете контору у которой для настройки и установки софта 1500 политик?
Я - да. т.к. недавно был в гостях и у них довольно легкая структура юнитов.
Относительно правильности установки msi я не буду спорить, но вы попробуйте упаковать в него SAP-клиента или еще какого нибудь монстра :)
Raistlin
10-08-2011, 21:55
И что? Вы привязали политику к самому верхнему OU. И отфильтровали по группе. Но это не значит, что вы привязали политику к группе. У меня, кстати, так и сделано - в частности, для всех приложений, где нет "пользовательской" части установки.
Затем. Фильтрация-то действует, но - см. мой первый пост. Как быть с пользовательской частью установки?
Да к группе не привязаны но они на нее действуют.
Посмотрите gpresult /v
С пользовательской установкой сложнее т.е. лучше ее не использовать, ну или только в тех случаях когда что то работает напрямую из профиля и т.п.
PS вы SCCM не рассматривали? Для больших сетях самое то (хотя в 2007 все работает несколько странно... ), для маленьких можно использовать SCCM Essential.
В версии 2012 есть много нового.
Raistlin
10-08-2011, 22:48
Было б можно не использовать - кто бы заморачивался? Но сплошь и рядом это требуется. Например, регистрационный ключ The Bat! пишется в HKCU.
Если смотреть шире, то речь даже не об установке, а о первоначальной настройке приложения. Чтобы пользователь получал настроенное не по дефолту приложение, но при этом имел возможность перенастроить его под себя. Здесь нужен скрипт, который будет проверять, например, наличие определенной ветви в HKCU и при ее отсутствии добавлять в реестр определенные записи. Можно, конечно, заодно проверять, установлено ли приложение в принципе, но - производительность, производительность... Вот если б была возможность не гонять скрипт вообще на машинах, где приложение не установлено, - но, боюсь, средствами групповой политики это не решить.
Про SCCM только слышал мельком (вернее, про предшественника - SMS). Надо бы попробовать, да.
ключ The Bat! пишется в HKCU »
Используйте модуль registry от GPE (Group policy Extensions)
Кстати. На одном из проектов занимался App-V (http://www.microsoft.com/rus/windows/enterprise/products/mdop/app-v.aspx)
Возможно для вас это будет выходом и решением.
Суть в том что приложение один раз собирается на эталонном ПК, все что ему требуется пакуется в специальный файл и клиент получает виртуализированное приложение т.е. на клиента ничего ставить не надо.
В идеале ПК это тонкий клиент который подключается к терминальной ферме.
Raistlin
10-08-2011, 23:07
Используйте модуль registry от GPE (Group policy Extensions) »
Не совсем понимаю, о чем речь. Я добавляю ключ скриптом.
Да и вопрос-то, скажем так, уровнем выше: как добавить, сообразим, а вот как красиво ограничить множество пользователей, кому добавить?
Можно вообще абстрагироваться от установки приложений. Речь о тонком использовании перемычек правил.
Не совсем понимаю, о чем речь. »
http://www.techdays.ru/videos/1066.html
GPE это клиентское расширение политик, а управляется все через GPP (Group Policy Preferences)
Это инструмент значительно расширяющий функционал групповых политик.
а вот как красиво ограничить множество пользователей, кому добавить? »
Только через фильтрацию политик.
1. отключаем стандартное разрешение Everyone - apply. Надо оставить только read.
2. добавляем группу пользователей. Например The Bat Users, тыкаем "применять".
С помощью GPE пожно создать условие
применять политику при условии что на диске или в реестре есть определенный файл или значение.
Можно сделать изврат вплоть до условия что ПК имеет в имени такую то маску или находится в определенной подсети.
Я предпочитаю условие - пользователь входит в группу Х и компьютер входит в группу Y.
Как то так...
Raistlin
11-08-2011, 00:00
Да, надо будет посмотреть GPP. Эх, жалко, все мои недоделанные скриптовые наработки с ее появлением, похоже, теряют смысл :).
© OSzone.net 2001-2012
vBulletin v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.