Intune Paketierung einfach gemacht

81a89475fc134470aeb4a85ab5c3ed7e

Ich arbeite ja gerne mit Installation Wrappern für Paketierungen. Dabei ist es egal ob es sich um Microsoft System Center Configuration Manager (SCCM) bzw. Microsoft Endpoint Configuration Manager (MECM) oder das Microsoft Deploment Tollkit (MDT) handelt, auch für die Microsoft Intune Paketierung habe ich diese genutzt. Beispiele dafür finden Sie in den Artikeln Unbeaufsichtigte Installation von Software und Unbeaufsichtigte Installation von Software – Nachschlag.

Der Gedanke war damals, ich habe ein Install-Skript und ein Uninstall-Skript. Warum das nicht auch für Intune nutzen? Also hatte ich mir das INTUNEWIN Format für Windows Apps (Win32) angeschaut. Dies ist im Prinzip ein Container in dem die Installationsdateien verpackt werden. Dazu dient das Microsoft Win32 Content Prep Tool, das kostenfrei auf GitHub zur Verfügung steht. Mit wenigen Parametern wird hier die IntuneWIN Datei erzeugt.

Um mir das erstellen zu vereinfachen habe ich mir ein kleines Skript geschrieben, das meinen Source-Ordner durchgeht und die passenden IntuneWin-Dateien erstellt. Da das Schema immer gleich aufgebaut ist, war das nicht schwer.

Als nächstes wollte ich das Skript um einen automatischen Upload und andere nützliche Funktionen wie Gruppenanlage und Zuweisungen erweitern. Klingt das nach etwas nützlichem? Für mich schon. Also machte ich mich auf die Suche nach passenden PowerShell Modulen und Befehlen. Gefunden habe ich allerdings was anderes, da sagt man immer mit BING kann man nur Suchen, aber nicht finden…

IntuneScripts von Greg Nottage

Gestolpert bin ich über die IntueScripts von Greg Nottage, einem Microsoft Mitarbeiter. Der hat genau das geschrieben womit ich anfangen wollte, ein Framework für Intune Paketierung. Da es unter der MIT Lizenz verfügbar ist, hab ich mich an einen Fork gemacht und fange jetzt an nach und nach noch Funktionen und Anwendungsvorlagen hinzuzufügen.

Das schöne ist, Greg hat einen sehr schönen PowerShell Wrapper für die Installation geschrieben, der sich um einiges kümmert. Zum Beispiel auch das Thema Logs und Registry Einträgen die für die Erkennungsregeln genutzt werden können. Auch sind Beispiele für Hotfix Installation für Abhängigkeiten und die Erkennung von Virtuellen Maschinen, um diese anders zu behandeln, vorhanden.

Konfiguriert wird die Intune Paketierung über eine XML Datei die für die Erstellung der IntuneWin-Datei und zum erstellen der Anwendung in Microsoft Intune gebraucht wird. Ich benutze überwiegend den PowerShell Wrapper für alle Pakete. Dieses kann über die Parameter „-Install“ und „-Uninstall“ angesprochen werden. Hier mal ein Beispiel anhand des Adobe Acrobat Reader.

Beispiel für den Acrobat Reader

Zur Installation mit dem PowerShell Wrapper verwende ich die MSI Variante des Adobe Acrobat Reader for Enterprises. Ich verwende allerdings nicht die EXE für die Unbeaufsichtigte Installation sondern entnehme der EXE die MSI und die MSP (Update Datei für MSI). Wichtig ist dabei, das mit dem Acrobat Customization Wizard DC noch die Transform-Datei erstellt wird. Dies Konfiguriert die Installation.

Den Wrapper habe ich so gestaltet, das nur das letzte MSP verwendet wird. Dies ermittelt der Wrapper selber anhand des Dateinamen. So muss der Wrapper nicht immer angepasst werden. Auch prüfe ich vorher ob schon ein passender Adobe Acrobat Reader installiert ist, wenn ja, wird nur das Update installiert. Der Code dafür den ich in das Framework eingefügt habe ist recht übersichtlich:

