IMECache: Attack of the Cleaner

In this blog, I will guide you through the Win32App installation IME process and each step of the IME flow. After I show you the whole Win32App installation flow, I will also show you how you could troubleshoot and solve some installation errors and retry the failed installation!

Please note that this particular problematic app is deployed using the ServiceUI tool.

1.Win32 App IME Installation Phases

When you want to monitor or troubleshoot a Win32 app installation, you will need to take a look at the Intune Management Extension log file:

C:\programdata\microsoft\intunemanagementextension\logs\IntuneManagementextension.log

You can open this log file with Notepad, but I recommend the CMTrace tool from the config manager toolkit. It’s way easier to read the log with this tool!

Download System Center 2012 R2 Configuration Manager Toolkit from Official Microsoft Download Center

But it seems that the download is no longer available at the Microsoft Download Center. If you are okay with downloading stuff from strangers…. here it is!

https://call4cloud.nl/wp-content/uploads/2022/07/cmtrace.zip

If you are more interested in the replacement of the wonderful CMTrace tool, you could also download this SupportCenterInstaller.Zip as it contains the OneTrace Tool

Now that we have all the tools in place, we could start looking at the IME log because this log will show us each phase a Win32App install goes through.

1.1. Pre-Detection and Applicability Phase

Before the IME can install the nice Win32App, it needs to get its detection rules. Otherwise, how can it know if the app is already installed? As shown below, when we want to install an app from the Company Portal, the IME will ensure it gets the policies.

When looking a little bit closer at the policy above, you will notice some nice things in it

• The first thing you could notice is the mention of the “Intent“. I made the app available so guess what the Intent should be .

0 –> Not Targeted
1 –> Available
3 –> Install/Required
4 –> Uninstall

• The second part you could have noticed in the policy, is that it also contains the needed detection rules.

Now IME knows what to check for, it fires up the ProcessDetectionRules and will start the detection of the App by checking the rules it got.

After IME (SideCarFileDetectionManager) successfully determines that the Win32App isn’t already installed (ApplicationDetected: False), it can begin to check the Applicability.

By checking the applicability, It will check the requirements you “could” have specified when you created the Win32 app earlier on. For example, which OS version do you require or what is FreeSpace required?

1.2. Downloading Phase

When the applicability checks out, the IME can download the intunewinfile (*.bin) from the Intune service (*.manage.microsoft.com) to the device.  The file download will be placed in the  C:\Program Files (x86)\Microsoft Intune Management Extension\Content\Incoming

Luckily, this time, the Intune Device certificate is available! When it is not available or expired you could get some weird behavior. I dedicated a blog to this some time ago.

https://call4cloud.nl/2021/04/intune-mdm-device-certificate-expired/

1.3. Decrypting and Verifying Phase

After the download is ready, it will verify and decrypt the .bin file into a zip file in the staging folder.

C:\Program Files (x86)\Microsoft Intune Management Extension\Content\Staging\ and from the staging folder, it will be unzipped to the c:\Windows\IMECache\GUID folder.

1.4. Installing Phase

IME will start and retry to install the Win32App 3 times for 5 minutes each 24 hours. IME will launch the Win32Appinstaller and will try to install the Win32app from the IMECache folder the data was extracted to earlier.

1.5.Detection Phase

IME will try to detect if the installation is successful by checking the detection rules you specified in the Win32App detection rules in Intune.

ApplicationDetected: False –> I guess that one speaks for itself!!

More about this in 4.2 ExitCode and STDOUT part

1.6.Reporting Phase

The final phase of the app installation is the reporting phase, IME will send the AppResults back to the service *.manage.microsoft.com

1.7 The Win32 App Installation Flow

I updated this Flow below because some information wasn’t correct. The data will be decrypted and moved to the IMECache folder instead of the staged folder.

2. Background info and the Serviceui Tool

We were asked to publish a new app for all users, called Eplan. When Installing this specific app some user interaction is required. When you need to have interaction between the user context with the system context the only option you have is to use serviceui.exe

By default, the Win32 apps which IME is installing, are installed by default in the System Context (0)

Please Note: A regular user session in a normal situation, has no permission whatsoever to view any messages or prompts from the app installation that is running in the system context.

Of course, you could change the install behavior in which context the app must be installed

When your users are all Local admin’s be my guest to change it to “users” but if you are reading my blogs often, you will know I really don’t like Local Admins. So changing this option to User is not going to work.

Serviceui.exe to the rescue. Serviceui.exe ensures that when the app is being installed in the system context, it can detect the user session and allow interaction with it.

https://www.microsoft.com/en-us/download/details.aspx?id=54259

A while ago, I created a blog about how to do this

