PowerShell-Skript wird nicht ausgeführt (GPO, StartUp)

[roccomarcy 20]

Guten Morgen,

 

ich habe hier eine Umgebung, bestehend aus mehreren Windows 2008 R2 und Server 2012 R2 Domänen-Controllern, sowie reinen Windows 7 Pro Clients.

Für eine Applikation muss in einem lokalen Drucker eine Einstellung geändert werden, was sich unter anderem durch WMI lösen lässt.

 

Dazu habe ich ein Skript in PowerShell entwickelt, welches Lokal die Option des Druckers anpasst. Es werden keine Dateien auf irgendwelche Netzwerkfreigaben geschrieben, es läuft rein lokal.

Kommen wir zum eigentlichen Problem.

 

Führe ich das Skript lokal auf den Arbeitsplätzen aus, so läuft es ohne Probleme. Nun habe ich das Skript als "Starten"-Skript eingebunden und auf eine Reihe Testcomputer verlinkt.

Leider wird das Skript nicht ausgeführt und in der Ereignisanzeige steht auch nichts interessantes.

 

Was könnte es für Hintergründe haben? Ich habe erst an mangelnde Berechtigung gedacht, habe daher das Skript lokal mit "SYSTEM"-Berechtigung ausgeführt (dank PSExec), aber damit hat es auch funktioniert.

In der Vergangenheit habe ich bereits "Auf Netzwerk warten" in den GPOs aktiviert.

 

Edit1: Das Skript wurde unter dem Reiter "PowerShell" angelegt, es wird direkt aufgerufen, also nicht über eine BAT oder ähnliches.

bearbeitet 20. Oktober 2017 von roccomarcy

[MurdocX 965]

Wird das Skript denn ordnungsgemäß ausgeführt? Rechtsklick "mit Powershell ausführen" ist nicht aussagekräftig, da die Standard-PS-Konfig verändert wird. 

 

Öffne eine normale Shell (Powershell) und starte das Skript von da aus. Funktioniert es? Wenn nicht, dann musst du die Executionpolicy's anpassen.

[roccomarcy 20]

Hallo,

 

ich hab es so ausgeführt, wie von dir beschrieben.

Es wurde über die Konsole ausgeführt, nicht über einen Rechtsklick.

Die Executionpolicys habe ich auch nicht verändert.

 

bearbeitet 20. Oktober 2017 von roccomarcy

[MurdocX 965]

Und das Ergebnis?  ;)

[roccomarcy 20]

Das Ergebnis wovon?
Es gibt keine Ausgabe auf die Konsole, das Programm schreibt in die Ereignisanzeige, dort ist auch ein Eintrag zu finden (bei manueller Ausführung).

[MurdocX 965]

Ah, du hast das Bild im Nachhinein hinzugefügt. ;-)

 

Lokale Skripte sind meist kein Problem. Nun der Test über das Netzwerk. Füge Sie deiner Gruppenrichtlinie hinzu und greife auf die Freigabe Sysvol bis zu deiner Gruppenrichtlinie um Sie dann über die PS auszuführen.

 

Beispiel

Windows PowerShell
Copyright (C) 2016 Microsoft Corporation. Alle Rechte vorbehalten.

PS C:\Users\weis_adm> ."\\DOMÄNE\SysVol\DOMÄNE\Policies\{BBDB6ABB-40CE-4A40-95BD-EAED3816364E}\Machine\Scripts\Shutdown\
Inventarisierungsskript.ps1" 

[roccomarcy 20]

Ah, da bekomme ich eine Sicherheitswarnung. Darauf bin ich natürlich nicht gekommen.

Danke für den Tip.

 

Was wäre denn jetzt der beste Weg um dieses zu umgehen? Per Batchdatei ausführen?

 

bearbeitet 20. Oktober 2017 von roccomarcy

[MurdocX 965]

Du könntest deine Skripte intern signieren oder über die Gruppenrichtlinien die ExecutionPolicy anpassen.

[roccomarcy 20]

Und wenn ich das über eine Batchdatei heraus ausführe?

[MurdocX 965]

powershell.exe -File "" -ExecutionPolicy Unrestricted

Wäre dein Weg zu Glück. Lass Dir aber gesagt sein.. Dieses Konstrukt ist alles andere als performant  ;)  

[NilsK 2.981]

Moin,

 

ich rate dazu, Skripte zunächst lokal zu kopieren und dann von dort auszuführen. Das ist in solchen Fällen in aller Regel sicherer.

 

Ist das Skript denn logisch dazu geeignet, als Startskript, also ohne Benutzersitzung ausgeführt zu werden?

 

Gruß, Nils

[daabm 1.387]

Noch was - willst Du "Druckeinstellungen" oder "Druckereinstellungen - Standardwerte" ändern? Ersteres geht nur in der Benutzersession, also nicht als Startskript, sondern nur als Anmeldeskript :)

Und Nils hat absolut recht - erst lokal kopieren, und dann lokal ausführen ist zuverlässiger. Und funktioniert auch "offline".

[MurdocX 965]

Und Nils hat absolut recht - erst lokal kopieren, und dann lokal ausführen ist zuverlässiger. Und funktioniert auch "offline".

 

Bei uns funktioniert das auch mit GP zuverlässig  ;)