In the last couple of years, Microsoft has placed an extremely high emphasis on patch management for Microsoft products. Microsoft has been so vocal regarding patch management that it is easy to forget that some non-Microsoft products need to be patched too. Regrettably, you can't use Windows Update or Windows Server Update Service to patch non-Microsoft products. In this article, I will discuss what your options are when it comes to patching third-party software.
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
What needs to be patched?
The first step in designing a patching strategy for non-Microsoft products is to determine what needs to be patched. Unfortunately, every organization's patching needs are different because every organization uses a different set of applications. Not every software manufacturer releases patches for their products, but, generally speaking, the more complex or the more expensive an application is, the more likely it is that the manufacturer will release periodic updates to the product.
Half of the battle of keeping non-Microsoft applications up to date is just getting the patches. Traditionally, this has meant visiting the manufacturer's Web site from time to time and checking to see if any new patches are available. More and more applications are starting to automate this process for you though. For example, products such as Adobe Acrobat Reader, Pinnacle Studio and Jasc Paint Shop Pro either automatically check for updates or ask you if you want to check for updates every time you open the application. Hewlett-Packard Corp. has taken a slightly different approach. It has released a utility called HP Software Update. The utility runs in the background and periodically asks you if you want to check for software updates for HP products.
Deploying the updates
Even if every non-Microsoft application in your entire organization offered some sort of automatic patching mechanism like the ones I just talked about, relying on such mechanisms usually isn't practical. The reason is that unless your applications download and deploy patches in a completely automated fashion, you are at the mercy of the end user to keep workstations patched. Think about it for a moment… If a user sees a dialog box asking them if they want to check for updates, they could easily click No and there isn't a thing that you could do about it.
This might not seem like a huge deal since we aren't talking about patches for the operating system or for an extremely high-profile application such as Microsoft Office, but patching third-party applications is almost as important as patching Microsoft products. Patching these applications makes the applications more stable (less buggy) and often fixes security vulnerabilities.
Regardless of whether you manually download patches or your applications download patches for you, the trick is to make sure that the patches are deployed onto each workstation that needs them.
There are several ways you can pull this off. In some cases you might even be able to use a Group Policy setting to automatically deploy patches for you. If you open the Group Policy Editor and go to Computer Configuration | Software Settings | Software Installation, you have the option of assigning an application to the computers that the Group Policy applies to.
For more information:
Book excerpt: What is patch management?
At first, this might sound useless, but keep in mind that patches are usually bundled into an executable file, and Windows treats all executables as applications whether the file really is an application or it's just a patch to an existing application. There are a couple of issues, though, with using the Active Directory to assign patches.
One is that setting up Active Directory to deploy applications can be a little bit complicated if every computer on the network does not have a copy of the application. If only the marketing department, for example, uses a particular application, then you would have to create a special Group Policy Object that only applies to computers in the marketing department so that people who weren't using the application wouldn't receive the patch. Things can become particularly tricky if you have multiple versions of an application deployed.
Another issue that makes using Group Policy for patch deployment tricky is that the Group Policy method can only be used to deploy applications (or patches) that use specific file types. Specifically, you can install Windows Installer packages (.MSI files), Transform Files (.MST files) and patch files (.MSP files).
If your patch does not use one of those file formats, you can make your own MSI file, but Windows does not natively contain the necessary tools for you to create your own MSI files. Therefore, you will have to rely on a third party MSI creation tool. There are several good, free tools available such as MAKEMSI and WinInstall LE 2003.
Using Active Directory to deploy patches will work in a pinch, but it is far from being an ideal solution. A better solution (although not nearly as cost effective) is to use a workstation management product that deploys files to your workstations on an as-needed basis. I personally like Microsoft's Systems Management Server, but there are many other options available. Some of the more popular software deployment packages are:
As you can see, deploying patches for non-Microsoft applications can be challenging. However, if you know which applications need to be patched, and you have some good workstation management software in place, the task is manageable.
ABOUT THE AUTHOR:
Brien Posey is an eight-time Microsoft MVP with two decades of IT experience. Before becoming a freelance technical writer, Brien worked as a CIO for a national chain of hospitals and health care facilities. He has also served as a network administrator at some of the nation's largest insurance companies and for the Department of Defense at Fort Knox.