Windows XP SP3 WSUS Approval

Hello all, does anyone know if there is a way to deny/block/unapprove an
update in WSUS for one particular workstation? The workstation has to stay
in it's group. It needs other updates, just not SP3. We use group policy
membership for WSUS. TIA for any info!!!

Steve

"Steve Esqueda" <Steve > wrote in message
news:2576B634-48DE-4AD3-B2E2-...
> Hello all, does anyone know if there is a way to deny/block/unapprove an
> update in WSUS for one particular workstation? The workstation has to
> stay
> in it's group. It needs other updates, just not SP3. We use group policy
> membership for WSUS. TIA for any info!!!

No, Steve, there is no way with WSUS to do this without changing the group
membership of the workstation.

You can, however, deploy the standard XP SP3 installation blocker tool
(available from the Microsoft Download Center), which will keep XP SP3 from
installing until the expiration date of the blocking for SP3.

Also, if the only reason you're concerned about maintaining the group
membership is to ensure other updates continue to be applied, you can
consider this:

[1] Create a SUBgroup of the existing group containing this workstation. By
default, all update approvals are inherited to new subgroups of existing
groups, so no additional approval action is required to set up this new
subgroup. One possible name for this group might be "NoXPSP3".

[2] Modify the approval status for Windows XP Service Pack 3 for this
subgroup so that Windows XP Service Pack 3 is set explicitly to "Not
Approved".

[3] Reassign this computer (and, potentially, any other computers that
subsequently develop XPSP3 issues) to the new subgroup, removing it from the
previous (parent) group. This can most easily be done by creating a NoXPSP3
Security Group, adding this computer to that group, and then using that
security group to filter the existing WSUS GPO. Create a second WSUS GPO
that is a copy of the existing policy, but change the target group name to
NoXPSP3.

All approvals made for the parent group will continue to be inherited by
this subgroup, so the behavior of all other updates will remain the same.
The only behavioral difference in the console is that this machine will
appear in a subgroup, rather than the parent group.

This "exception handling" is one of the primary reasons heirarchical groups
were added as as feature in WSUS v3 and this is the standard methodology by
which such exceptions are handled in the WSUS environment.

--
Lawrence Garvin, M.S., MCITP:EA, MCDBA
Principal/CTO, Onsite Technology Solutions, Houston, Texas
Microsoft MVP - Software Distribution (2005-2009)

MS WSUS Website: http://www.microsoft.com/wsus
My Websites: http://www.onsitechsolutions.com;
http://wsusinfo.onsitechsolutions.com
My MVP Profile: http://mvp.support.microsoft.com/pro...awrence.Garvin

Thank you Lawrence!!! That was exactly what I needed!

"Lawrence Garvin [MVP]" wrote:

> "Steve Esqueda" <Steve > wrote in message
> news:2576B634-48DE-4AD3-B2E2-...
> > Hello all, does anyone know if there is a way to deny/block/unapprove an
> > update in WSUS for one particular workstation? The workstation has to
> > stay
> > in it's group. It needs other updates, just not SP3. We use group policy
> > membership for WSUS. TIA for any info!!!
>
> No, Steve, there is no way with WSUS to do this without changing the group
> membership of the workstation.
>
> You can, however, deploy the standard XP SP3 installation blocker tool
> (available from the Microsoft Download Center), which will keep XP SP3 from
> installing until the expiration date of the blocking for SP3.
>
> Also, if the only reason you're concerned about maintaining the group
> membership is to ensure other updates continue to be applied, you can
> consider this:
>
> [1] Create a SUBgroup of the existing group containing this workstation. By
> default, all update approvals are inherited to new subgroups of existing
> groups, so no additional approval action is required to set up this new
> subgroup. One possible name for this group might be "NoXPSP3".
>
> [2] Modify the approval status for Windows XP Service Pack 3 for this
> subgroup so that Windows XP Service Pack 3 is set explicitly to "Not
> Approved".
>
> [3] Reassign this computer (and, potentially, any other computers that
> subsequently develop XPSP3 issues) to the new subgroup, removing it from the
> previous (parent) group. This can most easily be done by creating a NoXPSP3
> Security Group, adding this computer to that group, and then using that
> security group to filter the existing WSUS GPO. Create a second WSUS GPO
> that is a copy of the existing policy, but change the target group name to
> NoXPSP3.
>
> All approvals made for the parent group will continue to be inherited by
> this subgroup, so the behavior of all other updates will remain the same.
> The only behavioral difference in the console is that this machine will
> appear in a subgroup, rather than the parent group.
>
> This "exception handling" is one of the primary reasons heirarchical groups
> were added as as feature in WSUS v3 and this is the standard methodology by
> which such exceptions are handled in the WSUS environment.
>
> --
> Lawrence Garvin, M.S., MCITP:EA, MCDBA
> Principal/CTO, Onsite Technology Solutions, Houston, Texas
> Microsoft MVP - Software Distribution (2005-2009)
>
> MS WSUS Website: http://www.microsoft.com/wsus
> My Websites: http://www.onsitechsolutions.com;
> http://wsusinfo.onsitechsolutions.com
> My MVP Profile: http://mvp.support.microsoft.com/pro...awrence.Garvin
>
>

