You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We've come across an issue in our environment where several Windows 10 devices were failing to run the CMCH script. Upon investigating, it was found that the script (executed daily via a Scheduled Task) would run, but would abort with the error:
Configuration Manager Task Sequence detected on computer. Exiting script
If we manually run the code $tsenv = New-Object -COMObject Microsoft.SMS.TSEnvironment we can verify that the $tsenv variable indeed exists, however, none of these machines have a Task Sequence running, nor have one deployed to it.
The issue appears to be caused due to leftover or orphaned TSEnvironment COM registrations (which we suspect stemmed from the OS Upgrade we did last year), as a result, the COM object is always available to be instantiated even when there's no TS running.
Note that uninstalling and reinstalling the client does NOT get rid of the orphaned COM registrations, the only way to remove the leftovers is by deleting the relevant CLSID regkeys.Regasm.exe /u might also help, but I haven't tested this yet.
Whilst it would possible to manually de-register the COM object by deleting certain CLSID registry entries as part of the script, a simple workaround would be to ignore the COM object and simply check whether any of the known Task Sequence processes are active.
Therefore, I propose that we replace this piece of code:
if (Get-Process -Name TSMBootStrap,TSManager,TsProgressUI,TSInstallSWUpdate -ErrorAction SilentlyContinue) {
Furthermore, I reckon we should add more executables to this list to detect scenarios where it would be undesirable to have CMCH running in the background, for example: Setup, SetupHost,mighost,TiWorker, DISM,DismHost, WindowsUpdateBox,WUSA, ccmsetup, ccmrepair etc. This will prevent CMCH from running in case there are any Windows / ConfigMgr upgrades etc taking place.
The text was updated successfully, but these errors were encountered:
We've come across an issue in our environment where several Windows 10 devices were failing to run the CMCH script. Upon investigating, it was found that the script (executed daily via a Scheduled Task) would run, but would abort with the error:
If we manually run the code
$tsenv = New-Object -COMObject Microsoft.SMS.TSEnvironment
we can verify that the $tsenv variable indeed exists, however, none of these machines have a Task Sequence running, nor have one deployed to it.The issue appears to be caused due to leftover or orphaned TSEnvironment COM registrations (which we suspect stemmed from the OS Upgrade we did last year), as a result, the COM object is always available to be instantiated even when there's no TS running.
Note that uninstalling and reinstalling the client does NOT get rid of the orphaned COM registrations, the only way to remove the leftovers is by deleting the relevant CLSID regkeys.
Regasm.exe /u
might also help, but I haven't tested this yet.Whilst it would possible to manually de-register the COM object by deleting certain CLSID registry entries as part of the script, a simple workaround would be to ignore the COM object and simply check whether any of the known Task Sequence processes are active.
Therefore, I propose that we replace this piece of code:
With this:
Furthermore, I reckon we should add more executables to this list to detect scenarios where it would be undesirable to have CMCH running in the background, for example:
Setup
,SetupHost
,mighost
,TiWorker
,DISM
,DismHost
,WindowsUpdateBox
,WUSA
,ccmsetup
,ccmrepair
etc. This will prevent CMCH from running in case there are any Windows / ConfigMgr upgrades etc taking place.The text was updated successfully, but these errors were encountered: