Рекомендации по развертыванию приложений на основе групповой политики

Несколько месяцев назад я написал статью, объясняющую, как можно использовать групповую политику для развертывания программных приложений среди пользователей (http://www.windowsnetworking.com/articles_tutorials/Group-Policy-Deploy-Applications.html). Хотя в этой статье были рассмотрены основы развертывания приложений, нехватка места не позволила мне рассказать о передовых методах развертывания приложений с помощью групповой политики. Если вы еще не поняли, не каждое приложение можно успешно развернуть с помощью параметра групповой политики. Даже если приложение разработано таким образом, что его можно развернуть с помощью групповой политики, есть много возможностей для того, чтобы что-то пойти не так. В этой статье я хочу поделиться с вами некоторыми методами, которые увеличат ваши шансы на успешное развертывание.

Расширенная подготовка

Первая передовая практика, которой я хочу с вами поделиться, заключается в том, что вы должны подготовить приложение, которое вы будете развертывать, до его фактического назначения или публикации. В частности, если вы планируете внести какие-либо изменения в пакет установщика Windows, вы должны внести эти изменения до публикации или назначения приложения. В противном случае ваши изменения будут проигнорированы. Если вы обнаружите, что измененный пакет игнорируется, вам придется удалить приложение и исключить его из публикации или назначения, а затем повторно опубликовать или переназначить измененную версию. Если вы случайно развернете приложение до изменения установщика, иногда вам может сойти с рук развертывание измененного пакета приложения и обмануть Windows, заставив ее думать, что это обновление до немодифицированной версии в качестве альтернативы полному удалению и повторной установке приложения, которое было развернут случайно.

Используйте файлы MSI вместо файлов ZAP

Когда вы развертываете приложение через групповую политику, редактор групповой политики требует указать имя установочного пакета приложения. Есть два разных типа пакетов, которые вы можете использовать; МСИ и ЗАП.

Пакеты MSI всегда предпочтительнее пакетов ZAP. Пакеты MSI (пакеты установщика программного обеспечения Microsoft) — это файлы MSI, которые включены во все приложения, выпущенные Microsoft за последние несколько лет. Эти файлы также довольно широко используются сторонними приложениями. Файлы MSI, безусловно, являются предпочтительным механизмом для развертывания приложений, но, поскольку не каждое приложение поставляется с файлами MSI, Microsoft разрешает использование файлов ZAP.

Файлы ZAP — это в основном просто текстовые файлы, которые вы можете создать в качестве установочного пакета для приложений, не включающих пакет MSI. Конечно, есть причина, по которой я сказал, что файлы MSI предпочтительнее файлов ZAP. Во многих случаях назначенное приложение, развернутое с помощью групповой политики и содержащее файл MSI, может самовосстанавливаться. Это означает, что если один из файлов приложения случайно удаляется с компьютера пользователя, этот файл часто может быть автоматически заменен. Однако, если приложение было установлено с использованием ZAP-пакета, механизм самовосстановления не может быть использован.

Есть несколько других ограничений, связанных с использованием пакета ZAP для установки приложений. Приложения, установленные с помощью ZAP-пакета, не могут быть удалены, а фоновая установка не поддерживается.

Сейчас вы, наверное, задаетесь вопросом, почему я потрудился рассказать вам об этом. В конце концов, большинство людей столкнутся с проблемой создания ZAP-файла только в том случае, если нет доступного MSI-файла. Причина, по которой я говорю вам использовать файлы MSI вместо файлов ZAP, заключается в том, что вы можете создать свой собственный файл MSI. Традиционно файлы MSI было довольно сложно создать, если вы не являетесь разработчиком, но есть несколько сторонних приложений, которые могут создать файл MSI для вашего приложения с помощью сравнения. Идея состоит в том, что вы устанавливаете чистую копию Windows на ПК, а затем делаете снимок жесткого диска ПК. Затем вы устанавливаете приложение, для которого хотите создать MSI-файл, и делаете еще один снимок жесткого диска. Два моментальных снимка сравниваются на наличие различий, и на основе этих различий создается файл MSI.

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

Организованное назначение или публикация приложений

Одна из самых сложных вещей при работе с групповыми политиками в средних и крупных компаниях — это их иерархический характер. Отдельные объекты групповой политики могут быть назначены на уровне локального компьютера, домена, сайта и организационного уровня Active Directory для формирования групповой политики. Еще больше усложняет ситуацию то, что объекты групповой политики могут применяться как к пользователям, так и к компьютерам на любом из только что упомянутых уровней. Это означает, что может быть много частей, составляющих групповую политику, и есть много места для путаницы, дублирования или противоречий политик.

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

Эта конкретная рекомендация не будет работать для каждой организации, но я считаю полезным придерживаться публикации или назначения приложений либо пользователям, либо компьютерам, но не обоим сразу. Иногда могут возникать проблемы, если действующая политика назначает или публикует приложение как для пользователя, так и для компьютера. В этом случае я обычно стараюсь назначать или публиковать приложения только пользователям. Таким образом, вам не нужно беспокоиться о том, что одно и то же приложение будет назначено или опубликовано на уровне компьютера. Конечно, нет никаких причин, по которым вы не можете публиковать и назначать приложения как пользователям, так и компьютерам, вы просто должны быть осторожны, если делаете это.

Еще одна хитрость, которую вы можете использовать, чтобы избежать путаницы, — публиковать и назначать приложения в верхней части иерархии групповой политики. Элементы групповой политики применяются сначала на уровне локального компьютера, а затем на уровне домена, сайта и организационного подразделения. Если возникает противоречие, то параметр политики более высокого уровня переопределяет параметр политики более низкого уровня. Например, если параметр был применен на уровне домена, а затем на уровне организационного подразделения был применен противоречивый параметр, то параметр уровня организационного подразделения будет иметь приоритет над параметром политики на уровне домена.

Один из способов, которым вы можете воспользоваться преимуществом работы групповых политик и в то же время избежать путаницы, — публиковать и назначать приложения только на одном уровне в Active Directory (предпочтительно на уровне организационного подразделения). Конечно, это поднимает вопрос о том, как вы контролируете, на каких пользователях или компьютерах развертываются приложения, если вы используете только одно место в Active Directory для определения политик, связанных с развертыванием приложений.

Я не рекомендую использовать этот трюк для других типов настроек групповой политики, но он, как правило, работает довольно хорошо для развертывания приложений. Многие люди не осознают этого, но элементы групповой политики на самом деле имеют связанные с ними списки контроля доступа. Вы можете использовать эти списки управления доступом, чтобы контролировать, кому приложение доступно и кому оно недоступно. Например, представьте, что вы опубликовали приложение на уровне организационного подразделения, и при этом приложение стало доступным для всех. Предположим, однако, что у вас недостаточно лицензий, чтобы развернуть приложение для всех, поэтому вы хотите предотвратить развертывание приложения в бухгалтерии. Для этого вы можете щелкнуть правой кнопкой мыши список опубликованного приложения и выбрать команду «Свойства» в появившемся контекстном меню. Затем вы можете выбрать вкладку «Безопасность» и использовать содержащийся в ней список контроля доступа, чтобы предотвратить применение политики к бухгалтерскому отделу.

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

Вывод

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