lauchheimer
Goto Top

Logon-Skript Powershell über GPO funktioniert nicht

Tag Leute,

Um bei Win 10 Pro den App-Store und unerwünschte Apps zu entfernen, habe ich eine Powershell-Datei erzeugt, die ich gerne als Logon-Skript verwenden würde.
Diese habe ich über eine GPO zum Test einem User zugewiesen. Unser Server läuft mit Win Server 2012.

Ich habe im GPO-Editor eine RIchtlinie erzeugt und bei Benutzerkonfiguration das Power-Shell-Skript bei Anmelden zugewiesen.
Bei Sicherheitsfilterung habe ich den entsprechenden User ausgewählt.
Wenn ich mich nun mit dem User am Client anmelde passiert garnichts.

Mit dem Administrator-Konto habe ich die Powershell manuell gestartet. Das hat soweit gepasst.


Warum wird das Skript bei der Anmeldung des Users nicht gestartet?

Gruß Martin

Content-Key: 430088

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

Printed on: April 26, 2024 at 11:04 o'clock

Mitglied: 138810
138810 Mar 18, 2019 updated at 13:47:36 (UTC)
Goto Top
Wenn ich mich nun mit dem User am Client anmelde passiert garnichts.
ist ja auch logisch, "Logon" Skripte werden mit den Rechten des angemeldeten Users gestartet und mit diesen Credentials kannst du keine System-Apps entfernen, dazu muss die Shell elevated laufen und das tut sie wenn du stattdessen mit einem Startskript arbeitest, das läuft als NT AUTORITÄT\SYSTEM. Dazu musst du dann stattdessen die GPO auf die Computer filtern und das Skript als Startskript definieren.
Member: erikro
erikro Mar 18, 2019 at 13:39:31 (UTC)
Goto Top
Moin,

wie sieht denn das Skript aus? Sowas habe ich hier auch und das läuft wie Schmitz' Katze.

Liebe Grüße

Erik
Member: Pjordorf
Pjordorf Mar 18, 2019 at 13:45:16 (UTC)
Goto Top
Hallo,

Zitat von @Lauchheimer:
Warum wird das Skript bei der Anmeldung des Users nicht gestartet?
Das Skript wird gestartet aber da die rechte nicht passen passiert nichts
Das Skript wird gar nicht erst gestartet
Bau ein Pause ein, dann siehst du ob das Skript gestartet wird oder nicht.

Gruß,
Peter
Member: Peace-D
Peace-D Mar 18, 2019 at 13:45:19 (UTC)
Goto Top
Wird wohl zum einen an den Rechten liegen, wie freesolo schon erwähnt hat und zum anderen kann es auch sein, dass du den Rechner ebenfalls in der Sicherheitsfilterung angeben musst. Ich hatte nämlich auch schon öfter dein Problem, nur umgekehrt (sprich, GPO mit Computereinstellungen und ich musste auch den User angeben).
Member: erikro
erikro Mar 18, 2019 at 13:49:46 (UTC)
Goto Top
Moin,

Zitat von @138810:

Wenn ich mich nun mit dem User am Client anmelde passiert garnichts.
ist ja auch logisch, "Logon" Skripte werden mit den Rechten des angemeldeten Users gestartet und mit diesen Credentials kannst du keine System-Apps entfernen, dazu muss die Shell elevated laufen und das tut sie wenn du stattdessen mit einem Startskript arbeitest, das läuft als NT AUTORITÄT\SYSTEM.

Bei mir funktioniert das wunderbar unter dem User, die userabhängigen Apps zu eliminieren (remove-appxpackage). Das muss auch so sein, da die ja bei jedem neuen User wieder aus dem Image reingeschmiert werden. Ich hasse Windows 10. face-wink

Liebe Grüße

Erik
Mitglied: 138810
138810 Mar 18, 2019 updated at 13:57:26 (UTC)
Goto Top
Zitat von @erikro:

Moin,

Zitat von @138810:

Wenn ich mich nun mit dem User am Client anmelde passiert garnichts.
ist ja auch logisch, "Logon" Skripte werden mit den Rechten des angemeldeten Users gestartet und mit diesen Credentials kannst du keine System-Apps entfernen, dazu muss die Shell elevated laufen und das tut sie wenn du stattdessen mit einem Startskript arbeitest, das läuft als NT AUTORITÄT\SYSTEM.

Bei mir funktioniert das wunderbar unter dem User, die userabhängigen Apps zu eliminieren (remove-appxpackage). Das muss auch so sein, da die ja bei jedem neuen User wieder aus dem Image reingeschmiert werden. Ich hasse Windows 10. face-wink

