Workflow: Desktop application uninstallation

Overview

Large enterprises can easily lose track of the number of applications in use and, more importantly, those not in use. In many cases, applications are unnecessarily installed on user devices where they are not necessary, which can also contribute to the licensing count. In addition, removing applications at scale while ensuring employees approve and are made aware of the change is very time-consuming.

The Desktop application uninstallation workflow can be triggered across any group of devices not using a specific application and automate its uninstallation. The workflow first engages with the user to notify and ask the user for permission before uninstalling the application.

If the user refuses, an ITSM ticket is created to notify the relevant team that some users are not using an application but have refused the installation to escalate.

• Fully automated process to uninstall an application using Nexthink Flow. 

• Option to ask user permission or enforce application uninstallation.

• ITSM ticket creation for users who refuse to highlight users who don't use the application and don't want to uninstall. 

Changelog

V1.0.0.0 - Initial Release
V1.0.1.0 - Updated campaigns and corrected workflow logic

Dependencies

To utilize this workflow, you must install the necessary content into your Nexthink Infinity tenant.

Engage campaigns

• Application uninstallation request - workflow invoke

• Application uninstallation - completed

Remote actions

• Uninstall application

Configuration

ITSM API connector credentials

The configuration of connector credentials is essential for enabling API calls. See detailed information at https://docs.nexthink.com/platform/latest/webhooks-manage-credentials . Each Service/API thinklet has a dropdown field for credentials that needs to be filled out. When the workflow is installed or copied from the Library, this field will be blank as it is a local setup of each environment and is not included in the Library.

Trigger configuration for the workflow

This workflow is primarily designed to run automatically using a scheduled trigger. However, it can also be manually triggered for ad hoc usage. The example below how the automatic schedule could be configured for periodical check of devices with Microsoft Project installed but not used.

NQL:

devices during past 30d
| with package.installed_packages
| where package.name == "Microsoft Project*"
| where package.name != "*MUI*"
| where package.publisher == "Microsoft*"
| where package.type == program
| compute device_with_project_installed = device.count()
| include execution.events during past 30d
| where binary.name in ["winproj.exe"]
| compute device_using_project = device.count()
| where device_using_project = null

Global Parameters

There are three global parameters in this workflow:

• Ask user permission - allows the operator to choose whether or not to send an initial campaign asking for permission to remove the application.

• Application to be removed - this is the application name that will be passed to the remote action as a parameter. This should be the full application name as it appears in the “Uninstall a Program” section of the Control Panel.

• Application silent removal switch - By default, the /quiet flag is passed to the RA for silent removal of an MSI application. Should the application that is being removed require a different switch for silent removal, this can be specified here.

Workflow Structure

This section describes the key steps in this workflow:

• The workflow first checks the "Ask user permission?" parameter. The Engage campaign is initiated if it’s set to “Yes”. The response from the campaign is then evaluated. If permission is granted, the workflow proceeds with the remote action to uninstall the application. However, if permission is denied, or the application is still required, a ticket is raised in the ITSM application.

• Following the remote action execution, the user is notified about the successful action through an Engage campaign.