That is normal behavior because the agent is 32-bit and that variable redirects based on the application calling it. More information here: en.wikipedia.org/.../%25SYSTEMROOT%25

Hope this helps.

You can "Execute shell command" using a 64bit shell, just check the box in the procedure step.  This may solve your issue.

Aside from that, for using "test file" step, you may need to IF a "windows 32 or 64 bit check" first, then test file accordingly.

Thanks for your input guys

@SMason

Assuming that the OS has been installed to the C Partition, on 64bit machines the %programfiles% variable should redirect to C:\Program Files and %programfiles(x64)% should redirect to C:\Program Files (x64). To test this simply type these variables into the search box on a Windows 7 32bit and 64 bit machines and see what folders open. You can also view these variables using the SET command from a CMD window.

edit: I agree with you that its the 32-bit Kaseya agent getting this wrong...but I don't believe this should be the expected behaviour. I have submitted a bug to Kaseya.

@Dan

Unfortunately there is no 'using 64bit shell' when doing an IF --> TEST FILE check within Kaseya.

I am already using an IF --> Windows 32 or 64 bit Check prior to running the IF --> TEST FILE check. I have attached the script.

Thanks

Josh

Your test is not accurate because it is calling the variable with a 64-bit command prompt.

You should be testing with C:\WINDOWS\SysWow64\cmd.exe to get a 32-bit command prompt. Then try "echo %PROGRAMFILES%"

Ahhh...you are correct!

So there may in fact be nothing that Kaseya can do in regards to this? Unless I ask them to put a '64bit checkbox option' for the IF --> TEST FILE option?

In the meantime...I will recode using a 64/32 check...then use the %ProgramW6432% variable where needed.

Many thanks for your help.

Josh

Yes, Kaseya still has a lot of work to do. As long as you understand the concepts, you should be able to find ways to work around Kaseya's shortcomings.