How to Easily Identify and Reinstall Software During Configuration manager OS Refresh Task Sequence without MDT

So you’ve been asked to reinstall all applications for users for the sake of reducing user impact? What do you do? Is this is a good idea? Read on:

One of the most commonly requested items that adds complexity to Operating System deployments is the topic of identifying and reinstalling applications. If MDT is in use, it supports Application Mapping, which must be configured, but is not always approachable by the novice. Should go you that route? Maybe. But what if MDT isn’t integrated or the Application Mapping is just a bit over your head? What I suggest below is simply one of the many ways of addressing this particular need.

But first:

As a best practice, a company should already have a baseline of applications provided for each unique role such as department or position and only deviate from that baseline where necessary, and ideally identify and automate those exceptions such as where special licensed software should be deployed. User deployments and self-service go a long way to making this an easier process. In reality, however, the situation is usually much less clear. Self-service isn’t always supported, there is expectation for 100% deployment before the user receives a system or the network simply may not handle deploying large apps to remote areas after the system is provisioned.

As a result, rather than spending the time to identify what the users should have, the decision makers often fall back on saying to re-install whatever the user had.

This approach presents many problems including:

  • It fails to consider updated versions or apply any nuance – Should the user receive the latest and greatest version of Java? What if it impacts their Line of business apps? Are there combinations of applications that must run at a downgraded version? Should some departments receive newer versions than others? Can IT actually support the numerous versions being asked of them? All of this would require business analysis on what apps should be deployed by role. Without it, the option is either to run obsolete and potentially insecure versions of software for the foreseeable future.
  • It’s a licensing headache – even if we can reinstall the application, carrying over a license key is often not supported and in some cases may not be allowed.
  • It’s a lot of work – Every version of every application must be identified, assessed if a substitution or reinstall is necessary and those to be reinstalled must be packaged. This can be hundreds or thousands of hours of work.
  • It needs kept up to date – As new versions or applications are added, the automated process must also be updated.


Ok, enough opinion piece, let’s get to reinstalling applications.


  • A OS deployment refresh task sequence must already exist, we are simply adding a few steps to it. It’s ok if you need to format the disk, but we do need to run the task sequence from within a working version of Windows first, not WinPE.
  • All apps or packages that you want to reinstall must be packaged, deployed to your DPs and you must have some way of identifying systems that should have it reinstalled. If you don’t know how to do this, Configuration Manager supports WQL to identify applications or even includes an MSI parser in the task sequence to get the unique GUID for the installation detection.


After ensuring you are booted into Windows OS (not PE), Create a Set a TS Variable step for each app you wish to reinstall:


Use a condition on that step that checks if the app is installed (WMI or the built in installed app check)


When reinstalling apps after OS Deployment.