5
PowerShell Skript mit Windows Aufgabenplanung starten
Hallo zusammen,
ich bin gerade etwas am verzweifeln.
Ich habe eine Windowsaufgabe erstellt die ein Powershell Skript ausführen soll. Das PowerShell Skript liegt auf einem Netzwerkpfad, wo der Server drauf Zugriff hat.
Eingebunden habe ich das wie folgt unter Aktionen:
Programm/Skript:
C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
Argumente hinzufügen(optional): -command "G:\FD_50_Bank\System\Prosoz Batch Verwaltung\Skripts\StartManager.ps1"
Wenn ich das nun manuell ausführe über die Aufgabenplanung, dann erscheint kurz das Powershell fenster und schließt wieder sofort. Ab und an seh ich auch eine rote Meldung, kann aber nicht lesen was es ist.
Gehe ich nun direkt zum Skript und führe das Skript über den ISE aus, funktioniert alles problemlos. Ich verstehe nicht, warum und welche Probleme die Windows Aufgabenplanung hat.
Zusatz: Ich habe das Gefühl, das es was mit dem Netzwerkpfad zu tun hat. Skripte, die auf dem Desktop des Servers abgelegt sind, werden ohne Probleme ausgeführt.
ich bin gerade etwas am verzweifeln.
Ich habe eine Windowsaufgabe erstellt die ein Powershell Skript ausführen soll. Das PowerShell Skript liegt auf einem Netzwerkpfad, wo der Server drauf Zugriff hat.
Eingebunden habe ich das wie folgt unter Aktionen:
Programm/Skript:
C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
Argumente hinzufügen(optional): -command "G:\FD_50_Bank\System\Prosoz Batch Verwaltung\Skripts\StartManager.ps1"
Wenn ich das nun manuell ausführe über die Aufgabenplanung, dann erscheint kurz das Powershell fenster und schließt wieder sofort. Ab und an seh ich auch eine rote Meldung, kann aber nicht lesen was es ist.
Gehe ich nun direkt zum Skript und führe das Skript über den ISE aus, funktioniert alles problemlos. Ich verstehe nicht, warum und welche Probleme die Windows Aufgabenplanung hat.
Zusatz: Ich habe das Gefühl, das es was mit dem Netzwerkpfad zu tun hat. Skripte, die auf dem Desktop des Servers abgelegt sind, werden ohne Probleme ausgeführt.
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 482015
Url: https://administrator.de/contentid/482015
Printed on: April 19, 2024 at 03:04 o'clock
5 Comments
Latest comment
Moin,
ändere den Pfad in einen UNC Pfad und teste das dann.
GGfs. muss noch der Kontext des ausführenden Users in der Aufgabenplanung geändert werden.
Das sind die beiden Klassiker.
Gruss
ändere den Pfad in einen UNC Pfad und teste das dann.
GGfs. muss noch der Kontext des ausführenden Users in der Aufgabenplanung geändert werden.
Das sind die beiden Klassiker.
Gruss
Moin,
1. ISE eignet sich nie zum Testen. Teste immer auf einer Shell.
2. Ist das Laufwerk G: im Moment der Ausführung im Kontext des Users, unter dem das ausgeführt wird, vorhanden? Und hat dieser User Leserechte auf das LW G:?
3. Deshalb, wie @sabines schon sagte: In Skripten nie relative Pfade oder Netzwerklaufwerke, sondern immer komplette Pfade und UNC nutzen.
hth
Erik
1. ISE eignet sich nie zum Testen. Teste immer auf einer Shell.
2. Ist das Laufwerk G: im Moment der Ausführung im Kontext des Users, unter dem das ausgeführt wird, vorhanden? Und hat dieser User Leserechte auf das LW G:?
3. Deshalb, wie @sabines schon sagte: In Skripten nie relative Pfade oder Netzwerklaufwerke, sondern immer komplette Pfade und UNC nutzen.
hth
Erik
Hi,
beim manuellen Testen mal die Option "-NoExit" hinzufügen. Damit bleibt das Fenster stehen und man kann die Meldungen lesen.
E.
beim manuellen Testen mal die Option "-NoExit" hinzufügen. Damit bleibt das Fenster stehen und man kann die Meldungen lesen.
powershell.exe -NoExit -command "G:\FD_50_Bank\System\Prosoz Batch Verwaltung\Skripts\StartManager.ps1" E.
-command "G:\FD_50_Bank\System\Prosoz Batch Verwaltung\Skripts\StartManager.ps1"
Das ist falsch, wenn über Command dann so-Executionpolicy ByPass -NoProfile -command "&'G:\FD_50_Bank\System\Prosoz Batch Verwaltung\Skripts\StartManager.ps1'" Außerdem ist zu beachten das gemappte Laufwerke des Users nicht in die Session wandern wenn es in einem anderen User-Kontext läuft!! Hier also besser immer UNC Pfade benutzen und Berechtigungen des verwendeten Users in der Aufgabenplanung auf die Freigabe checken.
Danke, das mit dem UNC Pfad und dem richtigen Command hat geklappt.
