[Edit: 7/24/15, added Windows Action Center as a means for identifying AV is disabled]
The purpose of this blog is to inform the administrator or person charged with answering the question "Why is McAfee [VirusScan Enterprise] disabled?"
To answer this question, you must first ask another question:
How do you know the scanner is disabled?
Variants of this question include, "Where are you looking to see the scanner is disabled?" or "Why do you think the scanner is disabled?".
The response to this question is key, and unlocks the appropriate series of follow-up actions.
Response: Eicar is not detected
Eicar is not detected
This is the most reliable test. If you can put the test file virus (eicar.com) into a folder and double-click it without anything happening to the file, then you can say with high confidence that the scanner is disabled (or you have a really poor configuration).
Try not to overly complicate this test. Just save the file from www.eicar.org, and try to execute it.
FYI, I have experienced slowness when trying to access this site, so, I think I might put a copy of the eicar test string below with instruction on copying it and saving it to a file.
Your next step is to find out why the scanner is disabled, starting with looking at the Event logs.
However, if something does happen to the file, even if it is not what you were expecting, then it tells you the problem is slightly different than "the scanner is disabled". Maybe it's a much less severe problem, like "the product thinks it's disabled but is actually enabled and stopping malware".
The System Event log indicates the McShield service stopped (or terminated).
Event ID 7036 is a generic Windows system event for describing whether a service has started or stopped.
If you see a recent event id 7036 that says "The McAfee McShield service entered the stopped state" and no more recent activity to say the McAfee McShield service has entered the running state, then there's your problem .
This event is indicative of an entity stopping our scanner service. Stopping our scanner service is only possible if a) Access Protection has been disabled or the option "Prevent stopping of McAfee services" has been disabled, and b) You have adequate permissions to control services. The solution is simple; don't do (a) or don't provide users (b).
For any environment, if Access Protection has been disabled or if the "Prevent stopping of McAfee services" setting is disabled, then you have no guarantee your system (or VirusScan at least) is safe. You essentially provide malware a backdoor for neutralizing the scanner. Consider these settings critical. If you're not using Access Protection or you allow our services to be stopped, you must have some really good mitigation in place to reduce the risk... I hope.
The Application Event Log indicates a McLogEvent source with an Event ID higher than 5000
One of the most helpful troubleshooting spots for determining why the scanner is disabled. The product will write an event here, using an ID higher than 5000, to indicate a problem when loading the scanner.
For a complete list of events: https://kc.mcafee.com/corporate/index?page=content&id=KB52417
Most commonly seen events in that range are -
5051, Scanner experienced a fatal timeout; the scanner will automatically restart nowadays but in older versions it did not.
5004, Scanner is unable to communicate with our file-system filter driver. Usually caused by 3rd party filter drivers that do not play nicely with Antivirus software.
5022, The scan engine failed to load for reasons known to the scan engine. The actual cause might require a little digging but is most often due to the DAT files being corrupt or out-of-sync or missing.
The next steps will be determined by the event, because the event gives you the lead necessary for rectifying the issue.
The V shield icon has a crossed out symbol over it
You should perform the Eicar test. If it fails then move on to reviewing the Event logs.
If you've already done the earlier tests and inspected the Event logs and everything looks healthy, then you know this "disabled" status is bogus.
There are scenarios or reasons for when the product is unable to communicate with the scanner, and consequently it assumes the worst by showing a disabled status or reporting a disabled status to ePolicy Orchestrator.
This can occur on startup. The scanner is initializing, loading the scan engine which is reading the DAT files into memory, and those DAT files are not small - it takes time. However, it is a separate component that displays the status of the scanner via the shield icon and that separate component is asking "Hey! Are you started yet!?"... to which the scanner replies "No"... but eventually the scanner finishes loading and begins scanning. But the other component has already checked-in and got its answer.
VSE 8.8 Patch 5 addresses this problem.
Should the symptom continue even after applying Patch 5, you have an issue worth reporting to Support so we can figure out what's going on.
The VirusScan console has a crossed out symbol over it
The M shield icon has a "i" on it, and upon inspection it says "Issue - On-Access Scan disabled"
The Windows Action Center reports the AV solution is disabled
The ePO reports for On Access Scanner show for this system (or systems) it is disabled
See "The V shield icon has a crossed out symbol over it" before continuing...because that section explains a known cause that is fixed in Patch 5. And it advises to contact Support if the icon is showing a crossed out symbol still.
So what we're talking about here now is the fact that only ePO is reporting the scanner as disabled, whereas everything checked so far on the client appears OK. Read on!
ePO gets its data from the McAfee Agent.
The McAfee Agent gets data about installed products from those installed products.
Each product provides a Plugin for the purpose of interacting with the Agent - the plugin retrieves property information for the Agent when the Agent is performing property collection; the plugin enforces policy for the product when the Agent is performing policy enforcement. Simple right?
Well, if ePO is saying OAS is disabled then we have to back track the communication lines to see where that data came from. There are shortcuts one might try to take, but if you were to follow the chain backwards you would have to inspect:
At the ePO server, review the ePO server log when properties for the affected client were being processed, to make sure there are no errors.
At the affected client, review the LastProps.xml file. This is what the Agent created after collecting properties from the point product(s). The property value of interest is:
<Section name="On-Access General">
1 is the expected value, because we established earlier that the client's scanner is healthy and shows as enabled.
A "1" here means a problem occurred when ePO received the information such that it interpreted the value as "0". Enable debug logging at the ePO server and revisit the ePO server logs.
A "0" here means a problem occurred for the Plugin. There is some criteria not being met, that despite all visible checks on the client where it appears healthy, something less visible is causing the validation by the Plugin to conclude "disabled". Keep reading...
Hotfix 820636 is to blame
We released a hotfix that installed on top of Patch 1, Patch 2, and Patch 3. The code was included in Patch 4 and beyond.
The purpose of this hotfix is to provide more accuracy to ePO customers when showing the state of the On Access Scanner. With patch 4 we also provided a report that can be run to display this information.
Prior to the code change, the status check was rudimentary: "Is the service running, Yes/No", which is not an accurate reflection of the scanner being enabled or disabled. Now we validate the following:
- Is the McShield service running (MCSHIELD.EXE)?
- Does the Scanner believe it is running?
- Is the reporting service running (MFEANN.EXE)?
- Does the product believe the Scanner is running?
All these must be answered positively in order for the Plugin to advise bEnabled=1 when collecting this property information for the Agent.
One scenario where everything on the client looks healthy, but ePO is being told "disabled" will be because MFEANN.EXE is not a running process. It may have crashed or its dependent parent service, McTaskManager, may have been stopped. If either is true, therein is the cause for the reporting to ePO as bEnabled=0. The remedy requires finding out why that process is not running.
Another scenario, and this has been cropping up more lately, is that later versions of the McAfee Agent are doing a Property Collection immediately on startup. And on startup, guess what? The scanner is still starting. So when the Agent says "VSE, are you enabled?" then VSE's plugin can only respond with "Not enabled" at that point in time. The Property Collection needs to occur post startup, or a second collection needs to occur.
And that should cover every plausible scenario...
Copy the shown text (yes, it's meant to look a bit weird) and paste it into Notepad. Change your Notepad "Save as type" field to "All Files (*.*)" and type the name Eicar.COM, then Save it.
Don't use Wordpad, or Word, or any other kind of fanciful text editor that likes to pretty things up for you (because they do that by cushioning your file data with other meta data and formatting instructions, any of which changes the file and it will no longer be a valid Eicar String = no detection).