With the win32 app packages, the Endpoint Manager / Intune offers an excellent opportunity to distribute more complex applications, processes or settings to the devices.
A Win32 app can consist of any combination of scripts, data and installation files. In order to unify the basic structure and to be able to offer a log, all my packages consist of at least two files, which I use as a template.
Table of Contents
template
Because I'm a big fan of PowerShell and almost everything can be implemented with it, I have a PowerShell script for the installation and uninstallation routine.
I also use a PowerShell script for complex recognition rules.
Here are the files I use in my template:
| install.ps1 | Packs the installation routine in a PowerShell transcript (log) and writes it locally on the device. |
| uninstall.ps1 | Wraps the uninstallation routine in a PowerShell transcript (log) and writes it locally on the device. |
| check.ps1 | Serves as a detection rule for the package. Optionally, detection rules can also be created manually in the MEM. |
Alternatively offer that PSAppDeployToolkit an excellent way to create apps.
Contents / Explanation install.ps1
Here you insert your installation routine.
This can be as simple as calling an EXE / MSI with a silent parameter, or it can consist of many different commands and processes.
From the template you have to exchange / supplement the first line and line 8.
If you want the log to be saved to a different location, you can simply change the path within the variable $Path_local to adjust.
Contents / Explanation uninstall.ps1
The structure of the deinstallation script is identical to that of the installation. Here, too, you adjust the package name and the routine.
Content / Explanation check.ps1
The Intune / Microsoft Endpoint Manager knows whether a package has been successfully installed, we have to store a detection rule in each Win32 app. This can either be created manually (online in the UI) or using a PowerShell script.
With the manual detection rules you have the choice between MSI codes, files and registry entries. These options are very well documented and described at Microsoft: Detection rules, add and assign Win32 apps to Microsoft Intune | Microsoft Learn
If you want to create a complex rule, I have already provided you with many suggestions in the package. I also wrote a separate post about it: Custom Detection Script for Intune (win32 apps)
Create and upload an app package (intunewin).
To upload a Win32 app to Intune, we need to pack the created package into an Intunewin file.
You do it like this: Create Win32 App / .intunewin
Once the Intunewin file has been created, it can be published with the following configuration:
- Apps > Windows + Add
- Store installation and deinstallation commands, system / user depending on requirements
| installation | %SystemRoot%\sysnative\WindowsPowerShell\v1.0\powershell.exe -executionpolicy bypass -command .\install.ps1 |
| Uninstallation | %SystemRoot%\sysnative\WindowsPowerShell\v1.0\powershell.exe -executionpolicy bypass -command .\uninstall.ps1 |
- Requirements depending on the application
- Detection rule, cusrom: check.ps1 or manual
- Declare dependency if necessary
- Assign and finished.
EN
Pingback: Pre-installed PowerShell modules in Windows Sandbox | scloud
Pingback: Install fonts with Intune | scloud
In my opinion it is better to go for less scripting and avoid them whenever you have the possibility. There is no gain except that you have some additional lines of code that could cause trouble, require documentation, make intransparent what your package does and requires you to sign everything or lower the execution policy.
But I can totally understand that it is sometimes needed to have them to make stuff the installer can not provide :).
Pingback: Custom Detection Script for Intune (win32 Apps) | scloud
Pingback: Create Win32 App / .intunewin | scloud