How Can I Remotely Start an Interactive Process?

How Can I Remotely Start an Interactive Process?

  • Comments 4
  • Likes
Hey, Scripting Guy! Question

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

-- IS

SpacerHey, Scripting Guy! AnswerScript Center

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:

Parameter

Description

"wscript.exe c:\scripts\interactive.vbs"

Path to the script/executable file to be run. Because this is supposed to be an interactive process we specifically called out wscript.exe as the script host; that helps ensure that interactive elements (such as message boxes created using Wscript.Echo) actually appear as interactive elements.

"********084500.000000-420"

Time the job should run, using the UTC (Universal Time Coordinate) format. We won’t explain the UTC format today; for more details, see the Scripting Guide. For now, you only have to worry about two things: the 0845 (which represents 8:45 AM in 24-hour time format) and -420 (which represents your time zone offset from Greenwich Mean Time). Depending on the time you want the script to run and the time zone the computer is in you might need to change one or both of these values.

False

Indicates whether or not the scheduled job should run repeatedly. Because we only want this job to run once we set the value to False.

2

Days that the scheduled job should run.

 

Specifies the days of the month when the job should run. Because this parameter is used only when a job is scheduled to run more than once we simply leave it blank.

True

Indicates that the scheduled job is interactive and should run in a visible window. If this parameter was set to False (the default value) our script would - alas - run in a hidden window.

JobID

Out parameter that holds the Job ID assigned to the new task.

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?

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • I thought about the same loop hole when  I've read :msdn.microsoft.com/.../aa389769.aspx.

    I'm wondering how we could change your "********084500.000000-420" to now + 1 sec or any given time that is close to right now! ??? any idea?

  • "********084500.000000-420"

    "********084501.000000-420"  - add 1 second

    "********084500.000000-420"  - add five minutes

  • that I figure that much, I was more refering to a way to be Now (any time of the day)

  • $now=new-object -com WbemScripting.SWbemDateTime

    $newtime=$((Get-Date).AddSeconds(1))

    $now.SetVarDate($newtime)

    $now.YearSpecified=$false

    $now.MonthSpecified=$false

    $now.DaySpecified=$false

    $now.Value