1 Reply Latest reply on Sep 17, 2014 10:05 AM by cwinning

    Pending rescan status

    Rookie

      Greetings.

       

      I've been experiencing what I'm guessing to be timeout issues with Shavlik Protect. I've had this issue for some time now and am finally fed up and looking for advice.

       

      We are using Shavlik Protect Advanced 9.1.0 Build: 4334, Windows Server 2008 R2 SP1 and SQL Server 2008 R2. Agentless patch management.

       

      This is what happens:

      Regardless of whether its a scheduled deployment or manual, after a server has patched and rebooted, the console reports back that it is pending rescan but only on servers that do not reside locally. This happens for all servers in Europe and Asia, running English Windows. If I deploy patches to a server in Europe first, and then a US server, the US server will be stuck in that "pending rescan" state like its queued up behind the European one. If I run the US one first, no issue. If I wait 24-48 hours, they will both eventually report back.

       

      Timeout settings are already set to the maximum of 300 and we have WAN Accelerators in place.

       

      If I watch STPatchAssessmentSrv.exe in task manager, after issuing a patch to a non local server, it doesn't move for long lengths of time. I've gone away and come back after an hour and sometimes the information moves, other times it does not.

      If I kill STPatchAssessmentSrv.exe and then rescan the local server, I'll get the results fast but that really defeats the purpose of working toward a more automated approach. Then there is the long wait time to scanning the non local servers again.

       

      I am looking for recommendations on how to approach this situation.

       

      Thank you.

        • 1. Re: Pending rescan status
          cwinning CommunityTeam

          Hello,

           

          "If I wait 24-48 hours, they will both eventually report back."

           

          That statement right there would indicate there is not timeout during the scan.  From previous slow scans issues I've dealt with throughout the years, latency, bandwidth and possibly the WAN Accelerator (Riverbed?) may all be causing you slow scans.

           

          On your console system run a ping -t against one of the target machine you are scanning.  A local network typically will have <1MS latency and most scans against machines on the LAN will take a 2-5 minutes.  You can see where latency of 20+ will cause scans to take a long time to complete.  The higher the latency you see from a ping, the longer you can expect the scan to take for Protect.  High latency makes a large impact on scans due to the fact that our scan engine uses thousands of separate remote connections for registry and file verification.


          First and foremost, we suggest installing agents on remote machines due to the bandwidth needed to scan a machine without and agent.  You can install a Protect agent on systems to avoid slow scanning issues caused by network latency. The agent will run the scan locally on the client system so it avoids all network traffic while scanning.

           

          Logically place additional Protect Console on remote site. If you have a large amount of clients located in a remote site, you can then scan those systems over a LAN connection rather than over a high latency WAN connection to avoid these problems.

           

          There is an option to change the number of simultaneous machines scanned during the scan process. To make this change you will need to create a custom Patch Scan Template. On the 'General' tab under General Settings you can use the slider bar to set the number of machines the scan will simultaneously run on.  Dragging the bar to a lower number may help improve scan speeds by reducing your network saturation. You will need to use your custom patch scan template to run a scan for this to take effect.


          I've seen where WAN Accelerators cause slower scans do to the number of remote connections used to scan machines without and agent.  My only thoughts on this is to make sure it is running correctly and maybe bypass for a scan test.


          Let me know what you see during the pint -t during a WAN scan.


          Thank you,

          Charles