2

 
 
By eweek  |  Posted 2003-09-08 Print this article Print
 
 
 
 
 
 
 


Are service packs or security patches the best approach?

Usually, security patches and hot fixes are best. Service packs, as you probably already know, usually require more preparation, research and a more measured approach to deployment and are thus not really appropriate to be handled by a patch deployment system.

What are the pluses and minuses of going with "free" update services such as MS Software Update Services?

The biggest minus is that IT administrators have no centralized control or reporting and are restricted to a single platform. For desktops, thats usually not a problem because they are running a Microsoft operating system already. For servers, the single- platform restriction is a big drawback because there has been no additional testing or research beyond that done by the vendor. Although there is no initial cost, operational costs must be figured in to the cost of using "free" products in an enterprise.

Is there anything else besides patches we should be scanning for?

This is a good question because it gets us back to system stability and not just security. Patch management toolmakers keep an eye on all releases—security-related and otherwise—for the platforms they support. So the answer is, yes, you should be looking for hot fixes, and most toolmakers will help you get these patches out to the appropriate systems in your network.

Should I support Windows 98 when Microsoft no longer does?

Most patch management systems pride themselves on being able to get a patch to almost any Windows client system. It almost goes without saying that patch management companies dont make the patches. However, if a patch becomes available for an end-of-life Windows product, its likely that most patch management companies would tell you about it and provide a way to get it to the appropriate systems in your network.

What happens in the case of [the patch management] software itself becoming vulnerable?

Patch management systems go to great lengths to prevent rogue use. Security in the patch management system is a good point to add to your evaluation checklist.

Are products like PatchLink [the vendor of which, PatchLink Software Corp., sponsored this eSeminar] able to throttle to lower bandwidths?

Yes, and so can many other patch management systems. Lower-bandwidth capability is another good point for the evaluation checklist.

Remote access service dial-in clients would take forever to install anti-virus patterns and patches. Any suggestions?

Patch managers almost always compress patches. Other than that, CD distribution might help. In addition, software distribution systems are often better than the deployment mechanisms in patch management tools—that is, if the software deployment package offers what is commonly called checkpoint restart. This is the ability to restart a file transfer at the point at which it was unexpectedly disconnected, as often happens with dial-up users.

How quickly can I deploy a patch management system in a 45,000-plus workstation environment?

Here are some of the factors to consider in gauging patch deployment speed:

1) Are the systems to be patched concentrated in LANs? Concentrated LAN-connected systems go more quickly than remote systems.

2) Are you using the patch management system or a software deployment product to deploy patches? In general, software distribution systems in the large environment you described are set up with staging servers that help speed the deployment process. Software distribution systems are usually better equipped than patch management systems to handle very large distributions.

Should patches be deployed through e-mail, or should they be pushed to each client?

This is another good item for your evaluation checklist. Almost every patch management system allows IT managers to push patches in the LAN. In most cases, a patch management agent is needed to accomplish a push to remote systems or systems protected by a firewall.

Whats the average lag time between a vendor patch release and the availability of a "package"?

For most patch management systems (including those from Altiris Inc., BigFix Inc., Ecora Corp., Novadigm Inc., Shavlik Technologies LLC and St. Bernard Software Inc.), it takes a few days or weeks to do the necessary research on a patch. Obviously, high-profile patches get more rapid attention.

What do you think of using something like VMware to make a virtual test lab?

VMware is a good tool to use in a test lab. However, the most important thing is to have exact replicas of applications that are installed on your systems. Test patches against these exact replicas to get an accurate idea of the problems you might encounter after patching a system.

Is Unix or Oracle 9iAS covered in this discussion?

Several patch management vendors can support a variety of OSes, including some Unix platforms.

What about patches for network hardware (routers, firewalls and so on)?

Rendition Networks makes a product to manage router, firewall and switch configurations. Of course, the network hardware makers all make their own patch tools, too.

How can patch management systems determine if the patch has been installed properly?

Usually, patch compliance is determined by an inventory scan.

Wouldnt it be better to receive a reply from all units?

Good point. I think reports that show which systems havent reported in with the correct patch level would be useful.

What about the patch deployment through large-scale administrative tools, such as MS-SMS or LANDesk?

Using a patch management system to source and track patches, then employing a software distribution package to deploy them, is certainly a valid option, and one used by some of eWEEKs largest corporate partners.

A suggestion was made on how small companies could overcome testing without a lab by using the "guinea pig" approach. This makes sense for workstations. Any suggestions for server testing?

Get an old machine and make it a reference system.

In addition, its critical to study the tech notes about the patch, to ensure you understand the purpose and action of the patch.

Which is a better solution, the tools with or without agents?

Agents are required to reach systems that are protected by firewalls. Agents can also keep track of what patches are installed a little better than most agentless systems—however, agentless systems are very quick to install.

No agent on the client reduces maintenance costs for the patch management system. eWEEK Labs tests have shown that agentless systems are appropriate for most businesses.

But how do you patch servers when there are so many application dependencies? Do you do intensive testing?

Regression testing is the only way to understand the effect of a patch on business-critical applications.

Discuss This in the eWEEK Forum


 
 
 
 
 
 
 
 
 
 
 

Submit a Comment

Loading Comments...
 
Manage your Newsletters: Login   Register My Newsletters























 
 
 
 
 
 
 
 
 
 
 
Rocket Fuel