|
What should I do with superseded updates? |
| In general.... there's no need to take any action with regard to
superseded updates, because the Windows Update Agent will handle all of the detection
logic relevant to superseded updates that are in an approved state. However, note that I said 'in general'.... there are exceptions. The first exception has to do with the general idea of disk maintenance and service packs. If you're in the process of a service pack deployment, you need to be able to support updates for both pre-SP and post-SP systems. Once the SP is fully deployed, though, you may decide that you don't want to maintain that pre-SP content in the content store any more. In this case, you'd want to seek those superseded updates, mark them as declined, and then run the "PurgeUnneededFiles" tool to clear out the content store of all of the pre-SP content. You could then mark those updates back to "Detect Only" as a precautionary measure, or leave them marked as "Declined". The second exception has to do with Cumulative Updates for IE and OE. There's a bug somewhere in the detection logic, I'm no longer sure if it's WUA code, or if it's in the detection logic contained within the update packages, but either way, client systems fail to ignore superseded Cumulative Updates when a more recent (superseding) Cumulative Update has been approved for installation. To this end, you must mark all superseded Cumulative Updates in some sort of "not approved" fashion. Either downgrade them to "Detect Only", mark them as "Not Approved", or, as you may wish to purge the content store of the Cumulative Update files (some of which can be pretty sizable), mark the superseded Cumulative Updates as "Declined" and use the "PurgeUnneededFiles" tool to clear out the content store. The third exception has to do with a WSUS server configured to use Express Installation Files. When EIF is enabled, your content store can be as much as 10x larger than a non-EIF WSUS server providing the same content. As such, it may be fairly important for such systems to minimize the amount of 'dead content' sitting around on the server. In these cases, it might be desirable to be even more aggressive about marking superseded updates as "Declined" so that all 'dead content' can be purged from the content store. Personally, I think the best solution is to mark them as Declined, Purge the content store, and then reset them to Detect Only. In the event that a client comes along and needs that update, you can Approve it, the content will be downloaded again, and everybody is happy. The primary disadvantage of leaving them marked as Declined is the scenario where a 'new' client machines sneaks into the network and nobody recognizes that there's an unpatched machine because they're all marked as "Declined" on the WSUS server, so nothing ever shows as "Needed" on the client. |