This weeks Group Policy setting should be used in environments where you still use a logon script. While I implore you stop using logon scripts (see http://www.ihatelogonscripts.com ) they are still out there for a majority of customers and as such still need to be properly managed. This setting is called “Maximum wait time for Group Policy scripts†but it can also be referred to as a “dead man’s switch†which will kill any logons script from running if it ever locks up <sarcasm> which of course NEVER happens </sarcasm> . This setting can be found under Computer Configuration > Policies > Administrative Templates > System >Scripts.
The default value for this option is 600 seconds (10 minutes) but I recommend that you do configured this to something more reasonable between 60 seconds (1 minute) to 180 seconds (3 minutes) depending on your environment.
For more information on this option check out http://technet.microsoft.com/en-us/library/cc780635(WS.10).aspx
Blog Post: Group Policy Setting of the Week 28 – Maximum wait time for Group Policy scripts http://bit.ly/d2JqyO
RT @grouppolicy_biz: Blog Post: Group Policy Setting of the Week 28 – Maximum wait time for Group Policy scripts http://bit.ly/d2JqyO
RT @grouppolicy_biz: Blog Post: Group Policy Setting of the Week 28 – Maximum wait time for Group Policy scripts http://bit.ly/d2JqyO
Hi Alan,
The good thing with login/off startup/shutdown scripts, assuming they are correctly written, is that they run only as long as they need to to finish all tasks and they don’t lock up the login / … process any second longer that necessary. The setting you devoted your article is very important in situations when (mostly shutdown) scripts require to perform longer to finish all maintenance / deployment tasks. From my experience fully automatized deployment of humongous application packs of adobe or autodesk takes even more than an hour on some workstations. So the setting is still very important to have your applications installed and avoid the installation being interrupted in the middle of the process. And believe me, there are no other options as group policy software installation workable with these packages.
Everything worked fine until windows 7. The “2 hours script” policy is in place but the windows 7 processes shutdown scripts only for maximum 15 minutes and then it just shuts down completely. It doesn’t matter if the script was still in the middle of work. There is only a system log entry saying:
Event ID: 7043
The Group Policy Client service did not shut down properly after receiving a preshutdown control.
And it takes exactly 15 minutes to have the script interrupted and system shut down.
So is the setting obsolete in windows 7 or it’s another bug that needs to be looked at.
Are you saying that even when set for two hours this still fails at 15 minutes?
exactly
I can confirm the same. I have the group policy script max wait time set to 31999 seconds (1 second less than the max, or about 8 hours). Scripts run up to 8 hours on XP, but Windows 7 Pro SP1 kills after 15 minutes with the same Event ID 7043 mentioned. 10 minutes is the default, so the setting is having an effect, but maybe 15 minutes is the longest it can go.
Just a thought – perhaps try setting it to 0 (infinite)? It’ll never kill it, but at least it’ll let it run more than 15 minutes. I’m going to test this tonight…
As an aside, a great reason to use logoff scripts is to do a defrag. The performance impact means it can really only be done without a user present, so why not when they shut it down to go home? I even use it to call a third party defrag tool — but Microsoft assuming that a script would never need more than 15 minutes (like a good defrag almost always does) is just wrong. Why these common sense maintenance utilities aren’t built into the Windows server-client relationship is beyond me. “Defrag at next shutdown” should be a checkbox in Active Directory.