Scheduled Tasks w/ GUI issue

Are there issues running Scheduled Tasks in Windows 2003 when the task has a GUI? I have one that worked fine in Windows 2000 but won’t run on Windows 2003.

Details:

I have a .bat job that ran every hour throughout the day on an old Windows 2000 server for many years. I finally retired that server last week and moved the job (and associated programs and files) to a Windows 2003 server.

The .bat file calls a couple cmd line apps first, but the final step is a GUI based .NET app (it does some OCR on image files and then shuts itself down).

From the new server, logged on as the Scheduled Task owner I can run the .bat file from the command line successfully.

From the new server, again logged on as the Scheduled Task owner, I can right-click on the task in the Scheduler and run it successfully. This task simply runs that same .bat file.

If the Scheduled Task owner is logged on to the 2003 server and the task is started from a remote server (where the user started Scheduled Tasks and connected to this server) it’ll also run successfully.

If the scheduled task owner is not logged on to this server then the scheduled task fails at the step where the GUI app is launched. We can’t get any error messages. Running ProcMon from a different session/user account monitoring that user account didn’t turn up anything either.

For the moment, my horrible work-around is to leave the scheduled task owner logged on at the console with the screen locked. Of course, this becomes a pain each time that server is rebooted…

The scheduled task owner is our “domain service account” and is working with all other tasks on all other servers. It isn’t locked out or anything like that.

I even tried modifying the Task Scheduler to check the “Allow service to interact with desktop box” but that didn’t change anything. (Yes, I restarted the service after the change.)

Thoughts?

Updated (1/19/2010)

I need to clarify a bit: The .NET app I mentioned does a bunch of stuff that works. It isn’t until it gets to the point where it needs to open a window that the app then hangs. We can see the progress of the app via the logging entries it leaves behind so we can see it working fine with the last log entry being “about to start OCR”… and that’s where she hangs.

Related:


Leave a Reply