28.04.2023, aktualisiert um 08:19:36 Uhr

1844

Aufgabenplanung: Job beendet nicht

Hallo,

ich möchte über die Aufgabenplanung ein PS-Script ausführen, das eine Software (exe) installiert.
Der Job soll beim Hochfahren starten und unter System laufen.
Alle Dateien liegen lokal, die ExecutionPolicy ist auf Unrestricted.

Beim Hochfahren wird der Job auch gestartet, die Installation wird aber nicht durchgeführt.
Der Job bleibt dann im Status "wird ausgeführt". Im Prozessexplorer ist keine Aktion zu erkennen.

Setup und Script sind fehlerfrei. Manuell ausgeführt, auch unter System, funktioniert alles.

Der relevante Teil im Script lautet:

$SetupFile = 'C:\Pfad\zur\Setup.exe'  
$Args = '/S user=all'  

$Setup = [Diagnostics.Process]::Start($SetupFile, $Args)
$Setup.WaitForExit()

Derselbe Code funktioniert in einem über GPO gestarteten Startup-Script fehlerfrei.

Beim alternativen Aufruf ist das Verhalten identisch:

Start-Process -FilePath $SetupFile -Argumentlist $Args -Wait

Ich habe es auch mit direkt eingetragenen Variablen, ohne Wait und mit Verzögerung versucht. Selbes Ergebnis.
Ein Test mit dem Trigger "Bei der Anmeldung" hat funktioniert.

Den Pfad zur Exe und die Argumente direkt im Job eingetragen funktioniert auch.
Das ist aber keine Lösung, weil das Script noch mehr macht.

Woran kann das liegen?

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 6943469037

Url: https://administrator.de/contentid/6943469037

Ausgedruckt am: 21.11.2024 um 22:11 Uhr

14 Kommentare

Neuester Kommentar

Start-Transcript und verbose parameter ins Skript einbauen und log studieren.
Zusätzlich das Install-Log des Setups aktivieren und auswerten (MSI-Log?).

Manche Setups benötigen eine aktive GUI-Session damit sie funktionieren wenn sie besch. programmiert sind, so meine Glaskugel und ohne weitere Info zum Setup oder Programm.

Cheers briggs

Hi briggs,

das hatte ich schon versucht, allerdings gibt's da nicht viel zu studieren:
Nach

**********************
Die Aufzeichnung wurde gestartet. Die Ausgabedatei ist "C:\ProgramData\***\***.log".  

kommt nichts mehr.

Interessant ist allerdings, dass Einträge, die das Script ins AppLog schreibt, erstellt werden.
Es funktioniert alles bis zum Aufruf der Exe.
Das Setup wird gar nicht gestartet, zumindest taucht es nicht im Prozessexplorer auf.

Es handelt sich um das Setup für FileZilla.
Die Installation läuft einwandfrei, wenn es als Start-up-Script ausgeführt wird.

Verrätst du uns um welches Setup es sich handelt? EDIT: " FileZilla." - Guten Morgen.

Als scheduled Task getestet und funktioniert:

Ausführen als System
Aktion = Programm starten
Programm = powershell
Argumente = -ep bypass -file D:\a.ps1
a.ps1:

Start-Process "D:\FileZilla_3.64.0_win64-setup.exe" -ArgumentList "/S user=all" -Wait  

Exportierter Task (Pfad zu ps1 anpassen)
-Thomas

Thomas,

/S = Silent
Es ist das aktuelle Setup für FileZilla, hab's aber auch mit der alten Version getestet.

Jo ich hab's zu spät gesehen. Hab meinen Kommentar oben bearbeitet.

-Thomas

Zitat von @3063370895:
Als scheduled Task getestet und funktioniert:

Kann ich bestätigen läuft hier auch einwandfrei.

Ist da vielleicht noch eine andere Version oder Registry-Überreste einer vorherigen Installation vorhanden?

Erstmal Danke für die Infos.
Allerdings hatte ich das alles genauso eingestellt und getestet.
Reste aus der Registry kann man ausschließen, ich habe sowohl mit einer leeren VM als auch mit einer bestehenden, funktionierenden Vorinstallation (3.63.0) getestet.

@3063370895 Der Unterschied zu meinem Task ist der fehlende BootTrigger und die 'Höchsten Berechtigungen':

<Triggers>
    <BootTrigger>
      <Enabled>true</Enabled>
    </BootTrigger>
  </Triggers>
  <Principals>
    <Principal id="Author">  
      <UserId>S-1-5-18</UserId>
      <RunLevel>HighestAvailable</RunLevel>
    </Principal>
  </Principals>

