Temos um servidor 2008 R2 com uma tarefa agendada que executa um arquivo .bat que executa uma chamada para um aplicativo Java. A tarefa é acionada perfeitamente, mas para de executar qualquer coisa depois de criar o arquivo de log. Aqui estão os detalhes sobre como ele está configurado:
Ele é executado em uma conta de nível de usuário criada especificamente para a tarefa e que possui permissões configuradas para fazer logon como trabalho em lote.
Estas são as duas etapas que o arquivo em lote é capaz de executar (a segunda é a que trava):
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- A primeira ação do cliente Java é usar o utilitário log4j para criar um criador de logs com a classe do cliente como argumento. Isso parece ter sido bem-sucedido porque obtemos um arquivo de log em branco com o nome de arquivo indicado na chamada em lote acima. Este é o comando específico:
private static final Logger logger = Logger.getLogger(WsClientRunner.class);
- O cliente então inicia a função principal e lê o argumento 'update' para determinar o modo de execução e, em seguida, prossegue conforme programado.
Esta é a minha pergunta:Existem políticas de segurança ou outros processos que possam interferir nisso quando executados como um trabalho em lote, em vez de serem iniciados pelo usuário (ou seja, clicando duas vezes no arquivo em lote)?
Como o cliente Java parece funcionar bem quando executado sozinho - incluindo a gravação de resultados no arquivo de log - não achamos que seja necessariamente algo com o cliente Java, mas se todos vocês não tiverem respostas, eu vou verifique com o pessoal do StackOverflow a seguir.
Responder1
Verifique se na caixa Configurar para, Windows 7, Windows Server 2008 R2 para sistema operacional estão escolhidos.
Além disso, você precisa inserir Iniciar na pasta na guia Ação das propriedades da tarefa, mesmo que seja opcional.
Talvez isso ajude; isso me ajudou com um problema semelhante.
Responder2
Nós também tivemos esse problema. Acontece que as credenciais inseridas para a execução da tarefa agendada eram diferentes daquelas usadas para executar manualmente o script. Outros artigos que encontrei também apontaram para um problema de permissões.
Quando o ID usado para executar a tarefa recebeu permissões de administrador local, o trabalho agendado funcionou. Em seguida, testamos colocar o perfil em grupos de segurança locais mais baixos até encontrar aquele com menos acesso que ainda permitia a conclusão bem-sucedida do script.