Hey, Scripting Guy! How can I remotely start an interactive process?

— IS

Hey, IS. Well, the short answer is this: you can’t, at least not on Windows XP or Windows Server 2003. On those two versions of Windows any processes started remotely run in a hidden window: those processes can’t be interactive because the user will never see them. The process would do its part; for example, it might pop up a dialog box. However, the user will never see – and thus never respond to – that dialog box. In return, the process will just sit there and wait, like some B-movie actress sitting by the window, waiting for her long-lost lover to return from the sea.

You’re right: that was pretty poetic for a scripting column, wasn’t it? Hey, Scripting Guy!, where you get your daily dose of scripting and fine literature, all in one!

Believe it or not, running processes in a hidden window is – at least in part – a good thing: it helps minimize the risk from hackers who pop up fake dialog boxes that ask users to enter their passwords or credit card numbers. (Which reminds us: if you haven’t already emailed us your passwords and credit card numbers, please – um, never mind. The lawyers are reading over our shoulders again.)

In other words, the good news is that running processes in a hidden window helps protect you and your users; the bad news, of course, is that it severely limits your ability to remotely start scripts or other processes that require user interaction.

But you know how it is with scripting: just because you can’t do something doesn’t mean you can’t do something. Instead, you just have to find a way to work around the issue. And we just happened to have a workaround right here:

Const OverwriteExisting = TRUE

Set objFSO = CreateObject(“Scripting.FileSystemObject”)
objFSO.CopyFile “C:\Scripts\Interactive.vbs”, _
    “\\atl-ws-01\C$\Scripts\”, OverWriteExisting
strComputer = “atl-ws-01”
Set objWMIService = GetObject(“winmgmts:\\” & strComputer & “\root\cimv2”)
Set objNewJob = objWMIService.Get(“Win32_ScheduledJob”)
errJobCreated = objNewJob.Create _
    (“wscript.exe c:\scripts\interactive.vbs”, “********084500.000000-420”, _
        False, 2, , True, JobID)

As we noted, processes started remotely always run in an invisible window; there’s no way to get around that. If you want to run a process that a user interacts with that process must be started locally. So that’s exactly what we do here. In the first part of the script we copy a file named C:\Scripts\Interactive.vbs to the Scripts folder on the remote computer atl-ws-01. (Note that we’re using the Administrative share – C$ — to do this. If C:\Scripts is shared out we could use a “standard” UNC path like \\atl-ws-01\scripts instead.) Here’s the code that copies the file, overwriting any other file named Interactive.vbs that might exist in the Scripts folder:

objFSO.CopyFile “C:\Scripts\Interactive.vbs”, _
    “\\atl-ws-01\C$\Scripts\”, OverWriteExisting

That copies the file Interactive.vbs to the remote computer. But now how do we run that script and, more important, how do we run it locally?

Although there are a couple of different ways to do this, we opted to create a scheduled task that will start the script on the remote computer. To do that, we bind to the WMI service on the remote machine and then use the Get method to connect to the Win32_ScheduledJob class. That’s what these lines of code do:

strComputer = “atl-ws-01”

Set objWMIService = GetObject(“winmgmts:\\” & strComputer & “\root\cimv2”)
Set objNewJob = objWMIService.Get(“Win32_ScheduledJob”)

For our sample script, we’re assuming it’s a Tuesday morning and you want your interactive process to run at 8:45 AM. That’s what this crazy-looking line of code does:

errJobCreated = objNewJob.Create _
    (“wscript.exe c:\scripts\interactive.vbs”, “********084500.000000-420”, _
        False, 2, , True, JobID)

We don’t have room to explain all the parameters of the Win32_ScheduledJob Create method in today’s column; if you need that level of detail you should take a look at this section of the Microsoft Windows 2000 Scripting Guide. In brief, these are the parameters we configured:

Run the script, and at 8:45 AM Interactive.vbs should start up on the remote machine atl-ws-01. More important, because Interactive.vbs is started locally it will run in a visible window and thus be totally interactive: any message boxes, dialog boxes or other interactive elements used in the script will be accessible to the user.

Like we said, it’s a workaround and it’s a bit of a hassle. But it works, and that’s all we care about.

Well, that and bringing even more culture and sophistication to Hey, Scripting Guy! Maybe we’ll write the next column entirely in iambic pentameter; that would be very chic and very cool.

Anyone have the slightest idea what “iambic pentameter” is?