On Tue, Jun 20, 2017 at 1:47 PM, James Rankin <ja...@htguk.com> wrote: > In my testing I was never quite sure that trick would work. I wrote an article about it a few years ago, but the behaviour seems to be a little hit and miss.
I did it on 5 machines; it successfully re-set the group membership on all 5, and all 5 then were able to get the correct GPO applied. So, like they say ... Works For Me! LOL > > However if it reduces the amount of reboots required only by a few, it would appear to have done some good. > > -----Original Message----- > From: listsad...@lists.myitforum.com [mailto:listsadmin@lists. myitforum.com] On Behalf Of Kennedy, Jim > Sent: 20 June 2017 18:22 > To: ntsysadm@lists.myitforum.com > Subject: RE: [NTSysADM] Re: GPO being filtered out, denied by security - RESOLVED > > Nice find!! Gonna save this one. > > -----Original Message----- > From: listsad...@lists.myitforum.com [mailto:listsadmin@lists. myitforum.com] On Behalf Of Michael Leone > Sent: Tuesday, June 20, 2017 12:28 PM > To: ntsysadm@lists.myitforum.com > Subject: Re: [NTSysADM] Re: GPO being filtered out, denied by security - RESOLVED > > 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 < kennedy...@elyriaschools.org> wrote: >> Did you bounce the servers so they could pick up the new group memebership? >> >> -----Original Message----- >> From: listsad...@lists.myitforum.com >> [mailto:listsad...@lists.myitforum.com] On Behalf Of Michael Leone >> Sent: Tuesday, June 20, 2017 11:11 AM >> To: ntsysadm@lists.myitforum.com >> 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 <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? >> >> > >
