Customising the hard coded Group Policy processing timeout value

[Guest]

Hi,

I have been investigating a problem that we have recently encountered on our
Windows Server 2003/Windows XP network.

We deploy new workstation using a combination of RIS and Group Policy
Software Installation, to install the initial copy of Windows, and the
software that goes along with it. As we are a school, we have a very large
number of MSI packages that have to be deployed to certain workstations, and
sometimes this initial installation takes quite a long time.

As a result of this, we have recently come across a problem with the
built-in hard time limit for processing group policy of 60 minutes (1 hour).
This is mentioned on a couple of pages on the Microsoft website:

http://msdn2.microsoft.com/en-us/library/aa374304.aspx

and

http://technet2.microsoft.com/Windo...a909-4f61-aded-c5b69f5f730b1033.mspx?mfr=true
(under 'Time Limit for Processing of Group Policy')

Both of these pages state that there is no way to change this time limit.
However, we are experiencing problems with this limit, because of the
following scenario:

1) Package 1 installs (actually the Microsoft .Net Framework 1.1).
2) Package 2 installs (the Microsoft .Net Framework 2.0), and tries to
update mscoree.dll, which is in use by 'msiexec' and 'wmiadap', both Windows
processes. It requests a reboot (shown in the System event log), but other
packages continue to install for as long as Group Policy processing continues.
3) At 1 hour, we hit the the Group Policy processing timeout. At this point,
whatever package is installing at the time is stopped half way through, and
the computer reboots (for the .Net Framework 2.0 install).
4) Group Policy processing resumes. An event log error appears saying that
'An install for [packagename] is currently suspended. You must undo the
changes made by that install to continue. Do you want to undo those
changes?'. The system apparently automatically answers 'Yes', the previous
package is rolled back, and installation of the next package continues.
However the previous package that was installing before the reboot is never
installed.
5) The computer finally boots up, with one of the packages missing, and
little indication that this is the case. The administrator must check the
event log and remove/reinstall the package that was being installed at the
point of the timeout/reboot.

I believe that the whole of this could be fixed by extending the Group
Policy processing timeout beyond 60 minutes. As the above websites stated,
there is currently no documented way to do this. However, I did come across a
couple of web chats, where people from Microsoft indicated that they would
look into providing a way to change this timeout value, for example:

http://www.microsoft.com/technet/community/chats/trans/windowsnet/wnet_092904.mspx

MSFT Mike Stephens (Expert):
Q: Cross Active Directory/Group Policy Question, is there a way to bypass
the 1 hour timeout limitation for policy processing? With the size of some
MSI deployed applications it is a pain. Or make the timeout pessimistic so
it rolls back unfinished MSIs
A: Sorry, no there is not way to change this behavior. Your feedback on how
this is a problem in your environment would be very helpful. Please send
this to http://WindowsServerFeedback.com.
and

http://www.microsoft.com/technet/community/chats/trans/sysbuild/05_0621_tn_sys.mspx

Bret [MSFT] (Moderator):
Q: Bret> No, the period between when Group Policy processing starts when
you boot and the login screen I'm talking about. That has a hard timeout
of 60 minutes.
A: Oh my mistake. Sorry, as far as i know that is a hard timeout and no
way around it. I will forward the request though for this to be expanded.

As these chats took place in 2004 and 2005 respectively, I was hoping that
this might have been looked at since then, and that a hotfix might be
available. Could someone from Microsoft look into this please, and see if
there is a fix for this issue yet?

Regards,

Chris Hill
ICT Technician
Colchester Royal Grammar School

 

[Poprivet]

I can 't answer you questions, but I did want to let you know that you are
not talking to MS Inc. here; this is a usenet newsgroups and it's people
like you and I posting here, not company reps. MS folks do come around now
and then but not in a company role, simply to participate as you and I do.

Regards,