Und exakt da liegt der Hase im Pfeffer.
Der Task, und somit auch das Script, funktioniert einwandfrei, wenn ich ihn manuell, bei der Anmeldung und mglw. auch mit anderen Triggern starten lasse.
Sobald 'Beim Systemstart' eingestellt ist, tritt das besagte Verhalten auf.
Andere Aufrufe mit BootTrigger bspw. msiexec /i .... funktionieren.

Der Unterschied zu meinem Task ist der fehlende BootTrigger und die 'Höchsten Berechtigungen':

Das Häkchem muss man bei Verwenden des Principles "SYSTEM" gar nicht setzen, SYSTEM läuft eh immer mit höchsten Privilegien, das macht in dem Fall keinen Unterschied.
Habe das hier mit Boot-Trigger ebenfalls gerade mal getestet, läuft hier ebenfalls ohne Fehler durch!

Achtung! Das funktioniert nur wenn du einen "richtigen Neustart" machst, wenn der Hybride Standby (Fastboot) aktiviert ist triggert das nicht bei Herunterfahren und wieder anmachen sondern nur bei "Restart".

Hier noch mein Task als Export:

<?xml version="1.0" encoding="UTF-16"?>  
<Task version="1.3" xmlns="http://schemas.microsoft.com/windows/2004/02/mit/task">  
  <Triggers>
    <BootTrigger>
      <Enabled>true</Enabled>
    </BootTrigger>
  </Triggers>
  <Principals>
    <Principal id="Author">  
      <UserId>S-1-5-18</UserId>
      <RunLevel>LeastPrivilege</RunLevel>
    </Principal>
  </Principals>
  <Settings>
    <MultipleInstancesPolicy>IgnoreNew</MultipleInstancesPolicy>
    <DisallowStartIfOnBatteries>true</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>true</UseUnifiedSchedulingEngine>
    <WakeToRun>false</WakeToRun>
    <ExecutionTimeLimit>PT72H</ExecutionTimeLimit>
    <Priority>7</Priority>
  </Settings>
  <Actions Context="Author">  
    <Exec>
      <Command>powershell</Command>
      <Arguments>-ep bypass -File C:\temp\install.ps1</Arguments>
    </Exec>
  </Actions>
</Task>

Works as designed!

Danke für die Tipps.

FastBoot ist deaktiviert. Ich habe sämtliche Tests aber mit Neustart ausgeführt.
Der Task funktioniert auch, es hakt ausschl. beim Start des Prozesses, und auch das nur, wenn er beim Systemstart ausgeführt wird.

Ich werde das morgen nochmals mit einer weiteren Testmaschine probieren.
Vielleicht ist ja an der VM was im Argen.

In einer neuen VM, ohne Domäne, Richtlinien etc. tritt genau dasselbe Verhalten auf.
Auch unter einem lokalen Adminkonto und mit 30 Sekunden Verzögerung getestet.

In dem Script ist lediglich ein einzige Zeile:

Start-Process C:\ProgramData\FileZilla\FileZilla_win64-setup.exe

Führe ich es in der Session aus funktioniert es problemlos:

powershell.exe -file C:\ProgramData\FileZilla\test.ps1

Start-Transcript protokoliert nichts, ebenso -RedirectStandardOutput

Moin.

Zitat von @gemini:
In dem Script ist lediglich ein einzige Zeile:

Start-Process C:\ProgramData\FileZilla\FileZilla_win64-setup.exe

Das verwundert ehrlich gesagt nicht ... Musst du schon mit silent parametern ausführen sonst wartet das Ding bis in alle Ewigkeit auf Benutzereingaben!! 🐟

Schau dir mal die Zeilen oben in den Beiträgen genau an.

Gruß

Hi Ultramatic,

falsche Zeile kopiert, das war ein Aufruf in der PS um zu sehen ob überhaupt was passiert.

Der korrekte Aufruf war:

Start-Process -FilePath C:\ProgramData\FileZilla\FileZilla_win64-setup.exe -ArgumentList "/S user=all" -Wait  

Wobei ich alle möglichen Varianten durchprobiert habe.

Es hängt ausschließlich, sobald

[Diagnostics.Process]::Start($SetupFile, $Args)

oder

Start-Process -FilePath $SetupFile -Argumentlist $Args -Wait

beim Systemstart aus dem Script ausgeführt werden.

Dasselbe Script als Startupscript über GPO funktioniert.

Habe den oben geposteten Task aus diesem Kommentar getestet.

Mein Fazit: Funktioniert absolut fehlerfrei in einer cleanen Windows 10/11 VM.

Muss also irgendwo noch ein Fehler auf deiner Seite sein, nachdem es nun bei allen außer dir hier funktioniert.

Gruß