SCCM Task Sequence Hangs

A lot of people use a Task Sequence to deploy applications after the Operating System has been installed.  A customer of mine had an incident where the TS hung  because Hotfix KB2761938 wasn’t installed on the clients. This stopped the clients from  receiving applications. Except for installing the hotfix on the clients there’s a pretty easy fix for this.

But first, here are the symptoms of a hung Task Sequence:

.ExecMgr_OnContentAvailable invalid request GUID handle

Execmgr.log on the client will display lots of “OnContentAvailable invalid request GUID handle”-messages.


SMSTS_FolderStillExist

There’s a folder in C:\Windows\SysWow64\CCM\Logs called SMSTSLog. This is left here because the TS is still running.

 

SMSTS.LOG

If you open the logfile you’ll se that the TS has hung while “Pausing CCM Component SoftwareUpdates”.

Multiple TS Fails

The Task Sequence will be “Completed” if you look at it with SCCM Client Center.

 

Statefailures

A closer look will reveal that it has also Failed. (You can see this through Client Center too if you click the Plus-icon on Completed and navigate down in the advertisement.)
The screenshot above is from the excellent tool WMI-Explorer.

 

TaskSeqAgentRunning

A very important clue is that the SMS Task Sequence Agent is still running. (The process is called TSManager.exe)

 

Registry_Pause

In the registry all Software Distributions will be paused with the two keys:
HKLM\SOFTWARE\Wow6432Node\Microsoft\SMS\Mobile Client\Software Distribution\State\Paused
and
HKLM\SOFTWARE\Wow6432Node\Microsoft\SMS\Mobile Client\Software Distribution\State\PausedCookie

There are two ways to solve this. One way is to wait, because sometimes the TSManager-process dies by itself. The other way is to kill the process TSManager.exe on the client. This will remove the Registry Keys that pause Software Distribution, delete the SMSTSLog Folder, and remove the job from WMI. It’ll forget to remove two folders in the root of the C-Drive though. These two folders are called

c:\_SMSTaskSequence and C:\SMSTSLog.

I’ve written a script that lets you check individual computers or all your computers in your SCCM-environment for Task Sequences that are hanging. My customer had a frozen TSManager on 40% of their computers. So software distribution was bascially not working on 4500 computers…

Here’s the script:

CleanComputerFromBadTS_v1.7


Update.
 Some have requested a script that only does the checking, here’s a special version for that:

CleanComputerFromBadTS_v1.7_Checkonly.vbs

Some notes on the script. I’ve tested it pretty well but use it on your own risk. The script Checks for a running TSManager and kills it on the client. It’ll also check for paused software distributions, left over SMSTS-folders and it’ll clean the computer of old TaskSequences in WMI that are in a limbo state.

Run the script like this:
cscript.exe CleanComputerFromBadTS_v1.7.vbs <computername>

You can run the script like this :
cscript.exe CleanComputerFromBadTS_v1.7.vbs /CheckAll

With the /Checkall flag you need to edit the script to enter the name of your SCCM Server. The script will create three files; A log file, a file called CheckedComputers.log and a file called DoesntAnswer.log. The two latter files are used to remember which machines have been checked in case you abort the script.

There is also a third option called /NonPingableOnly which pings all clients that were un-pingable in the first run (the computer names are stored in DoesntAnswer.log)

If you have any questions, please ask them below.

Thanks for reading,
Mathias.