Hi Will,

If you are running modscript via the Run Script in scheduler as shown:

Then you will need to write your output to the Shell.Outputs() instead of using "Ext.Writestream". I use the following code when I may be running code from either a url or via the scheduler to write output:

if (Shell.Context() == "runmodscript-SOAP") {
    Shell.Outputs().push_back(Pair("jsonResult", out.to_json()));
} else if(Shell.Context() == "URL") {
    Ext.WriteStream(out.to_json());
}

You will be able to see this output under the scheduled tasks. You can use this option to write out any error messages, which should allow you to debug the problem with your server:

Michael

With Michael's approach, you can also set Shell.RedoMessage() = 'your error message' - this will result in Last Execution Status of Error

Well, those ideas are great but I commented out every "Ext.Writestream" so the output issue should be inert. The script checks IP addresses by writing out to the command line. It creates a file. Then it kicks off Powershell which pings the ipaddresses in the file and copies the results to a file. Then the script reads the powershell output and searches the content for the word "down". It's loosely based off of the search sample in the modscript doc. Could it be that the lines with Ext prefixes, like: "Powershell_results_var = Ext.ReadTextFile( "C:\\powershll\\output.txt" ); " are causing the problem? The scheduler shows that the script execution was a success, yet no results are present in the item records. Yet, the script works when invoked from the browser.

I would guess that line is a problem, something to do with permissions for the user that the script is running under. I would verify that the user/script has access to that directory,

I'm sure you know to check the server's Application Event Log ....

Here's my notes on AppScript "Ext.cmdLineWait".  These observations may be version-dependent:

When script is run in URL context, it's run by "tmtrack.dll"; when script is run in Notification context, it's run by "gsoap".

For URL context, CmdLineWait(), NewTask() and NewTaskWait() will run as "Default User" or "IIS APPPOOL\DefaultAppPool". Environment variables USERDOMAIN and USERPROFILE will be blank when running as "Default User" or "IIS APPPOOL" and "DefaultAppPool" when run as that user.
For Notification context, user is "gsoap_pool" or "IIS APPPOOL\gsoap_pool".

"fileName" path delimiters can be "/", "\" or "\\".
SBM does NOT expand environment variables in the "fileName" param.