Article 019

How do I use target groups?

Target groups are a way to categorize WSUS clients. That's the simple purpose. Why one might want to categorize them, might be for different reasons. One reason might be because there are several WSUS servers, and the groups are organized by clients of a particular server. Another reason, as I do, is to split up servers, desktops, and notebooks, so that I can apply different policies to each one -- but every client still syncs with a single server. Some examples of policy differences are:
    (a) Servers are configured with Option #3, so that updates do not install automatically (resulting in an undesired or unmonitored restart), and also have a shorter detection cycle, so that the data in the WSUS database is more current.
    (b) Desktops are configured with Option #4, so that updates install every night, and have a default detection cycle, as there's no real benefit in shortening the detection cycle for a desktop computer.
    (c) Notebooks might have some other policy options -- such as Option #2 to allow the user to decide when updates are downloaded, or a policy to disable Windows Update, or perhaps use an entirely different WSUS server that does not have content, forcing the notebooks to obtain content from microsoft.com, and thus reducing the load on the organization's VPN resources.

I also assign approvals on each update according to the platform they're designed to be installed on. For example, updates targeted to Windows Server 2003 are only approved for the Servers group, but not for the Desktop or Notebook (Windows XP) groups. You may have read about a recent incident where a Windows 2000 Professional system attempted to install MS02-008, which is only designed for installation on Windows 2000 Server. If this update, only applicable to servers, had only been approved for a Servers group, then the attempted installation would have never occurred on the desktop system.

The fundamental problem with moving computers in and out of groups, is that the list of approved updates for any given computer is a continually moving target. Also, due to an interesting 'feature' in the WUA, if you should happen to move a computer out of a target group before the update is actually installed, the absence of the approval in the new group can result in the cancellation of the scheduled installation of that update on that system.

Of course, if you have multiple WSUS servers, you will need to have multiple GPOs, because each GPO will have a different URL configured. And while consolidated reporting is not yet a full feature of WSUS, it is possible to have clients from multiple WSUS servers configured to report to the same target group. (At the moment the reports will be split across two servers, but a script due out shortly from the WSUS team may provide for the 'consolidation' of that data from multiple servers using the same target groups.)

The advantage of using client-side targeting and target group names assigned by GPO is exactly as you describe. When a system is placed into that target group, it will automatically appear in that target group on the WSUS server.

The complication, however, comes when you combine both features -- which can
be done successfully for some legitimate purposes. If the client thinks it's using client-side targeting (by virtue of the TargetGroupEnabled value set to '1' -- the Client-Side Targeting policy is enabled, and the configuration of a target group), then the client will report that target group as its preferred group, and that will be stored in the database. However, if the server is configured for server-side targeting, the computer will actually appear in the group assigned at the server, not the group reported by the client and stored in the database.

Unfortunately, though, because the client thinks it's a member of a specific group, exclusively, it uses that information to obtain a list of approved updates. An update would need to be approved for the specific group the client has configured, or for "All Computers". In the case where the client does not have client-side targeting information, it thinks it belongs to the "Unassigned Computers" group, and then will only detect updates approved for "All Computers" or for "Unassigned Computers".

Another way to think of this... "Unassigned Computers" is a pre-configured, non-removable, server-side target group. All clients join that group unless they receive instructions to the contrary (via a client-side target group name that exists on the WSUS server). You cannot assign a computer to "Unassigned Computers", it just appears there by default if it has no other instructions -- which will be the case if server-side targeting is being used and the client does not have the TargetGroupEnabled value set to '1'.

"All Computers" is just the master collection of all of the other target groups - of which there is only one on a default installation of WSUS: "Unassigned Computers".

The targeting group information will only be defined if you've enabled client-side targeting, linked the GPO to an OU, and computers that are members of that OU will then report themselves as members of the configured TargetGroupName in that GPO. However, lacking the presence of client-side targeting, the WUA assumes it's target-group is "Unassigned Computers", but this can be overrridden at the server, by moving the computer to a server-side created TargetGroupName.