Thanks, I wonder if putting in the script an action to change the timeout in the client’s WMI would work, policy would likely set it back but if it worked for the time that script runs…?
From: [email protected] [mailto:[email protected]] On Behalf Of Sherry Kissinger Sent: Wednesday, May 13, 2015 2:09 PM To: [email protected] Subject: Re: [mssms] Troubleshooting Configuration Baseline failures Oh, a timeout. That means that whatever it is you might be trying to do in that script... is running longer than the default timeout value. It's not a visible setting... and the link below is of course, technically unsupported... but if you WANTED to change that to something higher... Personally I wouldn't go crazy up to 10 minutes like this person did in their example. the default is 60 seconds. Maybe change it to 90, wait and see if that's "good enough", then 120; until the diminishing returns means you should stop tweaking it. 10 minutes, IMO, means some other thing in queue on a box might wait for 10 minutes for a timeout before moving to the next thing. You might introduce way more issues than you anticipate by just "let's just increase the timeout to 10 minutes". Esp. if you set this... and then a year from now wonder "why are there significant delays when..." on clients. Be careful with messing with defaults, esp. sorta kinda hidden ones like this. 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.aspx<https://urldefense.proofpoint.com/v2/url?u=http-3A__blogs.msdn.com_b_fei-5Fxias-5Fblog_archive_2013_10_21_system-2Dcenter-2D2012-2Dconfigmgr-2Dusing-2Dvbs-2Dto-2Dextend-2Dthe-2Ddcm-2Dscript-2Dexecution-2Dtimeout-2Dvalue.aspx&d=AwMFaQ&c=aLnS6P8Ng0zSNhCF04OWImQ_He2L69sNWG3PbxeyieE&r=pQGVi_ygWZb0EWR_EeMFzgKJCQ8AFTQI7Ck6iiIPItI&m=ImPNEzlX8rgIZOVGM9CaBNYBLzLkXcvPR0tSkY-X5ZU&s=mbbM-86AEzsTqCQjnxWvHLNVHC_cXjCjR_y3R_l2TuI&e=> On Wednesday, May 13, 2015 12:04 PM, "Krueger, Jeff" <[email protected]<mailto:[email protected]>> wrote: It’s sitting at about a 8-10% failure rate, I’ve tweaked the script to set the error action preference to silently continue, and I think that has helped. But digging into the client logs on some of the ones that have failed is not showing me very much, I may be looking in the wrong place. The info that comes back from the deployment under the monitoring node is a little more helpful, but the numbers are not adding up. Right now I’m seeing about 232 failures in the Assets and Compliance node, but the deployment shows 170 total errors… [cid:[email protected]] Where on the client would I be able to see the script execution timeout? And is there a setting that limits how long a discovery script can run for? Thanks! From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Sherry Kissinger Sent: Wednesday, May 13, 2015 12:46 PM To: [email protected]<mailto:[email protected]> Subject: Re: [mssms] Troubleshooting Configuration Baseline failures More details are needed (by me anyway). Is this baseline deployed to hundreds/thousands, and < 1% failure? or 99% failure? if <1% failure, then I would suspect something on the client--maybe .net is messed up, and it can't figure out how to interpret something. Or policy is out of whack, and needs a policy reset. Or something I've yet to encounter. There was even one time I spent forever trying to figure out what it was...only to find out the machine was having all kinds of issues; and was slated to be reimaged. If 99% failure, then I'd assume something was inherently wrong with the baseline itself On Wednesday, May 13, 2015 11:31 AM, "Krueger, Jeff" <[email protected]<mailto:[email protected]>> wrote: Haven’t been able to find much on troubleshooting Configuration Baseline failures. I have a baseline setup with a discovery script that runs well on most machines but it is reporting about 200-300 machines (it fluctuates) as failed. Looking at some of them and pulling up the logs I see the following In DCMReporting.log : Conformant Rule: ******_Baseline_f11b8413_5f8f_4871_bf75_e487c928d848_1_Configuration_PolicyDocument not found No ConfigPoints found for rule:System Center Configuration Manager.ScopeId_****_Baseline_f11b8413_5f8f_4871_bf75_e487c928d848_Configuration_PolicyDocument.1.5****__ScopeId_****_Baseline_f11b8413_5f8f_4871_bf75_e487c928d848_1_Configuration_PolicyDocument Jeff Krueger [email protected]<mailto:[email protected]> Solutions Design Team IT - Henry Ford Health System 248.853.4466 ________________________________ CONFIDENTIALITY NOTICE: This email contains information from the sender that may be CONFIDENTIAL, LEGALLY PRIVILEGED, PROPRIETARY or otherwise protected from disclosure. This email is intended for use only by the person or entity to whom it is addressed. If you are not the intended recipient, any use, disclosure, copying, distribution, printing, or any action taken in reliance on the contents of this email, is strictly prohibited. If you received this email in error, please contact the sending party by reply email, delete the email from your computer system and shred any paper copies. Note to Patients: There are a number of risks you should consider before using e-mail to communicate with us. See our Privacy & Security page on www.henryford.com<http://www.henryford.com/> for more detailed information as well as information concerning MyChart, our new patient portal. If you do not believe that our policy gives you the privacy and security protection you need, do not send e-mail or Internet communications to us.