Les den Text noch mal genau ... Besonders das Wort "System" face-wink
ja bei jedem neuen User wieder aus dem Image reingeschmiert
Deshalb entfernt man solche Apps direkt im Provisioning(Remove-AppxProvisionedPackage) des Images, dann passiert sowas auch nicht!
Member: erikro
erikro Mar 18, 2019 at 14:05:21 (UTC)
Goto Top
Moin,

Zitat von @138810:
Les den Text noch mal genau ... Besonders das Wort "System" face-wink

Da hast Du recht. Aber ich habe den TO anders verstanden.

ja bei jedem neuen User wieder aus dem Image reingeschmiert
Deshalb entfernt man solche Apps direkt im Provisioning(Remove-AppxProvisionedPackage) des Images, dann passiert sowas auch nicht!

Cool, danke. Früher ging das ja mit remove-appxpackage -AllUsers. Aber das funktioniert ja leider nicht mehr. Gehen beim Parameter PackageName Wildcards oder regex? Oder muss ich jedes einzeln wegskripten?

Liebe Grüße

Erik
Mitglied: 138810
138810 Mar 18, 2019 updated at 14:31:45 (UTC)
Goto Top
Zitat von @erikro:
Cool, danke. Früher ging das ja mit remove-appxpackage -AllUsers.
Das ist was komplett anderes. Wenn man eine App aus dem Provisioning entfernt landet diese bei neu angelegten Profilen auch nicht mehr im Profil. Das AllUsers bei deinem Befehl hier bedeutet entferne die App bei allen Usern aus den Profilen aber nicht aus dem Provisioning, d.h. also wenn du nur AllUsers benutzt landet die App trotzdem wieder bei neu angelegten Userprofilen weil sie eben auch noch im Provisioning-Bereich liegt.

Aber das funktioniert ja leider nicht mehr. Gehen beim Parameter PackageName Wildcards oder regex? Oder muss ich jedes einzeln wegskripten?
Also das kannst du ja hier nachlesen:
https://docs.microsoft.com/en-us/powershell/module/dism/remove-appxprovi ...
-- >Accept wildcard characters: False

Alle Apps solltest du aber nicht aus dem Provisioning entfernen, denn ein paar davon sind für das System nötig!
Member: erikro
erikro Mar 18, 2019 at 14:38:44 (UTC)
Goto Top
Zitat von @138810:

Zitat von @erikro:
Cool, danke. Früher ging das ja mit remove-appxpackage -AllUsers.
Das ist was komplett anderes. Wenn man eine App aus dem Provisioning entfernt landet diese bei neu angelegten Profilen auch nicht mehr im Profil. Das AllUsers bei deinem Befehl hier bedeutet entferne die App bei allen Usern aus den Profilen aber nicht aus dem Provisioning, d.h. also wenn du nur AllUsers benutzt landet die App trotzdem wieder bei neu angelegten Userprofilen weil sie eben auch noch im Provisioning-Bereich liegt.

Das -AllUsers funktioniert ja leider sowieso nicht mehr.


Aber das funktioniert ja leider nicht mehr. Gehen beim Parameter PackageName Wildcards oder regex? Oder muss ich jedes einzeln wegskripten?
Also das kannst du ja hier nachlesen:
https://docs.microsoft.com/en-us/powershell/module/dism/remove-appxprovi ...
-- >Accept wildcard characters: False

Jo, schon gemacht. Danke Dir nochmal.
Mitglied: 138810
138810 Mar 18, 2019 updated at 14:46:33 (UTC)
Goto Top
Das -AllUsers funktioniert ja leider sowieso nicht mehr.
Das kommt darauf an was du da in den Parameter hinein interpretierst.
-AllUsers

Indicates that this cmdlet lists app packages for all user accounts on the computer. To use this
parameter, you must run the command by using administrator permissions.
Der Parameter an sich funktioniert so wie vorgesehen.

Jo, schon gemacht. Danke Dir nochmal.
Keine Ursache.
Member: erikro
erikro Mar 18, 2019 at 14:49:06 (UTC)
Goto Top
Zitat von @138810:

Das -AllUsers funktioniert ja leider sowieso nicht mehr.
Das kommt darauf an was du da in den Parameter hinein interpretierst.
-AllUsers

Indicates that this cmdlet lists app packages for all user accounts on the computer. To use this
parameter, you must run the command by using administrator permissions.
Der Parameter an sich funktioniert so wie vorgesehen.

