Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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.

share|improve this question
    
Everything sounded like it pointed to this article support.microsoft.com/kb/867466 until you said that the task does start but fails at the "GUI step". How, exactly is it "failing"? –  Evan Anderson Jan 12 '10 at 17:44
    
The GUI program launches and... just lays there. We see it in task manager but nothing happens and it doesn't actually do anything (it logs progress and no log entries are generated). –  Chris_K Jan 12 '10 at 17:59
    
Regarding the kb link -- the scheduled task owner is a member of the Domain Admin group –  Chris_K Jan 12 '10 at 18:00
    
Have you tried running the application normally (not scheduled)? try also running as a real user as well (not a system user)... quite likely it's related to permissions –  Matt Jan 25 '10 at 21:04
    
Hi Matt. As mentioned above, the app runs fine normally, either as me or when logged in as the "service account.". It may be permissions, but if so I can't spot the issue when monitoring with procmon.exe. –  Chris_K Jan 26 '10 at 1:40
add comment

2 Answers

up vote 4 down vote accepted
+75

Do you have access to the source code for the program for debugging? It sounds like the windows creation is failing because there's no windows desktop available to the program unless the task owner is logged into the machine. This article http://msdn.microsoft.com/en-us/library/ms687105%28VS.85%29.aspx describes the process for window station and desktop creation.

share|improve this answer
    
This seems really likely. I've shared your link with the developer and am waiting to hear back from him. Thanks for that. –  Chris_K Jan 22 '10 at 22:09
    
We had this problem a few years ago and we sent a very similar artical to our developer and he had it fixed in a matter of hours for us. –  Mark Henderson Jan 25 '10 at 3:09
add comment

Is the task setup to start in a specific directory? Permissions are setup correctly in those directories that it is reading/writing to..

I'm assuming the "Run As' in the task is setup correctly (gotta check basics! :) )

Have you checked to ensure that the account is running the task is granted the right to "Log on as a batch job" (Local Security Policy\Local Policies\User Rights Assignments\Log on as a batch job)

share|improve this answer
    
Thanks for the response. Yes, the task is setup to start in a specific directory. Permissions there are good. If I'm logged on as the task's "Run As" user I can manually run the job (cmd line or manually starting scheduled task). If I'm logged on as the task's Run As user and let the scheduler kick it off the job runs fine. And finally, yes -- the "Run As" account is added to the Log on as a batch job. The program runs ... to a point. According to our logging, it hangs at the point where it would be displaying a windows for the first time. –  Chris_K Jan 21 '10 at 16:25
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.