App deployment is something just about every Intune admin must be comfortable with. Recently, most apps have become simpler to package and deploy. However, occasionally you’ll still have proprietary, legacy, or just poorly written apps that don’t contain silent installers or do things out of the ordinary. This was the case for an app I had to deploy at a client, and it was a new issue I hadn’t seen before.
This particular application was tiny (less than 1MB). It was simply a program that provided a UI that connected to a URL to interact with the data. It was so simple that it didn’t even require silent install switches because it did that on its own. All you needed was the installer and a config file located in the same directory, which was referenced during the installation to pull the required URL. Without the config file, user interaction to enter the URL is needed during install, which we don’t want.
When dealing with a new application deployment, it’s always best to test the install so you can verify your install syntax and detection rules/scripts. In this case, the application only had the option to install in the user context under the user’s profile. If you don’t know the difference between installing in the system and user context, see this post for more details. After doing a couple of quick tests, all was working as expected with the install. However, when I tested deploying the app through Intune, I received this error:
Before going further, let’s take a quick look at how a Win32 app is deployed to a device from the device’s perspective.
When the IME determines that a device or user is targeted by a Win32 app, the detection method is evaluated against the workstation. If the app is detected, nothing happens, and it reports back to Intune that the app is installed. If it’s not detected, it will download an encrypted payload of the Win32 app (the .intunewin file) as a .bin to the C:\Program Files (x86)\Microsoft Intune Management Extension\Content\Incoming directory. We can see that below for my app:
After the payload is verified, its then decrypted and extracted to the c:\windows\IMECache\<app id> directory. The child folder in the IMECache is named after the ID of the application and will contain the content you originally targeted when packaging your .intunewin file.
From here, the app gets executed based on your installation syntax. Which, in this case, was simply to call the .EXE since the default behavior was to install with no user interaction if the installer could see the .cfg file.
Now that we have a quick understanding of how the Win32 app is processed and installed, let’s get back to the error message. This was strange, because if we looked at the permissions of the app folder in the IMECache, we can see that we have read and execute permissions to the files. This is typical when an app is installed in the user context, because the user executing the install needs to have read and execute permissions to the location of the install files. If it’s a system context installer, only system and administrators would have access.
After doing some additional investigating and testing, the URL for the application is set as a registry value under the HKCU\Software hive. However, that doesn’t help our ability to install the application silently. If the config file isn’t in the working directory where the installer is located, then it won’t see it, and it requires user interaction. So, we either needed the config file, or to pre-populate the registry values. After doing another test install, I found that the config file was deleted from the directory after the reg values were written, but before the installer completed. Therefore, we have an explanation for the error since, as shown in the screenshot above, we don’t have modify rights to delete files. The options at this point were to set the necessary registry values as part of the install script or to work around deleting the config file.
The IME will delete the data from the IMECache folder (in most cases), but this brought up an interesting and rare situation where install files may need to be modified during the install process. If this is in the user context, they’d be prevented unless some changes were forced to the IMECache permissions, which we don’t want to do. So I crafted a simple script that works around this issue:
Copy-Item -Path ".\configurationfile.cfg" -Destination "$env:TEMP" -Force
Start-Process ".\Application.exe" -WorkingDirectory "$env:TEMP" -WindowStyle Hidden -WaitThe script will copy the file that needs to be modified (deleted in this case) to a directory where the user has modify permissions (the $env:TEMP variable maps to the user’s C:\Users\<user>\AppData\Local\Temp directory). Then, it sets the working directory for the process to the $env:TEMP directory, so the installer can see the config file and also modify it. We could copy all data over the $env:TEMP and then launch the installer from there, but it wasn’t necessary in this case.
Save that simple PowerShell script after adjusting for your app, and then use the below command as your install command, and you’ll be all set:
powershell.exe -executionpolicy bypass -windowstyle hidden .\install.ps1
This example highlights why testing is important for every Intune deployment. Even small, simple apps can sometimes behave unexpectedly when deployed with Intune. Using workarounds like we did in this post ensures reliability without weakening IMECache directory permissions. Always test and validate before deploying your apps in production.