All quiet on the Intune Detection Rules

This blog will not be a deep dive into a weird issue but will be more like an explanation of when you want to silently install and uninstall a Win32app in the user context. I will show you how to deal with the silent install, Uninstall, Applocker, and dealing with user-based detection rules.

1. What do we want to accomplish

A colleague asked me if it was possible to deploy an older version of the Xelion App (Phone App) with a ClickOnce setup silently to some users. Of course, it is!

Deploying apps is not my main focus, but I guess everything happens for a reason. When we want to deploy ClickOnce apps to our users, we need to overcome some challenges.

One of those challenges would be to ensure that we deploy the app without additional prompts like these.

The other challenges we needed to deal with were how we were going to configure and allow the ClickOnce app when using Applocker and how we would configure the detection rule. Let’s move on to our first installation attempt, shall we?

2. First attempt

When we first wanted to push the ClickOnce Win32app, we first used a rundll32 command to initialize the ClickOnce installation

rundll32.exe dfshim.dll,ShOpenVerbApplication https://softphone.xelion.com/ClickOnce/Softphone/XelionSoftPhone.application

It did its job, but unfortunately, we were prompted with some additional questions you would expect to get when launching a ClickOnce application file

Having the user click on accept isn’t what we want! When publishing this app as an available app, we would be okay with it, but if we want to deploy this ClickOnce app as a required one, it’s going to be hard for the user to approve the installation

3. The Better option

Throwing some prompts to the user to accept stuff or to click on install isn’t always nice so we decided to silently install the app with the use of the SilentClickOnce.exe file

This nice executable gives us the power to fetch the ClickOnce application file online and install it! Of course, some additional logging is included. What are we without logging? Nothing

Let’s move on and convert the script and the executable to an Intunewin file and upload it to Intune. When deploying the Win32App to Intune, we made sure we configured the Install behavior as User

We configured the install behavior as USER because the ClickOnce needs to be installed in the appdata\local\apps\2.0 folder and not in the SYSTEM its local AppData folder: C:\Windows\System32\config\systemprofile\AppData\Local

Of course, we only want to have this app installed if a specific requirement has been met. Without Java, the Xelion app isn’t going to work. Even when we have configured the Java app as a required app we still need to be sure Java is installed otherwise, the Xelion app isn’t going to work

As always we also need to define some detection rules… because we need to make sure the app will be detected in the user its Roaming AppData StartMenu Folder, after the app has been successfully installed.

We also made sure to configure the file detection rule to detect if the shortcut has been placed in the user’s start menu.

Please note: I am using the %username% as that one will resolve to the proper username! Using other variables such as %localappdata% isn’t going to work with detection rules!

Please note: before publishing the app to Intune, please make sure you check out your AppLocker configuration. Otherwise, you will end up with your ClickOnce app being blocked

4. Applocker

As stated in the previous part of this blog, when Applocker is deployed, we need to make sure this ClickOnce application is allowed to be executed.

To get the publisher information, I opened Google Chrome (yep Chrome not, Edge) and put in the URL. This will make sure the application file will be downloaded instead of executed

After we downloaded the .application file that was downloaded, we renamed it to XML so I could get some more information

As shown above, when we opened the XML we could fetch the required publisher information by searching for : publisheridentity

I opened Intune and selected the proper Applocker rule to add an additional Applocker publisher rule as shown below.

  <FilePublisherRule Id="57bd31d9-e593-45dd-bbc0-8dca53c3e54b" Name="Ondertekend door O=XELION B.V., S=ZUID-HOLLAND, C=NL" Description="" UserOrGroupSid="S-1-1-0" Action="Allow">
    <Conditions>
      <FilePublisherCondition PublisherName="O=XELION B.V., S=ZUID-HOLLAND, C=NL" ProductName="*" BinaryName="*">
        <BinaryVersionRange LowSection="*" HighSection="*" />
      </FilePublisherCondition>
    </Conditions>
  </FilePublisherRule>

