With Microsoft's renewed commitment to security comes an onslaught of patches and hot fixes. Many Windows administrators...
are mulling how to handle them all.
According to one expert's math, Microsoft has sent out about 30 patches and hot fixes so far this year. For this reason, it behooves all Windows shops to develop some form of patch management strategy, even if it means simply setting up a time every six weeks for a patch review. Simple as that sounds, even the most conscientious IT administrators can find the task daunting.
At the Center for Environmental Studies at Arizona State University in Tempe, IT administrators apply patches about once every six weeks and usually do the work on a weekend day, when the fewest people are online. Still, Wayne E. Porter, the university's data lab administrator concedes, "It's a never-ending battle."
Patch management on Windows is hardly straightforward, even though enterprises that are already running Windows 2000 on their servers have a potentially powerful tool for patch administration in the software's "Group Policy" feature. This feature defines options for managed desktop configurations for users and computers across the enterprise.
Theoretically, this means hot fixes can now be installed on remote machines using a Microsoft installer, as opposed to the old fashioned way -- one by one. Group Policy lets IT administrators restrict how servers run and in what context, allowing for granular administration of people in groups.
Microsoft declined to comment on this subject, but experts said the use of Group Policy to distribute hot fixes is hampered by Microsoft's inconsistent deployment practices.
"A SQL Server hot fix is different from an Internet Information Services hot fix, which is different from an Internet Explorer hot fix," explained Tim Mullin, CIO at AnchorIS.com, a Charleston, S.C., financial software company.
Not only are the hot-fix deployment procedures different, in some cases they are downright clunky. Mullin mentioned one case involving a rollup for SQL Server. It required the administrator to stop servers and -- from a file folder -- manually cut and paste different files over existing ones.
Overall, IT administrators have to take time to reformat the patches before they can be distributed. Slow patch deployment because of inconsistent application methods is just one part of the problem. Fear is another. Often, patches don't get installed because IT administrators are afraid that fixing something on one end might break something on the other end.
The business of adding new software without careful testing in a lab environment can easily muck up a server when you consider all the possible special configurations, old software, old drivers and third-party applications that may be running on one machine.
The specific security fix doesn't usually cause the problem. The culprit is more likely to be the fact that software updates often contain more than just a single bug fix. Some service patches are only fixes to code, while others are fixes bundled with product enhancements.
"We would prefer that Microsoft package its product enhancements separately from its bug fixes, particularly where there are security fixes that must be applied quickly," said John Bruce, principal consultant at ePresence, a Westborough, Mass., integrator.
Patch management tools
There is no shortage of patch management tools that IT administrators can use to check workstations against the public patch list.
Microsoft's own free Baseline Security Analyzer helps spot configuration problems. There is also Shavlik Technologies' HFNetChk, which has direct access to the Microsoft security database. Ecora Software, Portsmouth, N.H., offers a version of the PatchMeister for free.
These tools can identify local accounts without passwords and identify which patches the Windows administrator has already applied. They can also compare what is on the workstation with Microsoft's own database, said John Bruce, a principal consultant at ePresence.
What they cannot do is load the patches that are missing. A paid version of those software products helps you download the patches, Bruce said. The main difference between the products is the appearance of their user interface and the appearance of the reports they produce. Shavlik and Microsoft both use the same engine (written by Shavlik).
Getting the patch out
Ultimately, the goal is not just for Microsoft to make a patch available, but to motivate customers to use it. Microsoft has the Herculean responsibility of making sure that patches are easy to install and deploy. This is where consistency is important, in Mullin's opinion.
He said he hopes that as .NET Server becomes available -– and as Microsoft's Trustworthy Computing Initiative bears fruit -– the need for security patches will wane.