Note that, after doing this procedure, and then a "gpresult /r", it does *not* list the new group, in the list of computer group accounts. BUT ... it does show the proper GPO, which is tied to a group that isn't shown.
So I'm guessing that after the reboot, the group will show in "gpresult /r". But for right now, it does show the right GPO, and it does say that the machine is set to install automatically (which only members of the non-shown group are set to do). On Tue, Jun 20, 2017 at 2:21 PM, Michael Leone <[email protected]> wrote: > On Tue, Jun 20, 2017 at 1:47 PM, James Rankin <[email protected]> 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: [email protected] [mailto:[email protected] > orum.com] On Behalf Of Kennedy, Jim > > Sent: 20 June 2017 18:22 > > To: [email protected] > > Subject: RE: [NTSysADM] Re: GPO being filtered out, denied by security - > RESOLVED > > > > Nice find!! Gonna save this one. > > > > -----Original Message----- > > From: [email protected] [mailto:[email protected] > orum.com] On Behalf Of Michael Leone > > Sent: Tuesday, June 20, 2017 12:28 PM > > To: [email protected] > > 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 < > [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? > >> > >> > > > > > >
