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
Verify that the file "%PUBLIC%\Desktop\someLink.lnk" exists.
Remediation:
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   [ + ] Show Comments

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.

Answers

0
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
0
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
0
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
Answer this question or Comment on this question for clarity