none
Powershell und Task Scheduler Problem RRS feed

 > 

  • Frage

  • Question
    Anmelden
    0
    Anmelden

    Hallo zusammen,

    ich habe Probleme damit über den Task Scheduler ein Powershell Skript zur Ausgabe zu bewegen.

    Das Skript macht folgendes:

    Wenn ein Benutzer ein Zertifikat beantragt und der CA Admin dies ausgsstellt hat, sendet das Skript eine Email mit dem darin enthaltenen Zertifikat (das Skript schaut zwei Tage zurück, welche Zertifikate ausgestellt worden sind und sendet diese an die entsprechenden Personen).

    Dies funktioniert auch ohne Probleme beim manuellen ausführen (über Powershell oder CMD). Richte ich dafür einen Scheduled task ein, so läuft dieser scheinbar ohne Probleme durch (Return code 0). Hierfür wird allerdings keine Email generiert.

    Folgendes habe ich gemacht/überprüft:

      - Benutzer hat die benötigten Rechte zum Ausführen

      - Run with highest privileges

      - Start a program

      - Program/script : powershell

       - Add arguments (optional): -File "C:\path\file.ps1"

    Das ganze läuft auf einem Windows server 2012r.

    Meine Vermutung ist, dass das Skript gar nicht richtig ausgeführt wird. Hierfür wollte ich mir den Output einmal anschauen und habe dafür das "add arguments (optional)" - Feld erweitert ==> -File "C:\path\file.ps1" > test.txt

    Allerdings sehe ich dort keinen Output in dem File.

    Ebenfalls hatte ich schon mal versucht den Aufruf in ein Batch- File zu packen und dieses im Task Scheduler ausführen zu lassen. Auch ohne Erfolg leider

    Hat hier jemand vielleicht eine Idee?

    Vielen Dank im Vorraus und Grüße,

    MasterX

    Mittwoch, 19. Juli 2017 13:14
    |

Antworten

  • Question
    Anmelden
    0
    Anmelden
    Du könntest vielleicht eine einfache Loggingfunktion ins Script einbauen .... 

    Grüße - Best regards

    PS:> (79,108,97,102|%{[char]$_})-join''

    Mittwoch, 19. Juli 2017 14:48
    |
  • Question
    Anmelden
    0
    Anmelden

    > "add arguments (optional)" - Feld erweitert ==> -File "C:\path\file.ps1" > test.txt

    Ergänzend zu dem, was schon gesagt wurde: Es gibt ein Logging-Modul in der Gallery, das sich in alle Output-Streams einklinkt. Damit kannst Du IN deinem Skript ganz einfach protokollieren, wenn Du denn auch schon eine Bildschirmausgabe realisiert hast.

    Die > Umleitung ist keine Funktion der Shell (Windows) oder von Powershell, sondern von cmd.exe. Damit das geht, mußt Du cmd /c davor hängen. Und wenn Du - siehe oben - keine Bildschirmausgabe in Deinem Skript hast, dann siehst Du natürlich auch nix. Ach ja, ein 2>&1 sollte da auf jeden Fall auch noch angehängt werden, sonst kriegst nur StdOut, aber nicht StdErr :-)

    Mittwoch, 19. Juli 2017 18:23
    |

