Using Computer Groups in WSUS 3.1

Hello. I'm confused about something. Got WSUS 3.1 setup. Am using client side
targeting. I have a test environment setup but on the end will be psuing
updates out to about 1500 machines give or take.

Ive created the workstation groups in WSUS and have my GPO applied to th OU
containing the test computers which point to one of workstation groups in
WSUS.

The updates are there etc etc. I know that when I click on an update to
appove it I then choose which group to apply it to. What I am confused about
is how do I customize which workstation groups receive which updates? Can I
say this group only apply or not apply this update? Here is the issue I have.
We have several applications in use on PC in the domain that cannot get
certain updates. Some absolutely cannot go past .NET 2.0 and some still
cannot receive other certain updates. I need to be able to customize which PC
get which updates.

Would I create a domain level GPO, and then create security groups that
contain the pcs that I either do or do not want to recieve certain updates
along with a custom GPO applied to that OU which points back to the
corresponding group in WSUS??? If that's a good way to go, how do I then say
in WSUS that for this group apply everything but X update while at the same
time applowing X update to be able to apply to other groups??

Does that make sense?

Hope someone can help.
Thanks,
Chris

Carito wrote:

> Hello. I'm confused about something. Got WSUS 3.1 setup. Am using client side
> targeting. I have a test environment setup but on the end will be psuing
> updates out to about 1500 machines give or take.
>
> Ive created the workstation groups in WSUS and have my GPO applied to th OU
> containing the test computers which point to one of workstation groups in
> WSUS.

OK, good.

> The updates are there etc etc. I know that when I click on an update to
> appove it I then choose which group to apply it to. What I am confused about
> is how do I customize which workstation groups receive which updates?

I'm not sure I understand your question. An update will only be applied to
those groups to which it is approved.

> Can I
> say this group only apply or not apply this update?

Yes. For those updates which you only want to apply to some groups, do not
approve the update for "all computers" but only to those groups to which you
want to deploy it.

(It is also possible to approve the update to "all computers" and then override
this for particular groups, but I don't usually recommend this approach as I
find it can cause confusion. YMMV.)

> Would I create a domain level GPO, and then create security groups that
> contain the pcs that I either do or do not want to recieve certain updates
> along with a custom GPO applied to that OU which points back to the
> corresponding group in WSUS???

You seem to be confused between the difference between security groups and OUs?

It is usually a good idea to have one top-level GPO applied to all those
machines you want to be WSUS clients. This GPO can define all the settings that
are the same for all machines.

Then you need to apply a separate GPO to each set of machines that you want in a
particular WSUS group (or to have different settings). There are two ways to
apply a GPO only to particular computers.

The recommended way is to put the computers in a separate OU and apply the GPO
to that OU.

Another way, which is not recommended unless for some reason you can't separate
the machines into OUs, is to put the machines into security groups and create
GPO objects filtered by security group membership. If you think you want to do
this, you should probably discuss the details in the group policy newsgroup.

> If that's a good way to go, how do I then say
> in WSUS that for this group apply everything but X update while at the same
> time applowing X update to be able to apply to other groups??

Turn it around. For update X, approve only the groups that you want it to be
installed on.

Harry.

One of the reasons I was looking at using security groups and then filtering
out the seperate GPOs was because as AD stands now other areas of IT have
computers in different OUs for various reasons so they are basically all
over. They are not all in one place. So I thought it would just be easier to
create One WSUS OU per se have seperate security groups in it and consolidate
that way so that the computer objects could stay where they are And I have
one central location for all the WSUS stuff. Im still learning though.

My basic stumbling block though has been being in an environment where some
updates like .NET just cannot be installed but only to some computers.

So if I understand you, I would create one domain level GPO to apply to all
computers that can receive all updates and in that GPO I would set client
side targeting to say the "ALL Computers" group in WSUS.

Then I would do what I want for the machines that cannot receive certain
updates and create another OU with a seperate security group containing the
computes that say cannot recieve .NET updates, and have them point to the
pertaining group created in WSUS. Then onthat grops settings I would apprive
all updates but the .NET?? Do I have that right? I guess I didnt realize that
I could set the updates to apply to multiple groups.

Thoughts? Am I anywhere on the right track?

Chris



"Harry Johnston [MVP]" wrote:

