New "Get-MpPreference" Options

[Jonathan Green]

There are several new options in the configuration, but I haven't been able to find any docs.microsoft.com documentation on them. 

Aside from the fact that most know what they mean, its important to know Microsoft's intent more than our own interpretations.

Can MSFT chime in on them here? 

DisableRdpParsing

DisableDnsParsing

DisableDnsOverTcpParsing

DisableHttpParsing

DisableGradualRelease

DisableSshParsing

DisableTlsParsing

EnableDnsSinkhole

Feel free to tell my Bing search is broken.  

[#2]

@Jonathan Green Agreed, we need more info on these. We are facing an issue where external users using our SFB edge server are dropping skype calls after 1-2 seconds of sharing desktop video. After changing DisableTlsParsing to "true" instead of the default "false" for both users, the desktop video share is able to be completed. 

[#3]

Do you think it was related to overhead vs. the actual parsing being the root cause of the disconnects?

One would assume that WDATP or Defender would just now parse TLS logs (similar to PacketBeat, Microsoft's legacy packet gui, or logger of choice) via it's new packet capture abilities that were released 6+ months ago (20H2 or 20H1?).

I've been wrong in the past when I've applied logic to naming conventions in powershell, which is the reason I made this thread. :) 

The scenario you ran into would be great for performance gauging too.
I'd be curious over the specifics on network conditions and devices used. 

[#4]

@Jonathan Green I am not sure! All I know is that with plenty of packet capturing going on and 0 changes in our environment (excluding these new options and their default settings) within the last few weeks this has been a problem for our users who are utilizing the edge sfb server AND trying to complete a desktop screenshare. The audio call works great, but when one user turns on desktop sharing or video, the STUN binding doesn't complete. Wireshark can't capture a successful binding on either PC unless BOTH users have run this command: 

Set-MpPreference -DisableTlsParsing $true
It is also true that failing happens when setting this back to the default "false". 

Which device were you wondering about? I believe these are both Dell Laptops connecting (over the internet, no VPN) back to our public Skype For Business edge pool (2x2 pool). 

I am left with a very minimal understanding of TLS parsing in general, what the specifics of Microsoft implementation here is, and why it's impacting our calls. Changing the default option in our case certainly fixed the problem, hopefully we can get some docs on what I'm actually changing soon. 

[#5]

Please note, this command was actually recommended by a microsoft support engineer. There would have been no way for me to find the command as this is the only legitimate page that comes up when googling "disabletlsparsing"... Please give us at least a man page or something...