I have sent countless memory dumps, MERs, policy exports, system configs... all of it. The case for us has been with McAfee for over a year. We did work with McAfee Devs (Alex) and reproduced the issue on webex for them a 1000 times. Long story short, we were told that this is an issue with order of operations issues where Microsoft would have to modify the Outlook client. I cant accept that as a solution because i have seen an inferior product (Symantec Endpoint DLP) solve this by scanning the file when it is being attached. They added a quick spinning indicator as the file is being inspected for content.
As a contrast, anytime we add a 1MB file or larger, especially Excel, it takes about 10 seconds to process. THAT IS NOT THE ISSUE... Where this becomes an issue is when Outlook client says NOT RESPONDING after about 6 or 7 seconds. Why? Why cant McAfee figure out a way to either inspect the file while it is being attached or simply inspect it when the email messages goes to the Outbox?
Keep in mind that EVERYTHING on Outlook client, including any open emails/operations is now NOT responding and inaccessible until the file is "processed". It is even worse when the file in question contains macros or is 5 or 10 MB - you could be waiting for a minute. Again, the users would not complain if 1) Outlook does NOT get fully locked up with "NOT RESPONDING" (not just the current mail window), or 2) the pop up window that lets the user know that the email is processing does NOT get stuck open (full or half way) or ghosted or leaves artifacts of its borders or is slow to come up.
There are many ways this issue can be resolved but frankly this product has been promising a fix for years now and we have yet to see it. I am open to working with Dev to bring this issue to the forefront so we can get it resolved once and for all
Oh and BTW, Dev (Alex, Russian gentleman) was able to reproduce the issue in his lab. 11.4 and 11.5 promised a fix. My guess the issue was fixed for specific set of circumstances but it continues to persist for us. I have also tested on a fresh Win 10 image, Office 2016, no AD binding, no GPO/login scripts, no other apps or add-ins running. Still occurs.
We run EPO 5.10, Agent 184.108.40.206xx, ENS 10.6.1 or 10.7, Disk encryption 7.2, File and Folder Encryption 5.1 or 5.2, MAR and MVision EDR
Our case had stalled on the MSFT side and McAfee wasn't really able to go any further at that point. We are currently running 11.4 and are seeing some more instances of this occurring. One reason that our case stalled with MSFT is because they recommend running Outlook in cached exchange mode not online mode. Though we can repro the issue when in cached mode we have had a much more difficult time doing so. I will be starting prepilot for 11.5 next week to see if this improves any. I wanted to find out if your organization is running in cached mode or online mode to see if there is additional similarity. I have also re-opened our case with McAfee after see your post to help try and get the issue some more attention.
We are running in Outlook online mode - persistent connection to Exchange server. That is if you are on network. For users that are not on our network (work from home without VPN wrapper) Outlook will obviously go to cached mode and we continue to see this issue (I will re-test and verify)
I have 11.5 running on a 3-4K endpoints, including mine and the issue can be reproduced 100% of the time. It is interesting to note I just watched a lab environment (not ours), Office/Outlook 2016, online mode, user attached a 10MB Excel file and clicked send - 2 seconds at most. No hang ups, no Not Responding nonsense.
Makes me wonder about what could we be doing different that is causing such poor user experience.
Whats even worse is we use 11.4 on our XenDesktop/Citrix images with user density per host at around 15 users with decent resources for CPU/RAM allocated to each user. Citrix users see delays as bad as 30 seconds to a minute on emails without attachments.
I also reopened our ticket yesterday as we are gearing for global deployment despite these issues.
If you can try testing with a couple of devices and put them into cached exchange mode instead of online mode with your on network devices and see if it improves. The reason I mention that is because we have been shutdown hard by MSFT refusing to do any further support when in Online mode.
Over the last two years of working this issue I have seen several things play into it. McAfee has made some improvements in their DLP agent which have helped. However, I am strongly convinced that part of the delays are tied into how MSFT handles some of their backend communications with O365. Again though we have been at a dead end since I have had difficulty reliably reproducing it in cached mode for MSFT to look at. The issue happens but I cannot repro it on demand for log collection so it is a challenge.
I have also worked on this issue and can reproduce every time. ruled out many items.. easiest way to reproduce is to grab a 10mb file from dlptest when added to attachment as excel exchange or other hotmail etc. will pause , hang.. save that excel as a .pdf or a .csv and the results will then change and not be as bad. development acknowledged this issue and was going to work on scanning in outbox of outlook instead that way the user experience would not see outlook hanging.. most user may not see issues unless they attach large excel.
awaiting update from Alex in dev going on a year now
Whats interesting is saw a lab test with a 10MB file and it took 2 seconds to scan and release depending on your rules.
Any outbound email taking more than 6 seconds to process triggers "Outlook Not Responding" and locks up not just the current email but the entire Outlook client.
I also heard that they are working on moving the scan to while the email is in the outbox. I dont think a user would mind waiting 5-10 seconds as long as the client is responding and not crashing.