Microsoft Intune

Sample app secret decoder ring

I’ve published a bunch of sample Win32 apps for Intune and Autopilot, most of which are just PowerShell scripts bundled into an .intunewin file. For the first few, I posted the step-by-step instructions for setting up the app, but after doing a few of these that got tedious because they follow the same pattern. Rather than doing more posts for each one, let me just summarize here.

Getting the files

The files for each app are stored in GitHub, so you can either clone the repo using GitHub Desktop, Git, or Visual Studio Code. If you have no idea what I’m talking about, the other option is to download a zip file with the contents:

If you download the zip file, extract it somewhere.

Updating the .intunewin file

Each of the apps has a prebuilt .intunewin file that you could update and use for the Win32 app. But if you need to make any adjustments to the script and/or configuration files used by the script, you can first edit those files in the subdirectory (e.g. the “UpdateOS” folder in the above picture), and then from a command prompt navigate to the parent folder and execute the “makeapp.cmd” to generate a new .intunewin file with the changes you made.

Creating the app in Intune

This is the tedious part: You need to create a new Win32 app in Intune, and then populate the install and uninstall commands, as well as the detection method (and perhaps a requirements script, but that’s a subject for a later post). Why Microsoft has never provided a mechanism to embed those into the .intunewin file itself after all these years is a mystery. There’s no guarantee that the person creating the app (e.g. me), who knows the app details, has an easy way to provide those to the Intune admin (you) so that they can type them into the Intune portal. If you agree, feel free to upvote this feedback item:

https://feedbackportal.microsoft.com/feedback/idea/27c0602c-75fa-ee11-a73d-6045bd7e894e

Since that’s not possible, you need to put in those details yourself. First create a new app of type “Windows app (Win32)”, then select the .intunewin app you obtained or updated previously. Change the name, description, and publisher (you can’t put those details in the .intunewin file either) as appropriate, since the defaults won’t work very well:

For the installation command, it’s typically going to run PowerShell.exe. For the uninstall, it will delete the .tag file created by the script that says it was “installed.”

For the requirements, you can specify whatever you would like. For detection rules you need to look for the file that the script creates, the same one that is in the uninstall command:

You can then assign the app to any appropriate group.

App-specific details

Here are the “fill-in-the blank” details for the apps that I’ve published to GitHub. They follow pretty much the same pattern, with a couple of slight variations.

AppInstallationUninstallDetection (file exists)
AutopilotBrandingpowershell.exe -ExecutionPolicy Bypass -NoProfile -File .\AutopilotBranding.ps1cmd.exe /c del %ProgramData%\Microsoft\AutopilotBranding\AutopilotBranding.ps1.tag%ProgramData%\Microsoft\AutopilotBranding\AutopilotBranding.ps1.tag
OOBEEntertainpowershell.exe -ExecutionPolicy Bypass -NoProfile -File .\Launch.ps1cmd.exe /c del %ProgramData%\OOBEEntertain\Launch.ps1.tag%ProgramData%\OOBEEntertain\Launch.ps1.tag
OOBEPromptpowershell.exe -ExecutionPolicy Bypass -NoProfile -File .\Launch.ps1cmd.exe /c del %ProgramData%\OOBEPrompt\Launch.ps1.tag%ProgramData%\OOBEPrompt\Launch.ps1.tag
RenameComputerpowershell.exe -ExecutionPolicy Bypass -NoProfile -File .\RenameComputer.ps1cmd.exe /c del %ProgramData%\Microsoft\RenameComputer\RenameComputer.ps1.tag%ProgramData%\Microsoft\RenameComputer\RenameComputer.ps1.tag
UpdateOSpowershell.exe -ExecutionPolicy Bypass -NoProfile -File .\UpdateOS.ps1cmd.exe /c del %ProgramData%\Microsoft\UpdateOS\UpdateOS.ps1.tag%ProgramData%\Microsoft\UpdateOS\UpdateOS.ps1.tag

The variations:

  • Scripts created while I worked at Microsoft create files in %ProgramData%\Microsoft, while those after leave out the Microsoft folder.
  • Scripts where one script launches another (e.g. to run it in session 1 instead of session 0) have a command line that specifies the first script (Launch.ps1) and not the second (the one that does most of the work).

Leave a comment