A while ago, I wrote about prioritising patches and updates on a server -- what to install first, what order to consider things in -- and mentioned that the process was fundamentally different on a server than it is on a workstation.
Here I want to expand on how to handle the patching process on desktops, although the hierarchy of things to do is actually quite similar. My list covers the major categories of things that can be patched or updated in a typical desktop configuration and the order in which you should apply them whenever possible. (For instance, if you had a BIOS update the same week as a new graphics driver, the BIOS update ought to go in first since it runs on a lower level.)
|Checklist: Prioritizing desktop patches|
|As with servers, start here. Managing BIOS updates across multiple systems is all the easier when they're of the same make and manufacturer, but it requires "hard" downtime: The computer has to be powered down and rebooted to apply the new BIOS, and the administrator usually has to baby-sit each system individually that will be upgraded. Fortunately, many PC manufacturers now allow centralized updates to BIOSes through a management application -- Altiris, for instance, has a management solution for Dell desktops and notebooks that allows remote BIOS updates.|
|2. Device BIOSes|
|These include things like BIOS updates for disk controllers, video cards or other devices. Device BIOS updates go into a separate category from regular BIOS updates for two reasons: One, they are easy to overlook and not often considered for desktops; two, you usually cannot update them en masse. For example: If you're administering a group of graphical workstations that need updates to their video card's BIOSes -- and the only way to do that is via a 16-bit DOS-based updater -- you'll probably have to do that by hand for each computer. However, if you could perform the update through a 32-bit Windows application, you could probably push that out as you would any other update.|
|3. Device drivers|
|As with servers, one of the more common hardware device-driver updates published for a desktop computer is for the network controller. Make sure you test the update ahead of time. If you update a whole slew of machines with such a driver and the end result is that they're all knocked off the network, your only choice might be to either re-image them from scratch or fix each one manually.|
|4. The OS itself, including patches for it|
|This is the part almost everyone is directly familiar with and it needs relatively little elaboration here. One thing I'll add is something I also wrote about in the server version of this article: If there are device driver updates, they should be examined separately from other updates in case an OEM-provided version of the driver is more urgently needed.|
|This normally includes elements such as ODBC drivers but should also include things like the Microsoft .NET Framework. Note that with the .NET Framework, the 1.1 and 2.0 iterations (and the upcoming 3.0 edition as well) exist side-by-side and don't eclipse each other.|
|6. Application updates|
|As with the OS and its attendant patches, you can roll out application patches through the usual automated mechanisms, and it should be done only after everything else has already been applied.|
Trying to manage patches and updates on desktop systems has a number of direct parallels to how to do the same things on servers. In both cases, usually, you can only apply the changes in question within specific windows of opportunity, since the computer often has to be rebooted to apply everything. A server can only be brought down safely during off-peak hours, and a desktop really should be rebooted only when the user's not around.
On the plus side, you can, in theory, manage desktops a little more "destructively" than you can a server. If you use a mass-imaging solution that completely rebuilds desktop installations (and individual user data isn't stored locally), you can scrape and reset all the desktops using a single, centrally-updated image. It's also possible to do this once every couple of months -- re-image anew every so often, and then push out incremental fixes to each desktop as needed in the interim. This insures that individual machines don't somehow fall out of sync and that any problems that crop up between re-imagings are swept out. One obvious downside of re-imaging from scratch is the bandwidth needed to do this. If it's performed over the network, you may have to stagger updates between different departments or groups to make it manageable.
About the author: Serdar Yegulalp is editor of the Windows Power Users Newsletter. Check it out for the latest advice and musings on the world of Windows network administrators -- and please share your thoughts as well!