RE: gpupdate/GPO
The GPO kicked in after 3 reboots. Funny, this is NOT a new GPO at all.
it's at least a year old. I guess that's the beat of the GPO drum.
I went ahead and put a gpupdate /target:user /force in my login
script.
I also have an hourly task that runs at the administrative level and
am executing gpupdate /target:computer /force in it.
This should help get it down to the 'next' reboot, as I discovered in
my testing.
Thanks a lot, all.
Jason
From: MarvinC [mailto:marv...@gmail.com]
Sent: Thursday, January 01, 2009 5:32 PM
To: NT System Admin Issues
Subject: Re: gpupdate/GPO
Test a workstation by running gpupdate /force /sync and continue with
the reboot.
If the policy still doesn't apply then make sure that pc is
communicating with its local DC.
Run gpresult to see what policies, if any are being applied on a test
workstation.
Download the GPOTool and install it to perform a test to see where
policies are failing.
Are the PC assigned to an OU and the policy being applied to that OU or
do you have a flat structure where all PC's sit in the same OU?
Open the GPMC and make sure the PC is sitting in the correct OU.
and the beat goes on...
gl...
On Wed, Dec 31, 2008 at 4:20 PM, Ben Scott mailvor...@gmail.com wrote:
On Wed, Dec 31, 2008 at 3:07 PM, Jason Gauthier jgauth...@lastar.com
wrote:
I have one, or many, GPOs that are not apparently being applied on
workstations. Through some testing, I have specifically found that
IE
settings are not really taking effect. That is, until, I manually run
a
gpupdate /force, and the reboot or logoff.
GPO application can be tricky.
Some[1] computer settings can only get applied during startup
processing.If a GPO update comes in while the computer is running,
it won't take affect until the next boot, when startup processing runs
again.
If you make a GPO modification, it will get posted to one DC by
{DSA,GPMC,GPEDIT,.MSC}. You may then have to wait various amounts of
time for that change to get replicated to all your other DCs. If a
workstation happens to pick one of those other DCs during its boot,
before replication is finished, the startup processing won't even see
the change until the next reboot.
Normal startup processing frequently needs multiple passes for a GPO
to work, i.e., two (re)boots. The first time, it sees the update GPO,
and gets the settings, but can't apply them until the next (re)boot
for some reason. (Microsoft sure does love 'dem reboots.)
You can help reduce the need for multiple reboots by setting the
various GPO startup options for synchronous and foreground
policy/script processing. This serializes everything during the boot
process, instead of the fire-and-forget scenario Windows defaults to.
Makes debugging easier, too. I suggest this as a best practice.
There is some GPO stuff which only gets processed the first time a
GPO is applied on a computer. You have to do a GPUPDATE /FORCE for it
to be re-processed. For example, we get some service control
permissions in one of our GPOs. If the service in question doesn't
exist when the GPO is first applied, too bad. If the service later
gets installed, it won't get the custom control permissions until we
GPUPDATE /FORCE it.
== Footnotes ==
[1] Or maybe it's actually all computer settings. I forget. I've
been assuming all for years, since all you need is the one you care
about, and the details were not well-documented when AD came out.
Maybe things have become clearer since then.
-- Ben
~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/ ~
~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/ ~
Re: gpupdate/GPO
Are you using the enforced option? Jason Gauthier jgauth...@lastar.com 12/31/2008 3:07 PM All, I have one, or many, GPOs that are not apparently being applied on workstations. Through some testing, I have specifically found that IE settings are not really taking effect. That is, until, I manually run a gpupdate /force, and the reboot or logoff. Obviously, this is not really desired. Does anyone know why this would be happening, and how I can solve it? A GPO should be applied appropriately, without me mandating a forced update and reboot. Thanks, Jason Confidentiality Notice: This e-mail message, including attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure, or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/ ~
Re: gpupdate/GPO
Test a workstation by running gpupdate /force /sync and continue with the
reboot.
If the policy still doesn't apply then make sure that pc is communicating
with its local DC.
Run gpresult to see what policies, if any are being applied on a test
workstation.
Download the GPOTool and install it to perform a test to see where policies
are failing.
Are the PC assigned to an OU and the policy being applied to that OU or do
you have a flat structure where all PC's sit in the same OU?
Open the GPMC and make sure the PC is sitting in the correct OU.
and the beat goes on...
gl...
On Wed, Dec 31, 2008 at 4:20 PM, Ben Scott mailvor...@gmail.com wrote:
On Wed, Dec 31, 2008 at 3:07 PM, Jason Gauthier jgauth...@lastar.com
wrote:
I have one, or many, GPOs that are not apparently being applied on
workstations. Through some testing, I have specifically found that IE
settings are not really taking effect. That is, until, I manually run a
gpupdate /force, and the reboot or logoff.
GPO application can be tricky.
Some[1] computer settings can only get applied during startup
processing.If a GPO update comes in while the computer is running,
it won't take affect until the next boot, when startup processing runs
again.
If you make a GPO modification, it will get posted to one DC by
{DSA,GPMC,GPEDIT,.MSC}. You may then have to wait various amounts of
time for that change to get replicated to all your other DCs. If a
workstation happens to pick one of those other DCs during its boot,
before replication is finished, the startup processing won't even see
the change until the next reboot.
Normal startup processing frequently needs multiple passes for a GPO
to work, i.e., two (re)boots. The first time, it sees the update GPO,
and gets the settings, but can't apply them until the next (re)boot
for some reason. (Microsoft sure does love 'dem reboots.)
You can help reduce the need for multiple reboots by setting the
various GPO startup options for synchronous and foreground
policy/script processing. This serializes everything during the boot
process, instead of the fire-and-forget scenario Windows defaults to.
Makes debugging easier, too. I suggest this as a best practice.
There is some GPO stuff which only gets processed the first time a
GPO is applied on a computer. You have to do a GPUPDATE /FORCE for it
to be re-processed. For example, we get some service control
permissions in one of our GPOs. If the service in question doesn't
exist when the GPO is first applied, too bad. If the service later
gets installed, it won't get the custom control permissions until we
GPUPDATE /FORCE it.
== Footnotes ==
[1] Or maybe it's actually all computer settings. I forget. I've
been assuming all for years, since all you need is the one you care
about, and the details were not well-documented when AD came out.
Maybe things have become clearer since then.
-- Ben
~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/ ~
~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/ ~
gpupdate/GPO
All, I have one, or many, GPOs that are not apparently being applied on workstations. Through some testing, I have specifically found that IE settings are not really taking effect. That is, until, I manually run a gpupdate /force, and the reboot or logoff. Obviously, this is not really desired. Does anyone know why this would be happening, and how I can solve it? A GPO should be applied appropriately, without me mandating a forced update and reboot. Thanks, Jason ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/ ~
RE: gpupdate/GPO
On occasion it takes 2 reboot cycles for GPO's to be applied. You can help mitigate that by making the computer wait for network on startup under the computer section, System/Group Policy ADM's. Some computers do not get the NIC started before GP settings would be applied hence requiring a 2nd reboot to get the gp settings to take effect. From: Jason Gauthier [mailto:jgauth...@lastar.com] Sent: Wednesday, December 31, 2008 3:07 PM To: NT System Admin Issues Subject: gpupdate/GPO All, I have one, or many, GPOs that are not apparently being applied on workstations. Through some testing, I have specifically found that IE settings are not really taking effect. That is, until, I manually run a gpupdate /force, and the reboot or logoff. Obviously, this is not really desired. Does anyone know why this would be happening, and how I can solve it? A GPO should be applied appropriately, without me mandating a forced update and reboot. Thanks, Jason ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/ ~
RE: gpupdate/GPO
Wouldn't that group policy not get applied under that theory though? Or any new GP at all? Furthermore, the GPO should be reset every 15 minutes, however some settings are not actually applied until the force+reboot. From: gswe...@actsconsulting.net [mailto:gswe...@actsconsulting.net] Sent: Wednesday, December 31, 2008 3:16 PM To: NT System Admin Issues Subject: RE: gpupdate/GPO On occasion it takes 2 reboot cycles for GPO's to be applied. You can help mitigate that by making the computer wait for network on startup under the computer section, System/Group Policy ADM's. Some computers do not get the NIC started before GP settings would be applied hence requiring a 2nd reboot to get the gp settings to take effect. From: Jason Gauthier [mailto:jgauth...@lastar.com] Sent: Wednesday, December 31, 2008 3:07 PM To: NT System Admin Issues Subject: gpupdate/GPO All, I have one, or many, GPOs that are not apparently being applied on workstations. Through some testing, I have specifically found that IE settings are not really taking effect. That is, until, I manually run a gpupdate /force, and the reboot or logoff. Obviously, this is not really desired. Does anyone know why this would be happening, and how I can solve it? A GPO should be applied appropriately, without me mandating a forced update and reboot. Thanks, Jason ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/ ~
RE: gpupdate/GPO
Not all GPO's are applied in a background refresh. Many do require a reboot to take effect, Offline files being one for example. The GPO would not apply in the initial reboot because the computer does not get the update since the NIC has not come active yet. Then it pulls down the update and it requires a 2nd reboot to actually make the changes happen. We pretty much now only require a reboot to make all our GPO's take effect when enabling the Wait on Network option. From: Jason Gauthier [mailto:jgauth...@lastar.com] Sent: Wednesday, December 31, 2008 3:19 PM To: NT System Admin Issues Subject: RE: gpupdate/GPO Wouldn't that group policy not get applied under that theory though? Or any new GP at all? Furthermore, the GPO should be reset every 15 minutes, however some settings are not actually applied until the force+reboot. From: gswe...@actsconsulting.net [mailto:gswe...@actsconsulting.net] Sent: Wednesday, December 31, 2008 3:16 PM To: NT System Admin Issues Subject: RE: gpupdate/GPO On occasion it takes 2 reboot cycles for GPO's to be applied. You can help mitigate that by making the computer wait for network on startup under the computer section, System/Group Policy ADM's. Some computers do not get the NIC started before GP settings would be applied hence requiring a 2nd reboot to get the gp settings to take effect. From: Jason Gauthier [mailto:jgauth...@lastar.com] Sent: Wednesday, December 31, 2008 3:07 PM To: NT System Admin Issues Subject: gpupdate/GPO All, I have one, or many, GPOs that are not apparently being applied on workstations. Through some testing, I have specifically found that IE settings are not really taking effect. That is, until, I manually run a gpupdate /force, and the reboot or logoff. Obviously, this is not really desired. Does anyone know why this would be happening, and how I can solve it? A GPO should be applied appropriately, without me mandating a forced update and reboot. Thanks, Jason ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/ ~
RE: gpupdate/GPO
When you say the NIC has not come active are you talking about the PC/drivers, etc.. or are you talking about the time it might take the switch to bring the link up? I know some switches take longer than XP to boot due to STP. If it's the latter, it can be mitigated with switch config changes. If it's the prior, then you're right. I will need to employ some other trickiness.. which I should have ready to go anyway. Thanks! From: gswe...@actsconsulting.net [mailto:gswe...@actsconsulting.net] Sent: Wednesday, December 31, 2008 3:26 PM To: NT System Admin Issues Subject: RE: gpupdate/GPO Not all GPO's are applied in a background refresh. Many do require a reboot to take effect, Offline files being one for example. The GPO would not apply in the initial reboot because the computer does not get the update since the NIC has not come active yet. Then it pulls down the update and it requires a 2nd reboot to actually make the changes happen. We pretty much now only require a reboot to make all our GPO's take effect when enabling the Wait on Network option. From: Jason Gauthier [mailto:jgauth...@lastar.com] Sent: Wednesday, December 31, 2008 3:19 PM To: NT System Admin Issues Subject: RE: gpupdate/GPO Wouldn't that group policy not get applied under that theory though? Or any new GP at all? Furthermore, the GPO should be reset every 15 minutes, however some settings are not actually applied until the force+reboot. From: gswe...@actsconsulting.net [mailto:gswe...@actsconsulting.net] Sent: Wednesday, December 31, 2008 3:16 PM To: NT System Admin Issues Subject: RE: gpupdate/GPO On occasion it takes 2 reboot cycles for GPO's to be applied. You can help mitigate that by making the computer wait for network on startup under the computer section, System/Group Policy ADM's. Some computers do not get the NIC started before GP settings would be applied hence requiring a 2nd reboot to get the gp settings to take effect. From: Jason Gauthier [mailto:jgauth...@lastar.com] Sent: Wednesday, December 31, 2008 3:07 PM To: NT System Admin Issues Subject: gpupdate/GPO All, I have one, or many, GPOs that are not apparently being applied on workstations. Through some testing, I have specifically found that IE settings are not really taking effect. That is, until, I manually run a gpupdate /force, and the reboot or logoff. Obviously, this is not really desired. Does anyone know why this would be happening, and how I can solve it? A GPO should be applied appropriately, without me mandating a forced update and reboot. Thanks, Jason ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/ ~
RE: gpupdate/GPO
I would think IE settings wouldn't need a reboot... Many programs can try to adjust IE settings. AV programs, Spybot, Desktop Search, etc... could anything be overwriting the settings you are trying to adjust? From: Jason Gauthier [mailto:jgauth...@lastar.com] Sent: Wednesday, December 31, 2008 2:29 PM To: NT System Admin Issues Subject: RE: gpupdate/GPO When you say the NIC has not come active are you talking about the PC/drivers, etc.. or are you talking about the time it might take the switch to bring the link up? I know some switches take longer than XP to boot due to STP. If it's the latter, it can be mitigated with switch config changes. If it's the prior, then you're right. I will need to employ some other trickiness.. which I should have ready to go anyway. Thanks! From: gswe...@actsconsulting.net [mailto:gswe...@actsconsulting.net] Sent: Wednesday, December 31, 2008 3:26 PM To: NT System Admin Issues Subject: RE: gpupdate/GPO Not all GPO's are applied in a background refresh. Many do require a reboot to take effect, Offline files being one for example. The GPO would not apply in the initial reboot because the computer does not get the update since the NIC has not come active yet. Then it pulls down the update and it requires a 2nd reboot to actually make the changes happen. We pretty much now only require a reboot to make all our GPO's take effect when enabling the Wait on Network option. From: Jason Gauthier [mailto:jgauth...@lastar.com] Sent: Wednesday, December 31, 2008 3:19 PM To: NT System Admin Issues Subject: RE: gpupdate/GPO Wouldn't that group policy not get applied under that theory though? Or any new GP at all? Furthermore, the GPO should be reset every 15 minutes, however some settings are not actually applied until the force+reboot. From: gswe...@actsconsulting.net [mailto:gswe...@actsconsulting.net] Sent: Wednesday, December 31, 2008 3:16 PM To: NT System Admin Issues Subject: RE: gpupdate/GPO On occasion it takes 2 reboot cycles for GPO's to be applied. You can help mitigate that by making the computer wait for network on startup under the computer section, System/Group Policy ADM's. Some computers do not get the NIC started before GP settings would be applied hence requiring a 2nd reboot to get the gp settings to take effect. From: Jason Gauthier [mailto:jgauth...@lastar.com] Sent: Wednesday, December 31, 2008 3:07 PM To: NT System Admin Issues Subject: gpupdate/GPO All, I have one, or many, GPOs that are not apparently being applied on workstations. Through some testing, I have specifically found that IE settings are not really taking effect. That is, until, I manually run a gpupdate /force, and the reboot or logoff. Obviously, this is not really desired. Does anyone know why this would be happening, and how I can solve it? A GPO should be applied appropriately, without me mandating a forced update and reboot. Thanks, Jason ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/ ~
RE: gpupdate/GPO
I can't say no.. but I don't know what would. I can open the registry editor, run a gpupdate /force and the changes are not there. So, I base it off that fact alone. This is just proxy/autoconfig settings too.. nothing fancy at all. From: Sam Cayze [mailto:sam.ca...@rollouts.com] Sent: Wednesday, December 31, 2008 4:13 PM To: NT System Admin Issues Subject: RE: gpupdate/GPO I would think IE settings wouldn't need a reboot... Many programs can try to adjust IE settings. AV programs, Spybot, Desktop Search, etc... could anything be overwriting the settings you are trying to adjust? From: Jason Gauthier [mailto:jgauth...@lastar.com] Sent: Wednesday, December 31, 2008 2:29 PM To: NT System Admin Issues Subject: RE: gpupdate/GPO When you say the NIC has not come active are you talking about the PC/drivers, etc.. or are you talking about the time it might take the switch to bring the link up? I know some switches take longer than XP to boot due to STP. If it's the latter, it can be mitigated with switch config changes. If it's the prior, then you're right. I will need to employ some other trickiness.. which I should have ready to go anyway. Thanks! From: gswe...@actsconsulting.net [mailto:gswe...@actsconsulting.net] Sent: Wednesday, December 31, 2008 3:26 PM To: NT System Admin Issues Subject: RE: gpupdate/GPO Not all GPO's are applied in a background refresh. Many do require a reboot to take effect, Offline files being one for example. The GPO would not apply in the initial reboot because the computer does not get the update since the NIC has not come active yet. Then it pulls down the update and it requires a 2nd reboot to actually make the changes happen. We pretty much now only require a reboot to make all our GPO's take effect when enabling the Wait on Network option. From: Jason Gauthier [mailto:jgauth...@lastar.com] Sent: Wednesday, December 31, 2008 3:19 PM To: NT System Admin Issues Subject: RE: gpupdate/GPO Wouldn't that group policy not get applied under that theory though? Or any new GP at all? Furthermore, the GPO should be reset every 15 minutes, however some settings are not actually applied until the force+reboot. From: gswe...@actsconsulting.net [mailto:gswe...@actsconsulting.net] Sent: Wednesday, December 31, 2008 3:16 PM To: NT System Admin Issues Subject: RE: gpupdate/GPO On occasion it takes 2 reboot cycles for GPO's to be applied. You can help mitigate that by making the computer wait for network on startup under the computer section, System/Group Policy ADM's. Some computers do not get the NIC started before GP settings would be applied hence requiring a 2nd reboot to get the gp settings to take effect. From: Jason Gauthier [mailto:jgauth...@lastar.com] Sent: Wednesday, December 31, 2008 3:07 PM To: NT System Admin Issues Subject: gpupdate/GPO All, I have one, or many, GPOs that are not apparently being applied on workstations. Through some testing, I have specifically found that IE settings are not really taking effect. That is, until, I manually run a gpupdate /force, and the reboot or logoff. Obviously, this is not really desired. Does anyone know why this would be happening, and how I can solve it? A GPO should be applied appropriately, without me mandating a forced update and reboot. Thanks, Jason ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/ ~
Re: gpupdate/GPO
On Wed, Dec 31, 2008 at 3:07 PM, Jason Gauthier jgauth...@lastar.com wrote:
I have one, or many, GPOs that are not apparently being applied on
workstations. Through some testing, I have specifically found that IE
settings are not really taking effect. That is, until, I manually run a
gpupdate /force, and the reboot or logoff.
GPO application can be tricky.
Some[1] computer settings can only get applied during startup
processing.If a GPO update comes in while the computer is running,
it won't take affect until the next boot, when startup processing runs
again.
If you make a GPO modification, it will get posted to one DC by
{DSA,GPMC,GPEDIT,.MSC}. You may then have to wait various amounts of
time for that change to get replicated to all your other DCs. If a
workstation happens to pick one of those other DCs during its boot,
before replication is finished, the startup processing won't even see
the change until the next reboot.
Normal startup processing frequently needs multiple passes for a GPO
to work, i.e., two (re)boots. The first time, it sees the update GPO,
and gets the settings, but can't apply them until the next (re)boot
for some reason. (Microsoft sure does love 'dem reboots.)
You can help reduce the need for multiple reboots by setting the
various GPO startup options for synchronous and foreground
policy/script processing. This serializes everything during the boot
process, instead of the fire-and-forget scenario Windows defaults to.
Makes debugging easier, too. I suggest this as a best practice.
There is some GPO stuff which only gets processed the first time a
GPO is applied on a computer. You have to do a GPUPDATE /FORCE for it
to be re-processed. For example, we get some service control
permissions in one of our GPOs. If the service in question doesn't
exist when the GPO is first applied, too bad. If the service later
gets installed, it won't get the custom control permissions until we
GPUPDATE /FORCE it.
== Footnotes ==
[1] Or maybe it's actually all computer settings. I forget. I've
been assuming all for years, since all you need is the one you care
about, and the details were not well-documented when AD came out.
Maybe things have become clearer since then.
-- Ben
~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/ ~
