3 Replies Latest reply on Dec 29, 2011 11:57 AM by Bill Robinson

    Best way to make Patching work with patch levels within 8.1.02

    Steven Wyns



      We're currently running BL 7.6 and investigating what it takes to upgrade to 8.1.02. We currently are using patch management with a few scripts on top. The scripts will in fact prepare analysis jobs with an includelist defining the current patch level.


      So each of these patch analysis jobs is for a patch level ( Patches november2011, Patches december2011, ...) This way we can make sure that the set of patches that was tested in Development is the set that is in fact deployed to production. This sometimes poses some trouble with superseded patches and new releases of patches but in general it works.


      Within 8.1.02 the patch mechanism is more intelligent. It seems to support more possibilities to organize the patching. But with more possibilities comes the process of choosing the correct path


      With the knowledge I possess right now I think I have two options:

      1) Start with a catalog that contains all Windows platforms that are used in here and on that catalog we can then create different smartgroups. The smartgroups would look like: "Includelist november2011", "Includelist december2011", ... And maybe some excludelists as well.

      Within the white paper about security patches I've noticed a warning about using the lists option within the analysis job. Relations between patches will not be honored. Which seems to frighten me a bit


      2) Create a new patch catalog for every patch level. This makes sure the patches that were downloaded in the beginning are the patches that we'll use. We can then skip the lists option in the analysis job an make use of the logic to detect superseding patches. But this has a side effect to: The Catalogs need some repository to download the patches to. If we duplicate the catalogs we will need different payload repositories because we want to make sure nothing is changed on the patches. That will surely need a lot of diskspace when more catalogs are created. Also the download will be done multiple times.


      Both options seem to be valid for me but the both have side effects as well. Are there users in here that have a comparable requirement and maybe wondered about these options as well? Or even tried one of the options?


      Any ideas, remarks, better solutions, do's, don'ts, ...

        • 1. Best way to make Patching work with patch levels within 8.1.02



          The list based patch analysis does give you a warning patch relation not being honored properly.  This is because the list based analysis completely depends on the input list being provided and will not take into account the other patches in the underlying catalog.

          If i understand you correctly, you want to analyze against your fixed list of patches but also want to get any new patches that might have superseded any patch in your list ? Right ?

          • 2. Best way to make Patching work with patch levels within 8.1.02
            Steven Wyns



            I indeed want to analyze against my list only. I don't want to download new ones or superseded ones. I want to make sure the level of patches I've tested in Development is the level of patches I'm installing in production. Surely the number of installed patches per machine will differ depending on the installed applications but every server has a Development and a Production one. So that should be covered.


            So if there are superseded patches for some patches in my list then they will be installed with the next level.


            The patches I'm worried about ar those that are in my list and for which a superseding patch is also included in my list.

            • 3. Re: Best way to make Patching work with patch levels within 8.1.02
              Bill Robinson

              Use a patch smart group to include the patches you want.  you can use a filter like ‘release_date’ or something like that to group your patches.


              w/ multiple catalogs I don’t think you are really using any more disk space than if you have a single catalog w/ a history of patches.

              1 of 1 people found this helpful