powershell против GPO для установки, настройки, обслуживания

Здесь нет "правильного" ответа. Лично я предпочитаю использовать групповую политику для настроек / политик, но для развертывания приложений используйте PowerShell (или даже устаревшие сценарии WSH или пакетные файлы), если у вас есть один домен без сложных проблем с доверием. Однако есть компромиссы. Все действия в PowerShell, безусловно, законны.

Развертывание приложения (GPO против скрипта):

При развертывании программного обеспечения на основе GPO вы ограничены пакетами MSI. Это может раздражать продукты, которые не распространяются через MSI (например, setup.exe). В этом случае вам нужно упаковать его как MSI. Наслаждайтесь дистрибутивом Adobe Reader MSI + MSP (необходимо создать AIP). Если вам нужно настроить установку, вам нужно возиться с преобразованиями MSI. То, что может быть одной строкой в ​​сценарии, может стать сложным многоступенчатым процессом.

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

С помощью сценария вы можете установить или удалить что угодно, будь то MSI, EXE или что угодно. Если вам нужно выполнить некоторую работу по очистке перед установкой (например, очистить старые ключи реестра из предыдущей версии, которая не была удалена полностью), вы можете это сделать. Если что-то пойдет не так, вы можете добавить столько кода отладки / повтора / обходного пути, сколько вам нужно, и вы можете запустить msixec с включенным ведением журнала.

Сценарию обычно требуется некоторая условная логика, чтобы проверить, установлено ли уже программное обеспечение (и какая версия), а затем при необходимости вызвать программу установки. Если у вас нет опыта программирования, это может напугать. Это больше не решение «укажи и щелкни». У вас также больше возможностей напортачить, поскольку вы написали это сами.

Мы перешли с GPO на PowerShell для развертывания нашего приложения, и это значительно упростило работу. Когда выходит новая версия, все, что нам нужно сделать, это удалить новые файлы установщика в общий ресурс AppDeployment и обновить переменную $ expected_version в нашем скрипте. Занимает примерно 1/10 времени.

Вы также можете использовать гибридный подход, когда вы используете GPO для материалов MSI и скрипты для всего остального. Я не фанат этого, потому что мне нравится иметь одно место, где можно посмотреть, что установлено.

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

Настройки и конфигурация (GPO против скрипта):

Предпочтения групповой политики действительно просты в использовании для таких вещей, как создание значений реестра, сопоставление сетевых дисков, создание ярлыков и т. Д. Тот факт, что групповая политика имеет фоновое обновление, удобен, потому что вы можете применять настройки, не заставляя пользователей перезагружаться. Таргетинг на уровне элементов дает вам большую гибкость (и это в дополнение к WMI и фильтрации безопасности на уровне GPO).

Однако настройки групповой политики далеки от совершенства. Некоторые из моих раздражений:

1. Существует слишком много методов управления Internet Explorer, некоторые из них устарели, некоторые не работают с последней версией IE. Я всегда заканчиваю тем, что просто управляю настройками реестра напрямую.

2. Случайные ошибки в средстве просмотра событий, которые глупо. Пример: я создал элемент для удаления запланированного задания. Отлично, он пропал со всех моих рабочих станций. Теперь программа просмотра событий начинает заполняться сообщениями об ошибках «Я не могу удалить задачу, потому что она не существует». Ах!

3. Подайте заявку один раз и не подавайте повторно поиметь вас хотя бы раз в карьере.

4. Обновление против замены. Обратите внимание, потому что вы, вероятно, выберете не тот.

5. Есть ограничения на то, что вы можете делать с таргетингом на уровень предметов. Если вам нужен цикл for () или манипуляции со строкой (обрезка символов, корректировка регистра), вы вернетесь к сценарию.

6. Операции с файлом GPP происходят всегда, даже если файлы не были изменены. Ваши рабочие станции будут копировать один и тот же файл с сервера снова и снова, даже если он им не нужен. Это может неожиданно повредить ваш сервер и сеть. Таргетинг на уровне элементов может помочь смягчить это, но следите, если у вас установлен флажок «Удалить, если не применяется».

7. Многие из ошибок GPP в средстве просмотра событий не содержат полезной информации, которая могла бы решить проблему. Ты должен включить отслеживание.

Вы можете использовать PowerShell для настроек, но у него есть и недостатки:

1. Управление настройками реестра с помощью PowerShell становится беспорядочным (по крайней мере, с собственным поставщиком реестра). На мой взгляд, Microsoft облажалась, когда сделала значения реестра «свойствами» вместо фактических элементов. Это делает вещи намного более сложными, чем нужно. Вам понадобится набор условной логики для проверки ключей реестра и их создания перед созданием значений. Групповая политика в этой области намного проще.

2. Существует множество «базовых» задач системного администратора, которые вы не можете выполнить изначально в PowerShell (например, создание ярлыка, управление запланированной задачей). Вы должны вызвать Wsh, .Net Framework или использовать сторонний модуль.

3. Сценарии запускаются только при запуске / входе в систему. Без фонового обновления (если вы не настроили запланированное задание).

4. Если вам нужно вызвать устаревшие утилиты команд Windows (net.exe, schtasks.exe), то вызвать команду может быть непросто, и еще более «сложно» добиться того, чтобы вывод на экран соответствовал выводам PowerShell. У вас может быть команда, которая не работает, и вы этого не знаете.

Некоторые другие общие комментарии к сценариям (PowerShell или иначе) по сравнению с GPO:

