Microsoft's documentation on the format and deployment of Windows apps (Win32) within InTune is pretty comprehensive and is well supported by a number of technical blogs which take you through the packaging and the InTune Management Extension (IME) workflow
What is less well explained is what happens next.
Your V1 app has been marked as Required and deployed successfully but now the vendor has released V2. How do you get V2 onto the desktop ?
The new V2 app clearly requires repackaging to create an updated .intunewin payload and logic would suggest that if the V2 package replaces the old V1 version in the original InTune app definition the change will roll out to the desktops - but it doesn’t.
As far as InTune is concerned the V1 app is marked as installed for the device or the user. Simply uploading an updated .intunewin file doesn’t change that fact. The only way to break the log jam is to convince InTune that the app isn’t installed anymore which forces a re-install and a subsequent upgrade.
The Win32 object has a number of ways to detect if an app is installed. Again these are well documented in other technical blogs but in summary it involves checking for files, folders or registry entries or a combination of all three. This works for the initial deployment because it’s a fair bet that if the startup executable can’t be found in the install path it’s probably not installed. However for an upgrade this approach cannot be relied on. Unless the process creates a new file / folder or updates a registry entry that you can check for, the logic will always return ‘installed’ and assume there is nothing to do.
Even if you can update the original app object and identify a feature to test for, you are not going to get much feedback on how the upgrade is progressing. The best that you can hope for is a report that tells you that 100 instances are installed and, at any time 100 instances are still installed. There’s no feedback on the roll-out process because the app only reports if it’s installed - which it is in all circumstances.
For this reason, best practice suggests creating a new Win32 object for each app version and retiring the old version by removing the assigned group or changing the status from Required to Available. This makes things nice and clean and gives you a good idea of how things are progressing but doesn’t solve the problem of triggering the install process in the first place.
Fortunately the Win32 object gives you the option of running a script instead of looking for files and folders which allows you to check the version of the application using the script below.
$ver = (Get-Command "<<< Path to the app.exe >>").FileVersionInfo.FileVersion
if ($ver -eq "<< Version Number to Test For >>")
{
Write-Host "Updated Version Installed"
}
 |
| https://www.petervanderwoude.nl/post/working-with-custom-detection-rules-for-win32-apps/ |
This will force the update onto V1 machines and since the check is also run at the end of the process it’s a surefire way of ensuring the update has been a success.
Once you start scripting you can embed any logic you like but it’s best to keep it simple because once the code has been uploaded to Azure store there’s currently no method within the GUI to recover the script or even view the contents so this process has to be manually documented.
Clearly this is not an ideal situation and it’s likely that Microsoft has a roadmap to make this process easier, possibly by involving a version label or something similar. In the meantime it's worth giving some thought to how you intend to maintain Win32 apps before the initial install goes out.
