Successfully unregistered Task Sequencing Environment COM Interface. The smsts.log file shows certain folders and COM objects being unregistered, the log entries are as follows: I checked the script on the affected machines and saw that the script was successfully creating the 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 folder on the C: drive and that during an OSD build they not finished cleanly (unrelated issue).ĭuring a successful Task Sequence deployment a clean up task is run on completion.
But because they actually weren’t in a Task Sequence the script was crashing. I checked the script logs on the affected machines and found that they were crashing because they were detecting that they were in an SCCM Task Sequence and invoking specific logic.
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. 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. This COM object is temporarily registered during Task Sequence execution, and then it is unregistered on completion. The most commonly used way to do this involves trying to create an instance of the COM object. The ProblemĪt times it’s useful for a script to detect if it is running from an SCCM Task Sequence so it can alter its behaviour accordingly. This post shows how a script can detect if it is running from inside an SCCM Task Sequence in a way that avoids false positives.
0 kommentar(er)