Alle Antworten

  • Question
    Anmelden
    0
    Anmelden
    Du könntest vielleicht eine einfache Loggingfunktion ins Script einbauen .... 

    Grüße - Best regards

    PS:> (79,108,97,102|%{[char]$_})-join''

    Mittwoch, 19. Juli 2017 14:48
    |
  • Question
    Anmelden
    0
    Anmelden
    Probier mal aus, ob die Task als angemeldeter User funktioniert.
    Häufig ist der Grund, dass bei unbeaufsichtigter Ausführung bestimmte Ressourcen nicht zur Verfügung stehen (Netzwerk, COM-Objekte, z.B. Mail-Client usw.), da diese vom TaskScheduler grundsätzlich nicht zur Verfügung gestellt werden.
    Mittwoch, 19. Juli 2017 14:54
    |
  • Question
    Anmelden
    1
    Anmelden
    Probier mal aus, ob die Task als angemeldeter User funktioniert.
    Häufig ist der Grund, dass bei unbeaufsichtigter Ausführung bestimmte Ressourcen nicht zur Verfügung stehen (Netzwerk, COM-Objekte, z.B. Mail-Client usw.), da diese vom TaskScheduler grundsätzlich nicht zur Verfügung gestellt werden.

    Moin,

    das sagst Du hier im Forum nicht zum ersten Mal. Aber ist es so? Ich habe haufenweise Skripte, die auf alle möglichen Netzwerkressourcen zugreifen (Exchange-Remoting, SQL-Datenbanken, Dateien auf Shares, Send-MailMessage, Invoke-Webrequest, Invoke-RESTMethod usw.) Und alle laufen sie auf irgendwelchen Skriptschleudern, wo sich nie jemand interaktiv anmeldet... Vielleicht muss man hier differenzieren. Hast Du einen aktuellen Link, wo die Einschränkungen beschrieben sind?

    Was ich mir im Task Scheduler-Betrieb angewöhnt habe, ist

    - den Pfad zur PowerShell.EXE ausschreiben (manchmal braucht man sie in 32-Bit, dann muss man eh)

    - ExecutionPolicy explizit bypassen, auch wenn sie sonst verträglich gesetzt ist

    - dem ausführenden User per GPO noch einmal das Recht geben, sich als Batch anzumelden

    Der Hinweis mit dem Logging aus dem Skript heraus in eine lokale Datei ist genau richtig. Fürs erste einfach mal am Anfang des Skriptes irgendwas in ein Textfile ausgeben. Dann sieht man, ob das Skript überhaupt aufgerufen wird.

    Evgenij Smirnov

    I work @ msg services ag, Berlin -> http://www.msg-services.de
    I blog (in German) @ http://it-pro-berlin.de
    my stuff in PSGallery --> https://www.powershellgallery.com/profiles/it-pro-berlin.de/
    Exchange User Group, Berlin -> http://exusg.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com


    Mittwoch, 19. Juli 2017 16:35
    |
  • Question
    Anmelden
    0
    Anmelden

    > "add arguments (optional)" - Feld erweitert ==> -File "C:\path\file.ps1" > test.txt

    Ergänzend zu dem, was schon gesagt wurde: Es gibt ein Logging-Modul in der Gallery, das sich in alle Output-Streams einklinkt. Damit kannst Du IN deinem Skript ganz einfach protokollieren, wenn Du denn auch schon eine Bildschirmausgabe realisiert hast.

    Die > Umleitung ist keine Funktion der Shell (Windows) oder von Powershell, sondern von cmd.exe. Damit das geht, mußt Du cmd /c davor hängen. Und wenn Du - siehe oben - keine Bildschirmausgabe in Deinem Skript hast, dann siehst Du natürlich auch nix. Ach ja, ein 2>&1 sollte da auf jeden Fall auch noch angehängt werden, sonst kriegst nur StdOut, aber nicht StdErr :-)

    Mittwoch, 19. Juli 2017 18:23
    |
  • Question
    Anmelden
    0
    Anmelden

    danke schon mal für die Antworten.

    Es scheint tatsächlich ein Benutzer Problem zu sein. Obwohl der verwendete Benutzer volle Admin Rechte hat, verweigert das Skript den Start.

    Wenn ich den Scheduled Task als Administrator laufen lasse, dann funktioniert alles wunderbar.

    Jedoch kann ich dann nicht die Option "Run whether user is logged on or not setzen.

    Jemand noch eine Idee?

    Viele Grüße,

    MasterX

    Donnerstag, 20. Juli 2017 13:56
    |