Run .vbs from Task Scheduler. VBS should execute an .exe via shell

Question

I would not be posting if I had tried the plethora of possible solutions that have been posted about this previously.

I have developed a piece of software, which using a .vbs file (exporter.vbs) executes an .exe from another piece of software (reporter.exe), which is installed on the client machine.

Use Case Scenarios

Running the exporter.vbs manually (right click and open) works perfectly, exactly as expected. When run on my own machine via Task Scheduler as my own windows user, it works perfectly, exactly as expected.

When run on a clients Windows Server 2008/2012 box manually it works perfectly, exactly as expected. When run via the Task Scheduler as any user (Excluding Administrators group), the Task Scheduler reports back as 0x0, however the reporter.exe has not generated the files as expected.

When run on a clients Windows Server 2008/2012 box via Task Scheduler running as the user Administrators, it works, however overnight (when our task is set to run), it does not run.

Scheduled Task Setup - General

Scheduled Task Setup - Actions

The Scripts

In the scenarios above, the exporter.vbs appears to be tripping up at this stage of the script as the other parts of the script are running (the other part of the script empties the target XML files).

Function Export(filepath, report)
    dim fso
    set fso_tidy = CreateObject("Scripting.FileSystemObject")

    if fso_tidy.FileExists(filepath)=true then

        set fso_tidy = nothing

        set oShell = CreateObject("WScript.Shell")
        oShell.Run """"&simsdir&"\CommandReporter.exe"" /QUIET /user="""&simsu&""" /password="""&simsp&""" /REPORT:"""&report&" v"&rptv&""" /OUTPUT:"""&filepath&"""", 0, true

        set oShell = nothing

        set fso_tidy = CreateObject("Scripting.FileSystemObject")
        set objFile = fso_tidy.GetFile(filepath)

        if objFile.size > 64 then
            size = round(objFile.size / 1024, 1)
            WriteToLog "DATA", "(OK) "&report&" EXPORTED (size: "&size&"kb)"
        else
            WriteToLog "DATA", "(FAILED) "&report&" EXPORTED (size: "&size&"kb)"
        end if

        set objFile = nothing

    end if

    set fso_tidy = nothing
end Function

This function is called 5 times, one time for each report we need to export data from the Software.

What has already been tried

• Full user permissions on the my software's folder
• Tried running as every user, whether it be local or domain level on the client server
• Tried running the vbs using cscript.exe

Is there something I am missing in terms of how vbs need to be run from Task Scheduler if they manipulate files etc

Solution

You have the task set to run in the context of the Local System account. The System account is not a full-blown interactive user, so not everything will run in that context. You must keep the following considerations in mind when using it for tasks:

• Local System presents your computer account credentials to the network (i.e. COMPUTERNAME$), so if filepath is on the a network share, the local computer account must have permissions to it specifically (or the Everyone group).
• Local System does not have a user profile (technically it does but there's nothing in it). Anything that refers to a per-user registry setting or filesystem location will likely fail.
• Processes running as Local System cannot interact with the user, so if your script pops a dialog, the user won't see it.

Try running your task as a bona-fide local or domain account instead of the System account. You'll of course need to embed the password into the task for that to work.

Comments

[JosefZ]

in Action: either provide fully qualified path to your script, e.g. C:\scripts\exporter.vbs, or provide C:\Windows\System32\cscript.exe in program/script field and C:\scripts\exporter.vbs in argument field.

[itsphilz]

@JosefZ have tried that unfortunately and it doesn't work either.

[Syberdoor]

One thing that comes to mind is the working directory. Did you set that in the scheduled task? That field is called "Start in (optional)" in the scheduled task.

[itsphilz]

@Syberdoor yes tried that unfortunately.