6 Replies Latest reply on May 15, 2017 2:27 PM by phoffmann

    Patch History - False Positive Results?

    talk2neeraj2k7 Apprentice

      Hi Everyone,

       

      After patching my servers, when I use LANDesk query >> Security >> Patch History to see what patches got installed / failed on multiple servers, I see that many patches get fail to install however in reality most of the patches have got installed successfully (as I notice in "Security and Patch information" that there were many vulnerabilities were being detected prior to patching and after patching most of the vulnerability clears out).

       

      Does it happen due to reboot, meaning a patch is installing on the server and it requires a reboot to completely install and lets say I have disabled server reboots using 'Reboot Settings' and I handle the reboots manually after all the servers are patched.

      Is that the reason the patch shows as failed in 'Patch History' table as it did not get reboot and actually it does gets installed when I reboot my servers manually after the patching?

       

      So it means we cannot fully trust the 'failed' results shown in 'Patch History' table as whatever patches it shows as failed might have got successfully installed? As per my understanding it is the case, 'Patch History' table shows false positive results.

      Is there any way to figure out what patch 'really failed' or 'false failed'? I assume that 'Patch History' table records does not get update for 'false failed' meaning after patching and reboot completion it does not reflect the true picture to dictate 'look this patch we were assuming that it failed to install but now we can see that since the vulnerability got clear so it means associated patches that were previously shown as failed actually got successfully installed so let me update those records as success 'repair done' ?

       

      Is there any way to find out the correct results that what patches really got installed and what really got failed? May be through some other table that checks the whole stuff and keeps accurate records?

       

      Sorry for writing the whole long story.   Would appreciate your experience and thoughts on this.

       

      Thank you,

      Neeraj

        • 1. Re: Patch History - False Positive Results?
          Andy Harper Apprentice

          There are many and varied reasons why a patch may fail to install and be reported later as not required, not least patch supersession. It's useful practice to removed superseded patches from scanning. this will reduce the scan time and potential unnecessary client patch downloads and will also reduce the size of your patch repository (assuming you also select 'patch cleanup' in the Patch and Compliance 'download updates' settings). As you mentioned, rebooting can also change the state as pending operations may then be applied. With this in mind it's good practice to reboot before, patch and then reboot after if your maintenance window will allow. With patch reporting it is also easier to look forward to see what is still vulnerable rather than worry about what's been done as you will end up chasing your tail.

          1 of 1 people found this helpful
          • 2. Re: Patch History - False Positive Results?
            phoffmann SupportEmployee

            Yep - patch supersedence is the most likely factor here.

             

            A simple example:

             

            Say you're on 7-zip version 1.0 ... and you've recently scanned against vulnerabilities, you'd be vulnerable against (again - hypothetical) the following patches:

            - 7-zip version 2.0

            - 7-zip version 3.0

            ...

            - 7-zip version 15.0

            - 7-zip version 16.0

             

            ... all of this "is correct" because you're using a super-old version, and so ANY of the above versions would be applicable in patching it.

             

            HOWEVER ... if you install version 15.0 first (for instance), then installs for version 2 through 14 would be "failing" because you'd be trying to install an older version on to something that's already fixed.

             

            You get the same thing with Windows vulnerabilities.

             

            So it makes great sense to replace vulnerabilities / patches that have been superseded by newer things / "install only what you need" ... otherwise you'll end up inevitably installing something newer, then try to install something older as part of the "fix everything" job ... and while the patches will only get applied upon reboot, Windows will know "hey, this thing is already patched - no point in trying to install that old thing" and the result is a failure to install.

             

            There isn't a Windows status of "hey - that's not needed" as such.

             

            So - hopefully that clears that up. Patching and its related activities tend to require a fair bit of detail-sensitive lessons to be learned. It's all about such tiny details.

            1 of 1 people found this helpful
            • 3. Re: Patch History - False Positive Results?
              talk2neeraj2k7 Apprentice

              Thanks phoffmann, you made it easy to understand.

              • 5. Re: Patch History - False Positive Results?
                RobLent Apprentice

                As always a good explanation phoffmann

                 

                Is there a list of the Action Codes anywhere for Patch History?

                 

                I have 0,1,2,4,5,30,31,39,40,41,42,44 showing in the scanned results window.

                 

                What do they all mean?

                • 6. Re: Patch History - False Positive Results?
                  phoffmann SupportEmployee

                  RobLent - That's not too hard to figure out.

                   

                  I've not got a list set up, I just identify what I care about (or the folks I work with) and identify that.

                   

                  The basic steps for that can be found here -- Getting started with Patch Reporting (SQL, Tables & such) -- Example III.C covers that by means of "what patches ahve been installed". The descriptions on the actions can be matched easily enough .

                   

                  Hope that helps?