In message <> "Lawrence Garvin
[MVP]" <> was claimed to have wrote:

>"Steve Esqueda" <Steve > wrote in message
>news:2576B634-48DE-4AD3-B2E2-...
>> Hello all, does anyone know if there is a way to deny/block/unapprove an
>> update in WSUS for one particular workstation? The workstation has to
>> stay
>> in it's group. It needs other updates, just not SP3. We use group policy
>> membership for WSUS. TIA for any info!!!
>
>No, Steve, there is no way with WSUS to do this without changing the group
>membership of the workstation.
>
>You can, however, deploy the standard XP SP3 installation blocker tool
>(available from the Microsoft Download Center), which will keep XP SP3 from
>installing until the expiration date of the blocking for SP3.

I'm not sure this will help, based on the following URL the blocker has
already expired for XP SP3:

http://www.microsoft.com/downloads/d...displaylang=en

| A blocking tool is available for organizations that would like to temporarily
| prevent installation of Service Pack updates through Windows Update.
| This tool can be used with:
|
| * Windows XP Service Pack 3 (valid until May 19th, 2009)
| * Windows Vista Service Pack 1 (valid until April 28th, 2009)

Also, I seem to recall that the blocker is intended only for WU users,
whereas WSUS overrides the blocker, so it wouldn't help this user even
if we weren't past the cutoff date already.

>[1] Create a SUBgroup of the existing group containing this workstation. By
>default, all update approvals are inherited to new subgroups of existing
>groups, so no additional approval action is required to set up this new
>subgroup. One possible name for this group might be "NoXPSP3".

<snip>

This definitely looks like the best approach.

"Dave Warren" <dave-> wrote in message
news:...

> I'm not sure this will help, based on the following URL the blocker has
> already expired for XP SP3:
>
> http://www.microsoft.com/downloads/d...displaylang=en
>
> | A blocking tool is available for organizations that would like to
> temporarily
> | prevent installation of Service Pack updates through Windows Update.
> | This tool can be used with:
> |
> | * Windows XP Service Pack 3 (valid until May 19th, 2009)

Ouch.


> Also, I seem to recall that the blocker is intended only for WU users,
> whereas WSUS overrides the blocker, so it wouldn't help this user even
> if we weren't past the cutoff date already.

No, actually, the blocker tool will work in a WSUS environment. Many a WSUS
enviroment has been bitten by the presence of one or more blocker tools
"left over" from "long ago".

Consider how the tool works, and how WSUS works. The Windows Update Agent is
an independent entity. It gets update content from one of several resources
(WU / MU / WSUS). The blocker tool impacts the functionality of the WUA --
without regard for where the WUA is attempting to get the content from.

The reason the tool is generally irrelevant in a WSUS environment is because
it's trivial to simply Not Approve the update (XP SP2, XP SP3, Vista SP1,
IE7, IE8). Generally organizations using the tool are doing so because they
don't want it anywhere -- not for the purposes of restricting specified
individual machines.


>>[1] Create a SUBgroup of the existing group containing this workstation.
>>By
>>default, all update approvals are inherited to new subgroups of existing
>>groups, so no additional approval action is required to set up this new
>>subgroup. One possible name for this group might be "NoXPSP3".
>
> <snip>
>
> This definitely looks like the best approach.

It's definitely a *better* approach. :-)



--
Lawrence Garvin, M.S., MCITP:EA, MCDBA
Principal/CTO, Onsite Technology Solutions, Houston, Texas
Microsoft MVP - Software Distribution (2005-2009)

MS WSUS Website: http://www.microsoft.com/wsus
My Websites: http://www.onsitechsolutions.com;
http://wsusinfo.onsitechsolutions.com
My MVP Profile: http://mvp.support.microsoft.com/pro...awrence.Garvin

In message <> "Lawrence Garvin
[MVP]" <> was claimed to have wrote:

>"Dave Warren" <dave-> wrote in message
>news:.. .
>
>> Also, I seem to recall that the blocker is intended only for WU users,
>> whereas WSUS overrides the blocker, so it wouldn't help this user even
>> if we weren't past the cutoff date already.
>
>No, actually, the blocker tool will work in a WSUS environment. Many a WSUS
>enviroment has been bitten by the presence of one or more blocker tools
>"left over" from "long ago".
>
>Consider how the tool works, and how WSUS works. The Windows Update Agent is
>an independent entity. It gets update content from one of several resources
>(WU / MU / WSUS). The blocker tool impacts the functionality of the WUA --
>without regard for where the WUA is attempting to get the content from.
>
>The reason the tool is generally irrelevant in a WSUS environment is because
>it's trivial to simply Not Approve the update (XP SP2, XP SP3, Vista SP1,
>IE7, IE8). Generally organizations using the tool are doing so because they
>don't want it anywhere -- not for the purposes of restricting specified
>individual machines.

I could swear that I read that WSUS overrode the blocker, but I can't
find anything in my feed reader, so I'm likely misremembering...

Either way, with the blocker already being expired for XP SP3, it's a
moot point.