Tom`

Hi,

I have been investigating a problem that we have recently encountered
on our Windows Server 2003/Windows XP network.

We deploy new workstation using a combination of RIS and Group Policy
Software Installation, to install the initial copy of Windows, and the
software that goes along with it. As we are a school, we have a very
large number of MSI packages that have to be deployed to certain
workstations, and sometimes this initial installation takes quite a
long time.

As a result of this, we have recently come across a problem with the
built-in hard time limit for processing group policy of 60 minutes (1
hour). This is mentioned on a couple of pages on the Microsoft
website:

http://msdn2.microsoft.com/en-us/library/aa374304.aspx

and

http://technet2.microsoft.com/Windo...a909-4f61-aded-c5b69f5f730b1033.mspx?mfr=true
(under 'Time Limit for Processing of Group Policy')

Both of these pages state that there is no way to change this time
limit. However, we are experiencing problems with this limit, because
of the following scenario:

1) Package 1 installs (actually the Microsoft .Net Framework 1.1).
2) Package 2 installs (the Microsoft .Net Framework 2.0), and tries to
update mscoree.dll, which is in use by 'msiexec' and 'wmiadap', both
Windows processes. It requests a reboot (shown in the System event
log), but other packages continue to install for as long as Group
Policy processing continues. 3) At 1 hour, we hit the the Group
Policy processing timeout. At this point, whatever package is
installing at the time is stopped half way through, and the computer
reboots (for the .Net Framework 2.0 install). 4) Group Policy
processing resumes. An event log error appears saying that 'An
install for [packagename] is currently suspended. You must undo the
changes made by that install to continue. Do you want to undo those
changes?'. The system apparently automatically answers 'Yes', the
previous package is rolled back, and installation of the next package
continues. However the previous package that was installing before
the reboot is never installed. 5) The computer finally boots up, with
one of the packages missing, and little indication that this is the
case. The administrator must check the event log and remove/reinstall
the package that was being installed at the point of the
timeout/reboot.

I believe that the whole of this could be fixed by extending the Group
Policy processing timeout beyond 60 minutes. As the above websites
stated, there is currently no documented way to do this. However, I
did come across a couple of web chats, where people from Microsoft
indicated that they would look into providing a way to change this
timeout value, for example:

http://www.microsoft.com/technet/community/chats/trans/windowsnet/wnet_092904.mspx

MSFT Mike Stephens (Expert):
Q: Cross Active Directory/Group Policy Question, is there a way to
bypass the 1 hour timeout limitation for policy processing? With the
size of some MSI deployed applications it is a pain. Or make the
timeout pessimistic so it rolls back unfinished MSIs
A: Sorry, no there is not way to change this behavior. Your feedback
on how this is a problem in your environment would be very helpful.
Please send this to http://WindowsServerFeedback.com.
and

http://www.microsoft.com/technet/community/chats/trans/sysbuild/05_0621_tn_sys.mspx

Bret [MSFT] (Moderator):
Q: Bret> No, the period between when Group Policy processing starts
when you boot and the login screen I'm talking about. That has a
hard timeout of 60 minutes.
A: Oh my mistake. Sorry, as far as i know that is a hard timeout and
no way around it. I will forward the request though for this to be
expanded.

As these chats took place in 2004 and 2005 respectively, I was hoping
that this might have been looked at since then, and that a hotfix
might be available. Could someone from Microsoft look into this
please, and see if there is a fix for this issue yet?

Regards,

Chris Hill
ICT Technician
Colchester Royal Grammar School

 

[Sean Cai [MSFT]]

Hi Mr. Hill,

Thank you for posting in the Microsoft newsgroup!

I do understand your concerns. From my point of view, I understand your
feeling and how frustrated when you find that our product cannot meet your
needs. So, it is my pleasure to help you to reflect your recommendation to
the proper department for their consideration.

In addition, please feel free to submit your suggestion on our product to
the following link. Our Product Group reviews the suggestions submitted by
our customers. Your feedback is valuable for us to improve our products and
increase the level of service provided.

https://support.microsoft.com/common/survey.aspx?scid=sw;en;1208&showpage=1&
ws=search

You can also send your suggestion through email to MS Wish. MS Wish email
address is:[email protected]£®

Have a good day!

Sean Cai, MCSE2000
Microsoft Online Support

Get Secure! - www.microsoft.com/security
=====================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
=====================================================

 

[Guest]

Hi,

Actually, if you have a TechNet Plus subscription, one of the benefits is
that if you post to these newsgroups, it gets flagged up by Microsoft and
they say that they will respond to your message within a given period of
time. It's called 'Managed Newsgroups'. We shall see how well it works!

Regards,
Chris
--
''Therefore, if anyone is in Christ, he is a new creation;
the old has gone, the new has come!'' - 2 Corinthians 5v17

I can 't answer you questions, but I did want to let you know that you are
not talking to MS Inc. here; this is a usenet newsgroups and it's people
like you and I posting here, not company reps. MS folks do come around now
and then but not in a company role, simply to participate as you and I do.

Regards,

Tom`

Hi,

I have been investigating a problem that we have recently encountered
on our Windows Server 2003/Windows XP network.

