Every day is an adventure, isn’t it? Well, the other day was no different, really. My friend, co-worker, and ConfigMgr cohort Jason Rutherford was discussing with me an issue that had just popped up in an environment he is managing. As it seems, several clients were failing to install software in the middle of execution. However, there was no real rhyme or reason.

Apparently, my brain has made somewhat of a recovery from my early college days, because memory served me well that day. I remembered that, several weeks back, a client of mine had discovered that several ConfigMgr clients were reinstalling daily. After digging deeper, he found a scheduled task on these machines that initiated a reinstallation of the client every day. Certainly, this was from a botched initial installation, but there was no easy way to tell how many culprits were in the wild.

Lesser folk would spend their day trying to locate such instances and manually remove the scheduled tasks in an effort to resolve this issue. But we are not lesser folk. You are not lesser folk. We must automate this.

First thing is first: locate the path to the scheduled task. Now, interestingly enough, it resides in “\Microsoft\Microsoft\Configuration Manager” (it created a sub-directory called “Microsoft” under “Microsoft”, which is surely a hint to a botched client install).

Secondly, let’s detect and remediate. We took the approach of leveraging compliance settings along with PowerShell to detect and ultimately remediate the issue. To do so, we need to first create the Configuration Item, add that to a Configuration Baseline, then deploy to our client machines.   Create the configuration item as follows:

We decided that we only really care about Windows 7 and 8.1 workstations at this point:

Add the detection and remediation scripts (bottom of this post):

Go to the Compliance Rules tab, add the value from the script that returns if compliant (in this case, the string “Compliant”) and check the boxes to remediate and report noncompliance:

Next, create your baseline and add the CI:

Once created, we deployed to the baseline out (All Systems in this demo; you probably want to narrow your collection down):

In the properties of the deployment, we made sure to remediate when supported and generate an alert if the compliance was below 90%:

That’s it! While this does not exactly solve the puzzle as to why those scheduled tasks are present, this will both repair the issue and allow you to see how widespread it is. Plus, we automated the solution, so you can spend more time finding new beers. That’s what life’s all about anyway, right? **************************SCRIPTS**************************

## Detection Script

$Compliance = 'Compliant'
$ErrorActionPreference = "SilentlyContinue"
$TaskScheduler = New-Object -ComObject Schedule.Service
$TaskScheduler.Connect($env:COMPUTERNAME)
$TaskFolder = $TaskScheduler.GetFolder("\Microsoft\Microsoft\Configuration Manager")
$Tasks = $TaskFolder.GetTasks(1)
$TaskToDelete = "Configuration Manager Client Retry Task"
foreach($Task in $Tasks){
if($Task.Name -eq $TaskToDelete){
$Compliance = 'Non-Compliant'
}
}
$Compliance

## Remediation Script

$ErrorActionPreference = "SilentlyContinue"

# create Task Scheduler COM object
$TaskScheduler = New-Object -ComObject Schedule.Service

# connect to local task sceduler
$TaskScheduler.Connect($env:COMPUTERNAME)

# get tasks folder (in this case, the root of Task Scheduler Library)
$TaskFolder = $TaskScheduler.GetFolder("\Microsoft\Microsoft\Configuration Manager")
$rootFolder = $TaskScheduler.GetFolder("\")

# get tasks in folder
$Tasks = $TaskFolder.GetTasks(1)

# define name of task to delete
$TaskToDelete = "Configuration Manager Client Retry Task"

# step through all tasks in the folder
foreach($Task in $Tasks){
if($Task.Name -eq $TaskToDelete){
$TaskFolder.DeleteTask($Task.Name,0)
$RootFolder.Deletefolder("\Microsoft\Microsoft\Configuration Manager",0)
$RootFolder.Deletefolder("\Microsoft\Microsoft",0)
}
}