Patching a server is fundamentally different from patching a workstation, both in terms of the scope of the patches and the process involved. You can usually take workstations out of commission and rebuild them from a pre-patched image, if it comes to that. With servers, there is usually no such luxury. The amount of downtime you can afford with any server is likely to be minimal, even if you're dealing with a server that has backup (as, for instance, with an active/passive cluster).
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
One of the tougher jobs that server administrators have to deal with is figuring out the priority of patches for servers. They not only have to deal with the server, but also with the applications running on it, the middleware between applications and a host of other things. If you have a mess of patches to go into a given server, where do you start, and how do you move forward?
The best thing to do before you load in a single patch is to prioritize, to figure out what goes in first and why. Over time I've compiled a patch-ordering map for servers that covers just about everything, and I stick to it as best I can whenever it's time to bring a new machine up to speed. Also, this way, if something peculiar arises that might be traceable to a given change, it's a little easier to isolate what it might be.
|Checklist: Patching Windows Servers|
|Start here. For me, an updated BIOS counts as a patch; many of the changes might be minor, but significant (such as updates to power management or processor-stepping handling). If you're about to bring a server offline for major updates, it doesn't hurt to check if an updated BIOS is also available. For the sake of insurance, keep a copy of the current BIOS revision handy; see if your BIOS flashing utility lets you make a backup copy if you can't download one from your motherboard or system manufacturer's Web site. That way you can back off if things don't behave as expected.|
|2. Device BIOSes.|
|These include things like the BIOS for RAID controllers, video devices and so on. The same rules apply: Check on updates to these if you are planning some downtime. And, keep the backups.|
|3. Device drivers.|
|The most common hardware device driver you'll be dealing with on a server is probably a NIC driver, but there are others that come to mind, like disk controller drivers (for both RAID and standalone disks). Always be ready to roll back to earlier versions if something new causes a problem. I've occasionally gone to a new network driver that caused more problems than it solved -- not often, but often enough for it to be worth noting. One very nice thing about Windows is that at this point, you can usually update network drivers without a reboot.|
|4. Conventional OS patches -- security updates, functionality changes, etc.|
|This is the stuff typically obtained from Microsoft Update -- changes to Windows itself. If you get driver updates in this package, they can be loaded in at the same time, but I generally do them separately from everything else to make sure they're not going to cause conflicts.|
|This is the glue between applications -- ODBC drivers, Java virtual machines, Microsoft's data access components and so on. These things have become progressively more important over time -- can you imagine a Web server without database connectivity? -- and deserve to be considered on their own. The .NET Framework probably belongs in this category, although Microsoft likes to think of it as being more a part of the OS.|
|6. Application revisions|
|These include things like SQL Server or Exchange, or standalone server applications like Mercury Mail. Microsoft Update will roll in updates for any of these applications if they're Microsoft programs as well, but you can always elect to update other layers of the system first and test them before doing the application updates.|
I've mentioned throughout this piece that certain patches are pre-prioritized and provided by mechanisms like Microsoft Update. If you are only administering one or a few servers and they get most of their updates this way, you can allow Microsoft Update the freedom to handle the most important things, while manually dealing with elements that Microsoft Update can't.
Microsoft Update on server versions of Windows does not force a reboot as aggressively as it does on client machines. So, if you know you have downloads pending and want to allocate server downtime to slot in other updates, this is one way to get advance warning about when you can do it -- and you can research other things that might be updated during that window of downtime.
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!