@meanoldmanning, I had never turned debugging back on... I was living with the double-AV, incorrect reporting issue...
It randomly changed to 397312, then randomly broke itself by changing back to 393232...
Previously, when I did have debug logging ON via policy (using the workaround I wrote about) it immediately set 397312, but then eventually switched back to 393232 (even with debug logging still on).
If I were McAfee, I'd:
Seems like a straightforward fix, but apparently not. (Though I concede I'm making many assumptions that McAfee engineering likely would have more insight into)...
@billmollerAh, OK. Yeah, basically the only thing that 'fixes' the incorrect reporting issue on my 4 test systems is to enable logging. Obviously that is not the 'solution' as far as I am concerned. And at this point I am concerned that enabling logging to achieve correct reporting is actually masking other potential issues
Something I hadn’t mentioned yet, on my system I only have 1 ENS listed in the WMI output... have never seen it list multiples for me.
Clearly there is something causing a lot of inconsistencies here.
That's interesting. All 4 that I have tested showed multiple entries until I ran the script to clear them out.
Tech reached out to me to gather logs today. Unfortunately due to time zone differences it will have to wait until Monday.
Yeh its strange... Haven't checked the other machines I've got with the issue, but appears that it doesn't really matter anyway
Fingers crossed a true fix will be found... Normally great start for our migration away from VSE.
Left my PC on over the weekend, productState now randomly back to 397312 while AV on-access still ON and... still... up to date...
Rebooting to see if ENS changes the productState to an incorrect value again...
Exactly as I suspected, there's about a 2-3 minute period of time after a reboot where WSC indicates it's "getting protection info..." and doesn't show any real status.
I assume this is when AV products check themselves and set WMI accordingly. That's now completed, and ENS has changed its product state back to 393232, a completely wrong productState. ENS (on-access can) is still ON, and certainly it didn't become our of date during the 3 minute reboot...
productState : 393232
timestamp : Mon, 14 Oct 2019 13:44:28 GMT
It's like... if ENS actually has an update (updates AMCore or maybe even DATs) then it properly sets to 397312...
Yesterday, at about that time indicated in the screenshot, is when WMI reports that the product state was set to 397312.
However, if the computer is rebooted, ENS has no clue what's going on with itself so sets productState back to 393232. What a nightmare...
I wound up having to collect logs using the MER tool on a test system with debug logging enable and disabled to upload to support.
As stated previously, my test systems still only report 'properly' if debug logging is enable. In that state I can reboot until the cows come home and it still reports properly. That still doesn't feel like an appropriate 'fix' though.
any updates on this? Or are we basically stuck with the October Update being the 'fix'?
Corporate Headquarters
6220 America Center Drive
San Jose, CA 95002 USA