Ever wondered why Windows 8 and 10 don't seem to accept your GPO-based software deployment while Windows 7 does? Read on.
You, the admin, deploy an MSI-based software update via group policy. To your surprise, a week later, numerous Windows 8 and Windows 10 clients still run the old software and the users complain, while all, yes, all Windows 7 machines run the new one.
[Just for fun I'll write the whole article in interview style...]
Q: What has gone wrong?
A: Not much, you just did not keep pace with the latest performance optimization tricks that Microsoft has introduced: "fast boot" aka kernel hibernation.
Q: I've heard of bears that hibernate, but kernels? What is it?
A: A time saver. Instead of performing a full boot each time you shutdown your computer and turn it on again, Microsoft decided it would be smarter for the future operating systems to not shutdown but to hibernate the kernel, save it to disk and read it again at boot time -- it will make the system start a lot faster.
Q: So it's a good thing, but...?
A: But Microsoft hasn't documented the caveats that come with it and not many admins know about them, yet.
Q: So that is what this article is about, to let people know... about what?
A: About what needs to be done to take advantage of fast startup and still be able to deploy software!
Q: Ah, great. Go on, what are those caveats about?
A: The graphic at the top of this article illustrates it: instead of doing a full system initialization, fast startup will skip some processes and instead read a hibernated kernel from disk.
Q: Ah. I must confess I didn't understand, but you seem to say that this "time saver technology" leaves out some parts of the boot process -- important parts?
A: Not for the average home user, he will never notice. But it's important for company customers when targeted by GPOs to deploy software. These skipped processes will (amongst other things) prevent these GPOs from being processed at startup. Result: the software is not deployed.
Q: Now we are getting somewhere. You mean, Microsoft has somewhat crippled their own technology "software deployment" in favor of faster booting times? Why would they do that, and how would they explain to customers that it does not work anymore?
A: It does still work, but differently. On Windows 8 and Windows 10 it will only work if we instruct our running machine to restart. A true restart is in fact not the same as if we shutdown the machine and turn it on again –- because the latter now uses kernel hibernation. It used to be the same on Windows 7, but not any more since Windows 8.
Q: OK, and if I am not mistaken then that is your main point here? So if some guy at the office shuts down his computer in the evening and turns it on next morning, the software deployment would not run?
Q: It would only run at next restart?
Q: But that restart could be weeks away, maybe not before the next monthly patch day where a restart would surely be enforced, right?
Q: I see. Pretty nasty from an admin's point of view. Can't we simply turn off fast startup?
A: We could, but that would mean to lose this great new technology that we are profiting from day-in day-out just for getting it right on these few software-deployment days.
Q: Agreed, not good either. So what is this solution of yours about?
A: It's rather simple. I'll “tell” the system to turn off fast startup whenever it detects a GPO change that includes ready-to-deploy software. So on next start, it will indeed install that software immediately.
Q: How is that done?
A: Windows has a group policy service which monitors GPO changes. When a GPO version changes, it reads the new GPO. It does so for software deployment changes and the trick is, Windows writes an event to a log when it does detect these. I simply take the log and have it “watched” for these type of events.
Q: And when such an event is found? Wait… you mean then you temporarily disable fast startup?
A: Correct. The task scheduler will watch the event log and eventually tell the OS not to do fast startup next time it boots but instead take its time and process the software deployment GPO and install.
Q: Good thing. But we have to re-enable fast startup afterward somehow, right?
A: Right, that will be done at next startup as well, so it will only be deactivated for exactly one boot.
Q: That is done how?
A: By a GPO based startup script.
Q: The type of scripts that run on each computer start?
A: Carefully. Starting a Win8/Win10 system does NOT trigger startup scripts -– because of fast startup. So normally, it will not run, either. Only after the software installation it will run, or after reboots.
Q: Wow, that seems just right. So startup scripts are another thing that Microsoft has kind of sacrificed for faster boot times? Sounds as if Microsoft needed a selling point. Anything else missing?
A: Yes, scheduled tasks that use the trigger “at system startup” are also no longer working by default.
Q: Oh. But those have nothing to do with software deployment?
A: No, just worth mentioning as some important functions that admins deploy might rely on them as well. So if you rely on these, it would be better to turn off fast startup for good.
Q: Ok, understood. Just for the record, which event should admins have task scheduler look out for?
A: It's in the system log,
Source "Application Management Group Policy”
Create a task trigger for that very event. The whole task is deployed as described in https://technet.microsoft.com/en-us/library/cc725745.aspx by the way.
Q: And what would task scheduler do, then?
A: Task scheduler would run the following command as system account:
reg.exe add "HKLM\System\CurrentControlSet\Control\Session Manager\Power" /v HiberbootEnabled /t REG_DWORD /d 0 /f
Q: I get it, Hiberboot, that's booting using kernel hibernation files and a value of zero disables it. Good! Last thing: how would the startup script go?
A: The same command inverted, basically:
reg.exe add "HKLM\System\CurrentControlSet\Control\Session Manager\Power" /v HiberbootEnabled /t REG_DWORD /d 1 /f
Q: And you tested that on Windows 8.1 and 10?
A: I did.
Q: Has that task any other impact on the system, does it consume performance?
A: No further impact.
Q: Well, fine. Thanks, I got to try that, soon.