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 | | | | | | | | | |
| | | | | |
| |  | | | | | | 1. BIOS | | | | | | | | | |
| | | | | |
| <> | | | | | | | 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. | | | | | | | | | |
| | | | | |
| | | | | | | | 5. Middleware | | | | | | | | | |
| | | | | |
| <> | | | | | | | 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!