Please Note: It’s obvious as we are using a cmd script to launch that EXE file to silent install the ClickOnce application we need to allow the command prompt within the Applocker policy

5. Taking a closer look at the Installation

I guess I need to explain the installation and the user detection part a bit better because I noticed that there was some misunderstanding about the user-based detection rule.

I am mentioning this misunderstanding because I still remember a question about it and the official MSFT reply on the Microsoft Q&A pages

So, let’s fire up the Company Portal and start the installation of the ClickOnce application!

When we press install, the IME will try to install the Win32app Package following the flow I am mentioning in this blog below

Troubleshooting failed Intune Win32 Apps installation | IME (call4cloud.nl)

Looking at a part of that flow and the picture below, the IME will first fetch the attached policies from the Win32App. This information contains detection rules and the \“Runas”:0,\ parameter which defines the win32 app as a USER based installation

With the detection rules it got from the policies, the IME will try to detect the Win32App first by using the ApplicationDetectedByCurrentRule method.

As shown above, when the app can’t be discovered in the system context, we will end up with the message “False as system.” If it fails, it will run the same check, but this time, it will be run in the user context by using the applicationDetectedbyCurrentuser method.

We all know the outcome because the app isn’t installed yet. Within a few seconds, after the detection outcome was false, the required BIN file is downloaded

If the bin file was downloaded successfully, it will launch the installation and rerun the detection part to determine whether the installation was successful.

As shown above, it uses the same detection flow as when we press the install button to initialize the ClickOnce application. We will notice that the app has failed detection in the system context, but at the same time, it launches the DetectUnderUserContext method to determine if the detection is successful as the current user.

The detection rule will check if that Xelion folder exists in the logged-in AppData folder and if that folder is present the win32app will be marked as successfully installed

After some time waiting the app installation status will also show the app marked as installed in Intune. Isn’t that just wonderful?

6. Uninstalling the App

Even though this blog is more about the detection rules, I still needed to show you how the uninstall will take place when you are uninstalling an App that is targeted at the User Context.

As always, we have configured the uninstall string to ensure that when the Company Portal is ready to offer us the Uninstall button, we have everything in place.

But for now, we still need to assign a user group to the uninstall section to ensure the user-installed app is uninstalled. When we look at the IME log, we will notice that the uninstall also takes place in the user context!

As shown above, the Win32AppInstaller will be launched in the user session (Username is DOMEIN\Rudy). Within a few seconds, the Xelion uninstall prompt will be shown in the user his session!

7. Uninstalling the App and the UserName

After a conversation on Twitter, I decided to also point out this part of the puzzle in this blog. In this part, I will use the Take Control Viewer user-based installation as an example.

I will try to Uninstall the App even when it was installed in the user its local AppData folder. Let me explain a bit because uninstalling the application that was installed in the local user data folder and calling upon the uninstall.exe in it is just a bit different.

So how to deal with the username variable in the uninstall string? Are we going to use %username% or %localappdata% in the uninstall command as shown below?

Unfortunately, that uninstall string isn’t going to work and you will end up with an error code 2 in your IME log

Instead of entering an uninstall command directly, we could create an additional uninstall.cmd script. It’s almost the same as the detection rules

As shown above, the detection rule also places an additional file in the DetectionScripts folder which will be launched in the user context to detect the app. When looking at the additional uninstall cmd script, I am NOT using %username% this time but %localappdata%

Until the Microsoft Company portal gives us the option to uninstall the app ourselves I changed the assignment to make sure the Take Control viewer is installed for all users

After making sure the device was synced, the uninstall process launched. Because we are using an additional cmd script and using the %localappdata% variable the cmd will be launched in the user context and it will resolve the localappdata variable

Within a few seconds, the Take Control Viewer folder disappeared from our device

After giving Intune some time to consider it, we will notice that the status will change from installed to Not Installed!

Conclusion

This isn’t a deep dive, but hopefully, you enjoyed it and learned that setting up a detection rule and using %username% is not an issue when the app is installed in the User Context. But uninstalling the same app using the same %username% variable in the Uninstall command isn’t going to work!