1. Скрипты - это в значительной степени программные проекты. Код воля со временем растут и усложняются. Если вы не относитесь к нему как к «настоящему» программному проекту с комментариями, историей версий, подпрограммами и т. Д., Он воля превратиться в непреодолимый беспорядок, который ваш преемник в конечном итоге выбросит, потому что он этого не понимал.

2. Сисадмины (как правило) не программисты. Они не знают надлежащих дисциплин программирования (см. Пункт №1). Даже хорошо структурированный код может быть устрашающим и нечитаемым для администратора, не имеющего опыта программирования. Помните о навыках вашего нынешнего и будущего персонала.

3. У скриптов есть преимущество в том, что их можно проверять в системе контроля версий и различать. С объектами групповой политики это сделать немного сложнее.

4. Сценарии проще скопировать на USB-накопитель и взять с собой. Вероятно, так было с вашим подрядчиком. Вероятно, у него были существующие скрипты из предыдущих проектов, которые он смог переработать для вашего проекта. В моей среде у меня есть две сети с воздушным зазором (не спрашивайте), но с аналогичными конфигурациями, поэтому мы используем сценарии PowerShell везде, где это возможно, чтобы мы могли повторно использовать код между двумя сетями.

5. У GPO есть преимущество в том, что вы можете использовать такие инструменты, как RSoP чтобы получить отчет обо всех настройках, примененных к конкретной рабочей станции / пользователю. Это может быть важно для аудита и устранения неполадок.

6. Объекты групповой политики более «обнаружимы». Я могу войти в незнакомую среду и довольно быстро понять, какие политики и настройки применяются. Имея сценарий, я должен начать изучать код и надеюсь, что он хорошо прокомментирован.

7. Удаленное взаимодействие PowerShell может быть действительно удобен для одноразовой команды, которую вы хотите запустить в нескольких системах, и вы не хотите, чтобы она была «постоянной» политикой (например, все удалили этот временный файл).

Независимо от того, какой подход вы используете, убедитесь, что все хорошо задокументировано. Вы должны документировать вещи в микро-level («Реализована установка x для всех рабочих станций бухгалтерии для решения проблемы с приложением y»), а также на макрос-level («Все настройки нашей рабочей станции хранятся в объекте групповой политики под названием x»).

ПОСЛЕДУЮЩИЕ РЕДАКТИРОВАНИЯ: PowerShell 4 добавляет новую функцию под названием Желаемая конфигурация состояния. Похоже, что его можно использовать для достижения некоторых из того, что делают предпочтения групповой политики. Это могло бы изменить правила игры. Еще не работал с ним, но выглядит классно.

ПОСЛЕДУЮЩИЙ РЕДАКТИРОВАНИЕ 2: Я понял одну вещь: я не различал должным образом Групповая политика Политики против Предпочтения. Настройки во многом аналогичны сценарию PowerShell. Политики немного более жесткие, и их сложнее реализовать в сценарии. Для этого вам нужно, чтобы ваш сценарий заполнял HKLM \ Software \ Policies, но вы должны помнить о конфликтах с объектами групповой политики. В таком случае делайте то или другое, а не то и другое одновременно.

Очевидно, что Microsoft считает (и почти все согласны), что групповая политика - лучший способ справиться с большей частью конфигурации клиента. Интерфейс прост, и для большинства настроек вам даже не нужно прикасаться к клавиатуре. Он даже имеет встроенную функцию отчетности.

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

Кроме того, сценарии PowerShell по умолчанию отключены при установке Windows. Но не волнуйтесь, это можно изменить с помощью групповой политики.

Судя по предыдущему опыту по обе стороны консалтингового забора, я подозреваю, что вашим консультантам легче обобщать сценарии PowerShell. Легче переносить сценарии PS с одного клиентского сайта на другой, изменяя детали, чем экспортировать / импортировать GPO, учитывая различные таргетинг на OU, которые существуют.

Если вы говорите об обслуживании рабочих станций Win7, вам также следует подумать о специальной утилите для управления системой, такой как Microsoft System Center, Kace и т. Д. Следующее звучит так, как будто это может иметь некоторое сходство с вашей ситуацией:

Как (надежно) удаленно выполнять задачи на рабочих станциях Windows в домене?

Вы мог делайте все, что хотите, с помощью PowerShell / GPO (я действительно заинтересованы в изучении новой конфигурации желаемого состояния PS 4), но часто выделенная система сэкономит время / деньги.

Для общей конфигурации групповая политика предназначена именно для этого.

Для установки программного обеспечения я бы выбрал PowerShell 100%. Мне сказали, что публикация / назначение пакетов программного обеспечения через GPO - плохая практика, и мне не очень нравится выполнять скрипты входа / выхода. Имейте сценарий PowerShell, который может быть запущен пользователем из интрасети, или вы можете выполнить PSRemoting для самостоятельного запуска установки. PSRemoting позволяет вам вызвать команду (Invoke-Command или icm), а затем отправить ее на один, несколько или все компьютеры в домене.

Для обслуживания я бы использовал сценарии PowerShell, но тогда я не уверен, что вы имеете в виду под обслуживанием.

Использование PowerShell для развертывания объясняется тем, что это проще, если вы делали это раньше и у вас есть шаблон для сценариев. Вы можете просто использовать это вместо того, чтобы возиться через графический интерфейс для каждого пользователя / компьютера / роли / функции, которую вам нужно настроить.