6 Replies Latest reply on Jun 6, 2012 11:15 AM by jguenrdc

    Bad start McAfeee Enterprise 8.8

      I have installed McAfee Enterprise 8.8, engine 5400.1158, DAT version 6669.0000 on a Windows 2003 server R2, SP2.

       

      It seems impoosible to stop the McAfee shield service although I am logeed in as Administrator.  Is there any way to fix this that does not involve hours of trying this and that, rebooting the server etc?  How else can the virus definitions updated?

       

      Another problem is that when an initial scan was started Mcafee was taking forever as a couple of log files in a folder were being constantly updated byt another process.  I find it impossible to terminiate this on-access scan, even when repeatledly clicking, 'close' on the process panel.

       

      Also having set up a scheduled scan that excluses the folder in which these files are placed, it seems impossible to get this scan to run.  Why?

        • 1. Re: Bad start McAfeee Enterprise 8.8
          Troja

          Hi Arpo,

          are you using the default configuration?

          Regards,

          Thorsten

          • 2. Re: Bad start McAfeee Enterprise 8.8
            Troja

            Hi Arpo,

            also take a look to this thread defining low risk processes and excluions.

             

            https://community.mcafee.com/message/228172#228172

             

            Regards,

            Thorsten

            1 of 1 people found this helpful
            • 3. Re: Bad start McAfeee Enterprise 8.8

              You don't need to stop the McShield service to update the virus definitions.  If VSE was installed with the defaults, it will update automatically each day (at around 5 PM I think).  Go to the McAfee folder in the start menu and run the VirusScan console.  Look at the AutoUpdate task to see the settings.  If you want to manually update the virus definitions, just run that task.

              1 of 1 people found this helpful
              • 4. Re: Bad start McAfeee Enterprise 8.8

                Thanks for the replies, the AV is runing on a stand-alone legacy server the has no connection to the outside world.  Also simply putting a folder (and sub-folders) into the exclusion list does not seem to make any difference, the AV just cylcles around files in a folder because the contents of the log files are constantly being changed, meaning that the AV never progresses to all the other fiels that require scanning.

                • 5. Re: Bad start McAfeee Enterprise 8.8
                  Troja

                  Hi Arpo,

                  when you take a look at the scanning statistics is there any hint if the files are scanned or not??

                  Btw, you can also define Low Risk Processes for the processes which are writing the LOG Files.

                   

                  Neither you can use the VSE Profiler Tool to monitor what is going on. After changing the settings you can run the Profiler again. Both results can be compared to see the changes.

                   

                  Which software is running on this server??

                   

                  If there is any monitoring software which is using Java the Scriptscan function can also result into performance problems.

                   

                  Cheers,

                  Thorsten

                  • 6. Re: Bad start McAfeee Enterprise 8.8

                    Still no need to stop McAfee processes to update DATs.  Download the DAT or SuperDAT (definitions plus engine) from here http://www.mcafee.com/apps/downloads/security-updates/security-updates.aspx on another computer that does have internet access, copy it to the server in question, and run it.

                     

                    Not sure why the exclusions wouldn't work, did you try E:\Log Folder\*.log? (E is whatever drive letter is correct, Log Folder is the entire path to where the logs are, replace log in "*.log" with whatever extension the log files have).  Make sure to set the exclusion in both the On-Demand and On-Access scan.

                     

                    Perhaps writing to the log files is just using so much time accessing the hard drive that the file I/O system can't keep up with both the log file requests and the On-Demand scan requests?