Warum werden wöchentliche Aufgaben, die mit einem anderen Benutzer über PowerShell erstellt wurden, mit dem Fehler 0x41306 fehlgeschlagen?

8

Wir haben einige Skripte, die geplante Jobs mit PowerShell als Teil unserer Anwendung erstellen. Als ich sie kürzlich getestet habe, ist mir aufgefallen, dass einige von ihnen immer sofort fehlschlugen und keine Ausgabe jemals produziert wird (sie erscheinen nicht einmal in der Get-Job -Liste).

Nach vielen Tagen der Feinabstimmung konnten wir es auf alle Jobs isolieren, die wöchentlich ausgeführt werden. Unten ist ein Skript, das zwei Jobs erstellt, die genau dasselbe tun. Wenn wir dies in unserer Domain ausführen und Anmeldeinformationen eines Domänenbenutzers angeben, erzwingen Sie die Ausführung beider Jobs in der Taskplaner-GUI (rechte Maustaste - & gt; Ausführen), die tägliche läuft gut (0x0-Ergebnis) und die wöchentliche schlägt fehl (0x41306).

Hinweis: Wenn ich den Parameter -Credential nicht zur Verfügung stelle, funktionieren beide Jobs einwandfrei. Die Jobs schlagen nur dann fehl, wenn die Aufgabe sowohl wöchentlich als auch als Domänenbenutzer ausgeführt wird.

Ich kann keine Informationen darüber finden, warum dies geschieht, und auch keinen Grund, warum es sich bei wöchentlichen Jobs anders verhalten würde. Die Registerkarte "Verlauf" im Taskplaner hat fast keine nützlichen Informationen, nur "Task wird aufgrund einer Benutzeranforderung angehalten" und "Task beendet", die beide keine nützlichen Informationen enthalten:

  

Taskplaner wurde beendet "{eabba479-f8fc-4f0e-bf5e-053dfbfe9f62}"   Instanz von "\ Microsoft \ Windows \ PowerShell \ ScheduledJobs \ Test1"   Aufgabe. Der Taskplaner hat die Instanz gestoppt   "{eabba479-f8fc-4f0e-bf5e-053dfbfe9f62}" der Aufgabe   "\ Microsoft \ Windows \ PowerShell \ ScheduledJobs \ Test1" als Anforderung von   Benutzer "MyDomain \ SomeUser".

Was ist los? Warum laufen wöchentliche Aufgaben anders, und wie kann ich dieses Problem analysieren?

Dies ist PowerShell v3 unter Windows Server 2008 R2. Ich konnte dies nicht lokal reproduzieren, aber ich habe keinen Benutzer eingerichtet wie der in unserer Produktionsdomäne (ich arbeite daran, aber ich wollte dies so schnell wie möglich posten, in der Hoffnung, jemand weiß, was los ist!).

%Vor%

Bearbeiten: Hinzugefügt zu Verbinden, wie vom Snover vorgeschlagen:

Ссылка

Bearbeiten: Einige zusätzliche Informationen von Jeff Hicks

  

Ich habe Ihren Code verwendet, um die gleichen Jobs auf meiner 2008 R2-Box mit PS zu erstellen   v3. Beide Jobs konnten mit Start-Job von PowerShell ausgeführt werden. Aber in der   GUI, ich habe den gleichen Fehler für den wöchentlichen Job.

     

Ich erhalte das gleiche Ergebnis unter Windows 8. Etwas sagt die Aufgabe   Dienst zum Abbrechen. Ich habe einige andere Einstellungen getestet, aber sie hatten keine Wirkung.   Ich habe alle Logs durchgesehen, die mir einfielen und alles, was sie zeigen, ist   der Job wird gestartet, PowerShell wird geladen und dann der Taskplaner   Abbrechen.

     

Ich habe die wöchentliche Aufgabe zurückgesetzt, um sie heute noch vor ein paar Tagen auszuführen   gescheitert. Ich testete auch eine wöchentliche Aufgabe, die etwas anderes als   PowerShell und es lief gut.

     

Ich habe den wöchentlichen Job so geändert, dass er dasselbe Konto wie der aktuelle Benutzer verwendet   und es lief gut. Habe es wieder auf das andere Konto geändert und es   erneut fehlgeschlagen. Ich habe keine Ahnung von der Korrelation zwischen dem Auslöser   und Konto.

    
Danny Tuppeny 17.01.2013, 12:18
quelle

5 Antworten

1

Ich hatte ein ähnliches Problem beim Erstellen einer geplanten Aufgabe, aber ich erinnere mich nicht, ob es auf dem Tagesplan basierte. Ich habe den Wechsel zu gMSA account gefunden, um unsere geplante Aufgabe auszuführen. Dadurch konnten wir festlegen, dass die Aufgabe ausgeführt wird, unabhängig davon, ob der Benutzer angemeldet war oder nicht. Andernfalls müssen Sie den Benutzernamen und das Passwort angeben und nicht die Möglichkeit haben, dass der Benutzer angemeldet ist.

    
Tram 28.05.2016 20:27
quelle
0

