none
GPO-preferences not applies to a group in OU, only to users

    Question

  • 1. GPO created using User Configuration\ Prefernces \Control Panel \ Scheduled Tasks

    2. Applied to OU containing users and Group

    3. The Group contains users in current OU and users from different OUs.

    4. GPO applies only to users in OU to which it applied but not for users members of the Group but residing in other OU.

    Resultant GPO not shows GPO neither in applied nor denied for users in different OUs.

    Why?


    --- When you hit a wrong note its the next note that makes it good or bad. --- Miles Davis

    Wednesday, January 28, 2015 7:11 PM

Answers

  • 1. GPO created using User Configuration\ Prefernces \Control Panel \ Scheduled Tasks

    2. Applied to OU containing users and Group

    3. The Group contains users in current OU and users from different OUs.

    4. GPO applies only to users in OU to which it applied but not for users members of the Group but residing in other OU.

    Resultant GPO not shows GPO neither in applied nor denied for users in different OUs.

    Why?

    Because that's not how GPO works.

    GPO is linked to an OU (or an AD site, or, the domain root), and that GPO is processed by the computer objects (or user objects).

    If the GPO contains Computer Settings, computer objects will process and apply that GPO. A Group is not a computer.

    You *can* use GP Security Filtering to filter which computer objects within the OU will (or will not) apply that GPO, but GPO does not traverse/recurse/apply via Group objects (i.e. members of the group) in your example, because only those computer objects in that OU would apply that GP.

    [This is one of the primary reasons for designing your AD OU structure based around how GP needs to be applied. Structure your AD OUs so that the logical groupings of Users/Computers will allow linking of GPOs without having to create complex filters, and exploit the inheritance logic]

    If you have several different OUs containing computers, and each of those OUs requires some common settings applied, you would consider linking that single GPO to multiple OUs. If there are some computers in an OU which need those settings and there are also some computers in that OU which should not have those settings, you have several choices for implementation, here are a few;

    a) create another OU (perhaps as a child OU of the first OU) move some computers into the child OU and link the extra GPO there (this leverages the inheritance feature)

    b) leave all the computers in a single OU but apply Security Filtering to the extra GPO so the extra GPO only applies to those. (create an AD Group, add some computers to the new Group, and use this AD Group for the Security Filtering with a GPO Read+Apply permission, and remove the default permission for Authenticated Users)

    c) create another OU (not as a child of the first OU) and link all the needed GPOs to the new OU, and move some computers into the new OU


    Don
    (Please take a moment to "Vote as Helpful" and/or "Mark as Answer", where applicable.
    This helps the community, keeps the forums tidy, and recognises useful contributions. Thanks!)



    • Edited by DonPick Wednesday, January 28, 2015 8:15 PM
    • Marked as answer by pob579 Wednesday, January 28, 2015 8:17 PM
    Wednesday, January 28, 2015 8:04 PM
  • thats how it works, they get applied to users and computers within that OU
    • Marked as answer by pob579 Wednesday, January 28, 2015 8:17 PM
    Wednesday, January 28, 2015 8:06 PM

All replies

  • 1. GPO created using User Configuration\ Prefernces \Control Panel \ Scheduled Tasks

    2. Applied to OU containing users and Group

    3. The Group contains users in current OU and users from different OUs.

    4. GPO applies only to users in OU to which it applied but not for users members of the Group but residing in other OU.

    Resultant GPO not shows GPO neither in applied nor denied for users in different OUs.

    Why?

    Because that's not how GPO works.

    GPO is linked to an OU (or an AD site, or, the domain root), and that GPO is processed by the computer objects (or user objects).

    If the GPO contains Computer Settings, computer objects will process and apply that GPO. A Group is not a computer.

    You *can* use GP Security Filtering to filter which computer objects within the OU will (or will not) apply that GPO, but GPO does not traverse/recurse/apply via Group objects (i.e. members of the group) in your example, because only those computer objects in that OU would apply that GP.

    [This is one of the primary reasons for designing your AD OU structure based around how GP needs to be applied. Structure your AD OUs so that the logical groupings of Users/Computers will allow linking of GPOs without having to create complex filters, and exploit the inheritance logic]

    If you have several different OUs containing computers, and each of those OUs requires some common settings applied, you would consider linking that single GPO to multiple OUs. If there are some computers in an OU which need those settings and there are also some computers in that OU which should not have those settings, you have several choices for implementation, here are a few;

    a) create another OU (perhaps as a child OU of the first OU) move some computers into the child OU and link the extra GPO there (this leverages the inheritance feature)

    b) leave all the computers in a single OU but apply Security Filtering to the extra GPO so the extra GPO only applies to those. (create an AD Group, add some computers to the new Group, and use this AD Group for the Security Filtering with a GPO Read+Apply permission, and remove the default permission for Authenticated Users)

    c) create another OU (not as a child of the first OU) and link all the needed GPOs to the new OU, and move some computers into the new OU


    Don
    (Please take a moment to "Vote as Helpful" and/or "Mark as Answer", where applicable.
    This helps the community, keeps the forums tidy, and recognises useful contributions. Thanks!)



    • Edited by DonPick Wednesday, January 28, 2015 8:15 PM
    • Marked as answer by pob579 Wednesday, January 28, 2015 8:17 PM
    Wednesday, January 28, 2015 8:04 PM
  • thats how it works, they get applied to users and computers within that OU
    • Marked as answer by pob579 Wednesday, January 28, 2015 8:17 PM
    Wednesday, January 28, 2015 8:06 PM
  • Thanks.


    --- When you hit a wrong note its the next note that makes it good or bad. --- Miles Davis


    • Edited by pob579 Wednesday, January 28, 2015 11:21 PM
    Wednesday, January 28, 2015 8:17 PM
  • > so the right way will be: applying gpo to OU where computers resides but
    > USER Configuration will be applied to any logged in user.
     
    No - only if the user resides in the same OU.
     
    Computer settings apply to computers that reside in the OU where the GPO
    is linked.
     
    User settings apply to users that reside in the OU where the GPO is linked.
     
    If you want settings to apply to ANY logging in user, you need loopback.
    But I'd suggest not to enable loopback unless you have a good
    understanding on Scope of Management :)
     

    Martin

    Mal ein GUTES Buch über GPOs lesen?

    NO THEY ARE NOT EVIL, if you know what you are doing: Good or bad GPOs?
    And if IT bothers me - coke bottle design refreshment :))
    Thursday, January 29, 2015 3:09 PM