17
PowerShell-Script wird per Aufgabenplanung nicht ausgeführt
Mahlzeit!
Auf einem 2012 Server mit 2013 Exchange lasse ich einige Dinge automatisiert ablaufen, dazu gibt es diverse PowerShell-Scripts, die per Windows Aufgabenplanung gestartet werden. Alle Scripts laufen wunderbar, nur das neueste will nicht. Das hier passiert:
- direkt in der PS-Console funktioniert es (komplettes Script hineinkopiert)
- per Verknüpfungsaufruf funktioniert es
- beim Aufruf per Aufgabenplanung sehe ich zwar im Taskmanager, dass die PS läuft, es bewegt sich auch ein wenig der Arbeitsspeicher, aber das war es dann auch schon. Die PS wird nicht mehr beendet, obwohl ich angegeben habe, dass sie nach 30 Minuten beendet werden soll.
Es sollen nur ein paar Informationen zu Exchange-Konten ausgelesen, in eine csv-Datei exportiert und per Mail verschickt werden. Wie gesagt: manuell ausgeführt kein Problem, das Script also passt. Die Einstellungen habe ich mit anderen, funktionierenden Aufträgen verglichen: alles gleich. Vier-Augen-Check von einem Kollegen: ich habe mich bei der ps1-Datei verschrieben. Das hätte aber einen Fehler geben müssen. Fehler korrigiert: gleiches Ergebnis.
Was für Lösungen musstet Ihr mal anwenden, damit etwas, das keinerlei Fehler produziert, zumindest sagt, was nicht geht?
Ich, der Jörg
Auf einem 2012 Server mit 2013 Exchange lasse ich einige Dinge automatisiert ablaufen, dazu gibt es diverse PowerShell-Scripts, die per Windows Aufgabenplanung gestartet werden. Alle Scripts laufen wunderbar, nur das neueste will nicht. Das hier passiert:
- direkt in der PS-Console funktioniert es (komplettes Script hineinkopiert)
- per Verknüpfungsaufruf funktioniert es
- beim Aufruf per Aufgabenplanung sehe ich zwar im Taskmanager, dass die PS läuft, es bewegt sich auch ein wenig der Arbeitsspeicher, aber das war es dann auch schon. Die PS wird nicht mehr beendet, obwohl ich angegeben habe, dass sie nach 30 Minuten beendet werden soll.
Es sollen nur ein paar Informationen zu Exchange-Konten ausgelesen, in eine csv-Datei exportiert und per Mail verschickt werden. Wie gesagt: manuell ausgeführt kein Problem, das Script also passt. Die Einstellungen habe ich mit anderen, funktionierenden Aufträgen verglichen: alles gleich. Vier-Augen-Check von einem Kollegen: ich habe mich bei der ps1-Datei verschrieben. Das hätte aber einen Fehler geben müssen. Fehler korrigiert: gleiches Ergebnis.
Was für Lösungen musstet Ihr mal anwenden, damit etwas, das keinerlei Fehler produziert, zumindest sagt, was nicht geht?
Ich, der Jörg
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: 344430
Url: https://administrator.de/contentid/344430
Ausgedruckt am: 25.11.2024 um 14:11 Uhr
17 Kommentare
Neuester Kommentar
Hallo,
an unserem Exchange Server erstelle ich über ein Powershell Script täglich Statistiken die per E-Mail versendet werden. Mit dem direkten Aufruf von Powershell Scripts über die Aufgabenplanung hatte ich auch schon öfters mal Problemchen. Mittlerweile trage ich da eine Batch ein die das Powershell Script aufruft.
Inhalt der Batch ist dann einfach...
Evtl. hilfts...
Gruss
Dirk
an unserem Exchange Server erstelle ich über ein Powershell Script täglich Statistiken die per E-Mail versendet werden. Mit dem direkten Aufruf von Powershell Scripts über die Aufgabenplanung hatte ich auch schon öfters mal Problemchen. Mittlerweile trage ich da eine Batch ein die das Powershell Script aufruft.
Inhalt der Batch ist dann einfach...
powershell.exe -noprofile -executionpolicy bypass -File "C:\pfad\zum\powershellscript.ps1" Evtl. hilfts...
Gruss
Dirk
Hi,
inwieweit das PowerShell Logging hier helfen könnte, hängt von Deinem konkreten Code ab.
Ansonsten könntest Du ein einfaches Debug-Log schreiben lassen. Beginne eine Textdatei und schreibe bei allen neuralgischen Programmschritten "tue gerade dies", "tue gerade das". Wichtig ist, dass das sofort runtergeschrieben wird. Am besten noch mit Zeitangabe. Wenn der Task dann wieder hängt, dann schaust Du ins Log, wie weit er gekommen ist.
E.
inwieweit das PowerShell Logging hier helfen könnte, hängt von Deinem konkreten Code ab.
Ansonsten könntest Du ein einfaches Debug-Log schreiben lassen. Beginne eine Textdatei und schreibe bei allen neuralgischen Programmschritten "tue gerade dies", "tue gerade das". Wichtig ist, dass das sofort runtergeschrieben wird. Am besten noch mit Zeitangabe. Wenn der Task dann wieder hängt, dann schaust Du ins Log, wie weit er gekommen ist.
E.
Hallo emeriks,
er kommt genau bis vor die erste Zeile. Die erste Zeile ist inzwischen nur noch "write-output "Ding" > C:\Tools\test.txt" und nicht einmal das macht er. :-o
Y.
er kommt genau bis vor die erste Zeile. Die erste Zeile ist inzwischen nur noch "write-output "Ding" > C:\Tools\test.txt" und nicht einmal das macht er. :-o
Y.
Der Benutzer, mit welchem der Task läuft, darf aber in "C:\Tools" schreiben?
Überhaupt: "Mit höchsten Privilegien" schon versucht?
Überhaupt: "Mit höchsten Privilegien" schon versucht?
Start-Transcript "c:\pfad\log.txt"
# euer Code
#...
Stop-TranscriptUnter Ausführen "PowerShell.exe" eintragen, unter Argumente -File "c:\pfad\script.ps1"
Gruß
@emeriks: Ja, Rechte sind da. Habe ich gerade nochmal neu durchvererbt und anschließend mit gleichem Ergebnis getestet. "Mit höchsten Privilegien": nein, das wird dann vom Administrator ausgeführt, ich habe für mich aber einen eigenen User (auch Domänen-Admin aber eben mit meinem Namen. Der Original-Admin wird nicht verwendet.)
@exguru: "Start-Transcript" schreibt, dass das Script gestartet wurde und später dann, dass es zu Ende ist. Ende der Info, mehr gibt's nicht.
Es gibt aber Neuigkeiten, ich habe ein wenig herumgespielt:
Ich präzisiere mal, was ich genau mache, was genau nicht funktioniert:
Was nicht funktioniert: Ich will zum Test die Aufgabe manuell jetzt "Ausführen".
Was aber funktioniert, ist: wenn ich nicht die Zeitplanung auf monatlich lege. Stelle ich z.B. "täglich" oder "einmalig" ein, läuft das Ding. Nur, wenn ich "monatlich, jeden 1. jedes Monats" einstelle, kann ich das, obwohl in den Einstellungen steht "Ausführung bei Bedarf zulassen", nicht manuell starten. Das Problem ist also weder das Script noch die Berechtigungen, sondern irgendwas mit dem Taskplaner, der ein Problem damit hat, wenn ich die Aufgabe monatlich einplane.
Im Taskmanager ist währenddessen zu sehen, dass PowerShell bei ca. 30% CPU und 120MB RAM liegt, nach ca. 10 Sekunden ist CPU auf 0% und RAM verliert alle zwei, drei Sekunden ca. 0,3 MB, bis er auf 8,8 MB herunter ist. Da bleibt er dann stehen. Im Taskplaner steht weiterhin "wird ausgeführt", bis ich die Aufgabe manuell wieder beende. Inzwischen ist die Einstellung "Beenden nach" wieder auf Standard 3 Stunden (habe den Task neu angelegt), aber auch das interessiert ihn nicht.
Hat das schon mal jemand gehabt?
*irritiert*
Jörg
@exguru: "Start-Transcript" schreibt, dass das Script gestartet wurde und später dann, dass es zu Ende ist. Ende der Info, mehr gibt's nicht.
Es gibt aber Neuigkeiten, ich habe ein wenig herumgespielt:
Ich präzisiere mal, was ich genau mache, was genau nicht funktioniert:
- Ich lege eine neue Aufgabe an, die unabhängig von der Benutzeranmeldung laufen soll.
- Diese Aufgabe soll an jedem 1. eines Monats morgens um 00:05 Uhr laufen.
- Ich starte ein Programm (PowerShell) und übergebe das Script mitsamt Exchange-Aufruf und allem was dazu gehört als Parameter.
- Es gibt keine Bedingungen und ansonsten die Standard-Einstellungen (Registerkarten vier und fünf).
Was nicht funktioniert: Ich will zum Test die Aufgabe manuell jetzt "Ausführen".
Was aber funktioniert, ist: wenn ich nicht die Zeitplanung auf monatlich lege. Stelle ich z.B. "täglich" oder "einmalig" ein, läuft das Ding. Nur, wenn ich "monatlich, jeden 1. jedes Monats" einstelle, kann ich das, obwohl in den Einstellungen steht "Ausführung bei Bedarf zulassen", nicht manuell starten. Das Problem ist also weder das Script noch die Berechtigungen, sondern irgendwas mit dem Taskplaner, der ein Problem damit hat, wenn ich die Aufgabe monatlich einplane.
Im Taskmanager ist währenddessen zu sehen, dass PowerShell bei ca. 30% CPU und 120MB RAM liegt, nach ca. 10 Sekunden ist CPU auf 0% und RAM verliert alle zwei, drei Sekunden ca. 0,3 MB, bis er auf 8,8 MB herunter ist. Da bleibt er dann stehen. Im Taskplaner steht weiterhin "wird ausgeführt", bis ich die Aufgabe manuell wieder beende. Inzwischen ist die Einstellung "Beenden nach" wieder auf Standard 3 Stunden (habe den Task neu angelegt), aber auch das interessiert ihn nicht.
Hat das schon mal jemand gehabt?
*irritiert*
Jörg
"Mit höchsten Privilegien": nein, das wird dann vom Administrator ausgeführt, ich habe für mich aber einen eigenen User
Gerade dann kann das aber erforderlich sein! Wenn die Aktionen administrative Berechtigungen erfordert, welche über die Gruppe der lokalen Administratoren geerbt werden (u.a. auch Privilegien), dann musst Du die Aufgabe "mit höchsten Privilegien" ausführen oder UAC für diesen Computer komplett deaktivieren.Irgendwie passt der Rest von dem, was Du schreibst, nicht zusammen. Wenn das Problem sein soll, dass Du den Task nicht manuell starten kannst, wenn er auf "monatlich" steht, wie passt das zusammen, dass die Aufgabe auf "wird ausgeführt" stehen soll? Du kannst Sie dann nicht starten, weil sie noch läuft, und nicht, weil es dann wegen "monatlich" nicht geht.
Oder willst Du sagen, dass die Aufgabe (der gestartete PowerShell-Prozess) nur dann hängt, wenn "monatlich" eingestellt ist? Das klingt nonsens.
Dein letzter Satz, der wie Nonsens klingt, ist genau das, was Sache ist. Genau so sieht es aus. Stelle ich auf wöchentlich / täglich / sonstwas: läuft. Stelle ich auf monatlich: läuft nicht.
Ich gehe also mal auf die Suche nach diesem Thema...
Das mit den Rechten und so: der Original-Admin wurde genau zur Erstinstallation der Domäne verwendet und danach nie wieder (Passwort sicher verwahrt und so...). DC und Exchange werden seit rund anderthalb Jahren von mir mit meinem User administriert, der technisch ebenfalls Domänenadmin ist, also alles dürfen sollte. Das Script selbst macht nichts Wildes: Datum in eine Variable rein (für die Dateinamen später), abfragen, wie die Postfachbelegung pro Postfach ist, das Ganze in eine csv exportieren und als Mail versenden. Kein Rechte-Drama also, ein Dreizeiler praktisch).
Ich gehe also mal auf die Suche nach diesem Thema...
Das mit den Rechten und so: der Original-Admin wurde genau zur Erstinstallation der Domäne verwendet und danach nie wieder (Passwort sicher verwahrt und so...). DC und Exchange werden seit rund anderthalb Jahren von mir mit meinem User administriert, der technisch ebenfalls Domänenadmin ist, also alles dürfen sollte. Das Script selbst macht nichts Wildes: Datum in eine Variable rein (für die Dateinamen später), abfragen, wie die Postfachbelegung pro Postfach ist, das Ganze in eine csv exportieren und als Mail versenden. Kein Rechte-Drama also, ein Dreizeiler praktisch).
Dein letzter Satz, der wie Nonsens klingt, ist genau das, was Sache ist. Genau so sieht es aus. Stelle ich auf wöchentlich / täglich / sonstwas: läuft. Stelle ich auf monatlich: läuft nicht.
Du hast meine Fragen nicht beantwortet.Das mit den Rechten und so: der Original-Admin wurde genau zur Erstinstallation der Domäne verwendet und danach nie wieder (Passwort sicher verwahrt und so...). DC und Exchange werden seit rund anderthalb Jahren von mir mit meinem User administriert, der technisch ebenfalls Domänenadmin ist, also alles dürfen sollte. Das Script selbst macht nichts Wildes: Datum in eine Variable rein (für die Dateinamen später), abfragen, wie die Postfachbelegung pro Postfach ist, das Ganze in eine csv exportieren und als Mail versenden. Kein Rechte-Drama also, ein Dreizeiler praktisch).
Wie der User zu seinem Privilegien kommt ist vollkommen egal. Wenn er sie nutzen will und UAC ist aktiviert, dann muss der Prozess eleviert sein. Fertig aus. Bei Aufgabe "höchste Privilegien"Bezogen auf Deinen Fall könnte die Falle beim Speichern der Datei liegen, also wo die CSV gespeichert wird.
Aber egal, ich habe verstanden, dass das Script ja noch nicht einmal zu beginnen scheint, also schon die erste Zeile nicht mehr ausgeführt wird.
Exportiere den Task doch mal bitte als XML damit wir hier nicht raten müssen was du als Argumente etc. "genau" verwendest.
Jupp, geht los:
<?xml version="1.0" encoding="UTF-16"?>
<Task version="1.4" xmlns="http://schemas.microsoft.com/windows/2004/02/mit/task">
<RegistrationInfo>
<Date>2017-07-25T14:52:36.8740918</Date>
<Author>[Domain]\[Admin]</Author>
<Description>Belegungsübersicht der Exchange-Konten erstellen und per Mail versenden</Description>
</RegistrationInfo>
<Triggers>
<CalendarTrigger>
<StartBoundary>2017-07-25T08:15:44</StartBoundary>
<Enabled>true</Enabled>
<ScheduleByMonth>
<DaysOfMonth>
<Day>1</Day>
</DaysOfMonth>
<Months>
<January />
<February />
<March />
<April />
<May />
<June />
<July />
<August />
<September />
<October />
<November />
<December />
</Months>
</ScheduleByMonth>
</CalendarTrigger>
</Triggers>
<Principals>
<Principal id="Author">
<UserId>[Domain]\[Admin]</UserId>
<LogonType>Password</LogonType>
<RunLevel>LeastPrivilege</RunLevel>
</Principal>
</Principals>
<Settings>
<MultipleInstancesPolicy>IgnoreNew</MultipleInstancesPolicy>
<DisallowStartIfOnBatteries>false</DisallowStartIfOnBatteries>
<StopIfGoingOnBatteries>true</StopIfGoingOnBatteries>
<AllowHardTerminate>true</AllowHardTerminate>
<StartWhenAvailable>false</StartWhenAvailable>
<RunOnlyIfNetworkAvailable>false</RunOnlyIfNetworkAvailable>
<IdleSettings>
<StopOnIdleEnd>true</StopOnIdleEnd>
<RestartOnIdle>false</RestartOnIdle>
</IdleSettings>
<AllowStartOnDemand>true</AllowStartOnDemand>
<Enabled>true</Enabled>
<Hidden>false</Hidden>
<RunOnlyIfIdle>false</RunOnlyIfIdle>
<DisallowStartOnRemoteAppSession>false</DisallowStartOnRemoteAppSession>
<UseUnifiedSchedulingEngine>false</UseUnifiedSchedulingEngine>
<WakeToRun>false</WakeToRun>
<ExecutionTimeLimit>P3D</ExecutionTimeLimit>
<Priority>7</Priority>
</Settings>
<Actions Context="Author">
<Exec>
<Command>C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe</Command>
<Arguments>-command ". 'D:\Ex2013\bin\RemoteExchange.ps1'; Connect-ExchangeServer -auto -ClientApplication:ManagementShell;. 'D:\Tools\Scripts\Kontingentstatus_per_Mail.ps1'"</Arguments>
</Exec>
</Actions>
</Task>
Ich kann inzwischen dazu sagen (neuer Test, neues Ergebnis):
Zweimal genau der gleiche Task, genau das gleiche Script, genau die gleiche Einstellung. Einmal "Wöchentlich jeden Donnerstag um 00:05 Uhr" und einmal >> der einzige Unterschied!! << "Monatlich jeden Monat am 1. um 00:10 Uhr": Wöchentlich läuft, monatlich nicht.
Der Export oben stammt aus einem Versuch heut Vormittag, daher eine andere Uhrzeit.
:-o
Zweimal genau der gleiche Task, genau das gleiche Script, genau die gleiche Einstellung. Einmal "Wöchentlich jeden Donnerstag um 00:05 Uhr" und einmal >> der einzige Unterschied!! << "Monatlich jeden Monat am 1. um 00:10 Uhr": Wöchentlich läuft, monatlich nicht.
Der Export oben stammt aus einem Versuch heut Vormittag, daher eine andere Uhrzeit.
:-o
Sooo... ich habe fertig!
Die aktuelle Lösung ist leider nur halbgar, ich beschreibe es hier trotzdem, falls jemand mal an ein ähnliches Problem gerät. Ich habe weder im deutsch- noch im englischsprachigen Internet etwas dazu gefunden und auch der Trainer, bei dem ich aktuell in der Schulung sitze und der seit vielen Jahren Exchange lehrt (und nebenbei auch einen Hosted Exchange betreibt), steht genauso kopfschüttelnd davor, wie ein Kollege, der bereits mehrere hundert Exchange-Server installiert, migriert und betreut hat.
Der geplante Task wird wie folgt aufgerufen:
C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
und als Argument:
-command ". 'D:\Ex2013\bin\RemoteExchange.ps1'; Connect-ExchangeServer -auto -ClientApplication:ManagementShell;. 'D:\ExInfo\Scripts\Kontingentstatus_alle_per_Mail.ps1'"
Das ist genau der gleiche Aufruf, wo auch der Link im Startmenü hinführt, nur dass noch mein Script übergeben wird.
In der RemoteExchange.ps1 (Originaldatei von MS, wird vom Exchange mitgeliefert) wird eine weitere Datei im gleichen Verzeichnis "ConnectionFunctions.ps1" angezogen, ebenfalls von MS mit dem Exchange mitgeliefert. Hier drin ist eine Function, die prüft, ob der Dienst W3SVC (Webserver) läuft.
Wenn der Task auf "täglich" oder "wöchentlich" steht, ist alles korrekt, bei der Einstellung "monatlich" oder "einmalig" wird die boolsche Variable weder mit true noch mit false zurückgeliefert, sie ist dann einfach leer.
Warum das so ist, habe ich nicht weiter geprüft, vielleicht hole ich das nochmal nach.
Meine Abhilfe ist aktuell, dass ich den Rückgabewert in der if-Abfrage manuell auf true gesetzt habe, womit dann alles funktioniert. Ist nicht sauber, aber macht erstmal, was es soll. Ja, ich habe also das Originalscript geändert, das von MS beim Exchange mitgeliefert wird, deswegen meine Eingangsaussage, dass es nur halbgar ist. Bisher habe ich nur keine andere Lösung, außer vielleicht, den Task täglich laufen zu lassen und abzufragen, ob es der erste Tag im Monat ist.
Falls zu dem Umstand, dass die Variable leer bleibt, wenn ich "monatlich" oder "einmalig" ausführen lassen will, jemand was weiß, immer gerne her damit.
Grüße von Jörg!
Die aktuelle Lösung ist leider nur halbgar, ich beschreibe es hier trotzdem, falls jemand mal an ein ähnliches Problem gerät. Ich habe weder im deutsch- noch im englischsprachigen Internet etwas dazu gefunden und auch der Trainer, bei dem ich aktuell in der Schulung sitze und der seit vielen Jahren Exchange lehrt (und nebenbei auch einen Hosted Exchange betreibt), steht genauso kopfschüttelnd davor, wie ein Kollege, der bereits mehrere hundert Exchange-Server installiert, migriert und betreut hat.
Der geplante Task wird wie folgt aufgerufen:
C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
und als Argument:
-command ". 'D:\Ex2013\bin\RemoteExchange.ps1'; Connect-ExchangeServer -auto -ClientApplication:ManagementShell;. 'D:\ExInfo\Scripts\Kontingentstatus_alle_per_Mail.ps1'"
Das ist genau der gleiche Aufruf, wo auch der Link im Startmenü hinführt, nur dass noch mein Script übergeben wird.
In der RemoteExchange.ps1 (Originaldatei von MS, wird vom Exchange mitgeliefert) wird eine weitere Datei im gleichen Verzeichnis "ConnectionFunctions.ps1" angezogen, ebenfalls von MS mit dem Exchange mitgeliefert. Hier drin ist eine Function, die prüft, ob der Dienst W3SVC (Webserver) läuft.
Wenn der Task auf "täglich" oder "wöchentlich" steht, ist alles korrekt, bei der Einstellung "monatlich" oder "einmalig" wird die boolsche Variable weder mit true noch mit false zurückgeliefert, sie ist dann einfach leer.
Warum das so ist, habe ich nicht weiter geprüft, vielleicht hole ich das nochmal nach.
Meine Abhilfe ist aktuell, dass ich den Rückgabewert in der if-Abfrage manuell auf true gesetzt habe, womit dann alles funktioniert. Ist nicht sauber, aber macht erstmal, was es soll. Ja, ich habe also das Originalscript geändert, das von MS beim Exchange mitgeliefert wird, deswegen meine Eingangsaussage, dass es nur halbgar ist. Bisher habe ich nur keine andere Lösung, außer vielleicht, den Task täglich laufen zu lassen und abzufragen, ob es der erste Tag im Monat ist.
Falls zu dem Umstand, dass die Variable leer bleibt, wenn ich "monatlich" oder "einmalig" ausführen lassen will, jemand was weiß, immer gerne her damit.
Grüße von Jörg!
Wieso nutzt du nicht New-PSSession um eine Verbindung zum Exchange herzustellen?? Geht schnell und schmerzlos und von überall auch ohne Exchange Modul.
Zitat von @133883:
Wieso nutzt du nicht New-PSSession um eine Verbindung zum Exchange herzustellen?? Geht schnell und schmerzlos und von überall auch ohne Exchange Modul.
Führt ebenso zu einem Fehler. Der sieht anders aus, den habe ich nicht verfolgt, es passiert aber unter den gleichen Umständen: "täglich" geht, "monatlich" liefert den Fehler. Den habe ich noch nicht verfolgt, aber ich nehme mal an, dass da die gleichen Exchange-Scripts angezogen werden, macht ja wenig Sinn, dass die das Rad doppelt erfinden.Wieso nutzt du nicht New-PSSession um eine Verbindung zum Exchange herzustellen?? Geht schnell und schmerzlos und von überall auch ohne Exchange Modul.
Nein, dem ist nicht so. Die Exchange Tools binden noch einige normalerweise für einfache Dinge überflüssige Serialization Skripte mit ein und das ist anfälliger als mit PSSession die pure Verbindung zur Nutzung der CMDLets herzustellen.
