Scripting Question

K1000 Scripting Problems

02/07/2014 7935 views

Hi all,

I submitted a ticket to KACE Support about this issue, but from my experience, as soon as they hear the word "script", they lose all motivation to help because they no longer help with script writing. That being said, I thought I would post the same problem here to see if anyone could help.

There seems to be a fundamental issue with how scripts are run. I have a computer imaging process that I have used for about a year and a half now without any issues. When we upgraded our KBOX to 5.5 and our agents to 5.5.25198, it all stopped working. I have narrowed it down to some change in how runkbot.exe and the agent work. I used to be able to call "runkbot 3 0" or "runkbot *script id* 0" without any issues. Now, it seems that either of those commands run in the context of the invoker regardless of the script being referenced. 

For example, I have an online script set to "Run as" our domain admin. With these updates, when I do either a "runkbot 3 0" or a "runkbot 72 0" parts of the script fail because I see "(output) Running as: testadmin" (which is the standard user logged into the machine) and get the "ERROR: Access is denied" message. 

Again, this is not an issue with my script. I know this because if I run the same "runkbot 72 0" command from an elevated command prompt, it runs without any issues. For some reason, the "Run as" feature of the online scripts no longer works for the runkbot.exe command. I have also tested this on multiple scripts and have gotten the same results.

0 Comments   [ + ] Show comments


All Answers


That sounds like a probable bug.  Support may not help with script writing, but they should at least be willing to help get a bug report filed on functionality that was present in older versions and is not now.

If you need it to run as local system, you may be able to use a "-s" in the command, or "runkbot -s 4 0" for example. 

Past that and depending on how you wrote the script, you may be able execute the command from a batch file and call the command using the run-as from the kscript.

Answered 02/07/2014 by: jknox
Red Belt

  • Thanks jknox. I usually do call runkbot from a batch file, but the script itself makes changes to system files, updates the registry, etc where it needs admin rights. For some reason, I have lost the ability to call the script from a local machine and have it run as an admin even though the script itself is set up as an online script with the admin credentials.

Here are steps to reproduce a bug I've encounted in 5.5 with scripting. You may or may not be experiencing this. Dell has acknowledged this bug and said it will be addressed in 6.0. 

1) Create an Offline Kscript, attach sample batch script and set task to launch batch file. Save script. Running script results in CMD window appearing, and the process is running as SYSTEM (verified in task manager) 
2) Go back into same script, set to Online Kscript, set to 'Run as user logged in to console' or 'Run as User' (and enter credentials), then resave. Running script this time produces no CMD window (is this also expected behavior?), but I can see CMD.exe process running as current user if I selected user logged in to console, or the process running as the user I specified if I selected that option, both visible in task manager. 
3) Go back into the same script, set back to Offline Kscript. The 'run as' area will collapse and not be settable. Save script then run again. Now the same thing happens - no cmd window and I can see the CMD process running as the current user or the user I specified earlier when it was an Online script. 
4) Go back into same script again, set back to Online Kscript. The run as area expands, and the Run As option I selected earlier is still selected, not 'Run As Local System'. Set back to 'Run as local system' and set back to Offline KScript and resave. The script then runs properly again as System. CMD window appears and process runs as SYSTEM. 

No schedule on this script. Happens when I run the script via Run Now tab, or within the script itself. This happens with multiple scripts I've tried it on so far and can easily recreate the issue every time.  

Answered 02/10/2014 by: SDNBTP
Third Degree Blue Belt

  • That sounds very similar and probably related to what I am seeing. The tech support agent I am working with said he thinks he knows what is happening and, if so, it is a known bug with the agent and will be fixed on the next release (in a few months). He had me gather a bunch of logs so that he could confirm.
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