We deploy new workstation using a combination of RIS and Group Policy
Software Installation, to install the initial copy of Windows, and the
software that goes along with it. As we are a school, we have a very
large number of MSI packages that have to be deployed to certain
workstations, and sometimes this initial installation takes quite a
long time.

As a result of this, we have recently come across a problem with the
built-in hard time limit for processing group policy of 60 minutes (1
hour). This is mentioned on a couple of pages on the Microsoft
website:

http://msdn2.microsoft.com/en-us/library/aa374304.aspx

and

http://technet2.microsoft.com/Windo...a909-4f61-aded-c5b69f5f730b1033.mspx?mfr=true
(under 'Time Limit for Processing of Group Policy')

Both of these pages state that there is no way to change this time
limit. However, we are experiencing problems with this limit, because
of the following scenario:

1) Package 1 installs (actually the Microsoft .Net Framework 1.1).
2) Package 2 installs (the Microsoft .Net Framework 2.0), and tries to
update mscoree.dll, which is in use by 'msiexec' and 'wmiadap', both
Windows processes. It requests a reboot (shown in the System event
log), but other packages continue to install for as long as Group
Policy processing continues. 3) At 1 hour, we hit the the Group
Policy processing timeout. At this point, whatever package is
installing at the time is stopped half way through, and the computer
reboots (for the .Net Framework 2.0 install). 4) Group Policy
processing resumes. An event log error appears saying that 'An
install for [packagename] is currently suspended. You must undo the
changes made by that install to continue. Do you want to undo those
changes?'. The system apparently automatically answers 'Yes', the
previous package is rolled back, and installation of the next package
continues. However the previous package that was installing before
the reboot is never installed. 5) The computer finally boots up, with
one of the packages missing, and little indication that this is the
case. The administrator must check the event log and remove/reinstall
the package that was being installed at the point of the
timeout/reboot.

I believe that the whole of this could be fixed by extending the Group
Policy processing timeout beyond 60 minutes. As the above websites
stated, there is currently no documented way to do this. However, I
did come across a couple of web chats, where people from Microsoft
indicated that they would look into providing a way to change this
timeout value, for example:

http://www.microsoft.com/technet/community/chats/trans/windowsnet/wnet_092904.mspx

MSFT Mike Stephens (Expert):
Q: Cross Active Directory/Group Policy Question, is there a way to
bypass the 1 hour timeout limitation for policy processing? With the
size of some MSI deployed applications it is a pain. Or make the
timeout pessimistic so it rolls back unfinished MSIs
A: Sorry, no there is not way to change this behavior. Your feedback
on how this is a problem in your environment would be very helpful.
Please send this to http://WindowsServerFeedback.com.
and

http://www.microsoft.com/technet/community/chats/trans/sysbuild/05_0621_tn_sys.mspx

Bret [MSFT] (Moderator):
Q: Bret> No, the period between when Group Policy processing starts
when you boot and the login screen I'm talking about. That has a
hard timeout of 60 minutes.
A: Oh my mistake. Sorry, as far as i know that is a hard timeout and
no way around it. I will forward the request though for this to be
expanded.

As these chats took place in 2004 and 2005 respectively, I was hoping
that this might have been looked at since then, and that a hotfix
might be available. Could someone from Microsoft look into this
please, and see if there is a fix for this issue yet?

Regards,

Chris Hill
ICT Technician
Colchester Royal Grammar School

 

[Guest]

I ended up raising a support incident with Microsoft to sort this out: here
is the fix that I found for anyone else with the same problem.

The problem is indeed with the 1 hour Group Policy timeout, and there is
currently no way to directly modify this value. However, it is possible to
extend the time that Group Policy waits for by setting the MaxGPOScriptWait
key in HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System, which
is the same as setting the 'Maximum wait time for Group Policy scripts' value
in Group Policy. There is more information on this registry setting here:

http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/regentry/91596.mspx?mfr=true

If you increase this timeout from the default value of 600 seconds (10
minutes), or set it to 0 so that there is no timeout, then the computer will
wait for the specified amount of time after the 1 hour default for all Group
Policy processing to complete, before initiating the reboot. This fixed my
problem with software installation and hopefully also should fix any other
problems people might be having with the 1 hour Group Policy processing
timeout.

However if you are using RIS or another similar automated deployment system,
you may find that merely setting this value in Group Policy does not help, as
it will not apply to the *first* bootup after RIS has completed. To get
around this, you can set the registry value on the computer *before* the
first bootup by using cmdlines.txt. You can find out more about cmdlines.txt
on Microsoft's website, or MSFN's Unattended Windows site at
http://unattended.msfn.org/, but the basic procedure is:

