8
Aufgabenplanung: zurücksetzen Ergebnis der letzten Ausführung
Hallo zusammen,
ich habe aktuell eine nette Herausforderung und bräuchte mal etwas Spezialwissen.
Ich habe mir ein Skript zur Überwachung der Aufgaben auf einzelnen Servern gebaut. Das funktioniert mittels schtasks und etwas VBS-Skript-Fu ganz gut und ich bekomm eine HTML-Übersicht aller Tasks von allen Servern, die nicht gelaufen sind oder Probleme machen. Ich kann das leider nicht mit PowerShell lösen, da ich Server überwachen muss, die noch kein Powershell haben - bitte nicht lachen
Jetzt würde ich aber gerne einen Task "reparieren" und danach das last Result "löschen/zurücksetzen", damit mein Skript den Task erst mal wieder als "Okay" anzeigt, bis der nächste Lauf durchgeführt wird.
Hat jemand eine gute Idee/Tool/Skript um das "last run result" auf 0x0 zurückzusetzen?
Ich finde hier weder im Netz, noch in der Registry irgendwas dazu.
Für eine kreative Idee wäre ich sehr dankbar!
Grüße und guten Start in die Woche!
dng-alt
ich habe aktuell eine nette Herausforderung und bräuchte mal etwas Spezialwissen.
Ich habe mir ein Skript zur Überwachung der Aufgaben auf einzelnen Servern gebaut. Das funktioniert mittels schtasks und etwas VBS-Skript-Fu ganz gut und ich bekomm eine HTML-Übersicht aller Tasks von allen Servern, die nicht gelaufen sind oder Probleme machen. Ich kann das leider nicht mit PowerShell lösen, da ich Server überwachen muss, die noch kein Powershell haben - bitte nicht lachen
Jetzt würde ich aber gerne einen Task "reparieren" und danach das last Result "löschen/zurücksetzen", damit mein Skript den Task erst mal wieder als "Okay" anzeigt, bis der nächste Lauf durchgeführt wird.
Hat jemand eine gute Idee/Tool/Skript um das "last run result" auf 0x0 zurückzusetzen?
Ich finde hier weder im Netz, noch in der Registry irgendwas dazu.
Für eine kreative Idee wäre ich sehr dankbar!
Grüße und guten Start in die Woche!
dng-alt
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 839064696
Url: https://administrator.de/contentid/839064696
Ausgedruckt am: 22.11.2024 um 00:11 Uhr
8 Kommentare
Neuester Kommentar
Moin,
leider fehlen in meinen Augen ein paar Infos.
leider fehlen in meinen Augen ein paar Infos.
Zitat von @dng-alt:
Ich habe mir ein Skript zur Überwachung der Aufgaben auf einzelnen Servern gebaut. Das funktioniert mittels schtasks und etwas VBS-Skript-Fu ganz gut und ich bekomm eine HTML-Übersicht aller Tasks von allen Servern, die nicht gelaufen sind oder Probleme machen.
Wie oft soll dieses Skript denn laufen?Ich habe mir ein Skript zur Überwachung der Aufgaben auf einzelnen Servern gebaut. Das funktioniert mittels schtasks und etwas VBS-Skript-Fu ganz gut und ich bekomm eine HTML-Übersicht aller Tasks von allen Servern, die nicht gelaufen sind oder Probleme machen.
Ich kann das leider nicht mit PowerShell lösen, da ich Server überwachen muss, die noch kein Powershell haben - bitte nicht lachen
Kein Grund zum lachen, nur ernsthafte Bedenken. Ich habe selbst noch NT 4.0 Server am laufen in der Produktion, aber diese Produktionsserver sind nicht mit dem Netzwerk verbunden, sondern bilden ein einzelnes Netz aus Sicherheitsgründen, ohne Internetzugriff oder ähnlichem. Wenn du von einem PS-Server diese Server erreichen kannst, solltest du dir auch um dein generelles Konzept einmal Gedanken machen.Jetzt würde ich aber gerne einen Task "reparieren" und danach das last Result "löschen/zurücksetzen", damit mein Skript den Task erst mal wieder als "Okay" anzeigt, bis der nächste Lauf durchgeführt wird.
Hat jemand eine gute Idee/Tool/Skript um das "last run result" auf 0x0 zurückzusetzen?
Das was du hier vor hast widerspricht aber der Logik des "last run result". Das letzte Ergebnis war nunmal fehlerhaft. Reparier den Fehler und starte das Skript neu, dann passt auch 0x0Hat jemand eine gute Idee/Tool/Skript um das "last run result" auf 0x0 zurückzusetzen?
Für eine kreative Idee wäre ich sehr dankbar!
Theoretisch, je nachdem wie oft dein Skript läuft, könntest du mit Log-Dateien arbeiten. Beim ersten Lauf des Tages/der Stunde wird eine Log-Datei erstellt. Existiert die Log-Datei wird der Rest übersprungen. Dann führst du das Skript entsprechend oft aus. Beim ersten mal schreibt er die Log-Datei und meldet es ggf. als fehlerhaft. Beim nächsten durchlauf existiert die Log-Datei und die Aufgabe macht nichts weiter und wird erfolgreich beendet.
Servus,
sowas wie das "Ändern des Task-Result" ist Bullshit!
(Ginge zwar aber ist absolut nicht nötig: Der wird zwar in der Registry in einem Binary "DynamicInfo" hinterlegt und gehört durch die ACLs dem System-Account. Eine Änderung müsste also entweder durch Anpassung der ACLs und schreiben den Binarys gemacht werden, oder durch temporäre Änderung der Commandline und erneutem ausführen)
Im Normalfall machen das Monitoring-Tools über das Setzten eines "Ignore" oder "In Kenntniss" genommen Flags für das Event. So lange der Task also nicht erneut ausgeführt wird (sich also das letzte Ausführungsdatum seit dem letzten Durchlauf nicht geändert hat) wird der Tasks dann so lange ignoriert und erst wenn sich das Datum geändert hat wird erneut gewarnt.
Du kannst dir also diesen Status eine DB oder Textdatei/CSV/XML or whatever schreiben und bei jedem Durchlauf die Stati prüfen.
Grüße Uwe
sowas wie das "Ändern des Task-Result" ist Bullshit!
(Ginge zwar aber ist absolut nicht nötig: Der wird zwar in der Registry in einem Binary "DynamicInfo" hinterlegt und gehört durch die ACLs dem System-Account. Eine Änderung müsste also entweder durch Anpassung der ACLs und schreiben den Binarys gemacht werden, oder durch temporäre Änderung der Commandline und erneutem ausführen)
Im Normalfall machen das Monitoring-Tools über das Setzten eines "Ignore" oder "In Kenntniss" genommen Flags für das Event. So lange der Task also nicht erneut ausgeführt wird (sich also das letzte Ausführungsdatum seit dem letzten Durchlauf nicht geändert hat) wird der Tasks dann so lange ignoriert und erst wenn sich das Datum geändert hat wird erneut gewarnt.
Du kannst dir also diesen Status eine DB oder Textdatei/CSV/XML or whatever schreiben und bei jedem Durchlauf die Stati prüfen.
Grüße Uwe
Hallo Doskias,
vielen Dank für Deine schnelle Antwort. Ich habe bewusst nicht zu viel über das Konzept geredet, damit die Diskussion fokussiert bleibt auf das eigentliche Problem (Reset last run result).
Aber gut, dann hole ich mal etwas aus. Die überwachten Server stehen in einem geschotteten IP-Bereich und haben nichts mit der Produktivumgebung zu tun. Daher habe ich auch ein Skript erstellt, das die Tasks überwacht, da ich nur über große Umwege an die Server komme. Das Skript erstellt mittels schtasks eine Text-Datei mit allen Tasks der Server und mein VBS wertet die Ausgabe aus und verschickt das Ergebnis per Mail an mich. Das Skript läuft einmal früh und prüft, ob alle Tasks nachts gelaufen sind. Die eigentliche Aufgaben laufen teilweise täglich, teilweise wöchentlich, teilweise monatlich.
Das der Sinn des "last run results" ist, zu erkennen, dass der Task nicht gelaufen ist, ist mir klar. Ich kann aber manche Tasks nicht einfach starten, da andere davon abhängig sind oder andere Aktionen ausführt. Daher wäre es gut, dass "last result" zurückzusetzen um beim nächsten Lauf den Fehler erneut zu senden.
Mein Hauptproblem bzw. Frage ist, wo das last run result gespeichert wird, damit ich es manipulieren kann (Registry, XML,??).
Das mit dem zusätzlichen Log habe ich auch im Sinn gehabt, aber dass ist programmiertechnisch und ablauftechnisch nicht ganz einfach umzusetzen.
Trotzdem vielen Dank für die Denkanstöße und die Sicherheitshinweise!
Grüße
dng-alt
vielen Dank für Deine schnelle Antwort. Ich habe bewusst nicht zu viel über das Konzept geredet, damit die Diskussion fokussiert bleibt auf das eigentliche Problem (Reset last run result).
Aber gut, dann hole ich mal etwas aus. Die überwachten Server stehen in einem geschotteten IP-Bereich und haben nichts mit der Produktivumgebung zu tun. Daher habe ich auch ein Skript erstellt, das die Tasks überwacht, da ich nur über große Umwege an die Server komme. Das Skript erstellt mittels schtasks eine Text-Datei mit allen Tasks der Server und mein VBS wertet die Ausgabe aus und verschickt das Ergebnis per Mail an mich. Das Skript läuft einmal früh und prüft, ob alle Tasks nachts gelaufen sind. Die eigentliche Aufgaben laufen teilweise täglich, teilweise wöchentlich, teilweise monatlich.
Das der Sinn des "last run results" ist, zu erkennen, dass der Task nicht gelaufen ist, ist mir klar. Ich kann aber manche Tasks nicht einfach starten, da andere davon abhängig sind oder andere Aktionen ausführt. Daher wäre es gut, dass "last result" zurückzusetzen um beim nächsten Lauf den Fehler erneut zu senden.
Mein Hauptproblem bzw. Frage ist, wo das last run result gespeichert wird, damit ich es manipulieren kann (Registry, XML,??).
Das mit dem zusätzlichen Log habe ich auch im Sinn gehabt, aber dass ist programmiertechnisch und ablauftechnisch nicht ganz einfach umzusetzen.
Trotzdem vielen Dank für die Denkanstöße und die Sicherheitshinweise!
Grüße
dng-alt
Zitat von @dng-alt:
Mein Hauptproblem bzw. Frage ist, wo das last run result gespeichert wird, damit ich es manipulieren kann (Registry, XML,??).
Wie gesagt, die Registry-Keys sind in Besitz von SYSTEM und du müsstest zum Ändern erst den Owner ändern und dann ne ACL für den User hinzufügen, die Taskresults finden sich im Binary DynamicInfo im Subordner mit der GUID des TasksMein Hauptproblem bzw. Frage ist, wo das last run result gespeichert wird, damit ich es manipulieren kann (Registry, XML,??).
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tasks\{XXXXXX-XXXXXXX-XXXXXXXX-XXXXXX}
Und danach natürlich die Rechte wieder gerade ziehen.
Aber ich würde es wie schon gesagt absolut nicht machen, Microsoft kann hier jederzeit etwas ändern und du bekommst es dann vermutlich nicht mit!
Das mit dem zusätzlichen Log habe ich auch im Sinn gehabt, aber dass ist programmiertechnisch und ablauftechnisch nicht ganz einfach umzusetzen.
Ist doch kein Problem .da ich Server überwachen muss, die noch kein Powershell haben - bitte nicht lachen
Brauchst du doch auf den Servern gar nicht, es reicht wenn die per WMI erreichbar sind damit man deren Taststatus abfragen kann, auf dem Monitoring-Server kann dann durchaus das ganze per Powershell abgefackelt werden wenn man will .Zitat von @dng-alt:
vielen Dank für Deine schnelle Antwort. Ich habe bewusst nicht zu viel über das Konzept geredet, damit die Diskussion fokussiert bleibt auf das eigentliche Problem (Reset last run result).
gernevielen Dank für Deine schnelle Antwort. Ich habe bewusst nicht zu viel über das Konzept geredet, damit die Diskussion fokussiert bleibt auf das eigentliche Problem (Reset last run result).
Ich kann aber manche Tasks nicht einfach starten, da andere davon abhängig sind oder andere Aktionen ausführt.
Hier gibt es einen unterschied zwischen können und wollen. Du kannst das sehr gut, müsstest aber eventuell dein Konstrukt umbauen, was einiges an Arbeit bedeutet. Ich habe auch abhängige Task untereinander, aber ich Regel dies mit Log-Dateien in Verbindung zum last-Run des vorherigen Tasks. Ist recht einfach:if (!(test-path [Log-Datei]))
{Skript das ausgeführt wird, wenn Log-Datei nicht existiert}Mein Hauptproblem bzw. Frage ist, wo das last run result gespeichert wird, damit ich es manipulieren kann (Registry, XML,??).
Hat Colinardo dir jetzt ja gesagtDas mit dem zusätzlichen Log habe ich auch im Sinn gehabt, aber dass ist programmiertechnisch und ablauftechnisch nicht ganz einfach umzusetzen.
Wieso nicht. Lokale Log-Datei schreiben sollte doch kein Problem mehr darstellen nach dem was du deiner Beschreibung nach jetzt schon hast.Gruß
Doskias
Hallo Doskias, Hallo Colinardo,
vielen Dank für Eure Hilfe und Ausführungen. Ich habe ja gehofft, dass es eine "einfache" Lösung gibt, also den Task einfach zu resetten oder auf Installations-Zustand zurückzusetzen. Aber das sieht alles nicht gut aus. Das mit der DynamicInfo habe ich auch gefunden. Aber da die Reg-Keys vom SYSTEM kontrolliert werden, ist das nicht ganz unkritisch, ein jämmerliches Gefrickel und wahrschinlich auch mehr us unsicher. Ich könnte da zwar was mit PsExec bauen aber das auf alten Servern in einer unsicheren Umgebung halte ich für ziemlich dämlich.
Daher würde ich jetzt doch Euren Vorschlag annehmen und eine Steuerdatei für die Überprüfung bauen. Darin würde ich bestimmte Tasks bis zum nächsten Lauf einfach aus der Prüfung nehmen. Durch das "next run date" habe ich auch einen Indikator, ab wann ich die Überprüfung wieder aufnehmen muss.
Wenn ich mir das so durch den Kopf gehen lasse, dann ist der Aufwand vielleicht doch nicht so groß
Vielen Dank für den geistigen Tritt und die Ideen! Wahrscheinlich habt Ihr mich vor eigener Dummheit bewahrt!
Dankbare Grüße
dng-alt
vielen Dank für Eure Hilfe und Ausführungen. Ich habe ja gehofft, dass es eine "einfache" Lösung gibt, also den Task einfach zu resetten oder auf Installations-Zustand zurückzusetzen. Aber das sieht alles nicht gut aus. Das mit der DynamicInfo habe ich auch gefunden. Aber da die Reg-Keys vom SYSTEM kontrolliert werden, ist das nicht ganz unkritisch, ein jämmerliches Gefrickel und wahrschinlich auch mehr us unsicher. Ich könnte da zwar was mit PsExec bauen aber das auf alten Servern in einer unsicheren Umgebung halte ich für ziemlich dämlich.
Daher würde ich jetzt doch Euren Vorschlag annehmen und eine Steuerdatei für die Überprüfung bauen. Darin würde ich bestimmte Tasks bis zum nächsten Lauf einfach aus der Prüfung nehmen. Durch das "next run date" habe ich auch einen Indikator, ab wann ich die Überprüfung wieder aufnehmen muss.
Wenn ich mir das so durch den Kopf gehen lasse, dann ist der Aufwand vielleicht doch nicht so groß
Vielen Dank für den geistigen Tritt und die Ideen! Wahrscheinlich habt Ihr mich vor eigener Dummheit bewahrt!
Dankbare Grüße
dng-alt
Zitat von @dng-alt:
Durch das "next run date" habe ich auch einen Indikator, ab wann ich die Überprüfung wieder aufnehmen muss.
Würde hier stattdessen einfach die LastRuntime benutzen und loggen, und dann bei jedem Durchlauf prüfen ob die LastRunTime des Tasks größer als im Log ist. Habt ihr da kein vernünftiges Monitoring-System (PRTG/Icinga....)?Durch das "next run date" habe ich auch einen Indikator, ab wann ich die Überprüfung wieder aufnehmen muss.
Viel Erfolg.
Grüße Uwe
Es gibt eine für dich vielleicht brauchbare, einfache Lösung:
Task exportieren - Task löschen - Task importieren.
Alles bleibt dabei gleich, du verlierst nur die Taskhistory und somit auch den Fehlerzustand.
Task exportieren - Task löschen - Task importieren.
Alles bleibt dabei gleich, du verlierst nur die Taskhistory und somit auch den Fehlerzustand.
schtasks /query /xml /tn test1>%temp%\test1.xml
schtasks /delete /tn test1
schtasks /create /xml %temp%\test1.xml /tn test1
