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