Gulf Breeze Patch Management Procedures v1.2

Our Patch Management solution is an enhancement to the design presented in IBM Field Guide Distributing Microsoft Hotfixes Using IBM Tivoli Configuration Manager, version 1.4.

The Field Guide provides two generic scripts as well as documentation on how a customer may implement their own patch mgmt solution. IBM does not have an out-of-the-box plug-in-play solution for Patch Management using the Configuration Manager product. The customer must build the solution, themselves. Gulf Breeze consultants build the solution for you and can add the enhancements listed below as well as address your custom needs.

• Automatic build of software package profiles from Microsoft hotfix executables.

• Automatic distribution of hotfix software package profiles and installation of hotfixes.

• Unique creation of software packages for a hotfix across different Windows Operating System types.

• Argument files to modify the way the hotfix is installed. For example, add an arguments file for a hotfix executable to specify not to store backup files for future hotfix unistalls.

• Inventory script to collect the names of hotfixes installed on each machine scanned.

• Inventory table to store hotfix specific data.

• Automatic build of missing hotfix queries used to only deliver to machines that do not already have the hotfix installed (determined by an inventory scan).

• Only delivers to Profile Manager Subscribers - all machines in the customer's world that should be subject to automated hotfix distributions that do not already have the hotfix (cross-referenced with the missing hotfix queries).

• Applies CM_Status check only deliver to machines that have not already received the hotfix from a software distribution. Note: this is a configurable option. Another choice is to force the distribution which will deliver the hotfix even if it has already been installed with software distribution.

Enhancements:

• Automatically load all depots upon automatic software package builds. If TEC is implemented at your site, automated monitoring of Hotfix software package load failures will be configured to generate a TEC event. This helps IT staff be pro-active in making sure the loads are successful so that the distributions can occur from the depots (rather than the source host). If a Hotfix software package depot load is in progress, then the mdist percentage complete value is used to gauge whether or not to automatically deliver the hotfix. The default is not to automatically deliver the hotfix until the load is 80% complete (percentage is configurable).

• Two classifications for each hotfix build; Non-critical & Critical. Non-critical software packages wait for the user to reboot. Critical software packages pop-up a user notification message directly after the install if a reboot is required and a user is logged on. With Critical, if there are no users logged on then the reboot happens immediately. In addition, with Critical, if a popup is presented there is a count down of minutes until reboot (the value for and the notification message are tailored to the customer's corporate requirements). If the user acknowledges the message before the countdown expires, the reboot will happen immediately.

• Three classifications of automatic distribution; development, test, and production. Initially set the distribution type during the software package build. However, it is easy to change the distribution type by dragging and dropping the software package between DEV, TEST, and PROD profile managers. If the software package is in DEV, it will not be automatically distributed. If it is in TEST or PROD it will be automatically distributed. The difference between TEST and PROD is the set of subscribers. TEST profile managers may contain a set of TEST machines as subscribers.

• Security measures to separate server class machines from PCs. In this way, the server team can be assured that Hotfixes meant for PCs won't be accidentally delivered to servers. If this enhancement is desired, it will require the customer to separate their windows servers and PCs into separate policy regions through linking.

• Software Package templates include the ability to remove the hotfix.

• The arguments file used to modify hotfix executable install flags can also be used to modify remove flags.

• Automatic build can be initiated from a scheduled job or initiated directly from execution of the job by a Tivoli Administrator.

• Automatic build of Queries by specific OS type to simplify reporting and subscription used to determine which machines are missing the hotfix based on OS type (and overall).

• Additional custom built hotfix and service pack related queries to report status of hotfix install completion, troubleshoot hotfix distributions, report on machines scanned in the last 30 days, last 30-60 days, last 60-90 days.

• Query to spread distribution affect

This is a query based on a customer specificalgorithm defined to deliver hotfixes to a subset of production machinesthroughout the day rather than push to all at once. In this way, no onebusiness unit is likely to have the hotfix applied to all of their machines atonce.

Note: Like the IBM FieldGuide design, the Gulf Breeze design requires the customer to choose and downloadapplicable hotfixes from the Microsoft web site. The customer places the hotfixexecutables in a special hotfix uploads directory, which when checked by thePatch Management solution will kick off an automatic software package build.

You can find the procedures here