Scripting

Colorado

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.

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.

Was there ever a solution to this? We're having the same issue. Thanks!

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!