Adding Notifications to Win32AppRemedy with Proactive Remediations

With the newly announced Proactive Remediations in Endpoint Manager, we are adding notifications to Win32AppRemedy.

Win32AppRemedy is a solution that gives you an automated way to update Win32 Apps in Intune that are assigned as available. Up until now, this solution did not give the users any heads up information or possibility to decide for them selves when to update their app. Now the solution has been extended to also include end users toast with information about a coming forced update, and a clear path for them to perform this update on their own time before deadline is reached.

This new feature is built into version 2.0 of the Win32AppRemedy runbook. The runbook will now also have the possibility to run notifications by enabling it via an variable that we pass to the script as an automation account variable. Now the runbook will, based on the input parameters containing information about the old app and the updated app, automatically generate both the detection script and the remediation script used in Proactive Remediations. This scripts will then be converted to base64 encoding, (required for uploading via Graph API), uploaded to Proactive Remediations and assigned to All Users.

The reason for assigning this to all users instead of using the AppRemedy device group is that we want to detect if the application is installed even if it is installed outside of Intune. If you have users with administrative privileges, they might have installed the application themselves. In that case, they will be notified to update, pointed to Company Portal to install the updated version. If they do perform this, they app will then be managed on this device moving forward.

Requirements

To enable this additional feature, you will need to have all the pre-requisite requirements in place for running Endpoint Analytics Proactive Remediations (Read here for requirements), and have your tenant onboarded for that.

You also need to have the base requirements for Win32AppRemedy setup and configured. Read here to get started.

Now onto the notification element. If you want to have a graphical look on this, I recommend either host 2 files on any kind of public webserver, or use Azure Storage. I have used a Azure Blob for this allowing me to anonymously grab the graphics through a simple web request without authenticating.

Added variables for Win32AppRemedy V2

In addition to the variables listed here we now need the following variables:

The new variable CleanOldAppVersion will make Win32AppRemedy clean up Intune by deleting the old app version after it has assigned the new version to the remediation group.

How does this look in Endpoint Analytics?

When the runbook runs, it will do all the actions explained in the original post about Automated 3rd Party Patch Remediation and the notifications feature if you have enabled it. To see the result go to Endpoint Analytics > Proactive Remediations and you should see your automatically generated script package with a status of Active.

Now open up the package and click on Properties to verify that the scripts looks ok. You can easily copy the scripts and test them locally on your machine to verify they are looking ok. Especially the remediation script should be verfied to see that the graphics looks good. Verify that the schedule is correct and take a not of the Publisher. This can be changed inside the runbook.

Click on Settings to open up and look at the script details:

Here we see that all the scripts are in clear text that can be read, modified and copied out for testing if needed. If you want to verify the script, look for the variables inside the scripts like OrgAppID, UpdatedAppID and so on.

The complete flow of the solution

From the runbook starts to the forced app remediation happens multiple steps is happening.

First the runbook assigns the app with a start date and a deadline to the devices that had the previous version installed and delete the previous app from Intune if selected. The start date for the required app remediation group assignment is by default set to 2 days ahead with a deadline of 3 days. All the assignment settings is modifiable in the runbook script.

The default setting here means that no automatic enforced remediation will happen before June 30th, with a deadline at July 1st.

At the same time we have assigned the Proactive Remediation and the app is available to all users in Company Portal. At this time when the Proactive Remediation runs on your devices, users will be notified about the available app update.

All the text here can be modified if wanted. The application names are created automatically. If the user now clicks on Update now, the Company Portal is triggered and opens up on the page of the application in question. This allows the user to choose his own time for updating app before the deadline is reached.

Custom settings

Some of the more common customizations are set up as variables in the Initialize region. The current customizations available in this version is

If you need additional customization it has be be done within script region of the runbook.

The updated version of IntuneWin32AppRemedy can be found at github here: https://github.com/MSEndpointMgr/IntuneWin32AppRemedy

A look behind the scenes

Lets start by having a quick look at the output from the runbook. Click on the Completed run of the runbook and All Logs.

Make a note of the following:
1. Info about what being patched
2. No patching group existed meaning we do not have a group to delete
3. Adding the one computer that needs patching to the remediation group.
4. Deleting the old app from Intune.

If you have enabled Diagnostics in Intune and Azure AD to forward logs to Log analytics, you can run a few simple queries to see what is going on behind the scenes.

IntuneAuditLogs 
| extend ApplicationName_ = tostring(parse_json(tostring(parse_json(Properties).Actor)).ApplicationName)
| extend IntuneApp_ = tostring(parse_json(tostring(parse_json(Properties).TargetDisplayNames))[0])
|where ApplicationName_ == "Win32AppRemedy"  
| project ApplicationName_, IntuneApp_, OperationName, TimeGenerated

In the example above, not that my Azure AD App Name is Win32AppRemedy, and that is the actor we are looking for in this query. The result of this query looks like this showing the actions performed by the runbook:

In addition to this, we have the Azure AD Log that shows the actions happening in AzureAD:

 AuditLogs 
 | where Identity == "WIn32AppRemedy"
 | project Identity, OperationName, TargetResources

Here we see that the runbook created the group AppRemedy-Demo.2.0.0 and added the computer SKANKE-PC100 to that group.

End user experience

On the end user side of things, the end user will get the notification and can click “Install now” to invoke Company Portal to install the updated app version. Have a look at the short video below on how this would look for the end user.

Go here to get started: https://github.com/MSEndpointMgr/IntuneWin32AppRemedy