Can VBScript run shell commands in the "background"?
For example:
Set objShell = CreateObject("WScript.Shell") objShell.run "ping 127.0.0.1"
Can the Shell object execute ping without launching the console? In this example, would it be objShell.somethingelse?
I'm also curious if anyone's had any experience working directly with Icmp.dll; pinging multiple hosts simultaneously on separate threads (which is ultimately what I'm trying to do ).
I'm actually tryin to figure out how, conceptually, I can do anything simultaneously in a script. I have an app called MultiPing (not the Nessoft version)...mine is by one Thomasz Stelmach, and doesn't seem to have a home anymore. Anyway, if I remember correctly, on his now defunct webpage Thomas was explaining how Icmp.dll could support up to 50 simultaneous threads. I recently thought "there's gotta be a way to do this in a script!"...send a packet apiece to 50 hosts, then 50 more, etc. That would make pretty short work of speciallized network polling...still tryin to figure it out. :)
Since vbs is interpreted and requires cscript (or wscript) to run, isn't the multithreading capabilities of the script itself controlled or limited by cscript in some way ? Is cscript multithreading capable ?
I downloaded OSICMP.dll and the associated sample script "ping.vbs" from the link tnoonan provided above. Upon running ping.vbs, I was struck by the fact that the command output was being echoed to the "same" messagebox one line at a time. Actually, it appears as though each reply line gets its own box, but the box includes each previous reply, simulating "realtime" feedback. I think this may have some relevance to Juan Avila's post http://www.visualbasicscript.com/topic.asp?TOPIC_ID=2329 where he is trying to get realtime output into one messagebox.
The code of ping.vbs is below...I'm curious if anyone can detect any features in the script itself that would facilitate this method of stdout redirection, or if it's just a feature of the 3rd party dll. I've tried removing all OSICMP referrences, and substituting regular ping functions, but just get the one line per pop-up.
I'm not complaining or anything; I thought that the ThreadForker was something "real". Nonetheless, it is an interesting way of simulating multiple threads, and I've never thought of something like that before.
What exactly do you intend to achieve by ping the computers though ?
My superiors like to call in for up/down status on several so-called critical servers. In between our massive snmp polling cycles, it's nice to be able to get an instant status report. I already use batch and perl scripts for this and other things, but the reported "power" of WMI was quite seductive...the goal being to eventually get more than "up/down" status.
My interest in multithreading is very general, and, at this point, is fueled more by fantasy than practical application. We've many many thousand nodes, and I've found myself running, by "hand", several instances of the same script againts different chunks of hosts to save time...this is terrible practice, and ruins my day. :)
For the purpose of pinging, the results are important. In order to catch these results sent to the stdout, we will need to use files or EXEC. Simulating multithreading in this manner has its benefits of allowing us to set an arbitrary number of threads dynamically. The trick here is to determine how to track and use these results correctly and efficiently. In the case of using WMI or SICMP.Ping, it is rather difficult to dynamically change the number of threads and it is just might be as difficult to track the results.
I use WMI for determining the online status of a host on roughly 4000 hosts on a daily basis and it seems to be good enough for me under most circumstances.
Yes, getting precise results has always been a bit dicey for me. I used to use batch tokens, but would get erroneous positives, as border routers will return replies (i.e., "destination host unreachable") for down hosts depending on the circumstances (although, using the 9th token works pretty well most of the time: FOR /F "tokens=9" %%A IN ('ping -n 3 -w 3000 %IP%') DO whatever).
I'm fairly committed to sticking with WMI goin forward, as I'm tired of making all of these "niche" scripts. I'm curious as to the properties of Win32_PingStatus in terms of customization. Say a data circuit goes down, but a host is still up on a fail-over system (i.e., satellite)...can we adjust the timeout and extend the packet count to compensate? Or does WMI automatically keep trying for a certain amount of time?
Lol...I've had the same empathy for myself many a time . I think I have an inherent "when in Rome" mentality that predisposes me to shell scripting (I'm a bash-loyalist in Solaris as well). This drives my Perl-geek co-workers nuts...they've all had too much Cult of Larry Kool-Aid ("Hail Perl"). The only thing I use Perl for really is the Net::Telnet module, which is, admittedly, pretty damn useful (MS screwed us in the telnet dept.). Batch scripting's surely a trial, but it's my entrance into this whole game...and hell, it works right? Our production network is 90% windows, so I'm hoping WMI will become my secret weapon.