locked
Can I use Client Side Targeting and still put computers into manual groups? RRS feed

  • Question

  • Howdy,

    I am setting up WSUS Client Side Targeting to put our servers into groups.  We normally patch our Dev & QA machines first and then do the rest of our environment the next weekend.  What I'd like to do is also have a dozen or so machine that I can put in a Pilot group and have those go before everything else.  These machines would be hand picked machines that are not critical but would be across various OUs.

    If I have Client Side Targeting enabled, can I still right click a server and manually add it to mu new Pilot group?  If not, what's the best way to do this that doesn't involve putting the pilot machines into their OU in AD?

    Thanks.

    Wednesday, May 3, 2017 2:05 PM

Answers

  • ...What I'd like to do is also have a dozen or so machine that I can put in a Pilot group and have those go before everything else.  These machines would be hand picked machines that are not critical but would be across various OUs.

    ...what's the best way to do this that doesn't involve putting the pilot machines into their OU in AD?

    Create a GPO with the WSUS Targeting Group setting you want.

    Create an AD group to represent the pilot computers and add the desired computers into that AD group.

    Apply that AD group as the Security Filter on the GPO.

    Link that GPO to the parent OU of the desired computers (if your OUs are diverse, this link might need to be at the Domain root).

    EDIT/insert extra step -> Consider the implications of Inheritance blocking, in case you are using that :)

    GP Security Filtering, if done correctly, will ensure that only those Pilot_Group member computers get your targeting group applied.


    Don [doesn't work for MSFT, and they're probably glad about that ;]


    • Marked as answer by Kelemvor33 Thursday, May 4, 2017 5:12 PM
    • Edited by DonPick Thursday, May 4, 2017 10:24 PM
    Thursday, May 4, 2017 10:08 AM

All replies

  • Hi Kelemvor33,

    >If I have Client Side Targeting enabled, can I still right click a server and manually add it to mu new Pilot group? 

    No, if we enable client side targeting, then we'll check "Use Group Policy or registry settings on computers" in Option>Computers, so that clients will be located in the corresponding group which set on client side. And the "Change Membership" will grey out. We can't change the group of the clients on WSUS server side.

    >If not, what's the best way to do this that doesn't involve putting the pilot machines into their OU in AD?

    You may group these Pilot computers into a specific OU, then configure a GPO for this OU to locate these clients into the Pilot group on WSUS server.

    Best Regards,

    Anne


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Thursday, May 4, 2017 8:57 AM
  • ...What I'd like to do is also have a dozen or so machine that I can put in a Pilot group and have those go before everything else.  These machines would be hand picked machines that are not critical but would be across various OUs.

    ...what's the best way to do this that doesn't involve putting the pilot machines into their OU in AD?

    Create a GPO with the WSUS Targeting Group setting you want.

    Create an AD group to represent the pilot computers and add the desired computers into that AD group.

    Apply that AD group as the Security Filter on the GPO.

    Link that GPO to the parent OU of the desired computers (if your OUs are diverse, this link might need to be at the Domain root).

    EDIT/insert extra step -> Consider the implications of Inheritance blocking, in case you are using that :)

    GP Security Filtering, if done correctly, will ensure that only those Pilot_Group member computers get your targeting group applied.


    Don [doesn't work for MSFT, and they're probably glad about that ;]


    • Marked as answer by Kelemvor33 Thursday, May 4, 2017 5:12 PM
    • Edited by DonPick Thursday, May 4, 2017 10:24 PM
    Thursday, May 4, 2017 10:08 AM
  • Thanks.  I created an AD Group, added it to the Scope of the GPO object and remove the Authorized Users option.  Hopefully that's all it takes.  I guess I'll have to do some testing now.

    Friday, May 5, 2017 3:55 AM
  • Thanks.  I created an AD Group, added it to the Scope of the GPO object and remove the Authorized Users option.  Hopefully that's all it takes.  I guess I'll have to do some testing now.

    just be aware of the implications of MS16-072, it can affect things if you remove Authenticated Users ;)

    Don [doesn't work for MSFT, and they're probably glad about that ;]

    Friday, May 5, 2017 9:18 AM
  • Thanks.  I created an AD Group, added it to the Scope of the GPO object and remove the Authorized Users option.  Hopefully that's all it takes.  I guess I'll have to do some testing now.

    just be aware of the implications of MS16-072, it can affect things if you remove Authenticated Users ;)

    Don [doesn't work for MSFT, and they're probably glad about that ;]

    I was simply following these procedures:

    https://technet.microsoft.com/en-us/library/cc752992%28v=ws.11%29.aspx?f=255&MSPPError=-2147217396

    Is there a better way to to this?  I don't know if I need to remove authorized users or not but it mentioned it so I figured I would...

    Friday, May 5, 2017 5:50 PM
  • Thanks.  I created an AD Group, added it to the Scope of the GPO object and remove the Authorized Users option.  Hopefully that's all it takes.  I guess I'll have to do some testing now.

    just be aware of the implications of MS16-072, it can affect things if you remove Authenticated Users ;)

    Don [doesn't work for MSFT, and they're probably glad about that ;]

    I was simply following these procedures:

    https://technet.microsoft.com/en-us/library/cc752992%28v=ws.11%29.aspx?f=255&MSPPError=-2147217396

    Is there a better way to to this?  I don't know if I need to remove authorized users or not but it mentioned it so I figured I would...

    that TN documentation is no longer %100 reliable, since MS16-072 was released, because MS16-072 changes long-standing rules of the GPO game...

    If you check the comments at the bottom of that document (you may need to sign-in) you can see comments added which explain about MS16-072....

    If you Remove the Authenticated Users ACE/permission, the GPO will never apply to anything. This is a result of the change due to MS16-072. Instead, you must ensure that Authenticated Users (or Domain Computers) retains the "Read GPO" ACE/permission in addition to your desired security group.

    Your security group, which is used for the conditional filtering, has to have both Read GPO & Apply GPO.

    By default, when you create a GPO, the GPMC/GPME will add Authenticated Users with Read+Apply.
    When you need to change that to be filtered according to some other security group, you no longer want Authenticated Users to have the Apply GPO permission, but Authenticated Users (or at least Domain Computers) must continue to have the Read GPO permissions due to MS16-072.

    NB: Authenticated Users is a rather special security principal. It effectively represents DomainComputers+DomainUsers.


    Don [doesn't work for MSFT, and they're probably glad about that ;]


    • Edited by DonPick Friday, May 5, 2017 11:10 PM
    Friday, May 5, 2017 11:05 PM