3
Probleme mit GPO-basierter Softwareverteilung unter Windows 8.x und Windows 10 überwinden
Dies ist ein kurz gehaltener Tipp zu folgender Problemstellung:
Microsoft hat bei Windows 8 und höher in Grundeinstellungen die Verteilung von Software über GPOs stark erschwert. Viele Threads in Foren zeugen von verwirrten Admins, die nicht verstehen, was die Ursache dafür ist, dass es nicht mehr zuverlässig läuft.
Ursache ist das neue Feature "fast boot", welches kernel hibernation einsetzt. Erklärt wird das beides hier: http://blogs.msdn.com/b/b8/archive/2011/09/08/delivering-fast-boot-time ...
An sich eine schöne Sache...nur hätte Microsoft gut daran getan, die Konsequenzen dieser Änderung besser zu dokumentieren. Wer ahnt bitte, dass dadurch drei so wichtige Features wie MSI-Installation und auch Startskripte und ebenso diverse geplante Tasks mit Starttrigger aus dem Tritt gebracht werden. Alle drei genannten Features funktionieren nur noch bei einem Reboot, jedoch nicht mehr bei dem, was Anwender normalerweise tun: abends runterfahren, morgens wieder hochfahren.
Dieser Tipp zeigt, wie man recht einfach zumindest die MSI-Installationen wieder auf die Beine bekommt, ohne dabei auf fast boot verzichten zu müssen.
Der Ablaufplan: wird ein neues MSI zur Ausrollung veröffentlicht, dann merken dass die PCs über den Gruppenrichtlinien-Clientdienst. Dieser sagt dann dem PC spätestens beim nächsten GPO-Backgroundrefresh, dass er beim nächsten Hochfahren doch bitte ein MSI installieren soll; zudem macht er einen Eintrag im Eventlog, der selbiges aussagt. Damit auch wirklich ein echtes Hochfahren stattfindet, wird ein von uns einzurichtender geplanter Task von eben diesem Event getriggert und schaltet "fast boot" temporär aus. Bei nächsten Start wird somit installiert und es laufen auch Startskripte. Damit nun fast Startup nicht dauerhaft deaktiviert bleibt, fügen wir unserem Startskript noch eine Zeile hinzu, die fast Startup wieder aktiviert. Ergebnis: "alle sind glücklich"
Der geplante Task wird domänenweit deployed, wie hier beschrieben: https://technet.microsoft.com/en-us/library/cc725745.aspx
Ausführendes Konto: System
Trigger: Tasktrigger bei Event und zwar Log: System, EventID:108, Quelle "Application Management Group Policy
Ausgeführt wird fogender Befehl:
Ins Startskript kommt dem folgend dann noch eine Zeile:
Ich habe dies getestet auf 8.1, sehe jedoch keinen Grund, nicht davon auszugehen, dass es bei win10 genau so läuft.
Microsoft hat bei Windows 8 und höher in Grundeinstellungen die Verteilung von Software über GPOs stark erschwert. Viele Threads in Foren zeugen von verwirrten Admins, die nicht verstehen, was die Ursache dafür ist, dass es nicht mehr zuverlässig läuft.
Ursache ist das neue Feature "fast boot", welches kernel hibernation einsetzt. Erklärt wird das beides hier: http://blogs.msdn.com/b/b8/archive/2011/09/08/delivering-fast-boot-time ...
An sich eine schöne Sache...nur hätte Microsoft gut daran getan, die Konsequenzen dieser Änderung besser zu dokumentieren. Wer ahnt bitte, dass dadurch drei so wichtige Features wie MSI-Installation und auch Startskripte und ebenso diverse geplante Tasks mit Starttrigger aus dem Tritt gebracht werden. Alle drei genannten Features funktionieren nur noch bei einem Reboot, jedoch nicht mehr bei dem, was Anwender normalerweise tun: abends runterfahren, morgens wieder hochfahren.
Dieser Tipp zeigt, wie man recht einfach zumindest die MSI-Installationen wieder auf die Beine bekommt, ohne dabei auf fast boot verzichten zu müssen.
Der Ablaufplan: wird ein neues MSI zur Ausrollung veröffentlicht, dann merken dass die PCs über den Gruppenrichtlinien-Clientdienst. Dieser sagt dann dem PC spätestens beim nächsten GPO-Backgroundrefresh, dass er beim nächsten Hochfahren doch bitte ein MSI installieren soll; zudem macht er einen Eintrag im Eventlog, der selbiges aussagt. Damit auch wirklich ein echtes Hochfahren stattfindet, wird ein von uns einzurichtender geplanter Task von eben diesem Event getriggert und schaltet "fast boot" temporär aus. Bei nächsten Start wird somit installiert und es laufen auch Startskripte. Damit nun fast Startup nicht dauerhaft deaktiviert bleibt, fügen wir unserem Startskript noch eine Zeile hinzu, die fast Startup wieder aktiviert. Ergebnis: "alle sind glücklich"
Der geplante Task wird domänenweit deployed, wie hier beschrieben: https://technet.microsoft.com/en-us/library/cc725745.aspx
Ausführendes Konto: System
Trigger: Tasktrigger bei Event und zwar Log: System, EventID:108, Quelle "Application Management Group Policy
Ausgeführt wird fogender Befehl:
reg.exe add "HKLM\System\CurrentControlSet\Control\Session Manager\Power" /v HiberbootEnabled /t REG_DWORD /d 0 /f reg.exe add "HKLM\System\CurrentControlSet\Control\Session Manager\Power" /v HiberbootEnabled /t REG_DWORD /d 1 /f Ich habe dies getestet auf 8.1, sehe jedoch keinen Grund, nicht davon auszugehen, dass es bei win10 genau so läuft.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 272135
Url: https://administrator.de/knowledge/probleme-mit-gpo-basierter-softwareverteilung-unter-windows-8-x-und-windows-10-ueberwinden-272135.html
Ausgedruckt am: 23.12.2024 um 00:12 Uhr
3 Kommentare
Neuester Kommentar
Meine Lösung ist, einfach fast-boot auszuschalten. meine bisherigen Erfahrugne sagen, das es meist Probleme macht, und es die paar Sekunden Zeitersparnis nicht wert ist. Wenn geschwindigkeit beim booten wichtig ist, nimmt man einfach eine dementsrpechend passende Konfiguration.
ich weiß, daß ist HJolzhammermehtode, aber spart einige Kopfschmerzen.
lsk
ich weiß, daß ist HJolzhammermehtode, aber spart einige Kopfschmerzen.
lsk
2
ja genau. Features die die Welt nicht braucht.
..und sehr wahrscheinlich funktioniert die Install von APPs aus dem Shop reibungslos.
Und wenn ich den Tipp hier richtig verstehe, dann würde mit der 2. Zeile
- also erfolgter Softwareinstall wieder einschalten des Fastboots -
die Software zwar morgens nach dem Hochfahren verteilt werden,
aber Scripte usw. würden dann bei einem runter- hochfahren die Tage danach
doch nicht ausgeführt werden (weil FastBoot ja wieder an ist) ?
Dann wären bestimmt nicht alle glücklich.... (?)
..und sehr wahrscheinlich funktioniert die Install von APPs aus dem Shop reibungslos.
Und wenn ich den Tipp hier richtig verstehe, dann würde mit der 2. Zeile
- also erfolgter Softwareinstall wieder einschalten des Fastboots -
die Software zwar morgens nach dem Hochfahren verteilt werden,
aber Scripte usw. würden dann bei einem runter- hochfahren die Tage danach
doch nicht ausgeführt werden (weil FastBoot ja wieder an ist) ?
Dann wären bestimmt nicht alle glücklich.... (?)
Es geht nicht um Skripte, Schmitzi, die beeinflusst es nicht, nein, aber während MSI-Verteilung ein gebräuchliches Feature ist, sind Startskripte, die regelmäßig laufen müssen, eher ungewöhnlich und das meiste kann per GPP geregelt werden. Bei geplanten Tasks mit Starttrigger sieht das anders aus, dass die nicht gehen, ist nicht so schön, aber man muss diesen Trigger meist nicht nutzen, sondern kann es an andere Dinge, die früh passieren, ketten.
die paar Sekunden Zeitersparnis ...ja genau. Features die die Welt nicht braucht.
Wenn Ihr mal ein Instantgo-Notebook in Händen haltet, denkt an Eure Worte.
