we have; but not to 20 minutes. we changed it to about 4 minutes (default was
60 seconds I believe ??). What we changed it for wasn't DCM per se...
application detection scripts use the same engine, and for one particular line
of business, their 'default' script they used to detect an app installed or not
was timing out... sometimes. So because that particular LOB carries a big
stick here; we upped it, just for them, really. You need to have a balance
between upping that time out; and keeping it short enough so that when multiple
things are trying to run or install you don't delay other things triggering on
a client--because the client is waiting forever for the timeout on some
badly-written script. since that's a global setting, for anything DCM-like;
you need to be a bit cautious about it.
When I ran into something similar--what I wanted to do originally was "just a
script" and I wanted to just run it in a ConfigItem; and it was just taking too
long. So I ended going back to leveraging a Task Sequence with some fancy
logic on each step for whether or not to 'trigger remediation'. It was still
"just a script"; but Task items in a Task Sequence can have super long timeouts.
On Thursday, June 25, 2015 12:35 PM, April Cook <[email protected]> wrote:
We have a remediation script that is being tested, but it fails on 3 out of 4
with the following:
Enforcement Error 0x87d00321 The script execution has timed out. CCM
Basically the plan is to kick off a SEP repair, wait 20 minutes, and then check
for the service again. Even without the sleep timer we run into the same issue.
Would we even need to check for the service again afterward?
I cam across this link that talks about running a script to modify the timeout
value -
http://blogs.msdn.com/b/fei_xias_blog/archive/2013/10/21/system-center-2012-configmgr-using-vbs-to-extend-the-dcm-script-execution-timeout-value.aspxHas
anyone done this? Is there another way ? Any other thoughts?
