As a consultant offering software patching services, one of the biggest decisions you may have to make is whether or not to patch non-Microsoft products. On one hand, some of your customers probably have heterogeneous networks and therefore need to keep servers and workstations running non-Microsoft operating systems up-to-date. And even customers with a pure Windows network probably run some non-Microsoft applications. Being able to offer your customers patches for these non-Microsoft OSes or applications gives you an opportunity to make more money.
On the other hand, offering patches for non-Microsoft products opens a can of worms. There are many issues that you will have to deal with if you want to offer patch management services for non-Microsoft products. In this article, I will address many of these issues. My goal up is to get you thinking about what considerations you need to make before offering non-Microsoft patch services to your customers.
Perhaps the most important decision that you will make is which products you will offer patching services for. It just isn't practical to provide remote patching services for some products, and your customers need to know which products you will and will not patch.
As you narrow down the list of products you will support, it is also important to take into account builds and versions. This is to minimize the chances of any nasty surprises. For example, it isn't enough to tell customers that you offer patch management services for Microsoft Office. Otherwise, a customer with an old machine running version 1.0 of Microsoft Office will expect you to keep it patched. Thus, you need to be very clear about what versions you support.
The same concept holds true for non-Microsoft products. Not only do you need to look at version numbers, but when it comes to open source operating systems or applications you also need to take into account the publisher. Consider the Linux OS. Although Linux is available for free, there are commercial Linux vendors such as Red Hat. Most of the commercial Linux vendors actively look for bugs, create patches for those bugs, and run tests to make sure that the patches are reliable. Patches for other flavors of Linux might not even exist, or might not be reliable. If you want to offer patches for Linux, you need to be selective about which versions you intend to support.
So far I have explained why it is important to be selective about which applications you provide patching services for, and why it is important to specify versions or vendors. There are still, however, several other factors to consider when deciding which non-Microsoft products to offer patching services for.
One such consideration is how you will acquire the patches. Microsoft makes it very easy to get patches for their products. The Windows Update service downloads patches automatically. Most other companies don't offer this level of automation. You may find yourself visiting each vendor's Web site every day to find and download new patches. This isn't necessarily an overwhelming task, but you do need to be aware of what you're getting yourself into when you offer to patch a product.
Another consideration is whether or not your current patch management software is capable of applying patches for the software that you intend to support. For example, if your patch management software runs on a Windows server, is it capable of deploying a Linux patch?
Even if your patch management software fully supports a heterogeneous environment, there may be issues with the patch itself that would keep you from successfully deploying it to your customers. I have seen some patches that can not be applied without a product key. If a patch requires a product key, it will probably be impractical for you to distribute that patch to your customers.
One last issue to consider is how much faith you have in the company that created the patch. After all, when you patch a customer's system, you're taking a chance that the patch could break something. You therefore need to have a high level of confidence in the company that created the patch. You need to know that the patch is reliable, and that it's possible to roll back the patch if something should go wrong.
Ideally, you'll test patches before applying them to your customer's machines, but sometimes service level agreements and the time sensitive nature of patching makes testing impossible. For those you do test, there's always the chance that a patch that works fine on your system causes damage to a customer's system. It is therefore crucial to take into account reliability and the degree of difficulty involved in uninstalling a patch when deciding which products to offer patch management services for.
As you can see, offering patch management services for non-Microsoft products is not a decision to be taken lightly. There are a number of criteria that should be considered when deciding which products you want to offer patch management services for. Doing so now will save you frustration later.
About the author
Brien Posey is an award winning author who has written over 3,000 articles and written or contributed to 27 books. You can visit Brien's personal Web site at www.brienposey.com.
Dig deeper on Threat management and prevention