5 Replies Latest reply on Jul 20, 2016 3:11 AM by phoffmann

    Cancel a policy based repair task

    Apprentice

      Hi Everyone,

       

      If I start a policy based repair task for patching lets say at 10 PM and assume that policy sync interval is 30 minutes for all the devices I am targeting using this repair task.

      At 10:40 PM I realized  that I don't want to patch, so I right click the task and cancel it, when I canceled the task almost all or some devices started running vulscan, of course after vulscan is finished they are going to be patched (repaired).

       

      So my questions is are they not going to patch, since I cancel the task? or they are going to be patched since by the time I canceled the task most of the devices already received  the policy (sync the policy).

      If they are going to patch then how can we stop them from doing so, do we need to manually login to all the devices those received the policy and kill the vulscan process on it? is it going to stop them, I am sure Yes.


      Cannot we somehow remotely kill the vulscan process on those devices instantly without login to each of them, to be specific these devices are communicating with LANDesk Core server through CSA (management gateway).

       

      Of course we can deliver the batch script using distribution to kill the vulscan process but that's going to take 30 minutes (my policy sync interval), by that time all will be partially or completely patched depending on the no. of patches they require.

       

      Please let me know your ideas / insights / working knowledge on this.

       

      Thank you,

        • 1. Re: Cancel a policy based repair task
          phoffmann SupportEmployee

          Bit odd scenario - I'd argue you should be putting safeguards of the "do I really want to patch all this?" variety into your processes, but OK.

           

          So - the "problem" that you're facing is that you can't run a 2nd policy with a "kill vulscan" command, for a variety of reasons:

          - SDCLIENT won't run when vulscan is already running and vice versa (to prevent multiple parallel installs killing each other).

          - Disabling the task on the Core will only stop the policy being served to any more devices - devices that are in the process of working it down, already downloaded the "do all of these things" job manifest & are working them down as you correct assumed.

           

          So - do you need to remote in on every device?

           

          Nope!

           

          SOLUTION:

          • Use a "Manage Scripts" approach - the old CUSTJOB-based scripts go directly through the CBA & don't invoke VULSCAN / SDCLIENT at all, so you get a "Local Admin" command-line on the side, effectively. You get much less information back (it's somewhat old tech), but it will do what you need it to.

           

          So if you want/need an "oh heck..." get-out-clause, you should be able to prepare a custom script with a "kill all instances of vulscan" (you might have 2+ instances running) - just be aware that you *WILL* risk breaking machines potentially (it depends on how well / badly the patches in question react) ...

           

          Though overall I'd expect it should be OK-ish, since you're killing off vulscan (prevent further patches to be installed), and any existing / running patch install should still complete.

           

           

          • As an alternative - you can also use Diagnostics to help you out (on a more individual device basis - useful if you've only got a small handful to cover).

          Diagnostics.jpg

           

          You'd use one request to view the process(-es) running on the machine & then pick up the relevant PID's and then send commands to kill off the relevant vulscan processes.

          Diagnostics_Terminate.jpg

           

          That should help you out?

          • 2. Re: Cancel a policy based repair task
            phoffmann SupportEmployee
            Of course we can deliver the batch script using distribution to kill the vulscan process but that's going to take 30 minutes (my policy sync interval), by that time all will be partially or completely patched depending on the no. of patches they require.

             

            Just to highlight this - there's 2 errors in that.

             

            1 - You can distribute policies "immediately" - that's what the "Policy Supported Push" is for. In essence, the Core pokes all the relevant clients & tells them to "Go check for policies".

             

            2 - As I explained above, SDCLIENT and Vulscan check for running instances of each other, so as not to cause problems (parallel installs can get ugly - especially if you're installing around/over the same thing). So SDCLIENT won't run while Vulscan is running & Vice versa.

             

            That's why I suggested the "Manage Script" / CUSTJOB-based route, as that doesn't care about either of those things. Hope that clarifies things .

            • 3. Re: Cancel a policy based repair task
              Apprentice

              Thanks for the detailed answers phoffmann !

               

              I have few doubts, in my case all the servers / desktop communicating to LANDesk core server through CSA (Management Gateway).

               

              So are these methods going to work through the CSA?

               

              1) Use a "Manage Scripts" approach - the old CUSTJOB-based scripts go directly through the CBA - will it work through the CSA? I assume it won't work.

              2) Use right click device >> Diagnostics options - will it work through the CSA? I assume it won't work.

               

              If I can not use above mentioned two methods because it is the limitation of CSA, is there any workaround to get it work?

               

              I guess currently CSA has more limitations to offer than advantages for an MSP. For an MSP how can I justify advantages of CSA? Is there any advantages at all?

               

              Thank you,

              Neeraj Kumar

              • 4. Re: Cancel a policy based repair task
                Apprentice

                Hi Paul,

                 

                Regarding - 1 - You can distribute policies "immediately" - that's what the "Policy Supported Push" is for. In essence, the Core pokes all the relevant clients & tells them to "Go check for policies".

                 

                I guess we can not distribute policies "immediately" even through "Policy Supported Push", as if clients are checking into the core server through the CSA, first Push is going to be failed, as with CSA we can not use Push, alright then it will serve the task as policy, but until clients those are coming through the CSA sync their policy (assume 30 minutes or 1 hour configured policy sync interval), they are not going to receive it, so we need to wait for policy sync to happen, so I assume there is no way to distribute policies "immediately"

                 

                Could you please explain a bit on it.

                • 5. Re: Cancel a policy based repair task
                  phoffmann SupportEmployee

                  Hmmm - "Manage scripts" may not work through the CSA (don't have one on-hand to test out at the moment) - but since it's Core-initiated, will be more tricky (since the CSA is more of a "Client can see the Core" model, rather than the other way around) at the best of times. So yes - inclined to agree that this won't work in your given scenario.

                   

                  Much in the same vein, a "Run Now" thing won't be possible, because the Core won't know where the clients are in the world (as this stuff relies on clients contacting the Core). So yes - you are correct - a "run now" function requires the Core to be able to touch the clients, which is not realistic in a CSA-based environment (as clients know where the Core is, not the other way around).

                   

                  So for that sort of situation, I'd suggest shoring up against any "oops" through process & education (i.e. - making sure people know that they need to be careful & making sure that what they're going to send out as a policy is what they INTEND to send out as a policy) first and foremost. There's only so much "waving a magic wand" that is possible .