4 Replies Latest reply on Feb 8, 2017 2:02 PM by talk2neeraj2k7

    Optimize Patching Performance

    Apprentice

      Hi Everyone,

       

      What are the available options in LDMS 2016.SP3 to optimize (increase) the speed of patching, I have noticed that if a server is missing lots of patches it takes lot of time to install all the patches and complete the patching while on the other hand if I apply all those patches by manually running windows updates it takes very less time comparatively,  (Downloading of patches is not an issue as we pre-cache patches one day before patching) I am also aware that LANDesk does lots of checks while scanning and applying applicable patches like checking presence of files, their version information, looking into registry keys etc while windows updates only checks for presence of files. Still I think LANDesk takes lot more time than Windows updates while applying same no. and sort of patches. e.g. To apply 200 patches Windows updates takes around 2 to 3 hours while LANDesk takes 5 to 8 hours.

       

      I see only one relevant setting: Patch-only settings >> CPU utilization when scanning, I have not tested it yet, is it the only setting to optimize patching performance? I understand that there may be lot of factors involve like resources of Core Server (CPU, memory), I have decent processor and 8 GB RAM in my core server with 900 nodes at present. I assume that should be sufficient?

       

      Any thoughts to optimize patching?

      Capture.JPG

      Thank you,

      Neeraj

        • 1. Re: Optimize Patching Performance
          phoffmann SupportEmployee

          There's a few things by and large that you can do to help yourself here.

           

          1 - you disable superseded patches/vulnerabilities.

          This not only reduces scanning times, but also reduces the # of patches to be installed on to a 'new' machine DRASTICALLY.

           

          2 - You can crank up CPU utilisation to the max!

          We generally expect to run in a "play nice & be respectful" mode, so as not to stress the system. This is PRIMARILY only relevant to the Vulnerability *SCANNING* side of things.

           

          If you're patching Windows, you'll end up waiting on WUSA (Windows Update Service ... something - application?) to do its thing & actually apply the patches, which can take a *LONG* time (especially with .NET stuff for instance).

           

          3 - You can enable UI

          This is related to point # 2 above -- if the GUI is enabled to be shown, we'll use a whole CPU for the vulnerability *SCANNER*. This won't help with patching itself (because you're waiting on WUSA), but for vulnerability SCANNING, that can make a difference.

           

          The expectation / rationale is that "if you're enabling the GUI, you're likely to be trying to troubleshoot something - so we'll run as fast as we can to get you there".

           

          4 - You can install only the patches that are ACTUALLY NEEDED.

          This is related to point # 1 above. In the vulnerability view of a / several devices, you have this button:

          Hide_Replaced_Vuls.jpg

           

          If you've not disabled superseded vulnerabilities, you can do this on a "per selection" basis, so that we hide the irrelevant stuff.

           

          Having that list of "the minimum applicable stuff", you can then just repair that selection & have a much reduced set of patches that you need to install. However, the best way to do it is to control it via content & making sure you've got a rule set up that replaces superseded content as there's little point in scanning for that old stuff unless there's specific scenarios where you have to ignore that rule (for instance, you can't go to a newer version of .NET because of some in-house app restriction as an example).

           

          ... so - to summarise:

           

          • From the LANDesk side of things - you'll do yourself a favour by disabling superseded content. That'll reduce the number of patches to be installed & reduce scanning times.
          • From a Windows side of things (with WUSA specifically) ... not really much of anything that can be done. It'll take as long as it'll take (and that's beyond our control).
          • The CPU utilisation bar you've found is primarily related to vulnerability *SCANNING* ... not patching.
          2 of 2 people found this helpful
          • 2. Re: Optimize Patching Performance
            Apprentice

            Thanks phoffmann, Appreciate your detailed write-up and very helpful points to consider and would help me to speed up the patching performance.

            On a side note, I have one doubt can I also follow and try to do this as well (on my own risk) How to speed up patching by disabling creation of restore points per each single update

            Now doubt is how can I see system restore points created due to patching on Windows Server 2008 R2 and 2012 R2, It seems System Restore feature is only available on desktop OS (Win 7, 8, 10).

            Does the mentioned article also applies to Server Operating Systems? If yes, how can I verify restores, lets say I would like to delete them manually on the server.

            • 3. Re: Optimize Patching Performance
              phoffmann SupportEmployee

              I don't think Server OS'es get restore points.

               

              I suspect that Microsoft would generally expect you to have "an actual full / incremental backup solution in place regularly" for servers anyway.

               

              Restore points are by and large just a to try & have home users get themselves hopefully unstuck when they did something they shouldn't have.

              1 of 1 people found this helpful
              • 4. Re: Optimize Patching Performance
                Apprentice

                Thanks phoffmann, Hmm, so we can conclude that How to speed up patching by disabling creation of restore points per each single update (article only applied to Microsoft Desktops OS's)

                 

                Appreciate your help, Thanks Paul!

                 

                Thank you,

                Neeraj