Here's my clean install system. It was rebooted after using the removal tool, rebooted after clean installing the October update and rebooted a couple times since. Like I reported yesterday, for a brief period a couple hours after installing the October update package it suddenly showed ENS was running but then changed its state again to WD running after a reboot and hasn't reported properly since.
As others have stated, disabling Windows Defender isn't an option. WD is supposed to recognize ENS is installed and enabled and allow it to be the primary and only running antimalware system
This is the clean install machine. All 3 of the test laptop turn out the same result. Note the timestamp on the first ENS instance listed.
@meanoldmanning, your About looks almost identical to mine (versions of platform, TP, amcore, dats, etc) (I'm not running firewall or web control)
From your WMI powershell output, it looks like you also have duplicate ENS providers now... Good times... However, on yours, the "newer" ENS provider registration (10/9) has the "older" productState (393232). If WSC/WDA does any kind of querying of WMI, by date descending (to get the latest), this could be your issue (again, many assumptions on my part).
On mine, both duplicate entries have productState 397312.
If you're feeling brave, I'd run the VB script located here, Delete AntiVirusProduct WMI - Clear the anti-virus WMI class from an elevated command prompt (which I have personally run before), then reboot, then... wait (maybe 3 minutes?)... while Microsoft and McAfee re-register themselves (WSC seems to take a bit to get AV status), then re-run the get-wmiobject powershell command again.
So, here's something fun and should not have to be the acceptable 'solution'. I had NOT enabled debug logging on the test laptops because, you know, that shouldn't be how this gets fixes. I decided to assign a policy to the clean install computer that enabled logging and after a reboot it reports correctly - for now. We'll see how long that last because the laptop I use daily also has debug logging enabled and does NOT report correctly (update install)
When I had debugging on before the October update release, it changed the productState to 397312, so appeared to work (see my posts re: workaround), however, after a random daily update (perhaps AMCore) the productState returned to 343232 which reintroduced the issue.
I also noticed, during "clean install" testing, the Endpoint Product Removal Tool does not delete errant/old McAfee AV providers, which is when I ran that VBScript.
@chealey, is there a chart or link you could post that indicates how to decode productState? i.e. what's 397312 vs. 343232?