I don't see how as I haven't, unless it can be set by itself.
I'll try to reset the flags in the morning and see what happens.
I will let you know if it fixes it. Thanks.
- - - Updated - - -
As promised, I checked, there was nothing set beyond the defaults.
For shits and giggles, I did a "reset all" and still no go
It is so frustrating when things don't work as advertised.
I would appreciate it if you figured it out to let me know.
Thank you.
I was hoping it may have been a flag set by mistake somehow since none of the usual policies for this were set for you.I don't see how as I haven't, unless it can be set by itself.
I'll try to reset the flags in the morning and see what happens.
I will let you know if it fixes it. Thanks.
- - - Updated - - -
As promised, I checked, there was nothing set beyond the defaults.
For shits and giggles, I did a "reset all" and still no go
It is so frustrating when things don't work as advertised.
I would appreciate it if you figured it out to let me know.
Thank you.
I share your disappointment my friend, I am hoping it is a screwup that happened by M$ or perhaps some overzealous integration bug that they resolve.
In the meantime, I guess the least intrusive for work will be to remove the policy and deal with their intrusion into privacy instead.
- - - Updated - - -
I wanted to report back something that might explain this behavior. I poked around my dev circles and there are a few MS devs in there as well, we go way back so I trust them. One of them suggested a reason for this.
Now don't quote me on this, I hope we can independently verify this information but I am confident he is not wrong. He said that if "ANY POLICY" is active, the device will be considered "Managed" and as such the rule is that no "Managed" device can set it is own DNS and hence why this feature is disabled.
It makes no difference if the policy is related to it or not, it is a global: If policy count > 0 then "device is managed" therefore turn off DOH. Seems to be as simple and arbitrary as that. Why probably has to do with some notion that a managed device using this will somehow be escaping monitoring or trying to injure their enterprise, bluh bluh, but that is the long and short of it.
As soon as I am off and have a bit of time after my appointment, plan later tonight to test that theory by doing a couple of things. 1) Remove the policy, does it come back? 2) Force add the DOH policy, does it override it? I would welcome your input if you wanted to test that as well.
I ran into the same issue, I could not turn on dns over https, "This browser is managed blah blah..."
I have installed the group policies for Edge (which is now named "MicrosoftEdge" not "Edge" in the registry) and used it to block a bunch of bloatware.
I found this policy "User Configuration > Administrative Templates > Microsoft Edge > Control the mode of DNS-over-HTTPS".
Enabling it forces DNS over HTTPS on in Edge. I am unable to change the provider though. I do have 1.1.1.1 and 1.0.0.1 set in my adapter settings though and a visits to ipleak.net and cloudflare show that I am using cloudflare for dns requests.
Note: It is set to allow insecure fallback, if set to do not allow insecure fallback, this site will not load so even though everything looks like it is secure, it may not actually be so.
I also found "TLS Encrypted ClientHello Enabled" - Enabling this policy did not turn it on in edge.
I added the command line switch "--enable-features=EncryptedClientHello" to the edge shortcut and it appears to be working.
I've been testing my results using "ipleak.net" and "https://www.cloudflare.com/ssl/encrypted-sni/#results". The latter now shows Edge is passing in all 4 areas.
FYI: With DNS over HTTPS enabled this way, Netflix would not work.
Last edited by Sqrly; 12 Oct 2023 at 13:27.
Quote