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/> ~
