KACE Product Support Question

Why do some scripts "succeed" but fail to run?

12/19/2014 2897 views
I'm referring specifically to running batch files from the task section of a script.  I have an install script that is really just a small batch file and it keeps failing even when it shows as a success.

I'm having some K1000 scripting issues where the script will push the dependencies, but then fail to run them and still count it as a "run success."

Here's what I've done so far.  First, I broke the single batch file up into separate files to segregate the commands and make sure they weren't tripping over each other.  In the very first one, I put a few taskkill lines to end the processes of the application I'm trying to update.  If I select "wait for completion" on this one then the script just fails outright and logs it as a run failure and, from what I can tell, rarely actually runs that batch file.  I specifically routed the standard out and error to a text file for each line to see if it ran.  Sometimes it does, sometimes it doesn't.  But the script will never succeed if I mark any of the batch files as "wait for completion."

So the alternative is to not do that, which usually results in kbox copying over all the dependencies and then marking it as a run success without running any/all of the dependencies.

This is all done as the local system account.  None of the batch files are trying to touch anything but the local machine.  For the life of me, I cannot figure out why they often fail to even run.
Answer Summary:
2 Comments   [ + ] Show comments


  • The problem anyone reading this posting faces, is that you have not posted the actual batch files and therefore there is nothing for us to go on when it comes to checking for errors or simple things like not specifying full paths to any executable you are trying to run.
    The other thing I would add is that batch script is really not suited to any process where you want accurate error reporting. If your batch file completes then it will always return success regardless of whether any of the calls in the batch file returned an error, as the call itself has been successful. If you use VBScript, then you can more easily test each and every call to an external process for a specific return code.
    Finally, you also don't mention what your target operating system is. This is where a copy of XP or XP64 can prove useful, as you can run stuff as system from a command line opened using the AT scheduler, and XP still supports interaction with desktop if you use the /interactive switch on the AT scheduler call to cmd.exe. This then allows you to see any error messages that your script throws up, which is unfortunately not possible for localsystem calls on Windows 7.
  • I've noticed similar behavior on my K1000. I don't remember exactly where I read it but I recall finding something that stated that as long as the files made it to the client and they were "executed" (meaning the agent called your .bat file) then it returns as a successful run. But as you stated, there is no way of knowing based purely on the status returned by the agent.

    In my case, the batch was trying to access network resources and because I was running as local system it wasn't working (doh!). So running as a domain user worked.

    If you made sure the batch works normally (by double clicking) then I suppose it could still be a permissions issue. To determine if it is indeed a permissions issue you might try running the batch normally (by double clicking) except logged in as a user with non-admin permissions. Then again with admin permissions. See if that makes a difference.

    Let us know!

All Answers

getElementBytd is exactly right. As long as the package is delivered to the client, the K1000 considers the action successful.  The trouble-shooting steps are spot on.

Mary Scherich
KACE Technical Support
Answered 12/23/2014 by: KACE_Mary
Red Belt

Don't be a Stranger!

Sign up today to participate, stay informed, earn points and establish a reputation for yourself!

Sign up! or login


This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