Last Updated on February 23, 2023 by rudyooms

This blog will be no deep dive into a weird issue but 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.

I will divide this blog into multiple parts

1. What do we want to accomplish
2. The first attempt
3. The better option
4. Applocker
5. Taking a closer look at the installation
6. Uninstalling the App
7. Uninstalling the App and the UserName

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 have some challenges we need to overcome.

One of those challenges would be to make sure we are deploying the app but without some 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, with some additional logging 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 we configured the file detection rule to detect if the shortcut has been placed in the user his/her 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 having Applocker 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 will 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 failed it will run the same check but this time it will be run in the user context by using the applicationDetectedbyCurrentuser method.

I guess 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 will rerun the detection part again to determine if the installation was successful.

As shown above, it uses the same detection flow as we noticed 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 make sure 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 uninstall section to make sure the user-installed app will be uninstalled. When taking a look at the IME log we will notice that the uninstall will also take 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

Giving Intune some time to think about it, we will notice that the status will change from installed to Not Installed!

Conclusion

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