Administration of more than one PC is not a bed of roses. Especially in small companies or medium-sized enterprises, it’s often a horror, because of the fact that Computers, Network and Servers are grown “historically”. Who doesn’t know all oppurtinities he has to manage this, often drives a running shoe administration instead of remotely logging in. An important tool for automation of certain tasks like Updating software or Copying files during startup, are the startup scripts with type of Batch or Powershell. Unfortunately Windows 8, 8.1 and 10 are jackknifing this.
Hibernate / Fast Startup Boot prevents Execution
Microsoft has tuned many factors to optimize boot routine and decided for the last two major Windows version not to completely shutdown the operating system. Instead it is a hybrid hibernation. In contrast to the normal hibernation mode, not everything is saved to an image on hard disk. By the way, this is the reason why the uptime displaying in the taskmanager often counts several days. Side-effect here is, Startup Scripts are often not being executed. I have noticed this on like 20 PCs, which seldomly have executed the scripts during startup. Only a reboot gives a fresh initialisation of every OS component including startup script execution.
Remedy is a Registry modification
To get the startup scripts reliable executed, you have to disable the Hibernate Boot / Fast Startup in the Windows registry. Concerning this you have to set the Registry Key with the path of “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Power\HiberbootEnabled” to the DWORD value 0.
This can also be done via Group Policy in “Computerconfiguration” for all clients belonging to one GPO Policy.
Unfortunatly I didn’t find any hint on part of Microsoft or some MVP, why and when startup scripts are executed with these mixed hibernation startup.
More sources of errors
It is important to say there a many other failures which prevent a startup script execution. For example the PC (or user if you want to run a logon script) has no access or execution rights for the script. It is a good practise to store any logon or startup script on the SYSVOL of the domain controllers, so you don’t run the risk of missing access rights.
Likewise it is a common error to define Powershell scripts in the tab for batch scripts instead of using the tab “Powershell scripts”. This failure for example does not directly run into a failure like it is not tried to be executed. The Exectuion Policy in this case is restricted, no matter what you define in other GPO Directives! Interesting fact is a faulty replication of domain controllers also prevents scripts from being executed. If you experience missing execution of scripts the Windows events viewer and GPresult are your best analysing instruments.
This post is also available in: 
Deutsch (German)
