10
Probleme durch fast startup
...also known as "schnell vs. funktional" oder auch "Microsoft gegen Microsoft".
Moin Kollegen.
Es geht um eine dolle Eigenschaft von Windows 8.x und Windows 10 und Konsequenzen daraus.
Diese OS machen Kernel-Hibernation, d.h. Ausschalten und Einschalten ist nun funktional etwas anderes als neu zu starten. Das Ganze nennt sich "fast startup" und erspart dem Benutzer einige Sekunden beim Hochfahren.
Ein runter- und wieder hochfahren ist also kein Neustart sondern ein Einschlummern des Kernels und ein Wiedererwachen daraus. Runter-hoch ist natürlich auch weiterhin der Normalfall im Büro.
Konsequenz daraus: Mit default settings laufen weder unter Win8.x noch unter win10 Startskripte, ebenso wenig laufen GPO-basierte Softwareverteilungen mit MSI-Paketen.
Was also tun, wenn man ein MSI-update verteilen möchte, welches zwingend nur bei Neustart verteilt werden kann, weil das zu aktualisierende Programm im Betrieb permanent läuft?
Wie könnte man einmalig fast startup ausschalten und nach erfolgter Installation wieder einschalten? (ja, wir wollen es haben).
Es gäbe da sicherlich Wege über Setzen/Entfernen des Registrykeys
HKLM\System\CurrentControlSet\Control\Session Manager\Power\HiberbootEnabled
(wenn auf 0 wird langsam gestartet und MSIs funktionieren) - aber das zieht dann weitere Probleme nach sich.
Kennt ihr einen eleganten Weg oder eine best practice? Ich frage ausdrücklich nicht nach Alternativen zum MSI-Deployment per GPO und hoffe auch nicht auf den schlauen Vorschlag, fast startup dauerhaft abzuschalten.
Moin Kollegen.
Es geht um eine dolle Eigenschaft von Windows 8.x und Windows 10 und Konsequenzen daraus.
Diese OS machen Kernel-Hibernation, d.h. Ausschalten und Einschalten ist nun funktional etwas anderes als neu zu starten. Das Ganze nennt sich "fast startup" und erspart dem Benutzer einige Sekunden beim Hochfahren.
Ein runter- und wieder hochfahren ist also kein Neustart sondern ein Einschlummern des Kernels und ein Wiedererwachen daraus. Runter-hoch ist natürlich auch weiterhin der Normalfall im Büro.
Konsequenz daraus: Mit default settings laufen weder unter Win8.x noch unter win10 Startskripte, ebenso wenig laufen GPO-basierte Softwareverteilungen mit MSI-Paketen.
Was also tun, wenn man ein MSI-update verteilen möchte, welches zwingend nur bei Neustart verteilt werden kann, weil das zu aktualisierende Programm im Betrieb permanent läuft?
Wie könnte man einmalig fast startup ausschalten und nach erfolgter Installation wieder einschalten? (ja, wir wollen es haben).
Es gäbe da sicherlich Wege über Setzen/Entfernen des Registrykeys
HKLM\System\CurrentControlSet\Control\Session Manager\Power\HiberbootEnabled
(wenn auf 0 wird langsam gestartet und MSIs funktionieren) - aber das zieht dann weitere Probleme nach sich.
Kennt ihr einen eleganten Weg oder eine best practice? Ich frage ausdrücklich nicht nach Alternativen zum MSI-Deployment per GPO und hoffe auch nicht auf den schlauen Vorschlag, fast startup dauerhaft abzuschalten.
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 271809
Url: https://administrator.de/forum/probleme-durch-fast-startup-271809.html
Ausgedruckt am: 06.04.2025 um 19:04 Uhr
10 Kommentare
Neuester Kommentar
Moin,
lass die Kisten einen reboot machen, das triggert einen normalen Start auch bei aktiviertem fastboot.
Gruß jodel32
lass die Kisten einen reboot machen, das triggert einen normalen Start auch bei aktiviertem fastboot.
Gruß jodel32
Moin.
wie stellst Du dir das vor? Mail an alle: "bitte macht mal einen Reboot, jetzt gleich"? Vergiss es
Dass das eine Option ist, ist sonnenklar.
wie stellst Du dir das vor? Mail an alle: "bitte macht mal einen Reboot, jetzt gleich"? Vergiss es
Dass das eine Option ist, ist sonnenklar.
Zitat von @114757:
lass die Kisten einen reboot machen, das triggert einen normalen Start auch bei aktiviertem fastboot.
lass die Kisten einen reboot machen, das triggert einen normalen Start auch bei aktiviertem fastboot.
Ggf einen einaligen Zeitgetriggerten Reboot per Taskplaner oder GPO?
lks
Hi LKS.
Und wann sollte das durchsetzbar sein? Servicewindows jeden zweiten Dienstag 12 Uhr? Nee, komm, das ist auch nicht so prall. Da ist das mit dem Registrywert ja noch weitaus eleganter.
Und wann sollte das durchsetzbar sein? Servicewindows jeden zweiten Dienstag 12 Uhr? Nee, komm, das ist auch nicht so prall. Da ist das mit dem Registrywert ja noch weitaus eleganter.
oder die Kisten in der Nacht via WOL hochfahren lassen und via Powershell einen Reboot triggern und dann Shutdown.
WOL is nicht, da verschlüsselt inklusive PBA.
Hi
Ein mal wie du beschrieben hast per GPO in der Registrierung abschalten das update installieren und nie wieder einschalten.
Morgens können sich die Mitarbeiter einen Kaffee machen und alle sind glücklich.
LG
Ein mal wie du beschrieben hast per GPO in der Registrierung abschalten das update installieren und nie wieder einschalten.
Morgens können sich die Mitarbeiter einen Kaffee machen und alle sind glücklich.
LG
Mir kommt gerade die brauchbare Idee, dass man den regkey "on demand" auf Null stellen könnte, indem man einen Task deployed, der auf das Event reagiert, wenn eine Installation bis zum nächsten Neustart verzögert wird und dann den Regkey setzt - das passt. Rückgängig machen würde das dann ein Startskript.
EventID:108, Log: System, Quelle "Application Management Group Policy"
Was haltet Ihr davon?
Edit: ausgetestet, läuft. Wird evtl. demnächst als Tipp hier auftauchen.
EventID:108, Log: System, Quelle "Application Management Group Policy"
Was haltet Ihr davon?
Edit: ausgetestet, läuft. Wird evtl. demnächst als Tipp hier auftauchen.
1
Moin,
würde mich über einen Wissensbeitrag zu diesem Thema freuen.
VG
Val
würde mich über einen Wissensbeitrag zu diesem Thema freuen.
VG
Val
