This post shows how a script can detect if it is running from inside a Microsoft Configuration Manager Task Sequence in a way that avoids false positives.<\/p>\n\n\n\n
At times it’s useful for a script to detect if it is running from a ConfigMgr Task Sequence so it can alter its behaviour accordingly. The most commonly used way to do this involves trying to create an instance of the COM object Microsoft.SMS.TSEnviroment<\/strong>. This COM object is temporarily registered during Task Sequence execution, and then it is unregistered on completion. So in a script if you try to create an instance of the COM object and you succeed then it can be assumed that the script is running inside a Task Sequence.<\/p>\n\n\n\n Or so I thought…<\/p>\n\n\n\n I was involved in a simple Package and Program script deployment recently and I noticed that in around 1% of cases my script was failing. I checked the script logs on the affected machines and found that they were crashing because they were detecting that they were in a ConfigMgr Task Sequence and invoking specific logic. But because they actually weren’t in a Task Sequence the script was crashing. I checked the script on the affected machines and saw that the script was successfully creating the Microsoft.SMS.TSEnvironment<\/strong> COM object and therefore assuming a Task Sequence. On further investigation of the machines I found that they all had a left over C:\\_SMSTaskSequence<\/strong> folder on the C: drive and that during an OSD build they not finished cleanly (unrelated issue).<\/p>\n\n\n\n During a successful Task Sequence deployment a clean up task is run on completion. The smsts.log<\/strong> file shows certain folders and COM objects being unregistered, the log entries are as follows:<\/p>\n\n\n\n