Über PowerShell eine .exe ausführen lassen

Liebe Community,

ich arbeite derzeit an einer GPO, die ein PowerShellscript enthält über die ein paar dinge geschehen sollen.
Das Script soll überprüfen, ob ein bestimmter Ordner im User-Verzeichnis vorhanden ist und diesen ggf. anlegen, und anschließend zwei Dateien hinein legen.
Einer dieser beiden Dateien ist eine .exe-Datei, die anschließend ausgeführt werden soll.
Die User haben die Berechtigung die entsprechende .exe auszuführen.
Der Server der alles Steuert ist ein Server2019 und die Clients sind Win10 auf aktuellstem UpDate.
Ich habe beim anlegen der GPO auch darauf geachtet, die entsprechenden Einstellungen für PowerShellscripte vorzunehmen, damit diese überhaupt mittels GPO angesteuert werden können. (Stichwort richtiger Ordner für das Script, einstellung des Delay-Timer, Leseberechtigung auf den Ordner des Scriptes, etc)

Was klappt:
Die GPO greift und führt das Script aus, der Ordner wird angelegt die Dateien hinkopiert.

Was nicht klappt:
Die .exe-Datei wird anschließend nicht ausgeführt...

Navigiere ich vom Client zum Script auf dem Server und lasse es so durchlaufen, so läuft alles wie es soll, aber beim einloggen der User startet die .exe nicht, obwohl es bestandteil des Scriptes ist und das Script ansonsten wie gewünscht ausgeführt wird.

Im Folgenden mal mein Skrippt (Original Namen verändert)

function Get-ScriptDirectory {
    $Invocation = (Get-Variable MyInvocation -Scope 1).Value
    Split-Path $Invocation.MyCommand.Path
}

$installpath = Get-ScriptDirectory

$ProgrammLocalPath = "$ENV:UserProfile\Appdata\local\Programm\"  

$ProgrammSourcePath = "$installpath\Programm\"  

$ProgrammExe = "Programm.exe"  

$ProgrammIniPath = "Programm.ini"  

$ProgrammExePath = $ProgrammSourcePath + $ProgrammExe 
$ProgrammIniPath = $ProgrammSourcePath + $ProgrammIniPath 
$ProgrammLocalExePath = $ProgrammLocalPath + $ProgrammExe 


if (-NOT (Test-Path $ProgrammLocalPath)) {
    New-Item -ItemType Directory $ENV:UserProfile\Appdata\local\Programm
    Copy-Item $ProgrammExePath -Destination $ProgrammLocalPath 
    Copy-Item $ProgrammIniPath -Destination $ProgrammLocalPath 
        
}
else {
    if (-NOT (Test-Path $ProgrammLocalExePath)) {
        Copy-Item $ProgrammExePath -Destination $ProgrammLocalPath 
    }

        Copy-Item $ProgrammIniPath -Force -Destination $ProgrammLocalPath
}

$Command = $ProgrammLocalPath + $ProgrammExe
$Argument1 = "/ini=$ProgrammIniPath"  

& $Command $Argument1

Wie bereits gesagt, führe ich das Script händisch aus, startet das Script die .exe wie gewünscht, aber beim einloggen der User führt es nur die Copy-Jobs aus...

Hat einer eine Idee woran es liegen könnte und wie ich es umsetzen kann dass es beim einloggen der User startet?

Besten Dank im Vorraus

littleAdm

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

Content-ID: 535810

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

Ausgedruckt am: 17.11.2024 um 09:11 Uhr

7 Kommentare

Neuester Kommentar

Moin,

das würde ich vollkommen anders regeln:

Verteilen der Dateien über Benutzer- oder Computerkonfiguration -> Einstellungen -> Windows-Einstellungen -> Dateien
Verknüpfung im Autostart des Users über den gleichen Weg nur am Ende nicht Dateien, sondern Verknüpfungen.

Das sollte funktionieren.

hth

Erik

Moin,

Zitat von @erikro:
das würde ich vollkommen anders regeln:

Verteilen der Dateien über Benutzer- oder Computerkonfiguration -> Einstellungen -> Windows-Einstellungen -> Dateien
Verknüpfung im Autostart des Users über den gleichen Weg nur am Ende nicht Dateien, sondern Verknüpfungen.

Wäre auch mein Vorschlag.

Zu deinem Problem.
Ich vermute, das Script wird nicht im Kontext des angemeldeten Users ausgeführt!?

Gruß
em-pie

Vielleicht verstehe ich da etwas falsch, aber das Script selbst muss doch im Kontext des angemeldeten Users ausgeführt werden, damit der Pfad "$ENV:UserProfile\Appdata\local\Programm\" also übersetzt "%userprofile%\Appdata\local\Programm\" erkannt werden kann.

Da der Copy-Job dahin allerdings reibungslos läuft, ziehe ich den Schluss daraus -und bitte Korrigiert mich wenn ich falsch liege- dass das Script selbst im Kontext des Users ausgeführt wird. Daher sollte der Aufruf "& $Command $Argument1" auch im Kontext geschen!?

Wenn dem nicht so sein sollte, wie kann ich es einrichten, dass es im Kontext ausgeführt wird?

Ja, das kann man natürlich auch so machen, aber hier wurde intern entschieden es über das Script zu machen, da es uns schnellere Anpassungen bietet.

Moin,

logon scripts laufen grundsätzlich im Userkontext. Daran kann es nicht liegen. Findet sich vielleicht was Hilfreiches in den Protokollen? Eventuell ist ein Dienst, den das Programm braucht, noch nicht fertig. Dann würde ein

start-sleep 20

helfen. Eventuell mehr oder weniger als 20 Sekunden. Das musst Du ausprobieren.

Liebe Grüße

Erik

logon scripts laufen grundsätzlich im Userkontext. Daran kann es nicht liegen. Findet sich vielleicht was Hilfreiches in den Protokollen? Eventuell ist ein Dienst, den das Programm braucht, noch nicht fertig. Dann würde ein

Ja, an sowas erinnere ich mich auch.

> start-sleep 20
> 

helfen. Eventuell mehr oder weniger als 20 Sekunden. Das musst Du ausprobieren.

Danke für den Hinweis, werd ich ausprobieren. Kann aber erst ende nächster Woche Rückmeldung geben, da ich bis Mittwoch an einem anderen Standort sein werde und es erst dann wieder versuchen kann und heute auch nicht mehr dazu kommen werde.

Bis dahin habe ich mich zur Zeit mit einer Batch-Datei beholfen, da das sofort lief. Wäre aber natürlich schöner wenn alles in einem Script laufen würde.

Ich gebe dann Rückmeldung

Guten Morgen,

also es hat mir keine Ruhe gelassen, daher bin ich heute ins Büro gefahren und musste es ausprobieren.
Resultat: Die Anmeldung selbst verzögerte sich um die angegebene Zeit, sorgte aber nicht dafür dass die .exe schlussendlich ausgeführt wird.

Muss also leider weiterhin mit der Notlösung der Batch-Datei arbeiten. Aber danke für deinen Vorschlag.