The first one doesn't work. It doesn't give an error, but it doesn't launch the second script (I'm manually running the primary script for testing purposes).
The second one works if manually run. But when running it during logon, I get the same symptoms as before--once the first instance of wscript ends, it kills the second instance. I'm starting to think this isn't possible, and maybe I should take another route--like calling the looping script from the Startup group or the Run registry key. Is there a way to do that without any user interaction (i.e., no confirmation prompt asking the user if they're sure they want to run it)? -----Original Message----- From: Ben Scott [mailto:mailvor...@gmail.com] Sent: Monday, June 07, 2010 5:22 PM To: NT System Admin Issues Subject: Re: Nested VBS in logon scripts On Mon, Jun 7, 2010 at 4:35 PM, John Hornbuckle <john.hornbuc...@taylor.k12.fl.us> wrote: > The first suggestion hangs the login completely. Which makes sense, > because the first script is waiting for the second script to finish, > but the second script will never finish; its whole purpose is to run > perpetually as long as the user is logged in. Oh. I didn't read your original post closely enough. My bad. On Mon, Jun 7, 2010 at 4:05 PM, John Hornbuckle <john.hornbuc...@taylor.k12.fl.us> wrote: > ... call a second VBS script, with the goal being that the second > script will continue running in the background after the user has > logged in (it's a loop that periodically sends a bit of data somewhere). First, set your vendor on fire. That's one ugly kludge. (Or at least demand your money back. Seriously.) Next... spawning a separate script host should eliminate any direct interaction between the interpreters for the two scripts. I can only guess that when the first interpreter exits it must be taking away all its children, too. Something akin to process groups in *nix, perhaps. Try using the START command. START is a built-in of CMD.EXE, not a stand-alone executable. So you'll have to do something like: objShell.Run "CMD /C START \\server\path\SecondScript.vbs", 0, False You may also need to tell START to explicitly use the script host: objShell.Run "CMD /C START WSCRIPT \\server\path\SecondScript.vbs", 0, False -- Ben ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ NOTICE: Florida has a broad public records law. Most written communications to or from this entity are public records that will be disclosed to the public and the media upon request. E-mail communications may be subject to public disclosure. ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
