Jump to content

PowerShell Abmeldeskript via GPO funktioniert nicht


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

Nachtrag: Wenn ich auf dem Windows 10 NB, auf welchem in Windows 10 Startmenü die Verknüpfungen per Abmeldeskript gelöscht werden sollen, via Datei Explorer zum Pfad \\DomainXY.ocal\NETLOGON\Scripts\ wechsle und dann via rechte Maustaste auf das PS Skript CleanUp-FolderStartup.ps1 klicke und im Kontextmenü den Befehl auswähle, "Mit PowerShell ausführen", dann läuft das Skript durch.

 

Führe ich aber in der PS Konsole den Befehl via UNC Pfad aus, also  ."\\DomainXY.local\NETLOGON\Scripts\CleanUp-FolderStartup.ps1" dann kommt die Meldung ...kann nicht geladen werden, da die Ausführung von Skripts auf diesem System deaktiviert ist

 

Get-ExecutionPolicy = restricted

 

Darum habe ich mal das Skript erweitert in Bezug ExecutionPolicy, und wieder in der PS Konsole (NICHT mit admin gestartet, sondern mit den User Rechten) und wieder direkt den Befehl via UNC Pfad ausgeführt, nämlich  ."\\DomainXY.local\NETLOGON\Scripts\CleanUp-FolderStartup.ps1" dann erscheint aber nach wie vor die Meldung kann nicht geladen werden, da die Ausführung von Skripts auf diesem System deaktiviert ist

 

 

vor 5 Minuten schrieb daabm:

Dann machst Du jetzt mal ne normale Commandline auf (keine Powershell!) und gibst da ein

powershell -file <DeinUNCPfadausderGPO>

Und dann schau, was passiert.

 

PS: Was ich von Skripts aus UNC-Pfaden halte? Nichts...

Ich schaue später gleich, was passiert und werde deinen Tippe umsetzen und testen.

Jedoch frage ich trotzdem zurück, auch wenn Du nichts von UNC Pfaden haltest: Gibt es einen Grund, für diese Haltung?

Mein Skript sieht nun so aus

 

--------------

### Ausführung von PS Skripts erlauben
Set-ExecutionPolicy -ExecutionPolicy Bypass -Force

 

### Definition des Suchpfades
$Suchverzeichnis = "$Env:APPDATA\Microsoft\Windows\Start Menu\Programs\Startup"

 

### zu löschende Dateien suchen und in Variablen speichern
$Outlook = Get-ChildItem -Path $Suchverzeichnis -Recurse | Where-Object {$_.FullName -match "Outlook"}
$Edge = Get-ChildItem -Path $Suchverzeichnis -Recurse | Where-Object {$_.FullName -match "Edge"}

 

### Dateien löschen
$Outlook , $Edge  | Remove-Item -Force -Confirm:$False

--------------

Link zu diesem Kommentar
vor 23 Minuten schrieb andrew:

Darum habe ich mal das Skript erweitert in Bezug ExecutionPolicy, und wieder in der PS Konsole (NICHT mit admin gestartet, sondern mit den User Rechten) und wieder direkt den Befehl via UNC Pfad ausgeführt, nämlich  ."\\DomainXY.local\NETLOGON\Scripts\CleanUp-FolderStartup.ps1" dann erscheint aber nach wie vor die Meldung kann nicht geladen werden, da die Ausführung von Skripts auf diesem System deaktiviert ist

Du schreibst es selbst sehr deutlich. Lies dir das doch einfach mal ganz laut vor, dann fällt sicherlich der Groschen. ;)

Link zu diesem Kommentar

Und noch eine kurze Bemerkung zu deinem Input, lieber daabm. Du hast geschrieben: "PS: Was ich von Skripts aus UNC-Pfaden halte? Nichts..."

Dazu kann ich folgendes sagen/ schreiben: Wenn ich auf dem NB mit Windows 10 (mein Test Objekt) den Befehl rsop.msc ausführe und prüfe, was konkret sonst noch an Abmelde Skripts ausgeführt werden, dann sind es genau deren 2

 

- 1x ein .bat File

- 1x ein .vbs File

 

Beide Abmeldeskripts, welche neben meinem PS Abmeldeskript ebenfalls angewendet werden, liegen genau, wie mein PS Skript auch, im Pfad \\DomainXY.local\netlogon\Scripts\ Und: sind schon lange im Einsatz, funktionieren tadellos.

 

Warum soll dann mein PS Skript im gleichen Pfad NICHT funktionieren?

Ich verstehe es einfach nicht!

vor 1 Minute schrieb Sunny61:

Du schreibst es selbst sehr deutlich. Lies dir das doch einfach mal ganz laut vor, dann fällt sicherlich der Groschen. ;)

 

Weiss ich nicht, ob um diese Zeit bei mir der Groschen noch fällt, darum rate ich mal :-)

Admin Rechte? 

 

Wenn ich aber wie oben beschrieben die Sache in der GPO aufrufe, Ihr habt nun einen Schreenshot, an Info Material fehlt es glaube ich nicht *smile*, da kann ich auch keine Admin Rechte mitgeben, wenn Du auf das hinauswillst?

