This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(195.2, 86%, 28%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ESB%3C/text%3E%3C/svg%3E)
I have a driver app that uses Powershell script detection and just occasionally, the script over-runs the 60s default, causing the upgrade to fail. There are a number of 'solutions' to this such as those at the bottom of this question but I have been unable to find a way to change the default on a client during the course of a task sequence. I suspect this is partly due to the fact that CCMExec is in the provisioned state during this time and the full WMI 'featureset' is unavailable. Certainly one is unable to query or set this value with Powershell as far as I can tell.
However, if you run up a WBEMTest session during a task sequence, then connect to the namespace and enumerate all classes you ARE able to find the class and the Script Timeout property. If you then change the property and save the object then it is possible to change the value.
So my question is, given that it appears possible to change the value using WBEMTest, why is it not possible (to my knowledge at least) to do this via the command line? I would point out that the installed SCCM client also fails to inherit the site settings for this if you happen to have changed the ScriptExecutionTimeout property there.
Server Side:
https://learn.microsoft.com/en-gb/archive/blogs/fei_xias_blog/system-center-2012-configmgr-using-vbs-to-extend-the-dcm-script-execution-timeout-value
Client Side:
Set-WmiInstance -Path "root\ccm\policy\machine\actualconfig:CCM_ConfigurationManagementClientConfig.SiteSettingsKey=1" -Arguments @{ScriptExecutionTimeOut=400}
why is it not possible (to my knowledge at least) to do this via the command line?
Can you be more specific on what exactly doesn't work here? What do you mean by command-line and what exactly fails when trying with this method?
Hi Jason, thanks for replying. Some examples: If I hit F8 during the task sequence and run: gwmi -namespace root\ccmpolicy\machine\requestedconfig -query "Select * From CCM_ConfigurationManagementClientConfig" then this returns nothing, whereas with a 'full' client this returns data including the ScriptExecutionTimeout value and other settings below. Similarly, if I were to run: Set-WmiInstance -Path "root\ccm\policy\machine\actualconfig:CCM_ConfigurationManagementClientConfig" -Arguments @{ScriptExecutionTimeOut=400} then this returns 'Illegal null value' error. Note I don't include the '.sitesettingskey=1' here as this value is indeed null when the CM client is in provisioning mode, as can be shown if you run WBEMTest in provisioning mode, see attached screenshot and mof values below: class CCM_ConfigurationManagementClientConfig : CCM_ComponentClientConfig { [realkey] uint32 SiteSettingsKey; uint32 PerProviderTimeOut; uint32 ScriptExecutionTimeOut = 60; uint32 PerScanTimeout; uint32 PerScanTTL; boolean EnableUserStateManagement = FALSE; string Reserved1 = ""; string Reserved2 = ""; string Reserved3 = ""; }; As you can also see, the ScriptTimeOut value is actually present though. In WBEMTest, if I change this value, hit Save Property then Save Object then the value is indeed changed and sticks. I just don't know how to change that property via Powershell or any other commandline way from within a task sequence. Note, the mof values above are the default whereas I have manually changed the ScriptTimeout Value to 340 in the attached image via WBEMTest (other values remain the same). Hope this is a little clearer! Thanks /api/attachments/138020-wbemtest-prov.png?platform=QnA
Your first line of code above uses requestedconfig and your second uses actualconfig. Those are two different namespaces that are used for two separate purposes. You sshould be adjusting actualconfig within the TS just like you would on a standard client system.
Yes, sorry, that was my mistake copying and pasting the wrong line of code. You're absolutely right, it should be ActualConfig. I was messing around trying different things and pasted the wrong line into the question. Doesn't help anyone :-/
In any case, when I have tried this, I have only tried it with ActualConfig, and the problem remains.
Doing this via WBemTest or PowerShell is identical though. Perhaps try Set-CIMInstance instead of Set-WimInstance as Set-Wim and Get-Wim are deprecated and work slightly different.
I agree it should but unfortunately it doesn't. I have also just tried with Set-CIMInstance and in this case it's working in the same way as Set-WMIInstance and will not change the information I need.
Tinkering around further, I was able to to use these commands to update the ScriptExecutionTimeOut value but for this to work I had to change SiteSettingsKey to '1' (from null). This would be fine except that the only way to do this was again through WBEMTest, saving the object, so back to square one. Maybe there is some way to recreate this action from outside WBEMTest, but I can't seem to find it.
Even if I was able to change the SiteSettingsKey to 1, I am not sure if this would have any knock-on effect to the health of the CM client. I haven't noticed any in my testing but not sure if I'd be confident of changing this large-scale.
Have you tried setting/resetting all of the values that currently have a value in your command instead of just that single value? Per your MOF, there are a total of five attributes with values.
Sorry for the break, had to get on with some other work...
Just like ScriptExecutionTimeOut I can change other values, providing I add 'SiteSettingsKey=x' to the query, eg
Set-WmiInstance -Path "root\ccm\policy\machine\actualconfig:CCM_ConfigurationManagementClientConfig" -Arguments @{SiteSettingsKey=1; ScriptExecutionTimeOut=400}
Set-WmiInstance -Path "root\ccm\policy\machine\actualconfig:CCM_ConfigurationManagementClientConfig" -Arguments @{SiteSettingsKey=2; PerProviderTimeOut=300}
The above both 'work' and don't give an error but if I run up a WBEMTest session in that namespace/class, SiteSettingsKey always equals NULL. From what I can see there doesn't appear to be a way to fix this problem on a client in provisioning mode. Open to any other ideas though!
BTW when SiteSettingsKey = NULL you are unable to query the class (but you are able to enumerate it in WBEMTEST). You can only query the class if the value is 1 from what I can see.
Hello anonymous user
There is a Technet discussion which might be helpful for you. It is a bit old but provides some of a workaround:
How to increase script execution timeout for compliance settings scripts
-------
--If the reply is helpful, please Upvote and Accept as answer--
Thanks and yes I have seen that forum question already. That's for when you wish to set the timeout value at the site level. I have tried this but unfortunately it doesn't pass the value to the the client during the task sequence. I'm 95% sure this is due to the fact the client is in provisioning mode and doesn't pick up policy from the site at this point.