December 9, 2008 at 7:36 am
Hello,
I have some VBScripts that do some WMI actions (creating users, IIS settings,...). They data used in these WMI scripts is coming from a database on a SQL 2005 server.
The process is designed that a row is added in a SQL table with the variables that are required to execute the WMI using the VBScript. These variables need to be passed to the VBScript and the VBScript should be started and report the result (error/succes).
How can I do this? And is SQL then the best choice for this type of action.
A simple example code would be very welcome.
Thanks!
December 9, 2008 at 8:52 am
What adds the record to the table? Why doesn't it just call the WMI script directly?
By putting these into a table, you are essentially creating a processing queue. If you need a processing queue, the MS / SQL Server solution for this is Service Broker. It is a little clunky to set up (there is no UI), but it is designed to process a queue and provide any necessary feedback from this asynchronous processing.
December 10, 2008 at 12:17 am
The information is coming from a intranet site where engineers change the configuration in a web interface. The changes are written in a database. For a history of changes to be able to rollback, and to indeed create a process queue for providing to our WMI scripts. The reason that we do not want to directly link the WMI scripts to the web interface is security and to avoid that engineers have to wait for the script to finish. No we write it in a table with a parameter that it is not executed and a loop on the central processing servers should pick it up from the table and executes the WMI script.
December 10, 2008 at 5:12 am
I don't understand the security issue - if the user can put the script in the queue, then running it from the web page directly seems like it would be ok. I could still see logging it, but calling to another thread (so the user does not have to wait) and just making the WMI call from the web page seems like a much easier solution.
Again, if you really want to use a processing queue, I would suggest you pick up a book on Service Broker. Dropping this into a broker queue and having the queue processor call a web service to make the WMI call would be a very elegant approach.
December 10, 2008 at 7:09 am
Our point is that if we anyway need to store it in the database. Then we prefer to execute the transactions in the background based on that data in SQL i.o. saving it in the database and at the same time executing to WMI. The WMI is executed toward systems that are in some cases connected via VPN links. When we execute it from the client an error will be generated and the transaction will fail. When we process it from a queue in the database we can retake it when the connection is up.
Like you explain it now we indeed will investigate service broker, because it sounds to do what we require. While reading about it I don't really get the point in how to connect to WMI with it. How do you pass your data from the database to the code that connects to WMI. Or is this by default available on service broker? If someone has a quick example on this it would help to kick start us with it.
December 10, 2008 at 7:45 am
Your client is a web browser and the WMI call would be coming from the web server in an intranet environment, so a VPN disconnect on a web session could easily be survived by a WMI process running on a new thread.
To make a WMI call from Service Broker, the "best" way would probably be to create a web service that makes the WMI call and call to the web service using a CLR procedure call within your service broker processing procedure. Of course, the web service would be the exact same code you would have to write if you made the call from your web application directly.
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply