thetoxic
Goto Top

Powershell StartScript hängt - Execution Policy?

Hallo zusammen,

ich habe ein PS-Script geschrieben um eine Softwareinstallation auf Aktualität zu prüfen und zu aktualisieren.
Das Script funktioniert tadellos und ist in 3 min abgearbeitet. Der Inhalt spielt daher keine Rolle.

Per GPO ist festgelegt das PS-Scripts ausgeführt werden dürfen.
Computerkonfiguration -> Richtlinien -> Administrative Vorlagen -> Windows-Komponenten -> Windows PowerShell -> Skripausführung aktivieren -> alle Skripts zulassen

Das Script ist per GPO als StartScript definiert, sodass jenes vom PC beim hochfahren ausführen soll.
Die Scriptverarbeitung startet auch brav, leider bleibt der PC beim Hochfahren vor dem Anmeldebildschirm mit dem Bildschirm "Bitte warten" ewig hängen. Manchmal wird das Script allerdings ohne Probleme ausgeführt.
Mir scheint dass hier dennoch irgendeine Execution-Policy von Powershell nicht korrekt greift und hier im Hintergrund eine Abfrage im Sinne von "Möchten Sie dieses Script wirlich ausführen... blablabla..." bestätigt werden muss.
Wie beschrieben, ist dies per GPO jedoch zugelassen.

Ich verstehe leider nicht warum es manchmal funktioniert, und manchmal nicht.

Google spukte mir folgende interessanten Beitrag aus, allerdings sträube ich mich etwas davor die Einstellung an jedem PC zu setzen.
https://www.tmurgent.com/TmBlog/?p=2855


Hat jemand von euch eine Idee wie ich mich dem Problem nähern kann?
Gibt es sinnvolle Ereignislogs die die Ausführung von PS-Scripts protokollieren?

Content-ID: 3153344382

Url: https://administrator.de/forum/powershell-startscript-haengt-execution-policy-3153344382.html

Ausgedruckt am: 22.12.2024 um 16:12 Uhr

DerWoWusste
Lösung DerWoWusste 23.06.2022 um 14:20:09 Uhr
Goto Top
Hi.

Startskripte sind keine gute Idee, da sie nur laufen, wenn fast startup deaktiviert wird oder wenn die Rechner tatsächlich neu gestartet werden. Per default laufen sie nicht, wenn man den Rechner runter fährt und am nächsten morgen anschaltet.

Deshalb solltest Du (falls fast startup nicht etwa deaktiviert ist) umsteigen auf eine andere Verteilungsmethode, zum Beispiel scheduled Tasks.
Crusher79
Crusher79 23.06.2022 aktualisiert um 14:36:45 Uhr
Goto Top
Nutzen nur Startscripte im PS Format.

Wieso ist der Inhalt egal? Wir verteilen mittels chocolatey über nexus. Als letzterer mal hing dauerte die Anmeldung auch ewig.

Wie verteilst du denn die Software? Timeout von ka 60 Sek. wirkt wenig. Wenn das aber 10fach passiert sind wir schon bei 600 Sekunden!

Da du eh schon im Script bist, kansnt du auch eine Log-Funktion einbauen. Dann siehst du wo es gerade hängt. Es sei denn, es ist ein Einzeiler: Date alles up. Dann wird es schwer.

Einzeiler zum Loggen wäre sowas hier. Aber der Inhalt der PS ist nicht unwichtig! Es können Proxy-Server nicht richtig laufen. Das Internet Rep. für Update ist nicht da. Die Software läd Sachen nach und kann gerade nicht, weil Bedingugn XY nicht erfüllt ist.

Wir sind immer noch im Script......

"$(Get-Date) - Punkt Office vereilen: $ErrorMessage Item: $FailedItem" | Out-File -FilePath "C:\temp\startup-log.txt" -Append -Force  

Wenn es keinen Fehler gibt, kannst du das umschreiben. Und so nur zeitlich protokollieren im welchen Abschnitt du dich gerade befindest!

Würde auch gehen. $ErrorMessage macht nur bei Fehlermeldung einen Sinn!


Und doch mal den Inhalt posten?

Was hälst du von try-catch Blöcken im Script? Damit es nicht aussteigt.....
TheToxic
TheToxic 23.06.2022 aktualisiert um 15:08:34 Uhr
Goto Top
@DerWoWusste
es ist egal ob der Rechner Neugestartet wird oder einen harten Reboot erhält. Beide male ein gleiches Ergebnis wie beim Würfeln face-sad
Ich probiere es mit den geplanten Tasks mal aus.

@Crusher79
Das Script macht folgendes
  • Prüfe ob Programm X installiert ist mit Versionsnummer X
  • Wenn ja, alles gut, wenn nein kopiere einen Ordner von einem Fileserver in der Domäne nach C:\install
  • installiere von C:\Install ein Programm

Gefüllt mit diversen Fehlerabfragen ob die Dateien vorhanden sind, der vorherige Schritt erfolgreich war etc.

