I agree with you but it appears DLP cannot do it at this time as you would expect. I like the idea of the guy that suggested to follow the MSM technique but implement directly in the Registry thru the use of keys that allow or block lower level Bluetooth protocols by UUID. But that is another team in my org.
that solution in KB90690 only works for certain versions of Windows 10. What if you have a mixed environment? Does it require maintaining a separate tree structure for each version of Windows? or can both instructions be combined somehow?
I resolved this myself outside of McAfee by using the Microsoft Policy CSP. We don't have the MDM, but you can define the registry keys via GPO and you get the same result. It requires a bit of customization for your environment, but does work.
See below for details.
The regkey is located in:
RegSZ = value
i.e. the name of the registry string value, is 'value'. And value = the list of bluetooth services that you want to allow. By default it's all services, but when you create this key, you define all of the allowed services.
The bluetooth services allowed list usage guide (below), contains a list of possible values (however I've found some aren't in that list but can be found via Device Manager of an affected device).
As an example, if I only wanted to allow Bluetooth classic keyboards and mice my regkey would be:
There's a way to get that key to take without a reboot, but I can't recall what it is, so reboot for this to take affect.
BTH\MS_RFCOMM protocol is used by both Audio (I/O) and File transfer in Windows
Thanks for the update @jsubbura . WRT blocking fsquirt.exe. What happens if I rename fsquirt.exe, to letmetransfer.exe?
You can block fsquirt.exe with Windows GPOs as well, but the problem is if you rename it, it you can still transfer files. The only real working solution I've found is by removing the File Transfer services from the Bluetooth Allowed Services definition.