vor 9 Minuten schrieb cj_berlin:

### Ausführung von PS Skripts erlauben
Set-ExecutionPolicy -ExecutionPolicy Bypass -Force

Das sehe ich andauernd. Was glaubst Du, was diese Zeile bewirkt, wenn die Execution Policy die Ausführung des Skriptes nicht zulässt, wo das drinsteht? ;-) 

 

Ok, es ist spät, ich gebe es zu. PowerShell lässt keine unsignierten Skripts zu bzw. gemäss vorher von mir geposteten Meldung, Skripts können NICHT geladen werden. Ok, ich rufe ein Skript auf, welches NICHT geladen werden kann und in diesem versuche ich nun, dem entgegen zu wirken, was natürlich so nicht funktioniert, da genau dieses PS Skript nicht gelesen werden kann.

 

Das heisst, ich löse das Problem wie?

Ich stelle via GPO ein, dass generell das Ausführen von Skripts beim Abmelden erlaubt ist, gibt es diese Möglichkeit bzw. würde diese GPO Einstellung denn wirklich helfen, wenn es um Abmelde Skripts geht?

 

Gibt es noch weiter Alternative, was ist in genau diesem Fall nun Best Practices?

Ich will ein PS Skript beim Abmelden ausführen, es klappt aber anscheinend nicht, weil das Ausführen von PS Skripts per Default auf unseren Clients anscheinend NICHT erlaubt ist.

 

Ich meine, es geht hierbei ja auch um Sicherheit - und wie sogar.

Link zu diesem Kommentar
vor 10 Stunden schrieb andrew:

Dazu kann ich folgendes sagen/ schreiben: Wenn ich auf dem NB mit Windows 10 (mein Test Objekt) den Befehl rsop.msc ausführe und prüfe, was konkret sonst noch an Abmelde Skripts ausgeführt werden, dann sind es genau deren 2

 

- 1x ein .bat File

- 1x ein .vbs File

 

Beide Abmeldeskripts, welche neben meinem PS Abmeldeskript ebenfalls angewendet werden, liegen genau, wie mein PS Skript auch, im Pfad \\DomainXY.local\netlogon\Scripts\ Und: sind schon lange im Einsatz, funktionieren tadellos.

Ich glaube du hast seinen Punkt nicht so aufgenommen, wie er gemeint war. Keine Skripte per unc. ;) und wenn deine tadellos funktionieren, hattest du halt noch nie das Problem, was bei ihm gar nicht erst auftreten kann. 

Link zu diesem Kommentar
vor 11 Stunden schrieb andrew:

Ich stelle via GPO ein, dass generell das Ausführen von Skripts beim Abmelden erlaubt ist, gibt es diese Möglichkeit bzw. würde diese GPO Einstellung denn wirklich helfen, wenn es um Abmelde Skripts geht?

In einem *.bat per powershell.exe -deineParameter die Ausführung von PS-Scripten erlauben und in der nächsten Zeile rufst Du dein Script auf. So sollte es funktionieren.

 

Alternativ kann man natürlich auch über das Signieren von PS-Scripten nachdenken und nur noch signierte Scripte zulassen. Und natürlich die Scripte *VOR* der Ausführung lokal auf den Computer bringen.

Link zu diesem Kommentar
vor 19 Stunden schrieb daabm:

Und ganz allgemein: Logging hilft immer.

Edit: Aktiviere mal die ausführlichen Meldungen - https://gpsearch.azurewebsites.net/#1842

 

LOG Funktion

Habe das ausführliche loggen gemäss deinem Artikel aktiviert.

Was ich aber NICHT aus dem Artikel herauslesen konnte ist, in welcher Form ich dann den Mehrwert an Infos vorfinde bzw. wo? Ob in der Ereignisanzeige oder direkt als Bildschirmausgabe?

 

Als ich mich per RDP am Test NB mit Windows 10 eingeloggt hatte, bemerkte ich, dass mir direkt als Bildschirmausgabe Infos angezeigt wurden wie z.B. die GPOs, welche gerade vom PC/ User anwendet werden (es stand also nicht einfach, Login oder so was)

 

Darum muss ich davon ausgehen, dass ich beim Abmelden des Users bei der Bildschirmausgabe was schlaues sehen sollte?

Es steht nach wie vor 10min lang, der Abmeldevorgang läuft (leider nicht mehr Infos, Details, was gerade im Hintergrund abgeht).

 

Gibt es keine Logg Funktion, welche im Detail z.B. in der Ereignisanzeige oder in einem LOG File auflistet, was konkret beim Abmelden passiert. Da würde man dann herausfinden, was da im Hintergrund abgehet?!

 

vor 7 Stunden schrieb Sunny61:

In einem *.bat per powershell.exe -deineParameter die Ausführung von PS-Scripten erlauben und in der nächsten Zeile rufst Du dein Script auf. So sollte es funktionieren

 