Die standardmäßigen Joboptionen liefern möglicherweise einen Hinweis. Es gibt viele Standardwerte, die die Ausführung eines Jobs verhindern können. Einige davon sind möglicherweise spezifisch für Ihre Umgebung. Weitere Informationen finden Sie hier: Ссылка

Wenn das nicht ist, lass es mich wissen. Ich möchte diesem Thema folgen und dieses Szenario in den Leitfaden zur Fehlerbehebung aufnehmen.

Danke, Juni Blender (Juni) Senior Programming Writer, Microsoft

    
June Blender 17.01.2013 18:52
quelle
0

Ich habe endlich die Lösung für dieses Verhalten gefunden. Ich plante eine Aufgabe, die jeden Sonntag ausgeführt wurde, um ein Powershell-Skript auszuführen. Das Skript selbst lief gut. Dann habe ich versucht, es manuell im Aufgabenplaner zu starten. Dies endete mit Fehler 41306. Nachdem ich Ihre Kommentare hier gelesen hatte, änderte ich den Zeitplan, um nicht am nächsten Sonntag, sondern am letzten Sonntag zu starten (das Startdatum liegt also in der Vergangenheit). Danach konnte ich es sofort ohne Probleme starten.

    
Mitch 20.10.2016 13:40
quelle
-1

So geplante Jobs werden im Taskplaner ausgeführt, aber es gibt keine wirklich enge Integration. Wenn Sie einen geplanten Job registrieren, wird eine geplante Jobdefinition erstellt und hoffentlich werden Windows-Taskoptionen geplant. Es wird KEIN geplanter Jobinstanzjob erstellt, bis der geplante Windows-Task 1) den geplanten Job erfolgreich ausgelöst hat und 2 so weit erfolgreich ausgeführt wurde, dass er die Instanz erstellt hat.

Ich hätte es vorgezogen, wenn PowerShell in einem Fall, in dem der geplante Job fehlgeschlagen ist, zumindest die geplante Task-Engine abfragen und herausfinden würde, dass eine Instanz gestartet und fehlgeschlagen ist, und den Fehler oder was nicht bekommt.

Wenn du es registrierst, registrierst du es im Grunde mit einem Trigger, der passieren kann oder auch nicht, und verschiedene Dinge können dort auftreten, wo es fehlschlägt, bevor PS überhaupt ausgeführt wird.

Zum Beispiel können Sie sagen, dass es spezifisch ist, um unter certian Kredits zu laufen, und etwas stimmt nicht mit den Anmeldeinformationen, oder vielleicht ändern sich die Berechtigungen, NACHDEM du es registriert hast. Wenn der Auslöser passiert, wird Windows nicht in der Lage sein das zu starten geplante Aufgabe, und daher wird der geplante Jobcode PS nichts darüber sagen.

Ein interessanter Fall ist mir passiert, als ich ein paar Demos gemacht habe. Beim Testen auf meinem Laptop würde es es registrieren und 4 Sekunden später auslösen, dann könnte ich die Job-Instanz sehen, dann würde es enden und ich könnte die Ergebnisse bekommen.

aber es würde IMMER scheitern, wenn ich es vorführen würde. Und das lag daran, dass Optionen geplante Aufgaben standardmäßig nicht ausgeführt werden, wenn sie im Akkubetrieb ausgeführt werden, anstatt eingesteckt zu werden, und wenn ich meine Demos mache, würde ich meinen Laptop nehmen und Leute zeigen, und ich war nicht angeschlossen.

es ist traurig, weil es von der PS-Seite aus so aussieht, als wäre nichts passiert, wenn es um die geplante Task-Engine geht, gibt es einen Verlauf, den sie wegen spezifischer Fehlercodes und -meldungen versucht hat und fehlgeschlagen ist.

>

Wenn Sie einen Job mit fehlgeschlagenem Status und Grund in der nächsten Version sehen wollen, wählen Sie meinen Fehler beim Verbinden ab

Ссылка

    
klumsy 17.01.2013 19:09
quelle
-1

In meinem Fall, als ich den Verlauf der Aufgabe betrachtete, stellte ich fest, dass beim Erstellen der Aufgabe notepad.exe die Ausführung versuchte (weil notepad.exe als Standard zum Öffnen von% gesetzt war). co_de% files; weil es eine schnelle Möglichkeit war, die Skripte zu bearbeiten). Dies verursachte jedoch offensichtlich ein Problem.

Um es zu beheben, habe ich mit der rechten Maustaste auf eines meiner .ps1 -Skripts geklickt und PS1 gewählt und den Standardwert open with gewählt (der Pfad kann für jede Person variieren) die Eigenschaften der PowerShell-Verknüpfung, um Ihren spezifischen Pfad zu erhalten).

Ich habe dann versucht, die Aufgabe erneut auszuführen - Erfolg!

    
John 'Shuey' Schuepbach 06.02.2017 18:06
quelle