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?
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?
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 3153344382
Url: https://administrator.de/contentid/3153344382
Ausgedruckt am: 22.11.2024 um 00:11 Uhr
13 Kommentare
Neuester Kommentar
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.
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.
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......
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.....
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.....
Moin,
Aha.
Wie kommst Du auf die Idee? Woher sollen wir wissen, woran das liegen kann, wenn wir nicht wissen, was das Skript tut?
OK. Das solltest Du vielleicht überdenken. Aber erstmal sorgt es dafür, dass alles ausgeführt werden kann.
Sind denn die anderen GPOs, die man so braucht, damit das geht, auch definiert? Ist, wie @DerWoWusste schon angemerkt hat, auch der Schnellstart ausgeschaltet?
Wenn das Skript startet, dann greift keine Execution Policy, die das verhindert. Es startet ja.
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
Zitat von @TheToxic:
ich habe ein PS-Script geschrieben um eine Softwareinstallation auf Aktualität zu prüfen und zu aktualisieren.
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
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
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
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
Moin,
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
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.
@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
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
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
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
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
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.
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.
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.
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.