3 Replies Latest reply on Jan 12, 2016 12:17 PM by rmetzger

    Disable Scan Features from Command Line

    shocko

      Guys, I'm writing quite a complicated update script for my server estate. it does the following:

       

      1. Checks for various missing security updates, hotfixes and various combinations of both
      2. Installs then and reboots where necessary then starts the installation f the next patch

       

      I find that when the following components are enabled it drastically adds to the time take to install:

       

      • on-access scanning
      • on-access protection

      Ideally I could use a command line tool or an API in my script (VBS/Powershell/DOS) to disable these features during the installation and r-enable thereafter. Is this possible? I'd rather not have to resort to eitherrof the following:

       

      • Manually opening the console and disabling these features
      • Moving the computer to an OU where another policy applied to disable them
        • 1. Re: Disable Scan Features from Command Line
          rmetzger

          shocko wrote:

           

          I find that when the following components are enabled it drastically adds to the time take to install:

           

          • on-access scanning
          • on-access protection

           

          Ideally I could use a command line tool or an API in my script (VBS/Powershell/DOS) to disable these features during the installation and re-enable thereafter. Is this possible? I'd rather not have to resort to either of the following:

           

          • Manually opening the console and disabling these features
          • Moving the computer to an OU where another policy applied to disable them

          Well, to be blunt, though possible, I do not wish to publish any means for disabling VSE from the command line. To do so would provide malware writers the exact info they need to bypass VSE.

           

          I have never found VSE with minimally changed, or standard configurations, causing performance issues with installation of patches. Your mileage may vary. For that I would recommend McAfee Profiler as a tool to identify what is causing the slowness. This may help identify a better strategy for maintaining security while improving performance.

           

          I might consider a review of this SNS Tip: Intel Security SNS ProTip for VSE: Solve Performance issues when the scan option "When Reading from Disk" is enabled

          A snippet:

           

          Making performance issues go away differs from actually solving them. You can relieve performance options by disabling the "When Reading from Disk" scan option, but it is not safe to leave the scanner in that configuration. There are usually better and more secure options such as assigning High and Low-Risk Process policies or creating exclusions that will allow you to keep the Read scan enabled. The following resources will help you to determine a better solution for your environment:

           

          Hopefully this will help with your performance issues.

          Let us know if this is Helpful.

          Ron Metzger

          • 2. Re: Disable Scan Features from Command Line
            shocko

            I appreciate the security concern. We implement a lot of scripting and have problems especially with OAP. Due to cryptolocker and other outbreaks we have been recommended to block running of various processes from the TEMP folders. This blocks things like Windows 2008 R2 Service Pack1 from installing so in order to avoid changing policies we have to temporarily disable OAP. Ideally, if i could script that it would eb one less step to worry about. I suppose I could link a policy that does all this and script the application of that policy instead.

            • 3. Re: Disable Scan Features from Command Line
              rmetzger

              Hi Shocko,

               

              So, this is not a Performance issue.

               

              Since this is the Second Tuesday of the Month, Microsoft is issuing patches today.

               

              "Moving the computer to an OU where another policy applied to disable them"

               

              Is a good strategy in ePO which does not have the limited %TEMP% restrictions. You can then move, temporarily, objects, like your 2008R2 servers, to this group. Then after the policy has changed (by issuing a wake call or after the ASCI completes), run your scripts. This is probably the safest means for applying the patches under a documented and controllable structure. This also gives you an opportunity to review the update logs and taking appropriate actions as needed.

               

              Just remember to move the updated systems back to their appropriate group once the logs indicate full success.

               

              Good luck,

              Ron Metzger