On Fri, Oct 2, 2015 at 11:53 AM, Charles F Sullivan < [email protected]> wrote:
> You should probably only need to reboot the machines so that the group > membership is added to their access tokens. It’s the equivalent of a user > logging on and off after being added to a group. > I'll ask if they can be rebooted now, but all the people in charge of this box are out to lunch (physically ..). Me, I have an idea I can, it won't be the end of the world, but it's not my call. I wasn't involved in setting any of these up, they just now got thrown into my lap. I checked by going to Windows Update in the Control Panel; no updates applied for going on 2 years ... this is why I try and insist that the network admins have a say in configuring the box, but it looks like that didn't happen .. So even if I get it to work, there are 120+ updates that must be applied first (there's a few hours), not mention then updating the updates just applied ... TGIF ... > > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *Michael Leone > *Sent:* Friday, October 2, 2015 10:58 AM > *To:* [email protected] > *Subject:* [NTSysADM] WSUS GPO seems inacessible but only for new members > > > > This is odd. I have a GPO which assigns WSUS settings; criteria is that > computer account must be in a specific OU, and a member of a specific AD > group. This has been working well for years. > > > > Now, we've added a couple new servers at a remote site, and so I set them > up for WSUS (moved their machine accounts to the right OU, added them to > the right group). In AD, that's what I see, and the changes have replicated > to all DCs. > > > > When I do a Group Processing Policy result for these accounts, it sees > that the GPO is being listed as "inaccessible". Also, the GPO is being > listed by it's GUID, and not it's name. > > > > [image: Inline image 1] > > I don't know what's up with that, as the other accounts that this GPO > applies to properly show the GPO as applied, and with it's proper name. > It's only these new members that are showing this. (I spot checked 3 or 4 > other group members; they all show it as applied). > > > > So what would cause these new members to not be able to read the GPOs > (that's what inaccessible usually means, right?). The GPO is accessible to > all the other group members, so it shouldn't be a permissions issue of the > GPO itself, I wouldn't think. > > > > Doing a "gpresult /r" on these new members, the group membership does NOT > show the new groups the account belongs to, but DOES show that it is in the > correct OU (I see the OU name in the CN). It says that Group Policy is > being applied, as it is listing the 3 GPOs above as being DENIED, but > doesn't show the last GPO (the WSUS one). > > > > It DOES show the proper group memberships for the logged on user, too. > (not that that is relevant to the GPO, but does sort of indicate that the > machine is speaking to AD). > > > > I see no errors in event log on the member server. Not seeing anything in > the event log of the DC that the member says it is getting it's GPO info > from, either. > > > > Ideas as to where to go next? I have IP connectivity; the member is doing > what it's supposed to do (some sort of security camera setup). It does run > antivirus - Kaspersky for Windows Servers 8.0.2.213, like other servers. > The AV policy shouldn't be blocking anything AD related ... > > > > > > > > >