https://call4cloud.nl/2020/11/company-portal-app-benefits

3. The Problem

Now we know how the whole app deployment works, let’s take a look at the issue itself. Creating an App with serviceui.exe could be done within a few minutes. We have done this literally a thousand times…. But this one was a little bit different

After the app was visible in the company app we tried to install it in our Sandbox Intune Enrolled device. If you want to read more about Sandbox, please visit this blog

https://call4cloud.nl/2021/08/sandbox-multiverse-of-madness

After a few minutes, the installation phase begins. After pressing next, next, selecting some specifically required settings, and clicking on next, this error was shown. Error 1311. Source File not found

That’s strange because the installation file that was executed was copied to the IMECache folder during the decrypting phase.

4. Triggering the Reinstallation

I needed to retry the failed Win32App installation multiple times to find out the real issue. I decided to remove this part from this specific blog as it was overshadowing the story I was trying to tell, so I gave it a blog of its own. Go check it out here! It will show you how to retry a failed Win32App installation!

Having the possibility to speed up the retry installation of a failed application is always great to have!

5. The Exit Codes

I decided to remove this part from this blog, as it was overshadowing my steps to troubleshoot and solve this issue. But still, it’s very important to know how the exit codes and Intune Detection rules work so please read this blog

6. Take a look at what’s Happening

Now let’s go further after we reinitialized the installation again and check if the contents of the bin/intunewinfile were the same.  

We detected no differences…. Let’s check what has been copied to the IMECache folder

Looking at the IMECache folder above… it is missing many files… almost every file needed to install the app.

We double-checked the intunemanagement log to be sure we didn’t miss any errors. I expected the error 0x87D300C9 with the corresponding message: “The unmonitored process is progress, however, it may timeout”. When receiving this message, it could be due to some misconfiguration in the install parameters.

Unfortunately, we did not encounter any usable errors this time. To be sure, it was not the device itself. We also tried it on multiple cleanly installed VMs and sandboxes and retried the installation multiple times.

So what’s happening here?

–No PathTooLongException:  The folder is not over the 248 characters

–No Defender issue: we made sure we excluded these folders:

• c:\windows\IMECache
• c:\program files (x86)\microsoft intune management extension\content folder

To be sure the exclusion was added we performed a get-mppreference to get the exclusions. As shown below, the folders are added successfully!

*Source : Troubleshoot Win32 apps in Microsoft Intune | Microsoft Docs

-When you are packaging Win32 apps, please make sure you have the latest version installed! Because looking at the release notes of the Win32 Content Prep Tool / IntuneWinApp tool I noticed this:

In version 1.7 some issues were fixed with Unicode support.

• Unfortunately, updating the tool and recreating the app didn’t fix it, so let’s dig in some more. When looking closer and refreshing the IMECache folder every few seconds, we noticed the files were removed even while the installation was not yet completed…?

Let’s open the Intune log again. After scrolling down the log we noticed this StatusService error a few minutes while it was installing the App.

The installation is a success, but the detection rules failed… and within 7 seconds, the Intune Management Extension (IME) starts deleting the temporary IMECache folder.

Of course, this is default behavior because the app was installed successfully! Let’s take a look at the first installation window and the last error prompt.

That makes totally sense!!! The first installation is the 5.70 version, when this installation is completed successfully it will send a good Exit code and the IME will start cleaning up but the installation is not done yet, it still needs version 5.70 sp1!  The 5.70 sp1 installations will start, but it is missing all the files and will throw an error and revert the installation!

7. The solution

Okay, now we know it is default behavior how are we going to solve this? The solution is very simple! We need to make sure we combine all the files into a zip file. When the deploy application is called upon we need to make sure it first extracts all the files and when all the files are extracted it will start the installation.

7.1. Zipping it:

Instead of adding all the separate files and folders inside the app\files folder, we need to zip them.

7.2. Changing the deploy-application.ps1

We need to make sure we add an additional install task: Expand-Archive and change the execute-process parameter to match the setup file from the zip file.

7.3. Testing the Win32App

Create a new Intunewin app and upload it to Intune. While installing the app, watch the IMECache folder… instead of extracting all the files, it extracts the zip file.

It will start extracting the files to the specified folder and it will install successfully because this folder is not emptied after the first installation is completed!.

Conclusion

Again… another deep dive into troubleshooting Win32app installations. Some time ago, I also did a blog about troubleshooting the problem with the RunOnce key

https://call4cloud.nl/2020/11/the-chronicles-of-win32-app-installations-the-runonce-key-onedrive-and-adminless

It’s very important you know how to troubleshoot win32 apps and it’s even more important to know how to read the intune management log.