Geplante Aufgaben mit GUI-Problem

Gibt es Probleme beim Ausführen geplanter Aufgaben in Windows 2003, wenn die Aufgabe über eine grafische Benutzeroberfläche verfügt? Ich habe eine, die in Windows 2000 gut funktioniert hat, aber unter Windows 2003 nicht ausgeführt werden kann.

Einzelheiten:

Ich habe einen .bat-Job, der viele Jahre lang stündlich auf einem alten Windows 2000-Server ausgeführt wurde. Ich habe diesen Server letzte Woche endgültig außer Betrieb genommen und den Job (und die zugehörigen Programme und Dateien) auf einen Windows 2003-Server verschoben.

Die .bat-Datei ruft zuerst ein paar cmd-Zeilen-Apps auf, aber der letzte Schritt ist eine GUI-basierte .NET-App (sie führt eine OCR für Bilddateien durch und fährt sich dann selbst herunter).

Auf dem neuen Server, der als Eigentümer der geplanten Aufgabe angemeldet ist, kann ich die .bat-Datei erfolgreich über die Befehlszeile ausführen.

Auf dem neuen Server, der erneut als Eigentümer der geplanten Aufgabe angemeldet ist, kann ich mit der rechten Maustaste auf die Aufgabe im Planer klicken und sie erfolgreich ausführen. Diese Aufgabe führt einfach dieselbe .bat-Datei aus.

Wenn der Eigentümer der geplanten Aufgabe am 2003-Server angemeldet ist und die Aufgabe von einem Remoteserver aus gestartet wird (auf dem der Benutzer die geplanten Aufgaben gestartet und mit diesem Server verbunden hat), wird sie ebenfalls erfolgreich ausgeführt.

Wenn der Eigentümer der geplanten Aufgabe nicht an diesem Server angemeldet ist, schlägt die geplante Aufgabe in dem Schritt fehl, in dem die GUI-App gestartet wird. Wir können keine Fehlermeldungen erhalten. Das Ausführen von ProcMon von einem anderen Sitzungs- / Benutzerkonto aus, das dieses Benutzerkonto überwacht, hat ebenfalls nichts ergeben.

Im Moment besteht meine schreckliche Lösung darin, den Eigentümer der geplanten Aufgabe mit gesperrtem Bildschirm an der Konsole angemeldet zu lassen. Dies wird natürlich jedes Mal zu einem Problem, wenn der Server neu gestartet wird ...

Der Eigentümer der geplanten Aufgabe ist unser "Domänendienstkonto" und arbeitet mit allen anderen Aufgaben auf allen anderen Servern. Es ist nicht ausgesperrt oder so etwas.

Ich habe sogar versucht, den Taskplaner so zu ändern, dass das Kontrollkästchen "Dienst darf mit Desktop-Box interagieren" aktiviert ist, aber das hat nichts geändert. (Ja, ich habe den Dienst nach der Änderung neu gestartet.)

Gedanken?

Aktualisiert (19.01.2010)

Ich muss ein wenig klarstellen: Die erwähnte .NET-App macht eine Menge Dinge, die funktionieren. Erst wenn der Punkt erreicht ist, an dem ein Fenster geöffnet werden muss, hängt die App. Wir können den Fortschritt der App anhand der Protokollierungseinträge sehen, die sie hinterlässt, sodass wir sehen können, dass sie einwandfrei funktioniert, wenn der letzte Protokolleintrag "kurz vor dem Start von OCR" ist ... und dort hängt sie.

— Chris_K
quelle

Alles klang so, als würde es auf diesen Artikel support.microsoft.com/kb/867466 verweisen, bis Sie sagten, dass die Aufgabe zwar startet, aber beim "GUI-Schritt" fehlschlägt. Wie genau scheitert es?

— Evan Anderson

Das GUI-Programm startet und ... liegt einfach da. Wir sehen es in der Task - Manager , aber nichts passiert und es eigentlich nicht tut nichts (es meldet Fortschritt und keine Protokolleinträge generiert werden ).

— Chris_K

In Bezug auf den KB-Link - der geplante Aufgabeninhaber ist Mitglied der Domain Admin-Gruppe

— Chris_K

Haben Sie versucht, die Anwendung normal auszuführen (nicht geplant)? Versuchen Sie auch, als echter Benutzer zu laufen (kein Systembenutzer) ... sehr wahrscheinlich hängt es mit Berechtigungen zusammen

— Matt

Hallo Matt. Wie oben erwähnt, läuft die App normal, entweder als ich oder wenn sie als "Dienstkonto" angemeldet ist. Es können Berechtigungen sein, aber wenn ja, kann ich das Problem bei der Überwachung mit procmon.exe nicht erkennen.

— Chris_K

Antworten:

Haben Sie Zugriff auf den Quellcode des Programms zum Debuggen? Es hört sich so an, als ob die Windows-Erstellung fehlschlägt, da dem Programm kein Windows-Desktop zur Verfügung steht, es sei denn, der Aufgabenbesitzer ist am Computer angemeldet. Dieser Artikel http://msdn.microsoft.com/en-us/library/ms687105%28VS.85%29.aspx beschreibt den Prozess für die Erstellung von Fensterstationen und Desktops.

— Fred
quelle

Das scheint sehr wahrscheinlich. Ich habe Ihren Link mit dem Entwickler geteilt und warte darauf, von ihm zu hören. Danke dafür.

— Chris_K

Wir hatten dieses Problem vor einigen Jahren und haben unserem Entwickler einen sehr ähnlichen Artikel geschickt, den er innerhalb weniger Stunden für uns behoben hat.

— Mark Henderson

Soll die Aufgabe in einem bestimmten Verzeichnis gestartet werden? Die Berechtigungen werden in den Verzeichnissen, in die gelesen / geschrieben wird, korrekt eingerichtet.

Ich gehe davon aus, dass das "Ausführen als" in der Aufgabe korrekt eingerichtet ist (ich muss die Grundlagen überprüfen! :))

Haben Sie überprüft, ob das Konto ausgeführt wird, für das die Aufgabe das Recht hat, sich als Stapeljob anzumelden (Lokale Sicherheitsrichtlinie \ Lokale Richtlinien \ Zuweisungen von Benutzerrechten \ Als Stapeljob anmelden)?

— Rex
quelle

Danke für die Antwort. Ja, die Aufgabe ist so eingerichtet, dass sie in einem bestimmten Verzeichnis gestartet wird. Berechtigungen gibt es gut. Wenn ich als Benutzer "Ausführen als" der Aufgabe angemeldet bin, kann ich den Job manuell ausführen (cmd-Zeile oder manuelles Starten der geplanten Aufgabe). Wenn ich als Benutzer "Ausführen als" der Aufgabe angemeldet bin und vom Scheduler gestartet werden kann, wird der Job ordnungsgemäß ausgeführt. Und schließlich ja - das Konto "Ausführen als" wird als Stapeljob zum Anmelden hinzugefügt. Das Programm läuft ... bis zu einem gewissen Punkt. Laut unserer Protokollierung hängt es an der Stelle, an der zum ersten Mal ein Fenster angezeigt wird.

— Chris_K

Das Problem hierbei ist, dass für das von Ihnen ausgeführte Programm eine grafische Benutzeroberfläche erforderlich ist. Aufgaben haben keine Windows-GUI. Wenn Sie das Programm also ohne GUI ausführen können, sind Sie in Ordnung.

— Johnboy
quelle