$MSP = $(Get-ChildItem *.msp | Sort-Object -Property Name -Descending)[0].Name
$ARG = " /update " + $MSP + " /t AcroRead.mst /qn /norestart"
Write-Verbose "Install Base Installer"
IF (!(get-wmiobject Win32_Product | ? { $_.IdentifyingNumber -like "{AC76BA86-7AD7-FFFF-7B44-AC0F074E4100}"})) { Start-Process -NoNewWindow -FilePath "msiexec.exe" -ArgumentList " /i AcroRead.msi /t AcroRead.mst /qn /norestart" -Wait } ELSE {Write-Output "Acrobar already installed"}
Write-Verbose "Install Update"
Start-Process -NoNewWindow -FilePath "msiexec.exe" -ArgumentList $ARG -Wait

Die Deinstallation erfolgt über die MSI GUID. Hier ist der Code noch übersichtlicher:

Werbung
Start-Process -NoNewWindow -FilePath "msiexec.exe" -ArgumentList ' /x "{AC76BA86-7AD7-FFFF-7B44-AC0F074E4100}" /qn' -Wait

Jetzt muss noch die XML-Datei für die Konfiguration gefüllt werden. Die Vorlage kommt mit einer sehr guten Kommentierung, so das weitere Erklärungen eigentlich nicht notwendig sind.

<!-- <></> -->
 <CONFIG>
     <!-- Apart from username, leave Azure_Settings unchanged -->
     <!-- Completely remove the <Username> element and script will prompt -->
     <Azure_Settings>
         <Username>[email protected]</Username>
         <baseUrl>https://graph.microsoft.com/beta/deviceAppManagement/</baseUrl>
         <logRequestUris>$true</logRequestUris>
         <logHeaders>$false</logHeaders>
         <logContent>$true</logContent>
         <azureStorageUploadChunkSizeInMb>6l</azureStorageUploadChunkSizeInMb>
         <sleep>20</sleep>
     </Azure_Settings>
     <IntuneWin_Settings>
         <!-- Edit the AppType element - supported options are MSI, EXE or PS1 -->
         <AppType>PS1</AppType>
         <!-- Edit the installCmdLine element when using the EXE or MSI AppType -->
         <installCmdLine></installCmdLine>
         <!-- Edit the uninstallCmdLine element when using the EXE or MSI AppType -->
         <uninstallCmdLine></uninstallCmdLine>
         <!-- Edit the RuleType element - supported options are TAGFILE , FILE or REGTAG -->
         <!-- Ignored if AppType is MSI-->
         <RuleType>TAGFILE</RuleType>
         <!-- Edit the FilePath element when using the FILE RuleType -->
         <FilePath></FilePath>
         <!-- !!! Do NOT Edit the ReturnCodeType element !!! -->
         <ReturnCodeType>DEFAULT</ReturnCodeType>
         <!-- Edit the InstallExperience element - supported options are System or User -->
         <InstallExperience>System</InstallExperience>
         <!-- Edit the PackageName element to match the name of the .PS1 script that the IntuneWinAppUtil should reference -->
         <!-- For MSI or EXE AppType - this must be the name of the MSI or executable file in the ..\Source folder - without the .exe in the name -->
         <PackageName>Adobe Reader DC MUI 2100120155</PackageName>
         <!-- Edit the displayName element that will be shown for the imported package in the Intune console -->
         <displayName>Adobe Reader DC MUI 2100120155</displayName>
         <!-- Edit the Description element that will be shown for the imported package in the Intune console -->
         <Description>Adobe Reader DC MUI 2100120155</Description>
         <!-- Edit the Publisher name if required -->
         <Publisher>Adobe</Publisher>
         <!-- Edit the Category element that will be shown for the imported package in the Intune console -->
         <Category>Business</Category>
         <!-- Edit the LogoFile element to provide a logo shown in Company Portal -->
         <LogoFile>IFHLogo.png</LogoFile>
         <!-- Edit the AADGroupName element used for the required/available/uninstall group creation -->
         <AADGroupName>AAD-RG-SW-Acrobat_Reader_DC_MUI</AADGroupName>
     </IntuneWin_Settings>
 </CONFIG>

Weitere Beispiel Pakete

Dadurch das die PowerShell sehr flexible ist stehen viele Möglichkeiten offen, so das ich diesen nun bevorzuge, nicht nur für die Intune Paketierung. Auch meine MDT und SCCM Pakete werde ich nach und nach umstellen.

Einige Möglichkeiten die mit der PowerShell sehr einfach sind, ist zum Beispiel bei der Installation des OpenJDK, hier müssen noch ein paar Umgebungsvariablen gesetzt werden. Oder bei Greenshot, hier muss noch ein Shortcut angelegt werden. 

