I created a script.
The script does get copied to the local computer
The script does not run, through Kace.
When I manually run the script - in the Kace folder, it runs and works as intended.
So, the script gets copied to the Kace folder on the local PC, but doesn't run unattended. I have to manually run it. What the Hell are we doing wrong?

0 Comments   [ - ] Hide Comments


Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
Answer this question or Comment on this question for clarity


I'm assuming this is K1000? Can you copy/paste the script, maybe a screenshot of what you have so that we can see it?
Otherwise I would call in to support so that they can do a webex with you and get you situated.
Answered 07/15/2011 by: cserrins
Red Belt

Please log in to comment
Was there ever a solution to this? We're having the same issue. Thanks!
Answered 09/07/2011 by: Colorado
Senior Yellow Belt

Please log in to comment

Change the script from an offline script to an online script, but choose run as user logged into the console - dont actually enter crendentials.

Then run the script an let me know if it work correctly. Either way let me know how it works out. Depending on if it works, I'll tell you what I have found in my testing of multiple issues with the newest release of the 5.3 server update.
Answered 09/07/2011 by: isolinear
Orange Belt

Please log in to comment
Our users don't have admin rights so the script can't be run as the logged on user. But yes, that would have solved all of my problems! I was able to fix it once I found out what was going on. As best I can tell, it worked when I ran it locally because I was using the 64-bit version of wscript.exe. So, when my script was looking for a file in c:\windows\system32, it really looked there. When KACE executed wscript.exe, it was the 32-bit version and Windows x64 has a built in/hidden redirect that sends 32-bit apps to c:\windows\syswow64 when they request c:\windows\system32. That makes perfect sense, right? 64-bit apps look in system32 & 32-bit apps look in syswow64!?!?! Anyway, there's a workaround. If you use %windir%\sysnative instead c:\windows\system32, it lets the 32-bit app peek into c:\windows\system32. Using that, I was able to use the built in "verify the file "%windir%\Sysnative\xxxx.xxx" exists and KACE looked in c:\windows\system32 instead of c:\windows\syswow64. Hopefully that makes sense. It'll be nice when a 64-bit KACE client is released!
Answered 09/08/2011 by: Colorado
Senior Yellow Belt

Please log in to comment