Ja, eigentlich. Aber: "Wenn Sie die App nicht nur für einen Nutzer deinstallieren wollen, müssen Sie einfach "-AllUsers" ergänzen, also Get-AppxPackage -AllUsers *Programmname* | RemoveAppxPackage eingeben. Unter manchen neueren Windows-Version funktioniert die Eingabe von "-AllUsers" allerdings nicht mehr." (https://www.heise.de/tipps-tricks/Windows-10-Vorinstallierte-Apps-deinst ..). Die Erfahrung habe ich leider gemacht, dass ab einem bestimmten Update von Windows 10 mein Aufräumskript nicht mehr funktionierte.
Member: Lauchheimer
Lauchheimer Mar 29, 2019 at 15:06:41 (UTC)
Goto Top
Tag Leute,

Ich habe ganz einfaches Skript erstellt, das den Text "Hallo ausgibt" und danach Pause.

Wenn ich mich jedoch am Client anmelde passiert nicht. Wenn ich das Skript manuell ausführe funktioniert alles.
Ich habe eine GPO erstellt, das Skript im Sysvol abgelegt und einen Testuser zugewiesen.

Was habe ich vergessen?
Woran kann das liegen?

Gruß Martin
Member: Pjordorf
Pjordorf Mar 29, 2019 at 15:35:17 (UTC)
Goto Top
Hallo,

Zitat von @Lauchheimer:
Wenn ich mich jedoch am Client anmelde passiert nicht.
Dann hast du was falsch gemacht, falsch eingestellt das z.B. deine GPO nicht greift und ausgeführt wird usw. Anstelle deiner Textbox mit "Halo augibt" reicht ein Pause in einer CMD.Passen die Rechte,was sagt das Ereignissprotokoll, Was sagt es wenn du klärst ob die GPO überhaupt geladen und ausgeführt werden soll?
https://www.security-insider.de/fehler-beim-einsatz-von-gruppenrichtlini ...
https://www.windowspro.de/tool/group-policy-log-view-fehler-bei-gpo-ausf ...
https://www.faq-o-matic.net/2013/03/18/der-grose-group-policy-troublesho ...
https://www.tecchannel.de/a/windows-praxis-gruppenrichtlinien-ueberpruef ...
Schau auch wie deine Einstellungen sind.

Was habe ich vergessen?
Uns wichtiges zu nennen. Wir können jetzt nur Raten, und das macht keinen Spass.

Gruß,
Peter
Mitglied: 138810
138810 Mar 29, 2019 updated at 16:22:41 (UTC)
Goto Top
Zitat von @Lauchheimer:

Tag Leute,

Ich habe ganz einfaches Skript erstellt, das den Text "Hallo ausgibt" und danach Pause.

Wenn ich mich jedoch am Client anmelde passiert nicht. Wenn ich das Skript manuell ausführe funktioniert alles.
Vollkommen normal, denn Startskripte werden vor der Anmeldung ausgeführt und das unsichtbar für den User!!
Es gibt eine GPO die diese sichtbar macht, das sollte man aber nur zu Debugzwecken nutzen.

Außerdem muss dem Computerkonto Zugriff auf den Skriptordner gegeben werden nicht einem Userkonto, denn Startscripte laufen wie schon gesagt im Kontext des Computers nicht des Users!

Du solltest dich dringend diesbezüglich weiterbilden .
Member: Lauchheimer
Lauchheimer Mar 30, 2019 at 08:03:28 (UTC)
Goto Top
Zitat von @138810:

Vollkommen normal, denn Startskripte werden vor der Anmeldung ausgeführt und das unsichtbar für den User!!
Es gibt eine GPO die diese sichtbar macht, das sollte man aber nur zu Debugzwecken nutzen.

Außerdem muss dem Computerkonto Zugriff auf den Skriptordner gegeben werden nicht einem Userkonto, denn Startscripte laufen wie schon gesagt im Kontext des Computers nicht des Users!

Du solltest dich dringend diesbezüglich weiterbilden .

Hier liegt ein Missverständnis vor.
Ich habe ein Logon-Skrpit erstellt, Kein Start-Skript.

Außerdem habe ich am Client "Anweisungen in Anmeldeskripts während der Ausführung anzeigen" aktiviert.

GPResult kat keine Fehler angezeigt. Jedoch erscheint die Warnmeldung: "Eine schnelle Verbindung wurde entdeckt.
Ich kann allerdings keinen Eintrag bezüglich des Anmelde-Skripts finden.


Hat jemand noch eine Idee was fehlen könnte?

Gruß Martin
Mitglied: 138810
Solution 138810 Mar 30, 2019 updated at 08:15:41 (UTC)
Goto Top
Jepp, deine GPO zieht nicht.
Bitte lese auch diesen wichtigen Hinweis:
https://www.gruppenrichtlinien.de/artikel/sicherheitsfilterung-neu-erfun ...
Seit einiger Zeit muss nämlich das Computerobjekt ebenfalls Lese-Rechte auf die GPO bekommen! Ist das nicht der Fall wird die GPO auch nicht beim User angewendet.
Die typischen GPO Anfängerfehler halt.
Member: Lauchheimer
Lauchheimer Mar 30, 2019 at 08:33:19 (UTC)
Goto Top
Dankschön. Das war die Lösung.

Ich hatte nur einen User zugewiesen, jedoch keine PC.

Gruß Martin