> Carito wrote:
>
> > Hello. I'm confused about something. Got WSUS 3.1 setup. Am using client side
> > targeting. I have a test environment setup but on the end will be psuing
> > updates out to about 1500 machines give or take.
> >
> > Ive created the workstation groups in WSUS and have my GPO applied to th OU
> > containing the test computers which point to one of workstation groups in
> > WSUS.
>
> OK, good.
>
> > The updates are there etc etc. I know that when I click on an update to
> > appove it I then choose which group to apply it to. What I am confused about
> > is how do I customize which workstation groups receive which updates?
>
> I'm not sure I understand your question. An update will only be applied to
> those groups to which it is approved.
>
> > Can I
> > say this group only apply or not apply this update?
>
> Yes. For those updates which you only want to apply to some groups, do not
> approve the update for "all computers" but only to those groups to which you
> want to deploy it.
>
> (It is also possible to approve the update to "all computers" and then override
> this for particular groups, but I don't usually recommend this approach as I
> find it can cause confusion. YMMV.)
>
> > Would I create a domain level GPO, and then create security groups that
> > contain the pcs that I either do or do not want to recieve certain updates
> > along with a custom GPO applied to that OU which points back to the
> > corresponding group in WSUS???
>
> You seem to be confused between the difference between security groups and OUs?
>
> It is usually a good idea to have one top-level GPO applied to all those
> machines you want to be WSUS clients. This GPO can define all the settings that
> are the same for all machines.
>
> Then you need to apply a separate GPO to each set of machines that you want in a
> particular WSUS group (or to have different settings). There are two ways to
> apply a GPO only to particular computers.
>
> The recommended way is to put the computers in a separate OU and apply the GPO
> to that OU.
>
> Another way, which is not recommended unless for some reason you can't separate
> the machines into OUs, is to put the machines into security groups and create
> GPO objects filtered by security group membership. If you think you want to do
> this, you should probably discuss the details in the group policy newsgroup.
>
> > If that's a good way to go, how do I then say
> > in WSUS that for this group apply everything but X update while at the same
> > time applowing X update to be able to apply to other groups??
>
> Turn it around. For update X, approve only the groups that you want it to be
> installed on.
>
> Harry.
>

Carito wrote:

> One of the reasons I was looking at using security groups and then filtering
> out the seperate GPOs was because as AD stands now other areas of IT have
> computers in different OUs for various reasons so they are basically all
> over. They are not all in one place.

If the arrangement of the computers in the AD doesn't correspond to the way you
want the WSUS groups set up, it might be more sensible to put the computers into
the WSUS groups from the server console rather than using group policy to do it.

One potential advantage of using group policy would be if you wanted the various
IT groups to determine the appropriate WSUS group(s) for the computers under
their control.

> So if I understand you, I would create one domain level GPO to apply to all
> computers that can receive all updates and in that GPO I would set client
> side targeting to say the "ALL Computers" group in WSUS.

No. You don't assign computers to the All Computers group; by definition, all
computers are members, including computers that aren't assigned to any group.

> Then I would do what I want for the machines that cannot receive certain
> updates and create another OU with a seperate security group containing the
> computes that say cannot recieve .NET updates, and have them point to the
> pertaining group created in WSUS.

I think you may be confused about how group policy works - were you assuming
that if a GPO is applied to an OU containing a security group, the GPO would be
applied to all computers in that group? It doesn't work like that.

> Then onthat grops settings I would apprive
> all updates but the .NET?? Do I have that right? I guess I didnt realize that
> I could set the updates to apply to multiple groups.

That would normally be the method I would recommend. However, it sounds as if
you need more flexibility in excluding certain updates from arbitrary sets of
computers, so you might be better off with an approach like this:

Have a top-level WSUS group called "standard" (or something). For any update
that you want to install, you will set the approval for the "standard" group to
"Approved".

Have a subgroup of "standard" for each update (or related set of updates) that
you want to exclude for one or more computers. In the relevant update(s)
approval settings, set the approval for this subgroup to "Not Approved".

For example, you would have a "nodotnet3" subgroup, and you would set the
approval for the .NET 3 update(s) to "Approved" for "standard" and "Not
Approved" for "dotnet3". (Make sure you do this in a single operation, or that
you set the "Not Approved" before you set the "Approved", in case one of the
clients checks in while you're making changes.)

You might also have, for example, a "noxpsp3" subgroup, and set the approval for
XP SP3 to "Approved" for "standard" and "Not Approved" for "noxpsp3".

Normal computers would be in the "standard" group and would get all the updates
you approve.

Computers that shouldn't have .NET 3 installed would not be in "standard" but
would instead be in "nodotnet3". Because "nodotnet3" is a subgroup of
"standard" all updates other than .NET 3 will still be installed, even though
they aren't explicitly approved to the "nodotnet3" group.

Computers that shouldn't have XP SP3 installed would not be in "standard" but
would instead be in "noxpsp3". Again, "noxpsp3" is a subgroup of "standard" so
all updates other than XP SP3 will be installed even though they aren't
explicitly approved.

The trick to this setup is that a computer can be in more than one group. So if
you had a computer that shouldn't have .NET 3 *or* XP SP3, it would be in both
the "nodotnet3" and the "noxpsp3" groups. The explicit "Not Approved" settings
on the one group override the inherited "Approved" settings on the other group.

Once you've got to grips with this, you might also want to put the computers in
additional groups based on department or location, and/or desktop vs laptop, for
reporting purposes. You wouldn't approve any updates in these groups, as the
approvals would be determined by the other set of memberships.


Does this make sense to you?

Please note that I've never actually tried out this scheme, so I can't guarantee
how well it would work in practice. Lawrence has a bit more experience with a
variety of scenarios, he might have some comments and/or a different recommendation.

Harry.