One of the lesser known (or understood) features of WSUS is the ability to assign a computer to more than one Target Group. Multiple Target Groups can be useful for managing special-case approval needs for a specific update, as when a small subset of computers should not receive a particular update. They can also be useful for creating custom reporting groups, when used in conjunction with the WSUS Reporting capability for filtering by Target Group.
When using multiple Target Groups to manage approvals, there’s often a question of the effective approval for an update.
- If you have two peer groups and Update ‘A’ is Approved for Group ‘A’ and Update ‘A’ is Not Approved for Group ‘B’, then Group ‘A’ gets the update and Group ‘B’ does not. If a computer belongs to both groups, then the computer gets the update, because, unlike AD or NTFS ACLs, there is no “Deny” operation on a per-group basis. All it takes is one approval from one group where a computer has membership.
- If you have a parent-child group, and Update ‘A’ is Approved for the Parent Group, by default the Child Group will inherit that approval unless explicitly marked as Not Approved for the child group.
In the case where a handful of systems need to NOT get an update, the only practical way to implement the solution is with a Parent->Child group, where the Child Group is the group of exclusions. The advantage to this is that the six systems will inherit all of the existing approvals from the Parent Group, but the specific update of interest can be set to Not Approved for the child group.
If you create peer groups, then you must remove the six machines from the original group or they’ll still have an approval for the unwanted update. Also, you’ll have to replicate all of the existing approvals from the existing group to the new group. Finally, removing a computer from an existing (normal) group can be undesirable for many reasons, the most notable being reporting. For organizations that report by target group, removing systems from a regularly-assigned target group will negatively impact reporting. In the end, just way too much work to achieve the objective desired.
When the issue affecting the special-handling update goes away (i.e. the update is fixed, superseded, or expired), the only ‘undo’ that is required is to remove the systems from the child group and delete the group.