Wir haben einen 2008 R2-Server mit einer geplanten Aufgabe, die eine .bat-Datei ausführt, die einen Aufruf einer Java-App ausführt. Die Aufgabe wird problemlos ausgelöst, beendet aber die Ausführung, nachdem die Protokolldatei erstellt wurde. Hier sind die Details zur Einrichtung:
Es wird auf einem speziell für diese Aufgabe erstellten Benutzerkonto ausgeführt, das über die Berechtigung verfügt, sich als Stapeljob anzumelden.
Dies sind die beiden Schritte, die die Batchdatei ausführen kann (der zweite ist der, der hängen bleibt):
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- Die erste Aktion des Java-Clients besteht darin, mit dem Dienstprogramm log4j einen Logger mit der Client-Klasse als Argument zu erstellen. Dies scheint erfolgreich zu sein, da wir eine leere Protokolldatei mit dem Dateinamen erhalten, der im Batch-Aufruf oben angegeben ist. Dies ist der spezifische Befehl:
private static final Logger logger = Logger.getLogger(WsClientRunner.class);
- Der Client startet dann die Hauptfunktion und liest das „Update“-Argument, um den Ausführungsmodus zu bestimmen, und fährt dann wie programmiert fort.
Das ist meine Frage:Gibt es Sicherheitsrichtlinien oder andere Prozesse, die dies beeinträchtigen würden, wenn es als Batchjob ausgeführt wird und nicht vom Benutzer gestartet wird (z. B. durch Doppelklicken auf die Batchdatei)?
Da der Java-Client anscheinend einwandfrei funktioniert, wenn er allein ausgeführt wird (einschließlich des Schreibens von Ergebnissen in die Protokolldatei), glauben wir nicht, dass es unbedingt am Java-Client liegt. Wenn Sie jedoch keine Antworten haben, frage ich als Nächstes bei den Leuten von StackOverflow nach.
Antwort1
Überprüfen Sie, ob im Feld „Konfigurieren für“ als Betriebssystem Windows 7 oder Windows Server 2008 R2 ausgewählt ist.
Außerdem müssen Sie „Im Ordner starten“ auf der Registerkarte „Aktion“ der Aufgabeneigenschaften eingeben, obwohl dies optional ist.
Vielleicht hilft das; mir hat es bei einem ähnlichen Problem geholfen.
Antwort2
Wir hatten dieses Problem auch. Es stellte sich heraus, dass die Anmeldeinformationen, die für die Ausführung der geplanten Aufgabe eingegeben wurden, nicht mit denen übereinstimmten, die für die manuelle Ausführung des Skripts verwendet wurden. Andere Artikel, die ich gefunden habe, wiesen ebenfalls auf ein Berechtigungsproblem hin.
Wenn der ID, mit der die Aufgabe ausgeführt wurde, lokale Administratorrechte erteilt wurden, funktionierte der geplante Job. Anschließend haben wir getestet, das Profil in niedrigere lokale Sicherheitsgruppen einzuordnen, bis wir die Gruppe mit den geringsten Zugriffsrechten gefunden haben, die dennoch eine erfolgreiche Ausführung des Skripts ermöglichte.