"Restart needed for updates to take effect (0x000006d)"

a week down the line - we are still seeing large numbers  (118 at present) of devices at error - with the "RESTART NEEDED .............." message

They are all rebooted overnight - so how long should I wait before being concerned ?

They are ALL switched on !

Hello Weeboo,

a systematic approach is better than just looking at numbers and contingent events and actions. First thing to check is whether the endpoints in question have actually rebooted - Windows' system up time is an indicator. If they did the next step is to determine the component requesting the reboot, I'd check the VolatileFlags key first. If it's not present then one of the install logs should have a corresponding message near its end.

Christian

QC said:

Hello Weeboo,

a systematic approach is better than just looking at numbers and contingent events and actions. First thing to check is whether the endpoints in question have actually rebooted - Windows' system up time is an indicator. If they did the next step is to determine the component requesting the reboot, I'd check the VolatileFlags key first. If it's not present then one of the install logs should have a corresponding message near its end.

Christian

 

Hi Christian

Sorry for the delay in updating you

I tried the VOLATILEFLAGS key - on one device and found that it was not present - what is the next step ?

Also - if I did write a powershell script and run it on all devices on GP - Would it matter that the key was removed from ALL devices - even those not at error ?

Hello Weeboo,

the key isn't there just for the fun of it. As the note in the 0000006d article says you should only remove it if it persists after a reboot.

next step as mentioned in my previous post - did the endpoints actually reboot (and not go through turn off/fast boot cycle)? The ALUpdate log normally mentions the presence of the VolatileFlags key. PendingFileRenameOperations also constitute a reboot requirement. And, as said, a component's install log normally notes a reboot requirement.

Christian 

QC said:

Hello Weeboo,

the key isn't there just for the fun of it. As the note in the 0000006d article says you should only remove it if it persists after a reboot.

next step as mentioned in my previous post - did the endpoints actually reboot (and not go through turn off/fast boot cycle)? The ALUpdate log normally mentions the presence of the VolatileFlags key. PendingFileRenameOperations also constitute a reboot requirement. And, as said, a component's install log normally notes a reboot requirement.

Christian 

 

Yes - they are all switched down EVERY night and up every morning

The numbers at error - dropped down from a peak of around 160 to 120 to 100 to 80 but now appears to have bottomed out at 62 -  it has remained at this level for a week / 10 days

Hello Weeboo,

that the number decreased is a good sign. 62 is a lot (considering your total) but there might be common reasons. Some investigation is required though.

Christian

Are those devices Windows 10 devices with Fast Boot enabled? If so, shutting down does not really shut them down.

Fast Boot can lead to a lot of strange start behaviors like not applied policies or the mentioned issue.

I recommend to disable Fast Boot (unfortunately it returns with each Feature Update, so you would have to set the registry key to disable, maybe per GPO). Strange enough, that Windows 10 has a GPO to Force using Fast Boot, but none to disable.

Best greetings from Germany
Olaf

Olaf Engelke said:

Are those devices Windows 10 devices with Fast Boot enabled? If so, shutting down does not really shut them down.

Fast Boot can lead to a lot of strange start behaviors like not applied policies or the mentioned issue.

I recommend to disable Fast Boot (unfortunately it returns with each Feature Update, so you would have to set the registry key to disable, maybe per GPO). Strange enough, that Windows 10 has a GPO to Force using Fast Boot, but none to disable.

Best greetings from Germany
Olaf 

Thanks Olaf - this could be a reason why we still have large numbers of devices showing this error !!

Olaf Engelke said:

Are those devices Windows 10 devices with Fast Boot enabled? If so, shutting down does not really shut them down.

Fast Boot can lead to a lot of strange start behaviors like not applied policies or the mentioned issue.

I recommend to disable Fast Boot (unfortunately it returns with each Feature Update, so you would have to set the registry key to disable, maybe per GPO). Strange enough, that Windows 10 has a GPO to Force using Fast Boot, but none to disable.

Best greetings from Germany
Olaf

 

I have been searching on-line and it appears that MS have not offered the option within GPO to "disable" fastboot - or HIBERBOOT - Only to "enable" it

Any further help welcome

Thanks

You can create a Group Policy Preference setting to Replace the appropriate registry value:

In HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Power

Set the value of HiberBootEnabled to 0

and then apply this policy to your computers.

Best greetings from Germany
Olaf