Create a file called cmdlines.txt in a folder called '$oem$' at the same
level as the i386 folder for the image you are creating on your REMINST share.
Put inside the file the following contents:
[COMMANDS]
"MaxGPOScriptWait.cmd"

Now create a file called 'MaxGPOScriptWait.cmd' in the same folder, and put
inside the following contents:
%SYSTEMROOT%\SYSTEM32\REG.EXE ADD
"HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\policies\system" /v
MaxGPOScriptWait /t REG_DWORD /d 0 /f

(This should be all on one line)

This should create the relevant registry value during the graphical Windows
Setup sequence, so that it is set for the first Windows bootup. This value
will be cleared on the first Group Policy refresh that occurs, so you should
*also* set it in Group Policy so that it remains set for future bootups. I
have set the value to 0 so that there is no timeout, but you may want to set
it to a different value if you would still like processing to time out
eventually.

I hope that others find this solution helpful!

Regards,
Chris Hill
--
''Therefore, if anyone is in Christ, he is a new creation;
the old has gone, the new has come!'' - 2 Corinthians 5v17

Hi,

I have been investigating a problem that we have recently encountered on our
Windows Server 2003/Windows XP network.

We deploy new workstation using a combination of RIS and Group Policy
Software Installation, to install the initial copy of Windows, and the
software that goes along with it. As we are a school, we have a very large
number of MSI packages that have to be deployed to certain workstations, and
sometimes this initial installation takes quite a long time.

As a result of this, we have recently come across a problem with the
built-in hard time limit for processing group policy of 60 minutes (1 hour).
This is mentioned on a couple of pages on the Microsoft website:

http://msdn2.microsoft.com/en-us/library/aa374304.aspx

and

http://technet2.microsoft.com/Windo...a909-4f61-aded-c5b69f5f730b1033.mspx?mfr=true
(under 'Time Limit for Processing of Group Policy')

Both of these pages state that there is no way to change this time limit.
However, we are experiencing problems with this limit, because of the
following scenario:

1) Package 1 installs (actually the Microsoft .Net Framework 1.1).
2) Package 2 installs (the Microsoft .Net Framework 2.0), and tries to
update mscoree.dll, which is in use by 'msiexec' and 'wmiadap', both Windows
processes. It requests a reboot (shown in the System event log), but other
packages continue to install for as long as Group Policy processing continues.
3) At 1 hour, we hit the the Group Policy processing timeout. At this point,
whatever package is installing at the time is stopped half way through, and
the computer reboots (for the .Net Framework 2.0 install).
4) Group Policy processing resumes. An event log error appears saying that
'An install for [packagename] is currently suspended. You must undo the
changes made by that install to continue. Do you want to undo those
changes?'. The system apparently automatically answers 'Yes', the previous
package is rolled back, and installation of the next package continues.
However the previous package that was installing before the reboot is never
installed.
5) The computer finally boots up, with one of the packages missing, and
little indication that this is the case. The administrator must check the
event log and remove/reinstall the package that was being installed at the
point of the timeout/reboot.

I believe that the whole of this could be fixed by extending the Group
Policy processing timeout beyond 60 minutes. As the above websites stated,
there is currently no documented way to do this. However, I did come across a
couple of web chats, where people from Microsoft indicated that they would
look into providing a way to change this timeout value, for example:

http://www.microsoft.com/technet/community/chats/trans/windowsnet/wnet_092904.mspx

MSFT Mike Stephens (Expert):
Q: Cross Active Directory/Group Policy Question, is there a way to bypass
the 1 hour timeout limitation for policy processing? With the size of some
MSI deployed applications it is a pain. Or make the timeout pessimistic so
it rolls back unfinished MSIs
A: Sorry, no there is not way to change this behavior. Your feedback on how
this is a problem in your environment would be very helpful. Please send
this to http://WindowsServerFeedback.com.
and

http://www.microsoft.com/technet/community/chats/trans/sysbuild/05_0621_tn_sys.mspx

Bret [MSFT] (Moderator):
Q: Bret> No, the period between when Group Policy processing starts when
you boot and the login screen I'm talking about. That has a hard timeout
of 60 minutes.
A: Oh my mistake. Sorry, as far as i know that is a hard timeout and no
way around it. I will forward the request though for this to be expanded.

As these chats took place in 2004 and 2005 respectively, I was hoping that
this might have been looked at since then, and that a hotfix might be
available. Could someone from Microsoft look into this please, and see if
there is a fix for this issue yet?

Regards,

Chris Hill
ICT Technician
Colchester Royal Grammar School