Почему не устанавливается .msi пакет (установка программ) через групповую политику?

Домен на win server 2012
В оснастке «пользователи и компьютеры» создал подразделение test, добавил в него два пк: win7 и win10
Создал gpo для этого подразделения, в фильтрах безопасности — прошедшие проверку, в делегировании ничего не меняю.
В конфигурации компьютера\Политики\Конфигурация программ, в «Установка программ» создаю пакет для установки foxitreader, выбираю .msi файл, дальше «назначенный» и указываю путь к .msi (путь сетевой).
На клиенте выполняю: gpupdate /force, в ходе применения политики есть текст, чтобы политика software installation применилась нужно перезагрузить пк, но после перезагрузки программа не устанавливается
gpresult /r /scope:computer — пишет, что политика применена

+ для теста политики изменил ещё этот параметр: Конфигурация компьютера/Административные шаблоны/система/восстановление системы/отключить конфигурацию — после перезагрузки или выполнении gpupdate /force этот параметр (отключить конфигурацию) успешно обрабатывается.

Что я делаю не так? Почему .msi пакет не устанавливается, а параметр «отключить конфигурацию» в той же политике успешно применяется? С фильтрами безопасности и делегированием получается всё в порядке.
Права на папку где лежит .msi у пользователей есть (чтение/запись). Пробовал включать «всегда ждать сеть при запуске и входе в систему»

• Вопрос задан более трёх лет назад
• 7095 просмотров

Комментировать
Решения вопроса 1
Максим @Torres90 Автор вопроса

Нужно включать эти параметры:
Конфигурация компьютера \ Политики \ Административные шаблоны \ Система \ Вход в систему \ Всегда ждать сеть при запуске и входе в систему

Конфигурация компьютера \ Политики \ Административные шаблоны \ Система \ Групповая политика \ Указать время ожидания при обработке политики загрузки = (30 сек)

How to Deploy an EXE file using Group Policy

In this tutorial, you will learn how to deploy an exe install file using group policy.

If you need to install an MSI file then check out my previous tutorial How to Deploy Software using GPO.

Group policy software deployment does not support exe files. You will need to use a script and group policy to deploy software with an exe. I’ll show you these steps below.

I do not recommend this method as it will require the users to have administrator rights and the ability to run scripts. I strongly recommend against users having either of those rights. If you must deploy an exe with group policy then try to grant temporary rights, when the deployment is done remove the rights and ability to run scripts. The preferred method would be to use a 3rd party program that can securely install software on your remote computers. Those programs can be expensive so I understand the desire to use free options. I’ve been there before and at times you have no choice due to a lack of funding or management constraints.

Steps for deploying an EXE:

• Step 1: Configure a PowerShell Script
• Step 2: Configure UNC Share
• Step 3: Configure GPO Settings
• Step 4: Reboot the Computer

Step 1: Configure a PowerShell Script

First, you need to configure a script. The script needs to check if the program is already installed if not then install it, if already installed then do nothing. I’m using PowerShell but you could also use a batch file.

Here is the script I’m using:

#Script to install exe via GPO $folder = ‘C:\Program Files\7-Zip’ if (-not (Test-Path -Path $Folder)) < start-process -FilePath "\\srvwef\software\7z2107-x64.exe" -ArgumentList '/S' >else

Let me explain what each line does.

$folder = 'C:\Program Files\7-Zip'

The above line sets $Folder to the directory to check if it already exists. This will be used in the next line to determine if the program is already installed. Change the path to whatever program you want to check for.

if (-not (Test-Path -Path $Folder))

This line is testing if the path of $Folder does not exist. If it doesn’t exist then it will start the install process. If it does exist it will move to the else line and do nothing.

start-process -FilePath "\\srvwef\software\7z2107-x64.exe" -ArgumentList '/S'

This line starts the installation if the $Folder does not exist. I’m using a UNC path and the /S argument so it is a silent install. Users will need access to the location of the installer.

else <>

If the path of $Folder exists the script will move to this line and do nothing.

It’s a very basic script. You can modify it and add logging or other options. That is the nice thing about PowerShell you can customize it to your needs.

Save the script as this will be used in the next step. I saved my script as install.ps1

Step 2: Configure UNC Share

You need to have a secured distribution point for your EXE install file. It needs to be accessable for remote computers and users. I walked through on how to create a secure network share in the pervious tutorial for deploying an MSI file. Check it out if you need step by step instructions.

Step 3: Configure GPO Settings

Now let’s configure the group policy.

Create and link a new GPO to the OU containing your users. I’m going to add a new GPO to my Accounting OU.

Give the GPO a name. Then edit the GPO

Navigate to User Configuration > Windows Settings > Scripts (Logon/Logoff)

On the right side click on “Logon”.

