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.