We've actually managed to reproduce the issue now internally using a customers' VM which is making the analysis and testing process easier. Sadly as I mentioned a few times, we were previously never successful in reproducing this issue within our test or production environment (baring in mind we have the same software installed on our work devices too, it's surprising we didn't encounter this ourselves).
We as Partner assume you as Producer have TEST vm:
* Every derivate (PRO/ENT/LTSC of W7/W8/W10 up to 1909)
* Every regional Language SET and Regional Layout
* In every possible setup of Microsoft Patchday at least 12 months back
* With or without software thats on the market
Is this a 10 man box who tests software for a billion stock Company?
Don't tell me that's not possible in a VM age.
@SWISS we have many test VMs of varying language packs, versions, etc. upon which we do ALOT of intensive testing before releasing software. Sadly we can't cover every single scenario that is out there.
Unfortunately this is not an issue we've been able to reproduce, despite many people trying.
So far I have one test system running both the October Update and Windows 10 Feature Update 1909 and believe it or not it appears to be working correctly. I'm going to update a second system that already has the October Update installed to 1909 and see how that goes.
Also should note that all of my test systems are physical, and all are completely up-to-date as far as drivers and BIOS are concerned.
Tested in my own system installing ENS 10.7
I was able to restart my system 3 times without the issue re-occurring and was feeling hopeful. Then i went into windows settings and I installed a couple Windows Updates that were pending. Upon finishing that process, restarted the OS and the issue re-occurred.
So, some time between when I posted about my Windows 10 1909 with ENS October Update test system working as expected and this morning it, not surprisingly, stopped working as expected. This system was managed by my ePO server. So I removed it from being managed by my ePO server, rebooted and now it is performing as expected. It has only been maybe 15 minutes or so, so we'll have to see how enduring this result it, but if it persists it will be the third test system I have that works as expected when it is not managed by ePO. This then means there is something goofy about the most recent versions of ENS being managed by ePO, or there is something goofy in my policies that ONLY affects ENS on Windows 10 1903 and later.
I've installed 1909 via the enablement package and whilst my PC was initially showing as working, it too has gone back to showing Defender is running and ENS is not. I suspect that the EICAR test would show ENS is really running but failing to report back to the WSC.
I was curious about that myself, so I tested this on my second 1909/October Update test system (managed by ePO) and Windows Defender blocked it, not ENS.
EDIT - Forget to mention, on the systems I have that ARE reporting properly, they also function correctly. When testing with the EICAR file on those systems ENS blocks the file, not Defender.
Hi all, I thought I would share the latest investigation status from our Engineering Team with you all: Microsoft have now confirmed that they have an issue with WSC.
From a McAfee perspective, we are trying to build in a workaround into the December Update from our side, to avoid our customers encountering this issue regardless of their issue.
More details will follow in the linked KB91830 at a later date.