When patches are in decline

derekschauland

I am looking at a list of patches that no systems in my environment seem to need, however mgiht there always be one someday that needs some obscure patch.  Does anyone have a rule of thumb, best practice, off the wall logic, for when it is good to decline patches within Patch Manager?  Outside of things like the superseeded items it almost seems to make sense to just keep them all...

Derek

LGarvin

Greetings Derek.

The conventional wisdom for declining patches is this:

1. Any patch that is superseded and is reported by the client systems as 100% Not Applicable.

2. Any patch that you want to protect from being accidentally deployed (e.g. for quite some time I had .NET4 and IE9 declined, and will likely decline IE10 for Win7 when it gets released).  Patches can be UN-declined when a decision is made to actually deploy them.

3. Any patch that relates to a product that you don't have and will never have should be declined. The classic example here is *Itanium* updates.

There are two primary motivations for declining patches, other than hiding them from the WSUS native console update list.

1. Client systems do not evaluate detection logic for declined patches. By declining irrelevant patches, you can significantly reduce the work effort required by the WUAgent to perform a detection. In fact, this is so significant, that many implementations with too many updates synchronized, or too many updates approved, will experience timeout errors during detection events, or downstream server synchronization events.

2. For updates previously approved, declining the update allows the Server Cleanup Wizard to delete the installation file(s) associated with that update, and this will significantly reduce the amount of disk space consumed by the ~\WSUSContent folder.

One additional note on Itanium and other unwanted updates -- in fact, with Patch Manager, you can automate the declining of these updates, you can even DELETE them from the database entirely. I have generally made these recommendations to Patch Manager customers:

1. Itanium updates (unless you actually have an Itanium server -- I've never seen one; I don't even really believe they exist) should be deleted upon arrival. You can configure a monthly task to run late night on Patch Tuesday to delete all updates with the keywords 'Itanium' or 'IA64' in the Update Title.

2. If you still need Windows Server 2008 SP2 x86 updates (typically this is for x86 servers that cannot run Windows Server 2008 R2), you can configure a monthly task to decline the Windows Server 2008 SP2 x64 updates. (You probably don't want to delete them because there's always a remote possibility you might still need to install a non-R2 x64 system for some legacy issue.)

3. If you still need Windows Server 2008 SP2 x64 updates (really upgrading to R2 is the preferred option, but for some organizations, licensing costs are a consideration), you can configure a monthly task to decline or delete the Windows Server 2008 SP2 x86 updates. (Whether you choose decline or delete really depends on your evaluation of whether you might ever have to install an x86 server again.)