This 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. Patch your systems in this order
and your patch management policy will be stronger than ever.
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.
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 out your Windows patches as you would any other update.
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 automate patching on 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.
The OS:
Patching Windows OSes 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.
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.
Application patches:
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.
Practice Tests:
http://www.certexams.com/comptia/a+/a+essentials-exam-details.htm
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.
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 out your Windows patches as you would any other update.
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 automate patching on 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.
The OS:
Patching Windows OSes 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.
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.
Application patches:
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.
Practice Tests:
http://www.certexams.com/comptia/a+/a+essentials-exam-details.htm
No comments:
Post a Comment