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.

-----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


Reply via email to