Errrrrr? Ummmmm....when I said "Apache" I meant that if you were using a web browser going to a website that the returned vbscript would not run the WMI part of the program. The reason is - is that Apache does not have any kind of authority (like Admin capabilities) to run the WMI stuff.
The problem is that even though you are running under your account and the browser is running under your account, there are security locks put in place that prevent certain parts of vbscript from executing. These parts deal with being able to access information you may normally be able to access via the cscript or wscript commands.
What I'm trying to do: My orders are to set up a methodology whereby all of the QA people can access a program that will allow us to monitor and correct problems on various servers we are setting up. I first tried vbscript but our manager doesn't want our source code to get out into the wild. So I then tried Perl and tried putting it behind a web server. (Again a no go because the Perl script would work if I just ran it but when Apache tried to run it, Apache had a different set of privileges and thus Perl simply returned error messages to that effect.) So I tried using vbscript in the hopes that if the vbscript would execute on the client's browser that it would be able to do the WMI stuff. But again - no go because now the browser is the one which is blocking the vbscript from running.
However, I think I've found the answer: Exescript. This program will take a vbscript and make it into a true executable where it will actually run on a Windows box. So it fullfills both of my needs. And for a reasonable price too. :-)
2