Ich habe am Anfang des Scripts ein "Debugging" aktiviert mit Start-Transcript und Stop-Transcript, welches mir die Powershellausgabe brav in eine lokale TXT ausgibt, wenn ich das Script per Hand ausführe. Dies ist der erste Befehl im Script! Bereits dieser Befehl wird im Startscript nicht ausgeführt.

Daher meine Vermutung mit der Execution Policy.

Nach einem harten Reboot (Aus/Einschalten) wird dann das Script übersprungen.
erikro
erikro 23.06.2022 um 15:05:34 Uhr
Goto Top
Moin,

Zitat von @TheToxic:
ich habe ein PS-Script geschrieben um eine Softwareinstallation auf Aktualität zu prüfen und zu aktualisieren.

Aha.

Das Script funktioniert tadellos und ist in 3 min abgearbeitet. Der Inhalt spielt daher keine Rolle.

Wie kommst Du auf die Idee? Woher sollen wir wissen, woran das liegen kann, wenn wir nicht wissen, was das Skript tut?

Per GPO ist festgelegt das PS-Scripts ausgeführt werden dürfen.
Computerkonfiguration -> Richtlinien -> Administrative Vorlagen -> Windows-Komponenten -> Windows PowerShell -> Skripausführung aktivieren -> alle Skripts zulassen

OK. Das solltest Du vielleicht überdenken. Aber erstmal sorgt es dafür, dass alles ausgeführt werden kann.

Das Script ist per GPO als StartScript definiert, sodass jenes vom PC beim hochfahren ausführen soll.

Sind denn die anderen GPOs, die man so braucht, damit das geht, auch definiert? Ist, wie @DerWoWusste schon angemerkt hat, auch der Schnellstart ausgeschaltet?

Die Scriptverarbeitung startet auch brav, leider bleibt der PC beim Hochfahren vor dem Anmeldebildschirm mit dem Bildschirm "Bitte warten" ewig hängen. Manchmal wird das Script allerdings ohne Probleme ausgeführt.

Wenn das Skript startet, dann greift keine Execution Policy, die das verhindert. Es startet ja.

Ich verstehe leider nicht warum es manchmal funktioniert, und manchmal nicht.

Nachdem ich meine Glaskugel kräftig poliert habe, sagt sie mir, dass Dein Skript auf das Netz zugreift, das nach dem Neustart noch nicht bereit ist, weil die entsprechende Policy nicht oder nicht korrekt konfiguriert ist.

Liebe Grüße

Erik
Crusher79
Crusher79 23.06.2022 aktualisiert um 15:14:18 Uhr
Goto Top
So ad-hoc auch keine Idee.

Du kannst vor und nachdem prüfen:

"$(Get-Date) - Beginne Pruefung | Out-File -FilePath "C:\temp\startup-log.txt" -Append -Force
"$(Get-Date) - Beende Pruefung | Out-File -FilePath "C:\temp\startup-log.txt" -Append -Force

Einbauen. Und so weiter. Dann sieht man, wie lange er braucht und wo es stehen bleibt.

Chocolatey arbeitet ja ähnlich. Nur fetchen die im Cache Ordner des Programmes. Außer "choco install xyz" machen wir auch nicht viel.

Problem war mal Ausfall des Nexus Paketservers. Oder die Tatsache das wir nur 10 MBit/s haben und es eng wurde.

Meine Idee war mal, Ubuntu + Squid Proxy Cache zu nehmen!

Es gibt eine Anleitung den so zu konfigurieren, dass es ähnlich wie bei IPfire die Pakete länger behält. Bzw. nur die Updates und Software, die man möchte.

Hatte den schon mit Zertifikat versorgt - eigene CA im Unternehmen. SSL war auch kein Thema. Wäre das ggf. eine Option? Statt zu kopieren mittels Choco Pakete zu bauen? Statt im Inet kannst du es auch umbauen, dass große Software vom NAS gezogen wird....

Statt immer wieder zu laden, wird es aus dem Cache des Proxy Servers entnommen.

FirefoxESR, Chrome etc. sind ja meist Selbstläufer! Außerdem kann man auch explizite Versionsnummer angeben.

https://community.chocolatey.org/

https://wiki.squid-cache.org/SquidFaq/WindowsUpdate
TheToxic
TheToxic 23.06.2022 um 15:43:43 Uhr
Goto Top
Ok ihr lieben... ich lasse die Hosen runter... also fast...

Ich habe ein weiteres Script geschrieben mir dem selben oben beschriebenem Ergebnis. Mal geht es, mal geht es nicht.

Bitte, nun findet den Fehler im Script face-confused

Start-Transcript C:\install\test_script.log
$installPath = 'C:\install\'  

### C:\Install prüfen
write-host 'Prüfe ob C:\Install vorhanden'  
if (Test-Path -Path $installPath) {
	write-host 'C:\Install vorhanden'      
	}
else {
	write-host 'C:\Install nicht vorhanden'  
	new-item $installPath -ItemType directory
	write-host 'C:\Install erstellt'  
}
Stop-Transcript


