Member Avatar for Member #1111627

Hi all,

I am trying to schedule a Task that will run a vb script to open a browser, send some keys, and finally close the browser. The task starts, but seems to hang. The task is created as follows:

schtasks.exe /Create /RU "SYSTEM" /SC "DAILY" /MO "1" /ST "23:00" /TN "Open Browser" /TR "C:\somefolder\somescript.vbs"

The script looks like:

Set oShell = WScript.CreateObject("WScript.Shell")

oShell.Exec "iexplore http://localhost/mylocalsite"

WScript.Sleep 10000

oShell.SendKeys "uname"
oShell.SendKeys "{TAB}upassword"
oShell.SendKeys "{ENTER}"

WScript.Sleep 20000

'Close browser'
oShell.SendKeys "^w"

Also, adding c:\program files\internet explorer\ to my path variable allows me to execute iexplore as a command.

Dani AI

Generated

Most likely cause: the scheduled task is running in a non‑interactive session so the browser never receives keyboard events. As pointed out, processes started as SYSTEM or as tasks set to run “whether user is logged on or not” will not have an interactive desktop (Session 0 isolation). The fact the script runs by hand but behaved differently when scheduled — and that a batch wrapper worked — strongly points to a session/interaction difference rather than a syntax bug in the VBScript.

Practical remedies and checks:

  • Run the task under the actual interactive user account (not SYSTEM) and set the task to “Run only when user is logged on” if the automation requires GUI interaction. That places the process in the user’s desktop session where SendKeys can work.
  • Use the Task Scheduler Action to launch the interpreter explicitly (wscript/cscript) with the full path and set the “Start in” folder so relative paths resolve correctly.
  • Check IE settings (Protected Mode, Enhanced Security, first‑run dialogs) for the target site — any UI prompt will block automation if nobody can click it.
  • Inspect Task Scheduler History and have a simple scheduled test that writes to a file to confirm which account/session the task actually runs in.

Better, more reliable alternatives:

  • Avoid SendKeys for login automation. Use HTTP calls or a browser automation framework. Example PowerShell approach (replace with real endpoint and secure credential handling):
Invoke-WebRequest -Uri "http://localhost/mylocalsite/login" -Method POST -Body @{ username='uname'; password='upassword' }
  • For UI automation when a real browser is required, use WebDriver (Selenium) or AutoIt; those tools handle window focus and timing far better than SendKeys.

Quick checklist: confirm task user and “Run only when user is logged on” setting, verify no IE prompts, use Task history/logs to see failures, and avoid storing plaintext credentials in scripts.

Recommended Answers

All 6 Replies

Just a thought. Since IE is not usually used for non-interactive tasks, SYSTEM may be the wrong user context.
Also, the new security noted at https://www.autoitscript.com/autoit3/docs/libfunctions/_IECreate.htm can cause the browser to ask a question and you are not there to answer.

PS. This is mainly a guess here. I'm not there to see and duplicate this setup. But I'll share the above and hope.

Member Avatar for Member #1111627

, thanks for the link, but I'm not sure how I could use it in the VBScript. As for the use of "SYSTEM" in a user context, I've also tried using local accounts and have not succeeded.

Also, the script runs without issue when executed manually.

Think context. Use your account instead of system. I'm sure this has been kicked around many times, since IE is in some non-gui instance, you may find sending keystrokes to fail.

Maybe your goal is to log into a site daily or something. Maybe there are other ways like telnet and other scripts.

Member Avatar for Member #1111627

This is related to another problem that seems to solve itself when I log in and view a web-page and finally just close it. I will look into other alternatives, thanks.

Member Avatar for Member #1111627

I retried this in a batch file and it worked.

thanks for sharing this ,
I had same problum but now it solved !!

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.