If you’ve been following along, we’ve already covered a lot of ground on how Intune handles Win32 applications, as well as the mechanics of the detection rules, why your Intune registry detection rules fail, and a full installation flow.
These pieces focused on how Intune decides whether an application needs to be installed in the first place.
In this article, I’d like to also cover another scenario of a separate behavior that some people might not be aware of: what happens when you update the .intunewin file?
What Happens When You Replace the .intunewin File?
If you are in testing or normal production mode and you have an application deployed and users who already installed it, you cannot simply replace the .intunewin file in the original deployment.
Why is that?
In theory, you think it should work because Intune should notice that the deployment contents are different, right? Well, that is not the case, and to be honest, it’s the same approach that was with SCCM (MECM).
The reason comes back to exactly what we discussed in the previous detection rules articles.
When the Intune Management Extension (IME) checks in on a device, it evaluates the detection rule for each assigned application.
If the rule returns a positive result, indicating that the application is successfully detected, IME marks it as installed and moves on. It does not look at the version of the .intunewin file and does not compare timestamps or file hashes.
The only thing that matters at that point is whether the detection condition is met on the local machine.
So, if your detection rule checks for the presence of a registry key or a file path that already exists on the device because version 1.0 is installed, Intune returns “Installed” and does nothing else.
There is a chance that the deployment with the updated .intunewin file will reach some users.
However, these are the users who have not yet had the chance to install version 1.0, and if you change the .intunewin file before that happens, those users will receive version 2.0.
In this case, you will have a bit of a headache because what happens to the detection method?
If both version 1.0 and 2.0 are successfully detected, it means there is no way to export a report that says which version is installed on each machine. If the detection is different, users who receive the 2.0 .intunewin file will appear as “Failed” in Intune because the detection method will not work.
How to Trigger the Update?
If you continue to update the .intunewin file instead of creating a new deployment, the fix is quite simple: you need to change the detection rule to reflect something specific to the new version.
This gives IME a condition that is not yet satisfied on devices running the old version, causing it to treat the app as not installed and kick off the installation process.
In practice, this usually means that if you detect it using a registry value, update the version string your rule is looking for, or if you use an MSI product code, use the new GUID that comes with the updated installer.
If you are detecting a file, you can point to a file or path that only exists in the new version, or you can check on the file version itself to see if no new files are placed in the updated .intunewin file.
Once the detection rule change is saved and the devices check in, IME evaluates the rule, finds it unsatisfied on the machines running the old version, and queues the installation, after which the new .intunewin file is downloaded and executed.
It is worth mentioning that if this is done, Intune will trigger the installation of the updated package on top of the old package (if your device already had it installed).
If the old package is an MSI or EXE, you rely fully on the vendor logic. If your package is a complex script, you need to rely on the logic defined in your script.
However, keep in mind that Intune has a mechanism that prevents applications from being installed if they fail more than three times.
If an application fails three times, IME enters a cooldown period before it tries again. There is a lot to discuss in this area, so I suggest you check out the separate article Intune Application Retries and GRS to better understand the mechanics behind it.
The Cleaner Approach
Regardless of whether you have a small or large infrastructure, the best approach is creating the new version as a separate application entry in Intune entirely rather than editing the existing one.
This results in a clean deployment object that you can test against a small group first, validate, and then expand.
You can also use the old version as a prerequisite or set the old deployment group as an exclusion on the new one, which prevents any device from accidentally receiving both versions at the same time.
Once the rollout is complete and you have confirmed that the new version is installed, you can retire the old application in Intune and clean up.
Be aware that most vendor installers will not allow two versions to run simultaneously.
Conclusion
The key takeaway is this: the `.intunewin` file is just the payload. Intune’s decision on whether to deliver that payload is driven entirely by the detection rule.
Swap the file without touching the rule, and nothing changes for devices that already have the app installed. Change the rule to reflect the new version, and the update rolls out on the next check-in cycle.
It is one of those behaviors that makes complete sense once you understand how IME evaluates apps end to end, which is exactly why we covered that foundation in the earlier articles before getting here.
Final Takeaways
- When the Intune Management Extension (IME) checks in on a device, it evaluates the detection rule for each assigned application
- If the rule returns a positive result, IME marks the application as installed and moves on. If your detection rule checks for the presence of a registry key or a file path that already exists on the device because version 1.0 is installed, Intune sees “Installed” and does nothing further
- The fix is simple: you need to change the detection rule to reflect something specific to the new version
- Whether you have a small or large infrastructure, the best approach is to create the new version as a separate application entry in Intune instead of editing the existing one
- You can also use the old version as a prerequisite or set the old deployment group as an exclusion on the new one
