Sweet! That's a very good tip.
Kurt On Tue, Jun 20, 2017 at 9:28 AM, Michael Leone <[email protected]> wrote: > I didn't bounce the servers. But this did work: > > http://www.windowsnetworking.com/kbase/WindowsTips/Windows7/AdminTips/Admin/Forcingre-evaluationofcomputergroupmembership.html > > klist –li 0x3e7 purge > > Then run this command on the computer: > > gpupdate /force > > The first command clears the Kerberos ticket cache for the computer > account (that’s the 0x3e7 part) while the second command causes the > computer to authenticate anew and determine its new group membership. > > > > On Tue, Jun 20, 2017 at 11:21 AM, Kennedy, Jim > <[email protected]> wrote: >> Did you bounce the servers so they could pick up the new group memebership? >> >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] >> On Behalf Of Michael Leone >> Sent: Tuesday, June 20, 2017 11:11 AM >> To: [email protected] >> Subject: [NTSysADM] Re: GPO being filtered out, denied by security - MORE >> >> 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 <[email protected]> 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? >> >> > >