Then click on PowerShell Scripts or Scripts if using a batch file.

Click on the Add button, then click browse.

With the browser window open you want to copy and past the .ps1 file into this window. Do not modify the path, this is the path of the GPO, and the script needs to be copied into this path. Your path will look different than mine.

Click ok and ok again. You should be back at the main screen. This completes the GPO configuration.

Step 4: Reboot Computer

Now reboot, login and the software should install.

If the software is a silent install the user will not see anything when they login, it will install in the background with no user interaction. Unless you add some logging into the script you will not know if it installs are not. That is one drawback to using group policy to install the software. If this is a method you will use long term then I would add some logging to the script to help track for failed and successful installs.

Recommended: Active Directory Permissions Reporting Tool

Get instant visibility into user and group permissions in your Active Directory domain.

With Permissions Analyzer you can quickly view assigned and inherited permissions for any user or group.

Don’t let permission problems slow you down or put your data at risk. Get Permissions Analyzer for Active Directory today and take control of your permission management.

10 thoughts on “How to Deploy an EXE file using Group Policy”

Muhammad Hassan

What is the best way to deploy software? Computer oriented or user oriented and if we run the script on both (computer and user) which one will get priority? Can I see a graphical list with the status of all computers or users against this GPO? Reply

Robert Allen

With group policy I prefer deploying to computer. 1. It will install for all users. 2. It will install automatically. Deploying to users will not install automatically. Reply

What if my users dont have software install permission? I understand that regular software deployment via GPO (using .msi files) don’t require admin rights for the install, but in this case, using an .exe file running as a script, how can I “bypass” the admin password input? Thanks Reply

Robert Allen

I don’t think this can be done with GPO. I would look at 3rd party options that allow you to specify an account for installing the software. Reply

It is not easier to convert exe to msi, you can use different wrappers from exetomsi to Silent Install.
Google is very simple.
Top 3 search queries examples:
https://www.exetomsi.com/
https://www.exemsi.com/
https://apreltech.com/Blog/Exe_to_msi_wrapper And also a very nice gpo tool without PowerShell:
https://www.silentinstall.org/exe-to-gpo/
I hope this helped you) Reply

Have you tried them?
Is there any preference of choose one or another?
What are limitations of there free versions? Reply

Silas Nguyen
Good threads! Reply
Robert Allen
Thanks Silas Reply
Rich Kolbasowski

I need to deploy the Evergreen WebView2 Runtime to client machines and need to check if it is installed already. Your PS script looks like it would work but I cannot use the folder option to check for the software existence. Microsoft recommends checking two registry keys with populated fields for existence or use the GetAvailableCoreWebView2BrowserVersionString API and query the result for the nullprt response in the VersionInfo field. I am a total nubie with any scripting so do you have any examples that would meet this criteria. Any assistance would be much appreciated! Reply

Robert Allen

You can modify the script to check for a registry path. Use test-path to check a path, here is an example. test-path ‘HKLM:\software\7-Zip’ It will return true or false. Reply

Создание msi-пакетов и установка любого ПО средствами групповых политик Windows

Доброго времени суток, Хабр! Хочу представить интересный, по моему мнению, способ создания msi-инсталляторов для любого программного обеспечения и, как следствие, развертывание его средствами GPO. Подчеркну, что описанный метод не подразумевает создание «слепков» системы, а использует нативные инсталляторы софта, при чем для создания msi применяются только бесплатные для коммерческого использования продукты.

Введение, пара ссылок и дисклеймер

Каждый нормальный инсталлятор ПО имеет возможность автоматической установки с определенными или заложенными по умолчанию параметрами. Суть моего метода проста и заключается в том, чтобы запаковать нативный инсталлятор в «контейнер» msi и запустить его с необходимыми параметрами командной строки. В сети куча информации по автоматической установке того или иного приложения, и я не буду заострять на этом внимание. Наша цель, повторюсь, — установка ПО средствами групповых политик. Кстати, некоторые из вас могут возразить, что установку можно производить через ZAW, но, к сожалению, данный метод применим только для установки с правами текущего пользователя и не может применяться для централизованной автоматической установки приложений.

Интересный цикл статей по установке ПО через ГП. Для новичков рекомендую прочитать все, чтобы потом не спрашивать, чем отличается тип установки «назначенный» от «публичный».

Необходимый софт. Exe to MSI Converter freeware и всем известная orca Первый нужен для того, чтобы создать msi из exe, а вторая — чтобы получившийся msi-ник смог установиться через групповые политики.

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

Создание и подготовка пакета