Leider bin ich immer noch gleich weit wie am Anfang.

Habe einfach noch die Erkenntnis, dass es NICHT am Ausführen des Skripts scheitert, sondern das in diesem Fall das .bat File diesen Inhalt hier anscheinend gar nicht abarbeitet?

Denn wenn ich mich nach 10 min warten, bis der Logoff Vorgang endlich fertig ist, mich per remote wieder auf dem Test NB einlogge, stelle ich fest, dass der Ordner C:\Test\Skripts NICHT erstellt wurde und demzufolge wurde auch der Kopiervorgang des PS File vom NETLOGON Share NICHT in diesen, lokalen Ordner auf dem Client umgesetzt.

 

Inhalt .bat File

@echo off

REM #### Wenn der Ordner lokal auf dem Client NICHT vorhanden ist, wird dieser erstellt
IF NOT EXIST C:\Test\Skripts MD C:\IVSO\Skripts


REM ### Kopiervogang PS Skript aus NETLOGON Share in das lokale Verzeichnis auf dem Client
IF NOT EXIST C:\Test\Skripts\CleanUp-FolderStratup.ps1 XCOPY %logonserver%\NETLOGON\scripts\CleanUp-FolderStartup.ps1 C:\IVSO\Skripts\ /y


REM ### Ausführung PS Skript
REM powershell.exe -ExecutionPolicy Bypass -File C:\IVSO\Skripts\CleanUp-FolderStartup.ps1

 

Die letzte Zeile hier mit Powershell.exe habe ich aus kommentiert, weil es mich interessiert hat, ob es an diesem Schritt scheitert oder schon vorher. Nun habe ich die Erkenntnis, schon vorher und nicht an PowerShell und oder an der ExecutionPolicy Geschichte

 

Abmeldeskript_bat.JPG

bearbeitet von andrew
Link zu diesem Kommentar
vor 2 Stunden schrieb andrew:

REM ### Kopiervogang PS Skript aus NETLOGON Share in das lokale Verzeichnis auf dem Client
IF NOT EXIST C:\Test\Skripts\CleanUp-FolderStratup.ps1 XCOPY %logonserver%\NETLOGON\scripts\CleanUp-FolderStartup.ps1 C:\IVSO\Skripts\ /y


REM ### Ausführung PS Skript
REM powershell.exe -ExecutionPolicy Bypass -File C:\IVSO\Skripts\CleanUp-FolderStartup.ps1

 

Die letzte Zeile hier mit Powershell.exe habe ich aus kommentiert, weil es mich interessiert hat, ob es an diesem Schritt scheitert oder schon vorher. Nun habe ich die Erkenntnis, schon vorher und nicht an PowerShell und oder an der ExecutionPolicy Geschichte

 

Ja dann wird es wohl an dem xcopy-Befehl scheitern. Warum auch immer...

BTW: Es gibt ein Application Eventlog, das da möglicherweise Hinweise gibt. Und es gibt ein GroupPolicy Eventlog, das noch viel mehr Hinweise gibt - insbesondere zu "Abmeldeskript gestartet" und "Abmeldeskript beendet" (leider ohne Angabe, welche Skripts konkret...)

Link zu diesem Kommentar
vor 2 Stunden schrieb andrew:

Denn wenn ich mich nach 10 min warten, bis der Logoff Vorgang endlich fertig ist, mich per remote wieder auf dem Test NB einlogge, stelle ich fest, dass der Ordner C:\Test\Skripts NICHT erstellt wurde und demzufolge wurde auch der Kopiervorgang des PS File vom NETLOGON Share NICHT in diesen, lokalen Ordner auf dem Client umgesetzt.

 

vor 2 Stunden schrieb andrew:

@echo off

REM #### Wenn der Ordner lokal auf dem Client NICHT vorhanden ist, wird dieser erstellt
IF NOT EXIST C:\Test\Skripts MD C:\IVSO\Skripts


REM ### Kopiervogang PS Skript aus NETLOGON Share in das lokale Verzeichnis auf dem Client
IF NOT EXIST C:\Test\Skripts\CleanUp-FolderStratup.ps1 XCOPY %logonserver%\NETLOGON\scripts\CleanUp-FolderStartup.ps1 C:\IVSO\Skripts\ /y


REM ### Ausführung PS Skript
REM powershell.exe -ExecutionPolicy Bypass -File C:\IVSO\Skripts\CleanUp-FolderStartup.ps1

 

 

Entweder bist du hier beim anonymisieren durcheinander gekommen oder du (ver)wechselst mehrfach deine Ordner.

 

Ich meine, ich hätte es im anderen Thread schon angedeutet. Wäre es nicht einfach nur mit einem Anmeldescript / Aufgabe bei Benutzeranmeldung zu arbeiten, die prüft, ob man intern oder extern ist und dann entsprechend einen Autostart ausführt oder nicht. So in der Art:

if(Test-Connection -ComputerName $env:LOGONSERVER.TrimStart("\") -Quiet){
    # Intern
} else{
    # Extern
}

 

 

Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...