Hi - i am using VisualCron on a trial. I have a *.vbs file i am trying to run. It fails despite having the correct credentials. I have tried: EXECUTE SCRIPT - I have also tried running as a *.bat file under EXECUTE SCRIPT. Have also tried EXECUTE (using Command: wscript.exe, Argumemts: "<file path><filename>" ). Have also tried running as a batch file.

All without success. I know my *.vbs and *.bat files work perfectly. At least they do outside VisualCron. I have spent hours trying to work this out. Looking at other posts on this issue and following the advice has not helped, it seems to be a fairly common issue. I am starting to think this software is not worth it....Any help will be much appreciated. Thanks.🤬

What does the script do exactly?

Is it trying to access file from a network share?

---

Also, have you looked at the output (is there any output in the output column?)?

---

Hi - Nothing in the OUTPUT column.

What i am trying to do is run an exe file with the inifile.txt argument.
This works well under Windows SBS2003 standard Task Scheduler - with limitations VisualCron will address with the trigger and looping mentioned below.

"D:\Enterprise19\PSL Strip Application\myobimportexport.exe" inifile.txt

It requires specific credentials to run.

The exe file imports data from a Network Share and imports / exports to MYOB AccountRight Enterprise 19. The import/export is designed around MYOB's ODBC link.

The contents of the inifile.txt are:

D:\Enterprise19\AccountRight Enterprise 19\City Aerials Limited.MYO
D:\Enterprise19\PSL Strip Application\616038192957.key
\\Strip\strip\toMYOB_prod
\\Strip\strip\fromMYOB_prod
{MYONZ0901}
D:\Enterprise19\Myobp.exe

What i am trying to achieve is running this based on a trigger of MYOBP.exe closing. That much i have achieved. What i would like to do is have VisualCron loop back and run the exe 10 times (I haven't achieved that yet).However, the import / export fails with the "Non Zero Exit Code"

Have you set a Credential in VisualCron - you probably need to set one that has access to \\strip\

---

Yes - credential is correct. Same as what is was under Windows Task Scheduler. "D:\Enterprise19\PSL Strip Application\myobimportexport.exe" inifile.txt runs with a specific credential. I am using that credential with VisualCron.

I have also set up another job using a vbs script (EXECUTE) running under the same credentials as what i am trying to do here. The other job successfully copies files from the same shared path.

Could you remove line by line so you see exactly which line is failing and post it here?

---

Nothing i can remove from the script below - anything removed, the script will fail.

This is the script: PSL.vbs:

with createobject("wscript.shell")
.run """D:\Enterprise19\PSL Strip Application\myobimportexport.exe"" inifile.txt", 0, true

PSL.vbs runs the myobimportexport.exe file with the inifile.txt argument (shown earlier)

As mentioned, the script runs perfectly outside of VisualCron.

Try checking "Use shell execute" and run it.

---

No change. Any chance of setting up a remote support session?

Yes, install TeamViewer and send an email with connect information to support@visualcron.com

---

Hi - i have sorted out this problem. Yes - it came down to Credentials. I was configuring the job under a user with complete Administrator privileges and all necessary access rights. As a last resort, I completely removed the job (and associated Tasks). Then logged into the server as administrator. Set the Job and Tasks up again - expecting the Job & Tasks to fail because of the specific credentials required. However, it worked....! I don't know why this worked but it obviously has something to do with how VisualCron runs...

Thank you very much for your assistance with this 'frustrating process - very much appreciate your prompt replies.😁

I found that if the task (VC) was created before the admin user (windows user) was created it would not work.

If the task is created from scratch after the admin user was created it works fine.

So none of the task can be changed to use the credentials of the admin user, unless those task were created after the user.

Not sure if that makes since. Just the pattern I noticed to get the task working.