An update ... On Friday, I added 3 machines to the AD group that is linked to my WSUS GPO. As noted, the first one didn't show up in my WSUS console until after I rebooted. But this morning, the other 2 were also there, and they weren't rebooted. Guess they just checked in, as GPOs are supposed to, every 24 hours or so.
So once again, patience is a virtue (presuming you have the time to wait). On Fri, Oct 2, 2015 at 1:38 PM, Michael Leone <[email protected]> wrote: > On Fri, Oct 2, 2015 at 1:15 PM, Charles F Sullivan > <[email protected]> wrote: >> The reboot is not for the OU change at all, only for the group membership >> change. An OU is not a security principal like a group is. >> >> Computers, just like users, have access tokens that list their group >> membership. If you add a user to a group, the user gets it's access token >> when the person logs onto a machine. During a logon session if the user is >> added to a group, for example to give them access to an SMB share, they will >> not be able to access the share until they log off and back on, so that the >> group membership is added to their access token. >> >> For a computer, a reboot is needed, just as a logoff/logon is needed for a >> user in the above scenario. If you have a test machine, any test machine, >> add it to the same group and OU, refresh GP, then see what happens. Then >> reboot the machine and see what happens again. > > > And we have a winner ... yes, rebooting it made it all Just Work, and > now it's checking in with the WSUS server ... just waiting for it to > do a "reportnow", to see the huge number of updates needed ... > > I was getting confused, and comparing it to an LDAP lookup (meaning: a > lookup may show membership immediately, but the actuall access > governed by such group membership won't take effect until a reboot, > not just a login ...) > > >> >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] >> On Behalf Of Michael Leone >> Sent: Friday, October 2, 2015 12:11 PM >> To: [email protected] >> Subject: Re: [NTSysADM] WSUS GPO seems inacessible but only for new members >> >> On Fri, Oct 2, 2015 at 11:05 AM, Kibble,Tony <[email protected]> wrote: >>> >>> Simple obvious things first. >>> >>> >>> >>> Have the servers been rebooted since their OU and group memberships have >>> been changed? >> >> Not in the middle of the day, these are production machines. :-) And they >> shouldn't need to be rebooted, the gprsult shows the OU change. >> And the gpupdate /force should negate the need for a reboot (based on the >> simple changes I made to the machine account). >> >> >>> >>> >>> >>> Tony Kibble | Sr. Data Security Technologist | Business Information >>> Security Officer - International | IT >>> >>> >>> >>> From: [email protected] >>> [mailto:[email protected]] On Behalf Of Michael Leone >>> Sent: 02 October 2015 15:58 >>> 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. >>> >>> >>> >>> 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 ... >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> ________________________________ >>> >>> DISCLAIMER >>> >>> This material has been checked by us for computer viruses and, although >>> none has been found, we cannot guarantee that it is completely free from >>> such problems and we do not accept liability for loss or damage which may >>> be caused. >>> >>> This message is intended only for use of the individual or entity to whom >>> it is addressed and may contain information which may be privileged and >>> confidential. If you are not the intended recipient you are hereby >>> notified that any dissemination, distribution or copying of this >>> communication is strictly prohibited. If you have received this e-mail in >>> error, please notify the sender immediately via e-mail and delete the >>> message. Thank you. >>> >>> ******************************************************* >>> >>> Travelers Insurance Company Limited is authorised by the Prudential >>> Regulation Authority and regulated by the Financial Conduct Authority in >>> the UK and is regulated by the Central Bank of Ireland for conduct of >>> business rules. Registered in England 1034343. Registered as a branch in >>> Ireland 903382. >>> >>> Travelers Syndicate Management Limited is authorised by the Prudential >>> Regulation Authority and regulated by the Financial Conduct Authority and >>> the Prudential Regulation Authority. Registered in England 03207530. >>> >>> Travelers Underwriting Agency Limited is authorised and regulated by the >>> Financial Conduct Authority. Registered in England 03708247. >>> >>> Travelers Professional Risks Limited is an appointed representative of >>> Travelers Insurance Company Limited which is authorised by the >>> Prudential Regulation Authority and regulated by the Financial Conduct >>> Authority and the Prudential Regulation Authority. Registered in >>> England 05201980 >>> >>> Travelers Management Limited. Registered in England 00972175. >>> >>> The registered offices for all companies listed above is: Exchequer Court, >>> 33 St Mary Axe, London, EC3A 8AG. >>> All other branch offices are available from our websites. >>> >>> travelers.co.uk >>> travelers.ie >>> >>> Issues to: mailto: [email protected] >>> ________________________________ This communication, including >>> attachments, is confidential, may be subject to legal privileges, and is >>> intended for the sole use of the addressee. Any use, duplication, >>> disclosure or dissemination of this communication, other than by the >>> addressee, is prohibited. If you have received this communication in >>> error, please notify the sender immediately and delete or destroy this >>> communication and all copies. >>> >>> TRVDiscDefault::1201 >> >>
