PowerShell App Deployment Toolkit and Intune Win32 Apps

Hi Folks!

Leading on from this post about getting started with PSADT, and as promised, I’m writing up my experience with it and creating Win32 Intune apps.

So firstly, I’m assuming by now that you read and absorbed the first write up I did, you should have noticed that a couple of things I did in that post can actually be done differently and be eager and armed with understanding the format and have a good idea about what to do. Combine that with great ‘google-fu’ and you’re ready to continue your decent app packaging journey.

Using this with ConfigMgr applications is quite simple because once you’ve prepared your application you use the root folder as the source content for the application and the rest is pretty straight forward (holler at me if you want that blogging too). Putting that into Intune however is slightly different. There are many blog posts about Intune Content Prep Tool however in a nut-shell, this tool will take your content (source) files for your application, and output a single .intunewin file which is the file format that Intune understands. So lets go ahead and download the tool from here and extract it to a local folder.

The following files should be in the extracted folder

What we’re going to do is launch a cmd prompt as admin and browse to the folder that contains the files. This way if we have more that one app to create the executable wont exit when we’ve finished. When you launch the IntuneWinAppUtil.exe you will be asked three questions.

“Who would Use the Intune app must answer me these questions three”
…Monty Python (true story)

Pretty straight forward stuff, specify the sources folder (in our case this will be one of the subfolders we created by copying the TOOLKIT MASTER folder (see previous post), specify the setup file (note this is not the full install command with switches) in our case we’ll be specifying “deploy-application.ps1” which is the script that we’ll call when we want to install and uninstall the application in questions and finally the output folder for the .intunewin file we can import to Intune. The output file will take the format of [SetupFileName].intunewin so we’ll get deploy-application.intunewin. Remember if you’re making lots of Intune content files and they’re all made from PSADT, the output file will be the same so use different output folders.

Next, we’ll move over to Intune now and start to import the application. Log into https://endpoint.microsoft.com/ and navigate to the apps blade, select to add a new app and chose the type of “Win32”.

Then continue to populate the details of the app. In my example I’m using 7Zip. Here is the App Information section with the parts I’ve edited numbered

Next is the Program section

You can see here is where we call the two PowerShell commands (coincidentally these will be the same commands used in ConfigMgr)
You can set some Requirements of you own if you have them, I normally select Windows 10 1607 as the minimum OS and select the architecture based upon what I’m deploying. In the case of 7Zip I have downloaded just the x64 version of the application and then added an Execute-MSI statement in the PSADT code to install it. So my requirements might be this…

And finally we have the Detection Methods. Normally I like to use the the DisplayVersion of the application that gets stored in the registry hives after installation but in some case you can just use the MSI Product Code. Generally (but not all the time remember!) you can use one of the following two hives to harvest information about the installed application.

1. HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall
2. HKLM:\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall.

I wrote a quick PowerShell script to go get the child object under these keys for you and bring back the PSChildName, DisplayName, DisplayVersion and (for use later) the Uninstall String that’s stored in the registry so that you can install the app on your test box using the PSADT script you created for testing. I use these lines of code so much. After its installed you can then harvest what you need from the registry for the detection method. Here is the code I use.

Code

Clear-Host
$Hive = Get-ChildItem -Path HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall
$Hive2 = Get-ChildItem -Path HKLM:\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall
Write-Host -ForegroundColor Green "x64 Registry Hive - HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall "
$Hive | Get-ItemProperty | Select-Object -Property PSChildName, DisplayName, DisplayVersion, UninstallString | Sort-Object DisplayName | Format-Table -AutoSize -Wrap
Write-Host -ForegroundColor Cyan "x86 Registry Hive - HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall"
$Hive2 | Get-ItemProperty | Select-Object -Property PSChildName, DisplayName, DisplayVersion, UninstallString | Sort-Object DisplayName | Format-Table -AutoSize -Wrap

If you run this it’ll output to the PowerShell Console the keys (you can copy these straight into Intune detection clauses for Registry. And then you can select your column to use.
Here is an example:

From this I can take a number of things:
Firstly, the registry hive key at the top in green text (cyan for the other hive) I can copy this out as first part of the Key path on an Intune Detection Method. Then I can append the PSChildName item for the individual key, so if I wanted my clause to be whether or not the registry key simply exists, I can use the RegistryHivePath+PSChildName (in red below).

If I wanted to use the Version number, for example I wanted to say greater than or equal to I could use the RegistryHivePath+PSChildName as the Key Path, then use the DisplayVersion as the Value Name and use the correct operator, like so….

Which gives me…

Ok so now you have an idea on how to get your PSADT apps into Intune as Win32 Applications using the Intune Content Prep Tool, take a moment to go get a coffee as now we’ll move to testing them, once they’re finished uploading and syncing.

First, we’ll need to set up an AAD group to deploy the applications to and to which we can assign our user who should have an Intune license. Deploying the applications as available is the most effective way to test the applications before we push them out as a required install, using something like autopilot. So lets go and set up a new group ready for deployment.

Next manually add the user you’re deploying the application to, to the group. And finally edit the assignments of the application so that its assigned as Available to the group you want to test with.

Remember – You (mostly want to) deploy the app to the user because the user holds the Intune license. Once its uploaded and synced you should see that in your company portal on the device. Open Company portal on the test device and log in with the username/password for the test user in the group we created above. Here we see our 7Zip Win32 App (Yes I know there’s a MSfB app for 7Zip, stay with me here… its the process I want you to learn). We then highlight and select to install Happy days!
We can see here that it is indeed installed.

Now, if there are issues (and this is the good bit for me!) don’t forget that PSADT apps log their own install and uninstall logs into C:\Windows\Logs\Software however if you edit this to match the IntuneManagementExtension.log files location (C:\ProgramData\Microsoft\IntuneManagementExtension\Logs), you will have lovely logs to use for troubleshooting AND you can collect them remotely from the Intune portal!!

Once configured, you can use the “Collect Diagnostics” button and this will collect the logs remotely, without interrupting the end users. Wonderful!

THAT, I feel, is awesome and will help greatly with troubleshooting your Win32 Apps, should there be a problem
I hope this helps you.
Thanks for reading
Jonathan.