Why this policy is producing error? Configure new tab page URL

MVP

It's this Policy:

https://docs.microsoft.com/en-us/DeployEdge/microsoft-edge-policies#newtabpagelocation

 

And based on the description, I've set it correctly on Edge 87 (the installed up-to-date policy files are also for Edge 87)

 

dsadas.png

 

But it isn't being applied and I see an error in Edge:policy

 

ddfsfs.png

 

why does it say the policy is blocked? what am I doing wrong?

13 Replies

Could it be because in the description it says:

 

"This policy is available only on Windows instances that are joined to a Microsoft Active Directory domain, Windows 10 Pro or Enterprise instances that enrolled for device management, or macOS instances that are that are managed via MDM or joined to a domain via MCX."  ?

 

there it says this policy is available only on ..., I'm testing it on my personal Windows 10 machine that is not managed by a Windows server or MDM, could this be the reason?

 

If that is indeed the case then:

 

  1. the description is misleading, because it's not about availability, it's about whether the policy works or not.
  2. the error message in Edge://policy is vague and doesn't say exactly what happened and what is wrong.
  3. Any other policy that I tried works fine, this one doesn't. why a simple configuration like this would require a Windows server or MDM in order to work?

@HotCakeX Your machine needs to be MDM-Managed or AD-Joined, otherwise you get a "this policy is blocked" Error.

 

Workaround for non-MDM-Managed an non-AD-Joined Devices, have a look at my Blog-Post:

https://hitco.at/blog/apply-edge-policies-for-non-domain-joined-devices/

 

@Gunnar Haslinger 

 

Spoiler

@Gunnar Haslinger wrote:

@HotCakeX Your machine needs to be MDM-Managed or AD-Joined, otherwise you get a "this policy is blocked" Error.

 

Workaround for non-MDM-Managed an non-AD-Joined Devices, have a look at my Blog-Post:

https://hitco.at/blog/apply-edge-policies-for-non-domain-joined-devices/

 


 

 

Thanks, I just finished reading your blog post, It is a workaround on those specific Windows versions but there are things that need to be considered:

 

  1. I'm using Windows 10 20H2 (release preview) and it might/might not work with those registry keys. and I don't want to use them in case it conflicts with something else somewhere in Windows that is still undocumented or just simply unknown.
  2. Windows 10 is always changing and evolving, this solution is a brute force method to achieve what I want.

 

I would rather have an explanation to know at least why this requires a domain controller or MDM to work. after all, what I was doing is just a test and I didn't want to fire up any servers to do a simple task like that, but apparently, I need to.

 

so again, these 3 are my main concerns and I want Edge team to consider as feedback and change the behavior (if possible) in the future:

https://techcommunity.microsoft.com/t5/enterprise/why-this-policy-is-producing-error-configure-new-t...

 

@HotCakeX I would wonder if you can trigger the edge-team to give you a satisfying answer or a change of the current behavior. This behavior is "by design" or "by choice of Microsoft". It is not a technical decision but a management decision.

@Gunnar Haslinger 


@Gunnar Haslinger wrote:

@HotCakeX I would wonder if you can trigger the edge-team to give you a satisfying answer or a change of the current behavior.

 

This behavior is "by design" or "by choice of Microsoft". It is not a technical decision but a management decision.


It's the tech community, I'm not necessarily asking them to change it, I just need a technical explanation that why it is what it is. also, it's feedback from a user and that's what they are asking for.

 

The 2nd part of it is pure speculations

@HotCakeX 

 

I tried to get a solution / answer by opening a paid premier support ticket for this. This management-decision is not new, it was the same in Edge-Legacy. Answer is, it is a management-decision to pick some Policies not being manageably on devices not AD-joined or MDM-Managed. 

 

If you like to have a more technical answer: Malware could easily use these Policies to for example set your Homepage - a regular user on a Home-Machine (non-managed) will have a hard job to find out what's wrong and what happened. On managed machines this would be cleared out / reset to admins-choice on next policy-apply-run.

@Gunnar Haslinger 

Spoiler

@Gunnar Haslinger wrote:

@HotCakeX 

 

I tried to get a solution / answer by opening a paid premier support ticket for this. This management-decision is not new, it was the same in Edge-Legacy. Answer is, it is a management-decision to pick some Policies not being manageably on devices not AD-joined or MDM-Managed. 

 

If you like to have a more technical answer: Malware could easily use these Policies to for example set your Homepage - a regular user on a Home-Machine (non-managed) will have a hard job to find out what's wrong and what happened. On managed machines this would be cleared out / reset to admins-choice on next policy-apply-run.


well of course malware can do that, but if malware exists on the system, your new tab page URL, or Edge settings in general, is the Least thing you need to worry about to be honest.

there are many scenarios I'm thinking about right now that renders this useless, if this is the only line of defense.

 

But yes I can see how it's related to security, I found 18 policies with this requirement and all of them, more or less, seem lucrative to hackers.

@HotCakeX 

 


if malware exists on the system, your new tab page URL, or Edge settings in general, is the Least thing you need to worry about to be honest


I totally agree, this was one of my arguments too. 

 


I'm using Windows 10 20H2 (release preview) and it might/might not work with those registry keys. and I don't want to use them in case it conflicts with something else somewhere in Windows that is still undocumented or just simply unknown.

 


@HotCakeX my Solution is successfully tested with newest 20H2 Insider Build and newest Dev-Channel of Edge too (just updated/added Version Information in my Blogpost)


I'm using Windows 10 20H2 (release preview) and it might/might not work with those registry keys. and I don't want to use them in case it conflicts with something else somewhere in Windows that is still undocumented or just simply unknown.

 


@HotCakeX my Solution is successfully tested with newest 20H2 Insider Build and newest Dev-Channel of Edge too (just updated/added "Compatibility" Version-Information in my Blogpost)

@Gunnar Haslinger 

Thank you, good job,

correct me if i'm wrong but this further proves our point because your findings show that how easy it is for an attacker to fake MDM enrollment status on a victim's system and then push their malicious policy files.

in both methods, attacker needs to have an elevated access to do all these but the lack of proper verification of a legit MDM or Windows server domain lets them push the policy and that security measure they put in place is virtually useless, and all it does is to put unnecessary limitations for users.

 

@HotCakeX I agree, but in addition: as an "hacker" there is even no need to elevate to Admin/System. It is much easier to just modify your user-writeable Edge-Profile to do the same. Maybe not as persistent as setting policies, but the point is: If you allow malware to run on your system your Edge-Settings are the least problem and you already lost the game.

Yup, can't agree with that more