Weitere Paketvorlagen in meinem Repository (Ja, alle Originaldateien von Greg sind auch enthalten) sind:

  • Adobe Acrobat DC DE
  • Adobe Acrobat DC MUI
  • Greenshot
  • VC++ 2013
  • VC++ 2017
  • Microsoft 365 Apps 4 Enterprises im SAEC in Deutsch (Download über CDN)
  • Open JDK 16.0.1

Die Originalvorlagen (diese sind auch Teilweise in einem Worddokument dokumentiert) von Greg sind:

  • 7zip
  • Visual Studio Code
  • Invoke-OoBUpdates (OoB = Out of Band)

Weitere Funktionen des Frameworks für die Intune Paketierung

Neben dem Anlegen der benötigten Prüfregeln und dem Upload zu Intune erstellt das Framework auch direkt 3 Gruppen pro Anwendung und weißt diese der Software zu. Dabei handelt es sich um eine Gruppe zur erforderlichen Installation (Required), zur verfügbaren Installation (Available) und zur Deinstallation (Uninstall). Wobei die Uninstall-Gruppe auch direkt als Ausnahme für die beiden anderen Zuweisungen gesetzt wird.

Paketieren und Hochladen

Das Paketieren und hochladen des Paketes funktioniert einfach mit dem Befehl Invoke-Upload.ps1

.\Invoke-Upload.ps1 -Name "Dell Command Update 4.2.0" -userName [email protected]

Dann läuft das Script an und braucht ca. 3-5 Minuten, wobei ca. 2 Minuten verschiedene Wartezeiten für Azure sind.

Werbung
Ausschnitt von der PowerShell Ausführung des Befehl Invoke-Upload.ps1 für die Intune Paketierung
Ausschnitt von der PowerShell Ausführung des Befehl Invoke-Upload.ps1 für die Intune Paketierung

Wenn das Script dann fertig ist, ist die Anwendung in Azure hochgeladen, eingerichtet und die passenden Gruppen würden gemäß der XML Datei angelegt.

Screenshot Azure Portal: Eigenschaften Dell Command Update nach Invoke-Upload.ps1
Screenshot Azure Portal: Eigenschaften Dell Command Update nach Invoke-Upload.ps1

Für die Bulk Uploads gibt es noch eine JSON File die befüllt werden muss, danach können alle dort eingetragenen Pakete mit dem Befehl Invoke-BulkUpload.ps1 hochgeladen werden. Die Syntax ist wieder entsprechend einfach:

Werbung
Invoke-BulkUpload.ps1 -userName [email protected]

Was habe ich noch im Sinn mit der Lösung?

Eine der Ideen die ich noch habe ist, dass ganze um eine Versionsverwaltung zu erweitern. Das bedeutet das bei der Paketierung auch die Versionen automatisch berücksichtigt werden und dann vielleicht auch direkt in Azure hinterlegt werden können. So das neuere Versionen direkt auch ersetzt werden können. So könnte die Versionierung und das Patch Management bei der Intune Paketierung vereinfacht werden. Dafür könnte dann auch das neue Vorschau Feature Superseedance genutzt werden.

Eine andere Idee ist noch ein Globale Konfigurationsdatei anzulegen und auch AD Gruppen statt nur AAD Gruppen zu unterstützen. So das eine einfachere Integration in SCCM möglich wird. Wenn da die Erkennungsregeln dann passen würden, könnte das Migrationen vereinfachen.

Werbung

Habt Ihr noch Ideen / Wünsche für die Intune Paketierung? Hinterlasst mir einen Kommentar.

Das Repository findet ihr hier bei GitHub.

Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

New articles in english

Werbung

Themen

Active Directory Administrative Vorlagen Anleitung AppV5 Autopilot Azure Azure AD ConfigMgr Deployment GPO Gruppenrichtlinien Guide How-To Linux Microsoft Microsoft Intune Office Office365 PowerShell Public Preview SCCM2012R2 SCSM2012R2 ServiceMgr Sicherheit TechNet Windows Windows 10 Windows10 Windows Server 2012 Windows Server 2012R2

Hinweise zum Affiliate-Marketing

Auf diesen Seiten werden auch Affiliate Marketing Links angezeigt. Diese sind meistens an dem kleinen „€“ oder einem „*“ dahinter zu erkennen. Der Betreiber dieser Seite erhält beim Kauf über diesen Link eine Provision, ohne das es den Verkaufspreis beeinflusst. Diese Einnahmen tragen zur Finanzierung der Seite bei.