1. Запускаем exe to msi и указываем в нем путь к exe-установщику firefox. По ранее найденной в сети информации становится понятно, что по-тихому установить огнелиса можно с параметрами -ms -ira. Их-то и указываем во втором поле exe to msi и жмем «Build MSI».
2. Казалось бы все, msi-пакет готов. Действительно, запустив получившийся результат мы получим установленный в системе firefox и в статье можно было бы ставить точку. К сожалению, не все так просто. Текущий пакет установки не пригоден для развертывания через GPO и при загрузке компьютера вы будете получать совершенно ничего не объясняющие ошибки в логах «произошла неисправимая ошибка. » А все дело в том, что разработчики exe to msi тоже хотят есть и их бесплатный продукт генерирует msi «не по правилам».
3. Ну что ж, берем орку и открываем в ней наш эмсиайник.
4. Первым делом находим в левом списке таблицу Property и обращаем внимания на два поля — ProductCode и UpgradeCode. Эти два поля должны быть уникальны для каждого продукта, а наш exe to msi генерит всегда одинаковые. Ну что ж, не беда, жмем в верхнем меню View -> Summary Information, находим поле PackageCode и жмем New GUID. Получившийся результат копируем в буфер обмена и вставляем в ProductCode. Повторяем для UpgradeCode и наконец для самого PackageCode. Тут же в Summary Information правим поле Title на Mozilla Firefox, остальное по желанию. Это, по сути, ни на что не влияет.
5. Опять же в таблице Property меням ProductName на Mozilla Firefox (я до кучи меняю еще ARPCONTACT и Manufacturer). Можно так же поставить правильное значение для ProductVersion.
6. Вроде бы GUID и прочие «IDы» поменяли, но как показывает практика, этого недостаточно. Жмите в orca Tools –> Validate, снимите птицу Show INFO Messages и нажимайте Go.
7. Как видите, вылезла куча ошибок на наличие/отсутствие некоторых таблиц и значений. Я не стал заморачиваться и просто взял первый попавшийся (7zip x64 9.20) небольшой msi и скопировал оттуда 4 недостающие таблицы (через Export-Import, естественно): _Validation, AdminExecuteSequence, AdminUISequence и AdvtExecuteSequence. На самом деле, я уверен, что можно создать «правильный» msi-инсталлятор, без лишнего мусора, но не забывайте, наша цель всего лишь запустить родной setup приложения в тихую.
8. После добавления таблиц проходим снова Tools –> Validate (к слову, первый раз проверку можно вообще не делать и сразу импортировать таблицы). Если вы тоже взяли за основу msi от 7zip, то результатом будет шесть эрроров, которые необходимо устранить. Жмите Close, удаляйте лишние поля, отмеченные красным.
9. В конце можно еще раз проверить валидацию и убедиться что остались лишь ничем не мешающие варнинги. Сохраняем msi.
10. Вот в принципе и все, осталось добавить msi в ГП и назначить необходимые свойства.

Нюансы

1. При установке описанным выше методом у вас появятся как бы две копии софта. Первая — собственно нужное приложение, а вторая — исходный msi-ник, ведь мы же его как бы поставили. В принципе, это ни на что не влияет, кроме как на отображение в «Установка и удаление программ», и то, только в Windows XP (если вы ничего не меняли, кроме указанного мной). Минусом может быть появление лишних программ при автоматической инвентаризации софта, если вы ее используете.
2. Автоматически удалить приложение теми же средствами развертывания не получится. Точнее получится, но удалится только и так не нужный msi-контейнер. Ну можно повозиться со свойствами msi при его создании, чтобы оно захватывало с собой установленное ранее приложение, так же втихую. Я такой задачи не ставил.
3. При установке обновлений ПО нужно указывать в свойствах ГП приложения, чтобы оно заменяло предыдущее, т.е обязательно предварительно удаляло старое. Это гарантирует, что у вас не будут плодиться те самые никому не сдавшиеся левые дубли приложений в «установке и удалении программ».
4. Чтобы установить приложение, имеющее дистрибутив из нескольких файлов, вам придется сначала упаковать его в exe, который при запуске сам распакуется и даст команду для тихой установки. Рекомендую создавать sfx-архивы средствами того же 7-zip.
5. Ничего не мешает ставить ПО через скрипты автозагрузки. Более того, такой метод более гибкий, и я давно его использую через свои скрипты. Вот только использование родных средств ГП получается намного быстрее, т. к. простое создание msi из exe занимает пару минут.
6. Windows 7 почему-то не пишет «Установка управляемого приложения. », а просто говорит «пожалуйста, подождите». При первом развертывании всей кучи софта разом или при установке тяжелого приложения это может сподвигнуть юзера на звонок админу или нажатие кнопки резет.

• групповые политики
• создание msi-пакета

При подготовке материала использовались источники:
https://qna.habr.com/q/723285

How to Deploy an EXE file using Group Policy

https://habr.com/ru/articles/141719/