9 Replies Latest reply on Mar 26, 2018 7:04 AM by cwinning

    How to Automate the removal of old agents

    JasonBarnette Rookie

      Is there an easy way to automate the removal of old agents? We had a POC environment that agents were pushed out with. Now in production I am having issues with patching because some servers still have the old agent from the old environment, at least I think this is the reason.  The POC console has already been destroyed so I am unable to remove the old agents from there.

       

      I am currently using Ivanti Patch for windows servers Standard 9.3.0

       

      Message was edited by: Jason Barnette

        • 1. Re: How to Automate the removal of old agents
          cwinning CommunityTeam

          Hello,

           

          You could create a batch file with the following:  (this is specific to the 9.3.4510 agents)

          NET STOP "STAgent$Shavlik Protect"

          NET STOP "STDispatch$Shavlik Protect"

           

          REM Asset Engine

           

          MsiExec.exe /X{0892D31D-C262-479F-808B-225E185A6E18} /Q

           

          REM Patch Engine

           

          MsiExec.exe /X{60FBE511-E79A-40F2-A9CD-98AF7F6710D5} /Q

           

          REM Agent Framework

           

          MsiExec.exe /X{50EC6929-BDA4-4C21-A615-30B1E2CC5DBF} /Q

           

          pause

           

          You could attempt to push this batch file using the Custom Action feature:

           

          Furthermore, agents that are unable to check-in with the console will uninstall themselves after X number of days.  If you continue to use agents you could simply re-install the agents on these systems from the new console. If you choose to manage these system agentlessly, then you should be able to do so even if an old agent is installed on them.  The agent wouldn't interfere with agentless scans and deployments.

           

          What issues are you seeing?

           

          Thanks,

          Charles

          • 2. Re: How to Automate the removal of old agents
            JasonBarnette Rookie

            Hi Charles, Thanks for the response. I am relatively new to Protect so bare with me.

             

            First

            "Furthermore, agents that are unable to check-in with the console will uninstall themselves after X number of days"

            These agents have been on the machines for about 6 months now and have not removed themselves. I did check again and the POC server is still online but license is expired so they should not be checking in.

             

            2nd

            The exact issue is that when scheduling a deployment they get stuck in Scheduled from the console. This does not happen on every machine and I thought I narrowed it down to the boxes that I had installed an agent on during the POC. As a test I put on a template for a pre and post reboot just to see if Shavlik is able to communicate with the server and it does complete a pre reboot but nothing after. I can attach some logs if you would like but im not sure which one you will need. Any help would be appreciated.

             

            In the new environment everything is running agentless. 

            • 3. Re: How to Automate the removal of old agents
              cwinning CommunityTeam

              Hello Jason,

               

              1. The agents framework will only uninstall if it can't check-in to the console that installed it, even if the console has an expired license associated with it.  It could take up to 120 days from today if you shutdown/uninstall that console today.  Using the batch uninstall would be the quickest method of getting those removed.
              2. The agent wouldn't interfere with the agentless deployments, completely separate processes are used.  The good news is, we know the schedule isn't an issue since the target machines are performing the pre-reboot.  We could start by looking at the logs from C:\Windows\ProPatches\Logs.  It would give us insight on where the deployment is 'hanging'.  You could either zip and attach to this case or open a case with support so they can take a look at them.

              Possible issues:

              • Patch are not being copied to the target machine.
              • The target machine is unable to verify the digital signature of the patches due to an out of date root certificate.
              • A patch is hanging during the install.
              • Something is killing the deployment process.

               

              The logs should help.

               

              Thanks,

              Charles

              • 4. Re: How to Automate the removal of old agents
                JasonBarnette Rookie

                Thanks Charles,

                 

                I added the zip attachment to the first thread, I will start on the batch process to remove old agents. Appreciate all of your help thus far.

                • 5. Re: How to Automate the removal of old agents
                  cwinning CommunityTeam

                  Hello Jason,

                   

                  I do see a successful patch installs, many of them:

                   

                  The signature of the patch was verfified:

                  2018-03-23T13:46:24.0027400Z 2278 I Authenticode.cpp:134 Verifying signature of C:\Windows\ProPatches\Patches\windows6.1-kb4041678-x64.msu with CWinTrustVerifier

                   

                  The install started:

                  2018-03-23T13:46:32.4111939Z 2278 V UnScriptedInstallation.cpp:30 Executing (C:\Windows\ProPatches\Patches\windows6.1-kb4041678-x64.msu /quiet /norestart), nShow: true.

                   

                  A 3010 is a sucessful install, reboot required:

                  2018-03-23T13:47:17.4954829Z 2278 V ChildProcess.cpp:140 Process handle 00000540 returned '3010'.

                   

                  The remainder is updating the Tracker with the status, Installed Pending Reboot.

                  2018-03-23T13:47:17.4954829Z 2278 V DeployerImpl.cpp:113 Recorded 'PendingReboot' patch installation state in the registry.

                  2018-03-23T13:47:17.4954829Z 2278 V DeployerImpl.cpp:84 Instantiating a new CPostBootActionSequence

                  2018-03-23T13:47:17.4954829Z 2278 V DeployerImpl.cpp:138 Queued action update registry breadcrumb state to 99

                   

                  Patches are being deployed, a scan of these machines, after reboot, will verify this.

                   

                  The issue is, the target machine is unable to send the Deployment Tracker data back to the console machine.  It's not able to update any of the steps of deployment so it would look like the deployment is failing.

                  Sending data to 'https://GBLWPATCHP01.SEALEDAIR.CORP:3121/ST/Console/Deployment/Tracker/v92' failed: 12175.

                   

                  Verify port 3121 is enabled from the target to the console server.

                  The HTTP error 12175 is key here, it's possible there are articles out there with ideas on what to look at. Like verifying if you locked down SSL or TLS on your network.

                   

                  Thanks,

                  Charles

                  • 6. Re: How to Automate the removal of old agents
                    JasonBarnette Rookie

                    Hi Charles thanks again.

                     

                    The port 3121 is available from the target machine to the console.

                     

                    SSL and TLS settings are the same across the board so not sure why some boxes would work without an issue and others not. Does Shavlik use self signed certs? maybe the old POC box cert is stuck on the non working boxes? Again forgive my ignorance.

                    • 7. Re: How to Automate the removal of old agents
                      cwinning CommunityTeam

                      Hello,

                       

                      Certificate from the console would be updated when needed.  Maybe you could test removing an agent from one of the target machines and then see of the Deployment Tracker information updates in the next deployment to it.

                       

                      Another outside the box though is to install the agent on these systems from the new console, then uninstall them once they are installed.  You could use an Agent policy that doesn't have any tasks on it.  This would get the agents uninstalled and it would clean up any certificates on them too.  Maybe test this one 1 system?

                       

                      Thanks,

                      Charles

                      • 8. Re: How to Automate the removal of old agents
                        JasonBarnette Rookie

                        Hi Charles,

                         

                        So the agent deployment fails because of the same error. PingBack.cpp:63 Sending data to 'https://FQDNServername:3121/ST/Console/Deployment/Tracker/v92' failed: 12175

                         

                        Interestingly enough when i browse to the link I get an invalid cert page. I'm still leaning to a cert issue but not sure how to update it.

                         

                        • 9. Re: How to Automate the removal of old agents
                          cwinning CommunityTeam

                          Hello,

                           

                          The deployment aren't failing, the Deployment Tracker status communication from the target machine back to the console server is failing to update the Deployment Tracker.  The patches are installing, scan the target after it installs to confirm this.

                           

                          Did you remove an agent from one of these machines and deploy to it?  I highly suggest doing this to completely rule out the agent being an issue. I doubt this is the issue, the Deployment Tracker communication should good if port 3121 is open.  Something else is causing it to fail and the causes can be many.

                           

                          All the attempts to browse to the address used for the Deployment Tracker will fail.  I've seen various errors when trying to do so.  The communication uses certificate authentication for the Deployment Tracker so the error you see is interesting.  Was that using Google Chrome?  If yes, what does IE tell you?

                           

                          Some other notes:

                          The date and time of the target and console machine must match (same date, time within 5 minutes).

                          Locking down SSL or TLS will cause issues.