One of the most tedious but crucial functions of any administrator is keeping track of patches -- the inexorable flood of software updates, security fixes and revised operating system components. Not only do you have to stay on top of what's coming out, but you also must keep track of "who got patched with what" and "who still needs to be patched."
A sensible administrator can create a patch database to track the machines and applications that have or need patches. There are three ways to do this (in roughly ascending order of efficiency): by hand, with a third-party program or through Microsoft's own Windows Management Interface (WMI) and Group Policy Objects (GPOs).
Manual patch tracking
This is the most obvious method, but it is also the most tedious and least accurate. It involves little more than keeping meticulous notes, either in a spreadsheet or in a relational database. But it also requires exactitude and patience. If you're dealing mainly with custom applications or third-party programs, neither of which are easily inventoried through mechanisms like WMI, then manual tracking may be the only option.
 |
|
|
|
|
If you choose to track patches by hand, the details matter.
Serdar Yegulalp
Editor, Windows Power Users Newsletter
|
|
|
|
|
|
|
|
|
|
If you choose to track patches by hand, the details matter. You'll need a checklist for each patch:
- Date the patch was issued
- Revision number
- Specific problems addressed by the patch
- Which users and machines received the patch
- Any known or noted side effects or conflicts with other products
That last point is especially important. If you have documentation from the manufacturer about any known side effects, note them, and make sure the person receiving the patch isn't going to be affected. Another important detail is what other patches (if any) this patch supersedes or replaces. Think about how Windows service packs, for instance, eclipse each other. Finally, if the patch is small enough and you're using a program that lets you paste attachments into a file, you could even place a copy of the patch in the document and circulate it. Failing that, a link to an intranet folder or a Web site will work fine.
MyITForum has a number of scripts that an administrator can use when doing patch management. One quick-and-useful script is GetPatchList, which derives a list of all patches on a local or remote machine listed via WMI (i.e., all Microsoft patches and some third-party patches as well).
Third-party products for patch tracking
Third-party products have taken a lot of the pain out of patch management, making it possible for one person at one console to audit a whole organization's computers for patches.
The longstanding champion product in this realm is probably Gravity Storm Software's Service Pack Manager 7.1, which can scan an entire network and determine which machines need (or have) what security fixes. It also has sophisticated report-generating and criterion-filtering systems, allowing you to test whether or not systems have been patched according to certain profiles (i.e., do all the Windows XP machines in this organization have Service Pack 2?). This kind of querying model also makes it easier to deal with conflicts between a patch and a software product -- you can filter out machines where you know there would be a problem. Service Pack Manager also supports fixes for Microsoft's non-OS products such as SQL Server and Windows Media Player, although it doesn't (yet) support patch queries for non-Microsoft products.
WMI and GPO for patch tracking
For keeping non-Microsoft programs up to date, consider other products that use WMI and GPO to do patching. Using a WMI-based product allows the administrator to simply list the patches to be rolled out, define which machines need them, and leave the rest to Group Policy. There is no scanning or push-updating required -- this is a real boon for organizations with thousands of desktops. It's probably the most seamless solution of the three, although it requires much more work to be effective.
DesktopStandard's PolicyMaker Software Update is one such package; it uses a Group Policy client-side extension (a standard Microsoft add-on mechanism for GPOs) to allow a system to determine if it needs updates. The patches in question can be Microsoft patches, third-party patches with their own metadata, or even updates of your own creation that don't follow a particular model. It also has provisions for allowing patches to automatically supersede or replace each other -- one less thing to track by hand, which is exactly the idea when using GPOs to do patch tracking.
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!
More information from SearchWindowsSecurity.com
Tip: Weed out those unpatched systems
Tip: How to handle superseded patches
Topics: Look up additional patching tips and expert advice
