4 Replies Latest reply on Sep 19, 2018 3:25 PM by bdwest

    Patching "Repair" Task slower than alternatives?

    bdwest Apprentice

      In "autofix patches for specific scope," cwarren says, "Don't use repair tasks for a method of patching. It is horribly slow and inefficient."  I thought I had heard this same advice elsewhere.  I thought it had something to do with the way that the core server handled things, that a Repair would burden the core server more than other patching mechanisms would.  And so, I never tried a Repair Task.  I avoided them, thought someone (wish I could tell you who) said it was an outdated technology from an earlier version of LDMS.


      So recently a co-worker of mine and I started re-evaluating our patching process.  She and I separately called Ivanti, and the advice we got both times was that the Repair Task was a fine solution.  Repair and Autofix both use the same vulscan patching engine; Repair just tells the systems to do it now, while Autofix (at least by default) waits for the systems to check in before it tells them to scan for and install patches. So when (as we do in some situations) we select a group of systems, tell them to do a patch scan with an autofix-enabled agent setting, that's using exactly the same underlying mechanism (vulscan) as running a Repair task.  The only difference is that a Repair task has a presumably shorter list of patches (either manually selected in the moment or put into a custom group) to hand off to vulscan than Autofix does.  So by that logic, a Repair task should actually go more quickly than an Autofix task.


      So, for cwarren and any others who have given the advice that Repair tasks are slower and less efficient, what did you mean?  What am I missing in my understanding here?


      Thanks for your help.

        • 1. Re: Patching "Repair" Task slower than alternatives?
          cwarren SupportEmployee

          Repair tasks are slower and inefficient. If you are talking just at the client level, you are correct, there is not much difference. The big difference is at the core level and the scheduled task level.

          (this is all somewhat dependent on what version you are running as well, as this process is being updated)

          Repair tasks use a process called custjob, that was in use 9.5 and prior for all scheduled tasks. In 9.6 software distribution was updated to no longer use this. However repair tasks still do.

          If you are comparing running a few patches against a few machines (less than 40) there won't be a huge difference depending on how busy the core is.

          Custjob can only target 40 machines at a time, and has to wait for them to finish before moving on. This is where it is a lot slower. If you are patching an enterprise environment, or even a fairly small environment, this will quickly show how slow it can be.


          Have you compared the method I described in the post you reference? Against a large group of machines?


          You compare a repair task to a normal full scan with autofix, which is not a fair comparison either. The full scan is going to scan for all patches you have enabled, either by group or by type depending on your setting.

          The process I outlined does the same as repair task and limits the patches to just the ones you want to repair, so it is only scanning against that small subset of patches, and can be targeted to hundreds if not thousands of machines without overly burdening the core.

          Try running my process against 10,000 machines, then do the same for a repair task, tell me the results.


          Here is a simple analogy.

          My process.

          I send you an email. I wait for you to read the email and send me a response.


          Repair task.

          I call you. I wait for you to answer. You answer and I read the email to you. I verify that you understood the email I just read to you.


          Now, I have a mass email. I send it to 10,000 people. They read it and respond they got it.

          Or, I can do a conference call, but I can only have 40 people on the call at a time. I read them the email, then get the next 40 on the call. (actually when one drops another can get in, but you get the idea.)


          That is the difference in the processes.

          Reading the email takes the same amount of time if you do it, or I do it, but the delivery and how much work I have to do is vastly different.

          2 of 2 people found this helpful
          • 2. Re: Patching "Repair" Task slower than alternatives?
            bdwest Apprentice

            Thank you so much for giving the details that I couldn't remember about what the difference is.  Part of the problem as I was researching this is that the word "repair" is used informally with a range of meanings on the forums here.  So I couldn't find any details about what turns out to be the "custjob" process.


            We actually did use your process (or some similar variation of it) for the first 8-10 months or so of our LDMS 2016.3 implementation.  But I had come to the conclusion along the way (I'm fine with being proven wrong) that our ultimate goal should be to patch all systems with Autofix.  And indeed, at the end my custom patch group had 418 patches in it.  My hope was that any server or workstation that had been offline for any period of time could get completely up to speed without any additional steps but making sure that an autofix-enabled scan was run on it.  As the custom patch group got bigger and bigger (even with removing the superseded patches), I thought it made more sense to switch to autofix for everything.


            But recently we were challenged by people who used to handle patching on our network.  They pointed out that when we ran WSUS, we were able to use GPOs to set systems to scan and then download in advance the files needed, then when the maintenance window or other opportunity came, it could immediately take off and run those patch installer files.  But with LDMS 2016.3, either it downloads the installers it needs when you run the "real" scan (during maintenance time, for instance), or else if you run a pre-caching Repair task it will pre-cache ALL of the installer files for the custom patch group you're pointing to, including those that that particular system doesn't need.  When I asked Ivanti tech support today about this, they said there's NO way that LDMS/EPM can pre-cache Only the files that that machine needs.


            But in general we were challenged to make the whole patching process much faster than it now is.  That's the ultimate goal.  To hear Ivanti tech support tell it, using the Repair task gives the same results as any other approach.  Your description of how custjob works helps me see that that's not the way to go.

            • 3. Re: Patching "Repair" Task slower than alternatives?
              bdwest Apprentice

              So, in your opinion cwarren, what is a "best practice" strategy to cover both newly-released patches and systems that have been offline for a while and need to get caught up on patching, including old patches (and other common edge cases I may be forgetting)?  I can't imagine that it makes sense to keep adding new patches to your custom patch group and end up putting all of your approved patches in that group. But if you just use your custom patch group to push out the most recent patches, how do you make sure that old patches are getting deployed where they're needed (for instance, someone adds a newer version of .Net Framework to a system and it suddenly needs all of those patches)?

              • 4. Re: Patching "Repair" Task slower than alternatives?
                bdwest Apprentice

                And I know that every implementation has to find their own "best" for their own circumstances.  I'm just looking for some guidelines from anyone reading this given the points I've focused on in my question.