OK, here's a really weird one: Windows 7 has an environment variable %PUBLIC% that evaluates to C:\Users\Public. (Why do I care? because the Windows 7 "all users" desktop is %PUBLIC%\Desktop, where I want to put a shortcut.)

In a test Kscript, this step in On Success:
Launch "$(KBOX_SYS_DIR)\cmd.exe" with params "/c echo PUBLIC is: %PUBLIC%"
writes to the output log:
PUBLIC is: C:\Users\Public
So far, so good.

In another Kscript, these steps:
Verify that the file "%PUBLIC%\Desktop\someLink.lnk" exists.
Launch "$(KBOX_SYS_DIR)\cmd.exe" with params "/c if exist "%PUBLIC%\Desktop\*.*" run-a-program "%PUBLIC%""
write to the activity and output logs:
Checking if file exists: C:\ProgramData\Desktop\someLink.lnk
File does not exist: C:\ProgramData\Desktop\someLink.lnk
Launching program: C:\Windows\system32\cmd.exe /c if exist "C:\ProgramData\Desktop\*.*" run-a-program "C:\ProgramData""

Don't get hung up in the details; what I want you to see is that %PUBLIC% evaluated to C:\Users\Public in the test script (as expected), but it evaluated to C:\ProgramData in the other script. Both scripts are set to Run As Local System, and both Allow Run While Logged Off. I tried moving the steps among the Verify, Remediation, and Success sections, but it made no difference.

Now you may say, the Kscript steps "Verify a file exists" and "Launch a program" do not support the use of Windows environment variables. (Yes, that's what the documentation says, but in my experience they do. Still, it doesn't matter:) But in that last "Launch a program" step, I'm not asking the Kscript to evaluate %PUBLIC%; I'm asking cmd.exe to evaluate that variable, just like I did in the test script!

Anybody have any ideas why this environment variable evaluates incorrectly in the second script? Have I found a bug? Is there a workaround, without hard-coding C:\Users\Public? Sande
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


You sure there aren't typos? Can you give us a screenshot of the task?
Answered 01/31/2011 by: airwolf
Tenth Degree Black Belt

Please log in to comment
Worse and worse, in terms of predictability:

I noticed in the second script that I was using an earlier task set to "On Failure: Break", when I really wanted to Continue.

When I changed that earlier task to "On Failure: Continue", then this later task that uses %PUBLIC% began to evaluate correctly!

Moral of the story: In any Kscript task that uses %PUBLIC%, add a step to echo %PUBLIC% to the logs, so you can see if it evaluated correctly or not.

Possible moral of the story: Don't use Windows environment variables after "On Failure: Break".

I hit glitches like this at least once a week. If it weren't for these glitches, I'd like the KBOX 1000 just fine.
Answered 01/31/2011 by: snissen
Fourth Degree Green Belt

Please log in to comment
It's not a glitch when KACE tells you it's unsupported. I'm glad you figured this out though; it could come in handy for someone later.
Answered 01/31/2011 by: airwolf
Tenth Degree Black Belt

Please log in to comment