the last couple of years, Microsoft has placed an extremely high emphasis on patch management for Microsoft
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.
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.
Brien M. Posey, MCSE, is a Microsoft Most Valuable Professional for his work with Windows 2000 Server and IIS. He has served as CIO for a nationwide chain of hospitals and was once in charge of IT security for Fort Knox. As a freelance technical writer, he has written for Microsoft, TechTarget, CNET, ZDNet, MSD2D, Relevant Technologies and other technology companies. You can visit his personal website at www.brienposey.com.
This was first published in November 2005