Spaß beiseite...

@erikro

Das Script liegt in der dazugehörigen GPO. Da der PC die GPO verarbeitet bereits beim Start verarbeitet, hat er auch Netz und kann das oben stehende Script starten.
Und man stelle sich vor... selbst wenn das Script am Test PC lokal unter C:\install gespeichert ist und in der GPO darauf verwiesen wird, das gleiche Ergebnis. Mal geht es, meistens nicht...

Ich glaube es liegt nicht am Script-Inhalt face-wink
erikro
erikro 23.06.2022 um 16:32:41 Uhr
Goto Top
Moin,

Zitat von @TheToxic:
@erikro

Das Script liegt in der dazugehörigen GPO. Da der PC die GPO verarbeitet bereits beim Start verarbeitet, hat er auch Netz und kann das oben stehende Script starten.

Das ist falsch. Nach dem Ausführen der GPO sind die entsprechenden Einträge in der Registry vorhanden und werden auch dann ausgeführt, wenn kein Netz da ist.

Liebe Grüße

Erik
3063370895
Lösung 3063370895 24.06.2022 aktualisiert um 06:35:17 Uhr
Goto Top
Zitat von @TheToxic:

Ok ihr lieben... ich lasse die Hosen runter... also fast...

Ich habe ein weiteres Script geschrieben mir dem selben oben beschriebenem Ergebnis. Mal geht es, mal geht es nicht.

Bitte, nun findet den Fehler im Script face-confused

Start-Transcript C:\install\test_script.log
$installPath = 'C:\install\'  

### C:\Install prüfen
write-host 'Prüfe ob C:\Install vorhanden'  
if (Test-Path -Path $installPath) {
	write-host 'C:\Install vorhanden'      
	}
else {
	write-host 'C:\Install nicht vorhanden'  
	new-item $installPath -ItemType directory
	write-host 'C:\Install erstellt'  
}
Stop-Transcript


Spaß beiseite...

@erikro

Das Script liegt in der dazugehörigen GPO. Da der PC die GPO verarbeitet bereits beim Start verarbeitet, hat er auch Netz und kann das oben stehende Script starten.
Und man stelle sich vor... selbst wenn das Script am Test PC lokal unter C:\install gespeichert ist und in der GPO darauf verwiesen wird, das gleiche Ergebnis. Mal geht es, meistens nicht...

Ich glaube es liegt nicht am Script-Inhalt face-wink

Schonmal versucht als geplante Aufgabe beim Startvorgang zu starten?

Als Programm powershell und als Argument -File c:\pfad\zu\script.ps1 eintragen.

Ansonsten eventlogs durchkämmen, eventuell findet sich da ein Hinweis.
TheToxic
TheToxic 24.06.2022 um 09:14:12 Uhr
Goto Top
@chaot1coz

Das werde ich ausprobieren!
TheToxic
Lösung TheToxic 24.06.2022 um 09:35:37 Uhr
Goto Top
Danke euch für eure Unterstützung. Mit geplanten Task und dem Trigger "Beim Start" funktioniert es tadellos. Allerdings auch nur wenn die Scripte lokal liegen und nicht direkt in einer GPO.

Ich werde das wohl bei mir alles etwas umstrukturieren, aber mit den geplanten Tasks kann ich leben.

P.S.: Es liegt nicht am Inhalt des Scripts. Wie schon eingangs erwähnt, dies spielt bei meinem beschriebenem Problem keine Rolle. :-P
Crusher79
Crusher79 24.06.2022 um 09:47:46 Uhr
Goto Top
Wir haben es über UNC. Modulweise aufgebaut. Das Start PS1 geht je nach Vorgangn (Startup, Shutdown) etc. woanders rein. Art Lib/ Modul Aufbau.

Also hunderte von Zeilen über zig Dateien. Bei dir ist es ja sehr überschaubar. Sehr seltesam.

Aber für die Zukunft: Arbeite lieber mti try-catch Blöcken. Damit es nicht stehen bleibt, bzw. mit anderen Punkten weiter macht. Catch gibt dir dann auch die Exception wieder. Erleichtert die Fehlersuche.
DerWoWusste
DerWoWusste 24.06.2022 aktualisiert um 10:20:16 Uhr
Goto Top
Mit geplanten Task und dem Trigger "Beim Start" funktioniert es tadellos.
Achtung: wie gesagt, durch das Feature Fast startup durchkreuzt hier einiges. Nicht nur, dass Startskripts nur noch bedingt laufen... das Selbe gilt auch für geplante Tasks mit Trigger "Beim Systemstart". Da ist es besser, einen Trigger zu nehmen wie "täglich 5 Uhr Morgens" und dann einzustellen, dass ausgelassene Tasks sofort nachgeholt werden sollen.
TheToxic
TheToxic 24.06.2022 um 10:31:29 Uhr
Goto Top
Danke für den Hinweis. Ich werde es beobachten face-wink