1 Reply Latest reply on Nov 30, 2015 11:16 AM by LANDave

    How to deal with 401 return codes

    mmajeres Apprentice

      I understand that the 401 return code indicates that "Another instance of the agent is running."  I'm wondering how most people deal with it when doing a widespread distribution.  It's not unusual for me to see that code on 10% of large (1000+ endpoints) pushes.  Do most users just wait it out, and hope it resolves itself over time; manually connect to each machine and kill some processes; or some other resolution?

        • 1. Re: How to deal with 401 return codes
          LANDave SupportEmployee

          What is happening here could be a few things:

           

          Vulscan could be running at the time that you are trying to do a Software Distribution job.  Vulscan and Software Distribution sdclient.exe share the same mutex so they don't run at the same time.

           

          Also there could have been a job that didn't clean up properly...

           

          So definitely look for running SDCLIENT processes and running VULSCAN processes.

           

          If the Vulscan client is still running there may be an open dialog that hasn't been answered, or a scan is taking a long time.

           

          A vulscan that is still running will show a vulscan_PID_###.log file in the C:\ProgramData\LANDESK\log file in version 9.6, in version 9.5 this will be located in C:\Programdata\vulscan

           

          You can look in those logs to see what it is currently doing.  

           

          One of the causes of this could be the fact that WMI calls were introduced into 337 of our definitions and it significantly increased scan times for Vulscan and caused 100% CPU usage at times in TrustedInstaller.exe (A windows process).

           

          Our Patch Content team has removed the WMI calls from these 337 definitions and pending testing they will be released into content.   This should significantly speed up the scan time and CPU availability.  

           

          Check your schedules and see that Vulscan is not scheduled to run at the same time you plan your scheduled jobs.  I think you will see that a lot of users try to wait it out, but it is not guaranteed that those processes will clear out on their own.