We have quite a few scripts setup on our K1000 that, for various reasons, need to run as the user currently logged into the PC.

Since the 5.4 SP1 patch, its just stopped working.

When you run a script against a PC on the K1000 the script just sits there running and never ends or does complete "successfully" but just skips over the task that has the need to run as the logged in user.

I did some further investigating and it appears that in the patch they have modified the permissions on the downloads, scripts and kbots_cache folders in C:\ProgramData\Dell\KACE\ (and possibly others) so that the local Users group no longer has write permissions to these folders.
If you try to re-add the permission it appears the K1000 Agent (or something else) simply changes it back.
We even created a Group Policy to change the permissions but this only works 50% of the time as it gets changed back.

So why is this a problem? When you run a script as the logged in user everything the KACE agent does on the local PC is run as the currently logged in user (as with most companies our users dont have local admin rights) including the XML file into kbots_cache (what appears to the be the file that tells the KACE agent what to do) and the actual files that you need to run (normally in the downloads folder) as such the scripts fails with an access denied error as the user doesnt have rights to write to these folders.

Turning on the debug function in the KACE Agent shows exactly that, heres an error from the runkbot.log file:

[Mon Mar 25 09:21:57 2013] Kbot [157-1364174506r4] not found locally, downloading ...

[Mon Mar 25 09:21:57 2013] DownloadFile: unable to create destination file: C:\ProgramData\Dell\KACE\kbots_cache\157-1364174506r4.xml.part Error: Permission denied 

[Mon Mar 25 09:21:57 2013] FetchAndWriteToCache: Kbot[157-1364174506r4] Download failed, error code = 99

Now correct me if I'm wrong, but doesnt this defeat the purpose of the "Run as user logged into Console" option?

The offical response from our local country KACE support is that the way it works now "is a bug fix".

Has anyone else come accross this issue?

Thanks,

Nicholas

0 Comments   [ + ] Show Comments

Comments

Please log in to comment

Community Chosen Answer

2

it may be due to a fix they did or may have to due, but we have noticed app #279 in our kbox cache, cannot find on server, contains an ACL fix from dell\kace.

 

Answered 04/23/2013 by: SMal.tmcc
Red Belt

Please log in to comment

Answers

1

Hi SMal.tmmc,

Thanks for your answer, you pointed me in the right direction.

I had a look through the KBOTS table on the K1000 and found this kbot marked as "system" and appears to have been added by the 5.4 SP1 update.

It looks like when a kbot is marked as "system" its hidden from the listing in "Scripting" > "Scripts".

But if you specify the KBOT number (155 in our case) in the URL so it was: http://k1000/adminui/kbot.php?ID=155, which let me make changes to the KBOT.

The batch file in your screenshot is called "lockdown.bat" in the script, I changed the "Users:R" to "Users:C" on each of the lines.

It also appears this KBOT is configured to run at inventory, a force inventory on one of our workstations showed the write permissions for users now applied to these folders.

Not a very nice fix and it would be great to know why the KACE team made these changes that essentially made part of the scripting module useless.

I hope this helps anyone else thats come up against this problem.

Thanks,

Nicholas

Answered 04/30/2013 by: nwhyatt
Senior White Belt

  • You should post these findings as a blog.
  • This issue still exists in version 6.0
    • I do not have that problem at all with 6.0, I would contact support if you are having rights issues. With 6.0 they gave the user rights to C:\ProgramData\Dell\KACE\user. I run my user based scripts to gather infomation and have them dump the txt files they create there. My Custom Software Inventories then find and read those files just fine.
      • SMAl.tmcc,

        You're so dand right:C:\ProgramData\Dell\KACE\user works like a charm! I was having an issue where like 50% of computers received access denied to the root of their C drive... This was a solution, but appartment there is a larger underlying problem, but that is for me to worry not you!
      • I am having same issue with 6.4...runs as system instead of logged in user but does work on some.
Please log in to comment
Answer this question or Comment on this question for clarity