PowerShell-Skript wird nicht über geplante Aufgaben ausgeführt
Auf meinem Domänencontroller befindet sich ein kleines Skript, das so eingerichtet ist, dass es mir per SMTP eine E-Mail über das neueste Sicherheitsereignis 4740 sendet.
Wenn das Skript manuell ausgeführt wird, wird es wie geplant ausgeführt. Bei der Einrichtung zur Ausführung über geplante Tasks wird zwar nichts ausgeführt (keine E-Mail-Adresse).
Das Skript lautet wie folgt:
If (-NOT ([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole] "Administrator"))
{
$arguments = "& '" + $myinvocation.mycommand.definition + "'"
Start-Process powershell -Verb runAs -ArgumentList $arguments
Break
}
$Event = Get-EventLog -LogName Security -InstanceId 4740 -Newest 5
$MailBody= $Event.Message + "`r`n`t" + $Event.TimeGenerated
$MailSubject= "Security Event 4740 - Detected"
$SmtpClient = New-Object system.net.mail.smtpClient
$SmtpClient.Host = "smtp.domain.com"
$MailMessage = New-Object system.net.mail.mailmessage
$MailMessage.from = "[email protected]"
$MailMessage.To.add("toemail.domain.com")
$MailMessage.IsBodyHtml = 1
$MailMessage.Subject = $MailSubject
$MailMessage.Body = $MailBody
$SmtpClient.Send($MailMessage)
Scheduled Task wird wie folgt eingerichtet:
RunsAs:LOCAL SYSTEM
Trigger: On event - Log: Security, Event ID: 4740
Action: Start Program - C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
Argument: -executionpolicy bypass c:\path\event4740.ps1
Ich habe auch folgendes ausprobiert:
Trigger: On event - Log: Security, Event ID: 4740
Action: Start Program - C:\path\event4740.ps1
Entsprechend dem Aufgabenverlauf: Aufgabe gestartet, Aktion gestartet, Vorgang erstellt, Vorgang abgeschlossen, Aufgabe abgeschlossen. Ich habe einige verschiedene Links auf der Site mit dem gleichen 'Problem' durchgesehen, aber alle scheinen eine Art Variable zu haben, die ich nicht habe. Ich habe auch einige der genannten Lösungen ausprobiert und dachte, sie könnten verwandt sein, aber leider funktioniert nichts. Ich habe sogar versucht, meine geplante Aufgabe zu entfernen und wie hier erwähnt zurückzusetzen: http://blogs.technet.com/b/heyscriptingguy/archive/2012/08/11/weekend-scripter-use-the-windows-task -scheduler-to-run-a-windows-powershell-script.aspx
Hat jemand schon einmal einen solchen Fehler gefunden oder wissen, wie er dieses Problem umgehen kann?
Fehlerbehebung:
Ich beschloss, eine .bat-Datei über eine geplante Aufgabe aufzurufen. Ich habe eine einfache Datei erstellt, die das aktuelle Datum/die aktuelle Uhrzeit in einem überwachten Ordner anzeigt. Wenn Sie die Datei manuell und über eine durch das 4740-Ereignis ausgelöste Task ausführen, werden die gewünschten Ergebnisse erzielt. Das Ändern der .bat-Datei, um die .ps1-Datei stattdessen aufzurufen, funktionierte manuell. Bei Auslösung durch das 4740-Ereignis wird die .bat jetzt nicht mehr ausgeführt.
Es wurde eine erfolgreiche Problemumgehung gefunden, die für mein Szenario gilt:
Nicht abmelden, nur die Sitzung sperren!
Da dieses Skript auf einem Domänencontroller ausgeführt wird, melde ich mich über die Remotedesktopkonsole beim Server an und melde mich dann vom Server ab, um meine Sitzung zu beenden. Beim Einrichten der Aufgabe im Aufgabenplaner verwendete ich Benutzerkonten und lokale Dienste, die keinen Zugriff hatten, um im Offline-Modus ausgeführt zu werden, oder mich strikt anzumelden, um ein Skript auszuführen.
Dank einiger Fehlerbehebungshilfen von Cole konnte ich über die RunAs-Funktion nachdenken und beschloss, die nicht funktionierenden Anmeldungen zu umgehen.
Ich habe im Taskplaner meine manuell erstellten Aufgaben gelöscht. Mit der neuen Funktion in Server 2008 R2 bin ich in der Ereignisanzeige zu einem 4740-Sicherheitsereignis navigiert und habe mit der rechten Maustaste> Aufgabe an dieses Ereignis anhängen ... geklickt. Nachdem der Task erstellt wurde, sperrte ich meine Sitzung und brach meine Remote Desktop Console-Verbindung ab. Wenn das Profil "Gesperrt" ist und nicht abgemeldet ist, funktioniert alles wie gewünscht.
Ändern Sie Ihre Aktion in:
powershell -noprofile -executionpolicy bypass -file C:\path\event4740.ps1
Auf einem Windows 2008-Server R2: In Taskplaner unter der Registerkarte "Allgemein" - Stellen Sie sicher, dass der Benutzer "Ausführen als" auf ein Konto mit den erforderlichen Berechtigungen zum Ausführen des Skripts eingestellt ist.
Ich glaube auch, dass Sie die Option "Nur ausführen, wenn Benutzer angemeldet ist" aktiviert haben. Ändern Sie dies in "Ausführen, ob der Benutzer angemeldet ist oder nicht". Lassen Sie die Option "Kennwort nicht speichern" deaktiviert, und Sie müssen wahrscheinlich die Option "Mit höchsten Berechtigungen ausführen" markieren.
Obwohl Sie möglicherweise bereits eine Lösung für Ihr Problem gefunden haben, werde ich diese Notiz trotzdem veröffentlichen, um eine andere Person zu unterstützen. Ich bin auf ein ähnliches Problem gestoßen ... Ich habe im Grunde ein anderes Domänenkonto zum Testen und Vergleichen verwendet. Die Aufgabe lief einwandfrei, wenn "Ausführen, ob Benutzer angemeldet ist oder nicht" aktiviert ist.
Ein paar Dinge, die Sie beachten sollten, um sicherzustellen, dass:
- Das Konto, das zur Ausführung der Aufgabe verwendet wird, muss gemäß der lokalen Sicherheitsrichtlinie des Servers über die Berechtigung "Als Batch-Job anmelden" verfügen (oder Mitglied der lokalen Administratorgruppe sein). Sie müssen das Konto angeben, das Sie zum Ausführen von Scripts/Bat-Dateien benötigen.
- Stellen Sie sicher, dass Sie die richtigen Kennwortzeichen eingeben
- Aufgaben in 2008 R2 werden nicht speziell interaktiv ausgeführt, wenn Sie sie als "Ausführen, ob der Benutzer angemeldet ist oder nicht" ausgeführt wird. Dies wird insbesondere dann fehlschlagen, wenn Sie in dem Skript nach Objekten suchen, die für ein Benutzerprofil spezifisch sind, als die Aufgabe erstellt wurde, da die Powershell-Sitzung diese Informationen zum Starten benötigt, andernfalls beginnt und endet sofort . Als Beispiel für die Definition von $ Path beim Ausführen eines Skripts als "Ausführen, ob Benutzer angemeldet ist oder nicht", und ich ein angegebenes Laufwerk angeben. Es würde nach dem Laufwerk suchen, wenn die Task startet, aber da das für die Ausführung der Task validierte Benutzerkonto nicht angemeldet ist und Sie in dem Skript auf ein Quell-/Objekt verweisen, für das es arbeiten muss, ist die Task nicht vorhanden Beenden Sie einfach das zugeordnete Laufwerk (\ server\share) x:\und den tatsächlichen UNC-Pfad\server\share
- Überprüfen Sie Ihre Schritte, das Skript und die Argumente. Manchmal kann das kleinste Stück einen großen Unterschied machen, selbst wenn Sie diesen Vorgang schon oft ausgeführt haben. Ich habe mehrmals einen Buchstaben bei der Eingabe des Passworts oder ein Semikolon vermisst, manchmal beim Erstellen eines Skripts oder einer Aufgabe.
Überprüfen Sie diesen Link, und hoffentlich können Sie oder jemand anderes von diesen Informationen profitieren: https://technet.Microsoft.com/en-us/library/cc722152.aspx
Um die Funktion "Als Administrator ausführen" zu erreichen, wurde das Flag implementiert:
-ExecutionPolicy Bypass
Dies scheint nur bei der Ausführung von Powershell-Dateien wirksam zu sein. Also habe ich meinen Befehl in die .ps1-Datei fallen gelassen, ihn mit -ExecutionPolicy Bypass ausgeführt, und jetzt verhält sich meine geplante Aufgabe wie erwartet.
Program: Powershell.exe
Add Arguments: -ExecutionPolicy Bypass -File C:\pscommandFile.ps1
Zusätzlich zu den Hinweisen von oben erhielt ich Fehler und fand eine Lösung unter folgendem Link http://blog.vanmeeuwen-online.nl/2012/12/error-value-2147942523-on-scheduled.html .
Auch das kann helfen:
Klicken Sie im Aufgabenplaner auf die geplanten Auftragseigenschaften und dann auf Einstellungen.
Bei der zuletzt aufgelisteten Option: "Wenn die Task bereits ausgeführt wird, gilt die folgende Regel:" Wählen Sie "Stop the vorhandene Instanz" aus der Dropdown-Liste aus.
Ich denke, die Antwort darauf ist auch relevant:
Summary: Geplante Tasks von Windows 2012 sehen nicht die korrekten Umgebungsvariablen, einschließlich PATH, für das Konto, unter dem die Task ausgeführt wird. Aber Sie können dies testen und wenn es passiert, und wenn Sie erst einmal verstanden haben, was passiert, können Sie es umgehen.
Wenn Sie dieses Problem unter WIN 10 haben, kann dieses Problem wie für mich gelöst werden. Ein Update hat den Taskplaner versaut.
Dieser Kommentar hat mein Problem gelöst.
"Ihr Tipp zu" einmaligen "Aufgaben funktioniert gut - es wird definitiv als Problemumgehung ausreichen, bis MS das Problem behoben hat. Der einzige Vorteil von "täglich", soweit ich sehen kann, ist das Fehlen eines beliebigen Datums, das mit der Laufzeit zusammenhängt. Es kann für andere verwirrend sein, warum der Job am X-Datum gestartet wird. '
Trigger-Einstellungen "Einmal" bedeutet "einmal", "Sofort" bedeutet "sofort"
Bitte stellen Sie sicher, dass die Argumente in Kleinbuchstaben sind, wie von Cole9350 erwähnt.
Ich hatte ein sehr ähnliches Problem. Ich behielt das VSC-Fenster mit Powershell-Skript, wenn die Zeitplanaufgabe manuell ausgeführt wurde. Ich habe es gerade geschlossen und es funktionierte wie erwartet.
In meinem Fall (dasselbe Problem) half es, -NoProfile in Befehlsargumenten der Task-Aktion hinzuzufügen und das Kontrollkästchen "Mit höchsten Berechtigungen ausführen" zu aktivieren, da auf meinem Server die Benutzerkontensteuerung aktiviert ist.
Mehr Infos über it Linkbeschreibung hier eingeben
Noch eine Idee, die funktioniert hat. Es ist wirklich albern, aber anscheinend ist die Standardeinstellung für das Ziel-Betriebssystem (rechte untere Ecke des Bildschirms) Vista / Windows Server 2008. Da die 10-Jahres-Marke überschritten ist, ist Ihr Powershell-Skript wahrscheinlich nicht mit diesen kompatibel.
Das Ändern des Ziels auf Windows Server 2016, wie im folgenden Screenshot gezeigt, hat den Trick für mich getan.
Wenn Sie keine Fehlermeldungen haben und nicht wissen, was das Problem ist - warum PowerShell-Skripts nicht mit einer geplanten Aufgabe beginnen möchten, führen Sie die folgenden Schritte aus, um die Antwort zu erhalten:
- Führen Sie CMD als Benutzer aus, für den geplanter Task zum Ausführen des PowerShell-Skripts festgelegt wurde
- Navigieren Sie zu dem Ordner, in dem sich das PowerShell-Skript befindet
- Führen Sie das PowerShell-Skript aus (entfernen Sie alle Anweisungen, die die Fehlerbenachrichtigungen blockieren, wenn innerhalb des Skripts eines vorhanden ist, z. B. $ ErrorActionPreference = 'Silentlycontinue'.)
Sie sollten alle Fehlerbenachrichtigungen sehen können.
Im Falle eines meiner Skripts lautete es:
"Kann Typ [System.ServiceProcess.ServiceController] nicht finden. Stellen Sie sicher, dass die Assembly, die diesen Typ enthält, geladen ist."
Und in diesem Fall muss ich zu Beginn des Skripts eine zusätzliche Zeile hinzufügen, um die fehlende Assembly zu laden:
Add-Type -AssemblyName "System.ServiceProcess"
Und nächste Fehler:
Ausnahme, die "GetServices" mit "1" -Argumenten aufruft: "Dienststeuerungs-Manager kann nicht auf Computer" "geöffnet werden. Für diesen Vorgang sind möglicherweise andere Berechtigungen erforderlich."
select: Die Eigenschaft kann nicht verarbeitet werden, da die Eigenschaft "Database Name" bereits vorhanden ist
Ich wanderte schließlich zwei Tage lang nach Lösung, wenn Folgendes gefunden wurde:
1) Lassen Sie powershell.exe als Administrator ausführen
- klicken Sie mit der rechten Maustaste auf das Symbol powershell.exe
- klicken Sie auf Eigenschaften unter der Tastenkombination
- klicken Sie auf die Schaltfläche "Weiter", um den Lauf als Administrator zu überprüfen.
2) die im Taskplaner-Fenster unter dem Aktenbereich die folgendes Skript als neuer Befehl
%SystemRoot%\syswow64\WindowsPowerShell\v1.0\powershell.exe -NoLogo -NonInteractive -ExecutionPolicy Bypass -noexit -File "C:\ps1\BackUp.ps1"
Ich hatte fast das gleiche Problem wie dieses, aber auf Server 2012 R2 etwas anders. Ich habe ein Powershell-Skript im Taskplaner, das 3 Dateien von einem Ort an einen anderen kopiert. Wenn ich das Skript manuell in Powershell starte, funktioniert es wie ein Zauber. Wenn sie jedoch vom Taskplaner ausgeführt werden, werden nur die ersten beiden kleinen Dateien kopiert und dann an der dritten (großen Datei) hängen. Und ich erhielt auch das Ergebnis "Der Betreiber oder Administrator hat die Anfrage abgelehnt". Und ich habe fast alles in diesem Forum gemacht.
Hier ist das Szenario und wie ich es für mich behoben habe. Kann nicht für andere arbeiten, aber nur für den Fall, dass es:
Szenario 1. Powershell-Skript im Taskplaner 2. Läuft mit einem Domänenkonto, das ein lokaler Administrator auf dem Server ist 3. Ausgewählt "Ausführen, ob Benutzer angemeldet ist oder nicht" 4. Mit höchsten Berechtigungen ausführen
Fix: 1. Ich musste mich mit dem Domänenkonto am Server anmelden, damit ein lokales Profil in C:\Users ..__ erstellt wurde. Der Benutzer hat überprüft, ob der Benutzer Zugriff auf alle Laufwerke hat, auf die ich in meinem Skript verwiesen habe
Ich glaube, Nr. 1 ist für mich das wichtigste Problem. Ich hoffe, das funktioniert für andere da draußen.
Ich habe eine andere Lösung für dieses Problem, die für einige von Ihnen gelten könnte.
Nachdem ich mein Power Shell-Skript (xyz.ps1) erstellt hatte, öffnete ich es zur späteren Bearbeitung in Notepad. Daher machte Windows eine Verknüpfung zwischen meiner xyz.ps1-Datei mit notepad.exe und Scheduler versuchte, mein Power-Shell-Skript (xyz.ps1) mit notepad.exe im Hintergrund auszuführen, anstatt es in Powershell auszuführen. Ich habe dieses Problem gefunden, indem ich dem Abschnitt "Alle laufenden Aufgaben anzeigen" im Scheduler genauestens Aufmerksamkeit schenkte, der zeigte, dass notepad.exe zum Ausführen des xyz.ps1-Skripts verwendet wurde. Um dies zu überprüfen, klickte ich mit der rechten Maustaste auf meine xyz.ps1-Datei im Windows-Explorer, ging zu "Eigenschaften" und zeigte Notepad gegen den Abschnitt "Öffnet mit" an. Dann änderte ich "Öffnet mit" in% SystemRoot%\SysWOW64\WindowsPowerShell\v1.0\powershell.exe. Das hat den Trick gemacht. Nun führte der Scheduler meine xyz.ps1 mit powershell.exe aus und gab mir die gewünschten Ergebnisse.
Informationen zum Auffinden Ihrer Powershell.exe finden Sie in diesem Artikel: https://www.powershelladmin.com/wiki/PowerShell_Executables_File_System_Locations