Perhaps the POC fix was only tested on 1903 users & not those on 1809 reporting the issue? (Since we were told earlier in the thread it was only an issue with 1903)
Had a remote support session today under my new case number (4-20380411771) and repeated all the same checks. Support rep said it's only a cosmetic issue, which I pointed out it's really not since Defender is actually running & scanning along with ENS.
@chealey, I tried to re-open my support case on the McAfee website, but it indicates:
This Service Request is closed.
To reopen this Service Request, please contact your McAfee support technician.
So, following the instructions, I reply to any email sent to me by my support technician, and immediately receive an auto-response email indicating:
This is a system-generated message in response to your email about SR # <4-20058973171>. This service request is currently closed and this e-mail is not being monitored.
Please do not reply to this email.
So... I had to create a new SR 4-20381580551 which exists only to tell McAfee to re-open SR 4-20058973171.
Perhaps the re-opening SR process could be reviewed as well...
I had the same 'unmonitored' reply... So create a new case... Then later got an email saying 'we've received your request to open the case, so we have now loaded a new case for you...
So although it says it's unmonitored, clearly it's not completely true hah
@billmoller I've reopened your old case. Please upload the originally requested data to your old SR so we can re-engage engineering.
Upon closure of a case, the emails are no longer monitored however some do get through and are picked up. As a general policy we advise that customers should call to reopen a case or as you've done, you can raise a new SR, asking for the old one to be reopened.
@billmoller Just out of curiosity if your systems are managed by ePO change the policy under Endpoint Security Common > Options that applies to your test computers so that debug logging is enabled. If you change the setting locally and not in that ePO policy then a policy refresh will set it back to whatever is defined in the ePO policy.
Now, all that said, debug logging still should not be the fix.
@meanoldmanning, I've been able to force productState to 397312 in the past by turning debug logging on, but even then, after an update, it would eventually go back to 393232...
Just after reading your post, and before I was about to enable debug logging again, I checked the productState.
After doing literally nothing this morning (except letting an ASCI interval naturally pass/process by checking agent log), the productState changed from 393232 (BAD) to 397312 (GOOD), and it's "working" now...
I'm in the middle of a long operation, and will attempt a reboot soon.
Pretty frustrating, huh? I'm waiting for the fellow assigned to my case to reply to my updates on my ticket about what I have found so far. As I have stated above, I have tried a few different scenarios so far on 4 different laptops and all have wound up needing to have debug logging enabled eventually to appear to function correctly.
Oh boy! 4 AV products listed! Now ENS is listed 3 times!
This is on a test computer that had the PoC installed then had the October Update installed over the top of it, so no telling what kind of a mess this system is
I'm fairly certain that ENS is setting the productState (and WSC is getting the productState), therefore... ENS is improperly reporting that it is off and out of date and WSC is properly starting WDA in its place...
What a cluster...
When it switches back to 393232 if you look at the Settings > Common > Advanced is Debug Logging still enabled or has it toggled back off? Or had you not enabled it to begin with?
Corporate Headquarters
6220 America Center Drive
San Jose, CA 95002 USA