How to check whether Windows Defender is disabled after installing Endpoint Security Threat Prevention
The clients of the customer having the effrct use following ISO:
Something interesting I've found while trying to collect additional logs for support... I can't reproduce the error while ENS is set for debug logging & full access to client interface.
Still need to test which of these 2 setting makes the diffedence (or both?).
Ah so it's 4 people (CUSTOMERS) working now for Mcafee to solve their product bug?
What's that called social support? How about social pricing?
We have found the PART which makes it:
It's the AMSI Option.
All we know at 14:28 O'Clock 09.09.2019
* ISO: SW_DVD5_WIN_ENT_LTSC_2019_64-bit_German_MLF_X21-96437.ISO
* Fresh install from ISO ESX 6.5, E1000, No VMWARE Tool, Domain JOINED, NO GPO, NO other soft
* OK >Windows Defender Services UP
* Push Agent 188.8.131.528 > Reboot (Client IN NEW OU in EPO with Default Mcafee Policy)
* OK > Windows Defender Services UP
* Push ENS 10.6.1 (Plattform, Exploit + ATP Module [No Firewall Module]) > Reboot
* OK > Windows Defender Services DOWN (Except Firewall) > OK
* Assign Stepwise Policy from Productive
* When we APPLY Policy ON-ACCES-SCAN and ENABLE AMSI BOX the effect comes
* ERROR > Windows Defender Services UP (Except Firewall) > OK
* ERROR > Warning from W10
Now to NOT complete MISSUNDERSTAND and Maybe it should be like that? But nobody told all the people who had cases open?
Now when AMSI is working or AMSI is enabled should the Service "Windows Defender Antivirus Service" be running or NOT?? (Can it RUN and then TURN off). Is this by feature and how it should be?
On the machines WE HAD the effect this ONLY showed UP shortly after Reboot BUT then slowing down logon and GPO extreme.
It happens if you have the AMSI report only or sharp/active.
We have AMSI on (enforced, not obvserve), but not sure its a factor. AMSI quite possibly does rely on the Defender service itself as it stems from Windows functionality (basically windows passes the script from memory to the AV for traditional scanning, which would otherwise be missed since its never in a file).
So far i've got 3 confirmed systems where this is repeatable on... and 1 that doesn't appear to show the issue (with the same OS build & ENS policies)... Very weird. We have a lot more deployments of ENS, but not enough time to go check each one individually to see if they're behaving the same for now... Nobody else is complaining, but in our case we aren't getting any AV not running popups, because Defender doesn't crash... both 'happily' run together.
We have AMSI on (enforced) on over 20 EPO Onpremise customers with all ENS 10.6.1 JULY Repost and Agent 184.108.40.206. Just finished updating all of them. The client base runs from around 900 clients with the same clients to SBS/KMU with different W10 Versions PRO/ENT 1809/17XX and 1903 in place.
All of them we trurned AMSI on as you mentioned.
This is one of the first W10 LTSC 2019 we have in place and on VDI. Maybe the reason why we discovered it because we take an extreme close look to performance with that customer.
We several times in Mcafee forums asked on MORE info regarding AMSI and ENS. Esp. we woul dlike to know more info on LOG / DEBUG / Trace if something goes wrong outside the Mcafee components.
I've tried with AMSI disabled today & the issue continues... So thats not the cause, at least in my instance.
Windows only seems to detect ENS correctly on my laptop after a reboot when debug logging is enabled for threat prevention.
I also tried with:
The issue continued in all three scenarios (with "Check New Policies" and reboots in between).
About to try with TP debug logging on as suggested by @JayMan