This blog explains how the Intune Management Extension (IME) handles the cleanup of the IMECache folder after it has finished installing a Win32App. We will also examine what happens when cleanup fails and why some folders persist even after a reboot.
Introduction
Let me start by saying that if you’ve ever dug around on a device after a successful Win32 app deployment and found leftover folders in C:\Windows\IMECache, you’re not alone.
You might have wondered why those folders in the IMECache are still there, even though the win32 app appeared to be successfully installed hours or even days ago. We will walk through how the Intune Management Extension (SideCar) unpacks and manages the Win32 app content. We’ll examine when the folder is reused, when it’s deleted, what triggers re-extraction, and what happens when something blocks the cleanup.
From Encrypted download to the IMECache Folder
When a Win32 app is deployed through Intune, the .intunewin package first lands in a temporary download location. The moment the file drops down in the incoming folder, it is still encrypted. The agent then decrypts the file and unzips it into a subfolder inside C:\Windows\IMECache. (For more details about the whole installation flow, check out our webinar)
This folder contains the raw content used for detection and installation, think install.cmd, MSI files, PowerShell scripts, or whatever else was packaged. The folder name follows the format of AppId_AppVersion.
This unzip and staging process is handled by a component inside the agent called ContentUnzipper.
What determines whether IME unzips the Win32App again
Here’s where the reuse logic comes in. IME doesn’t automatically unzip the same app every time it’s triggered. It checks whether a matching folder already exists in IMECache. If it does, and the folder is less than 36 hours old, it’s reused.
But there’s an override in place. Some flows, like a retry, or certain enforcement cycles, force a re-unzip no matter what. Internally, this is controlled by a parameter called alwaysRefresh. When that’s set to true, IME skips the age check and deletes the folder anyway.
So the real behavior looks like this:
- If the folder is fresh and alwaysRefresh is false, IME reuses it.
- If it’s older than 36 hours or alwaysRefresh is true, it gets deleted, and the content is unzipped again.
After installation, the IMECache cleanup begins.. (or at least tries to)
Once the app has been installed successfully, IME attempts to clean up the extracted folder. It does this by calling its internal file system methods to delete the IMECache subfolder.
If that delete works, the folder is gone. If it fails due to locked files, bad permissions, or anything else, IME logs the error and schedules the folder for deletion on the next reboot.
This is done through the Windows API MoveFileEx.
The MoveFileEX will add an entry to the PendingFileRenameOperations registry value under HKLM\SYSTEM\CurrentControlSet\Control\Session Manager.
On the next reboot, Windows checks this registry key and “attempts” to delete whatever was listed. (if it has enough permissions to do so)
But that doesn’t always work either.
Here’s the thing. MoveFileEx works great for files and folders that are empty and not locked. However, if the folder contains files in use or has restricted permissions, the deletion fails silently. Windows doesn’t log or retry; it just moves on.
This is why you may sometimes see lingering folders still sitting in IMECache after a reboot, even though they were clearly marked for deletion in the registry beforehand.
What about the IMECache permissions during unzip
During the unzip process, IME sometimes sets permissions on the extracted folder, but only under specific conditions.
If the app has a contentCacheDuration set to int.MaxValue, which usually means the app should be reused indefinitely across sessions, IME adds Read and Execute permissions for the INTERACTIVE user group. That way, the content can still be accessed.
Outside of that case, IME doesn’t mess with permissions. Therefore, if an installer script or MSI changes ACLs during installation, it locks the SYSTEM or administrator account out of the folder, which will block deletion later. It’s worth noting that the IME doesn’t attempt to fix or reset permissions after the app has been installed. So, if you mess with the IMECache folder… well, good luck… You need to fix that yourself!
The IMECache Leftovers
If you’re trying to figure out why a Win32 app keeps reinstalling or why detection fails even though the app is clearly present, the IMECache folder is one of the first places to look. It tells the story of what content was extracted, when, and whether IME thinks it needs to start fresh.
It also gives you clues about cleanup failures. If the folder’s timestamp is old or if it persists through reboots, check for leftover locks, permission changes, or detection scripts that still reference it. You can also check the registry under PendingFileRenameOperations to confirm whether IME tried to schedule deletion.
Conclusion
The IMECache folder is part of a controlled IME/Sidecar process. If an app is installed successfully, the folder should be removed. If that fails, it is scheduled for deletion after a reboot. Also worth noting is that if permissions or locks get in the way, the folder can survive even after multiple reboots. With it you need to manually remove that folder yourself!