OK, I've noticed that there are more servers exhibiting this GPO denial. All were added to the AD group that applies to this denied GPO. All that were added to the AD group yesterday are fine, GPO *not* being denied.
Maybe I just need to leave it? I would have thought that a "gpupdate /force" would have been enough. I even forced a site replication between DCs, just in case Ad changes hadn't been replicated yet. On Tue, Jun 20, 2017 at 10:28 AM, Michael Leone <oozerd...@gmail.com> wrote: > I'm scratching my head at this. I created a new GPO, to set updates to > be applied automatically, and rebooted automatically. I created a new > AD group; added 10 server accounts to it. Set the security filtering > on the new GPO to this new group. > > All seemed fine, I spot-checked the 10 servers to be sure that GPO was > being applied (I did a gpupdate /force /target:computer, then checked > gpresult /r). And it is being applied as it should. > > With one exception. One server says it is being filtered out, and > denied by security. And I can't figure out why. There are no > delegations on the GPO, so it can't be denied from there. > > All server accounts are in the same OU. All are members of all the > same AD groups. > > Here's the thing. This account is a member of 2 AD groups. Both groups > are on security filtering for my WSUS GPOs. And it *is* applying the > one GPO (the one that is set to download only, not install). > > But it is not applying the other GPO, which is set to install, and > which is higher in precedence. (I know it's higher in precedence, this > GPO is properly being applied to the other members of that AD group). > > Where do I go from here? How can I determine why just this one server > is filtering out the GPO, when the other group members are not > filtering it out?
