what is the command you are running ? scriptutil is standalone, it doesn't run as a job directly, so you are calling scriptutil from a nsh script?
yes, it's calling from a nsh script like this:
echo "START SCRIPT"
scriptutil -h vmlbcatfl12.lvtc.gsnet.corp -s PropertyWinAdminUser
echo "FINISH SCRIPT"
and the windows version is:
OS_VERSION 2008 R2
What type of nsh script is this ? run against all targets? run once, pass target list as argument, copy and execute ?
Any idea if the command is supported by Windows in this case?.
1 of 1 people found this helpful
yeah - i thought that used to work. i'm guessing since it doesn't have a .bat or .cmd extension then it fails. if you give it a .bat extension and give the path to it when you call scriptutil it should work:
prime% scriptutil -h jetfire -s /opt/bmc/bladelogic/NSH/share/sensors/PropertyWinAdminUser.WindowsNT
"C:/tmp/_jetfire-21461-0-PropertyWinAdminUser.WindowsNT" is not a valid Win32 application.
prime% scriptutil -h jetfire -s /opt/bmc/bladelogic/NSH/share/sensors/PropertyWinAdminUser.bat
It works in that form but i have to know the o.s of the server before execute it and the advantage of the command is that is not necessary to know the o.s.
It is a possible solution, thanks.
Right – to me it seems like a defect – when scriptutils copies the file over it should change the extension to be .bat or .cmd.
Bill, I think there's more to this. When there is a sensor for each OS, it should indeed apply the right extension, but if you specify an extension by forcing the full path of a script (instead of just a name), it should use that instead. I've tried running vbscript (with a .vbs extension) on a target before, or a .exe even, and it always comes back with this error.
I would think scriptutil should be working kind of like psexec on Windows, where it just executes the script or command remotely as if a user called it from a command-prompt. It doesn't seem to do this.
Was a defect ever created for this?
yeah - that's true. unix at least has the shebang. windows depends on file extensions and usually that's disabled because auto-running vbs and other scripts is a security issue. so that would be an issue. we could probably do some handling of the file type/ext or a comment line in the file to figure out what interpreter to run...