We have a 2008 R2 server with a scheduled task that runs a .bat file which executes a call to a Java app. The task triggers just fine, but stops executing anything after it creates the log file. Here's the details on how it's set up:

  • It runs on a User-level account created specifically for the task, and which does have permissions set up to log on as batch job.

  • These are the two steps that the batch file is able to execute (the second one is the one that hangs):

cd E:\CLIENT_DB\WS_Client\bin\

java -Xms256m -Xmx512m -XX:MaxPermSize=512m -cp ..;..\*;..\certs;..\config;..\client;..\client\*;..\lib\*;..\lib\axis2\* WsClientStarter update > E:\CLIENT_DB\Logs\WSCLIENT_LOG_%DATE:~4,2%-%DATE:~7,2%-%DATE:~10,4%.txt
  • The Java client's first action is to use the log4j utility to create a logger with the client class as the argument. This appears to succeed because we get a blank log file with the file name as indicated in the batch call above. This is the specific command:

private static final Logger logger = Logger.getLogger(WsClientRunner.class);

  • The client then starts the main function and reads the 'update' argument to determine the run mode, then proceeds as programmed.

This is my question: Are there any security policies or other processes that would interfere with this when run as a batch job as opposed to being started by the user (i.e. double-clicking the batch file)?

Since the java client appears to work just fine when run on its own--including writing results to the log file--we don't think that it's necessarily anything with the Java client, but if you all have no answers, I'll check with the folks at StackOverflow next.

  • It sounds like the task configured so that it runs only when the user is logged on, or is not saving their credentials. – Greg Askew Oct 19 '12 at 20:46
  • What credentials are you using to run the scheduled task? The same user that successfully runs the bat file manually, localSystem, other? – smithian Oct 19 '12 at 20:55
  • We have the tasks set to "Run whether user is logged on or not" and "Run with highest privileges". The user account used to run the task is not currently the same as the one that runs it manually, but prior to the creation of the task-specific account, that user was the same as the task's assigned user account--and we had the same results. – Ant Oct 22 '12 at 12:48
  • Also, in response to @inhabitant's "answer", there are no error codes returned. We've checked Event Viewer, Task Scheduler, and the client's own logs (the blank logs referred to above) and there are never any error codes. The only time we ever got error codes was when we had the task timeout set to longer than 24 hours, because it was set to run every night, and since the client was still hung 24 hours after it started, the task couldn't restart itself. Now that we have the timeout set to 8 hours, Task Scheduler simply says "Stopped" and Event Viewer says "Task stopped due to timeout". – Ant Oct 22 '12 at 12:51

Please check if in Configure for box, Windows 7, Windows Server 2008 R2 for operating system are chosen.

Also, you need to enter Start in folder in Action tab of Task properties, even though it is optional.

Maybe this will help; it helped me with similar issue.


We had this problem as well. Turns out the credentials put in for the scheduled task to run under were different than those used to manually run the script. Other articles I found pointed to a permissions issue as well.

When the ID used to run the task was granted local administrator permissions, the scheduled job worked. We then tested putting the profile in lower local security groups until we found the one with the least access that still allowed the script to successfully complete.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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