Mit dem win32 App Paketen bietet der Endpoint Manager / Intune eine hervorragende Möglichkeit komplexere Applikationen, Abläufe oder Einstellungen an die Geräte zu verteilen.
Eine Win32 App kann auf allen möglichen Kombinationen von Scripts, Daten und Installations-Dateien bestehen. Um dabei das Grundgerüst zu vereinheitlichen und ein Log bieten zu können, bestehen alle meine Pakete aus mindestens zwei Dateien, welche ich als Template nutze.
Table of Contents
Template
Weil ich ein grosser Fan von PowerShell bin und sich damit beinahe alles umsetzen lässt, habe ich für die Installations- sowie Deinstallations-Routine ein PowerShell Script.
Auch für Komplexe Erkennungsregeln nutze ich ein PowerShell Script.
Hier die Dateien, die ich in meinem template nutze:
| install.ps1 | Verpackt die Installationsroutine in ein PowerShell Transkript (Log) und schreibt dieses auf das Gerät lokal. |
| uninstall.ps1 | Verpackt die Deinstallationsroutine in ein PowerShell Transkript (Log) und schreibt dieses auf das Gerät lokal. |
| check.ps1 | Dient als Erkennungsregel für das Paket. Optional, Erkennungsregeln können auch manuell im MEM erstellt werden. |
Alternativ bieten auch das PSAppDeployToolkit eine hervorragende Möglichkeit Apps zu erstellen.
Inhalt / Erklärung install.ps1
Hier fügst du diene Installationsroutine ein.
Diese kann ganz einfach sein und einfach eine EXE / MSI mit einem Silent-Parameter aufrufen, oder aus vielen verschiedenen Befehlen und Abläufen bestehen.
Aus der Vorlage musst du die erste Zeile, sowie die Zeile 8 austauschen / ergänzen.
Wenn du das Log an einem anderen Ort abgespeichert haben möchtest, kannst du einfach den Pfad innerhalb der Variabel $Path_local anpassen.
Inhalt / Erklärung uninstall.ps1
Das Script zur deinstallation ist vom Aufbau her identisch mit dem der Instillation. Auch hier passt du den Paket-Namen und die Routine an.
Inhalt / Erklärung check.ps1
Das Intune / der Microsoft Endpoint Manager weiss, ob ein Paket erfolgreich installiert wurde, müssen wir in jedem Win32 App eine Erkennungsregel hinterlegen. Diese kann entweder manuell erstellt werden (Online im UI) oder per PowerShell Script.
Bei den Manuellen Erkennungsregeln hats du die Auswahl zwischen MSI-Codes, Dateien und Registry-Einträgen. Diese Optionen sind bei Microsoft sehr gut dokumentiert und beschrieben: Detection rules, add and assign Win32 apps to Microsoft Intune | Microsoft Learn
Möchtest du eine Komplexe Regel erstellen, habe ich dir im Paket bereits viele Vorschläge zur Verfügung gestellt. Zusätzlich habe ich dazu einen separaten Beitrag geschrieben: Custom Detection Script für Intune (win32 Apps)
App-Paket (intunewin) erstellen und hochladen
Für den Upload einer Win32 App zu Intune müssen wir das erstelle Paket in eine Intunewin-Datei paken.
Das machst du so: Win32 App / .intunewin erstellen
Ist das Intunewin-File erstellt, kann es mit folgender Konfiguration veröffentlicht werden:
- Apps > Windows + Add
- Installation- und Deinstallations-Befehl hinterlegen, System/User je nach Anforderung
| Installation | %SystemRoot%\sysnative\WindowsPowerShell\v1.0\powershell.exe -executionpolicy bypass -command .\install.ps1 |
| Deinstallation | %SystemRoot%\sysnative\WindowsPowerShell\v1.0\powershell.exe -executionpolicy bypass -command .\uninstall.ps1 |
- Requirements je nach Applikation
- Erkennungsregel, Custom: check.ps1 oder manuell
- Abhängigkeit, falls nötig deklarieren
- Zuweisen und fertig.
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 :).