Why are Microsoft Edge enterprise policies not reflected in edge://policy even though the corresponding registry entries exist?

Question

Why are Microsoft Edge enterprise policies not reflected in edge://policy even though the corresponding registry entries exist?

Veil Doken 0

0 comments

2 answers

Your answer

Answer 1

Hi Veil,

The most common causes are incorrect registry paths, unsupported policy values, or policies being configured under the wrong registry hive.

I'd first verify that the policies are stored under HKLM\SOFTWARE\Policies\Microsoft\Edge or HKCU\SOFTWARE\Policies\Microsoft\Edge, depending on the intended scope.

Then, open edge://policy, select Reload policies, and check whether the policies appear with an error or conflict status. Also verify that the policy names and data types match Microsoft's documentation and that the installed Edge version supports them.

If the issue persists, check Group Policy application using gpresult /h C:\gpresult.html and review relevant Windows event logs for policy processing errors. One important detail: registry entries existing does not necessarily mean Edge recognizes them; the registry location, value type, policy support, and scope must all be correct.

Microsoft reference: Microsoft Edge browser policies.

Hope this helps you narrow down the issue!

Xuan Nhu.

Answer 2

Registry entries appear in edge://policy only when they use the current Chromium-based Edge policy path, match the policy’s documented name and data type, are supported by the installed Edge version, and satisfy any device-management requirements.

1. Check the registry path first

Current Microsoft Edge mandatory policies belong under:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Edge

Recommended policies, where supported, belong under:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Edge\Recommended

The similarly named legacy path is for the retired EdgeHTML browser and is not read as current Edge policy:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\MicrosoftEdge

Microsoft’s current deployment documentation identifies HKLM\SOFTWARE\Policies\Microsoft\Edge as the policy location ^1^. A reported case with this symptom was resolved by changing scripts from the legacy/similar registry location to the current Microsoft\Edge location ^2^.

Use PowerShell to compare the locations:

$paths = @(
  'HKLM:\SOFTWARE\Policies\Microsoft\Edge',
  'HKLM:\SOFTWARE\Policies\Microsoft\Edge\Recommended',
  'HKLM:\SOFTWARE\Policies\Microsoft\MicrosoftEdge'
)

foreach ($path in $paths) {
    Write-Host "`n[$path]"
    if (Test-Path $path) { Get-ItemProperty $path }
    else { Write-Host 'Not present' }
}

If values exist only under Microsoft\MicrosoftEdge, recreate the policies through the current MSEdge.admx templates or move the deployment configuration to the documented Microsoft\Edge path. Do not delete the legacy key until its ownership and purpose are established.

2. Validate each policy against its policy-reference entry

A correctly located value can still be ignored when its name, type, applicability, or version is wrong.

For each missing policy, look it up in the current Edge policy list ^3^ and verify:

Exact value name
Mandatory or recommended path
Registry value type, such as REG_DWORD or REG_SZ
Minimum supported Edge version
Whether the policy is deprecated or obsolete
Whether it requires a browser restart
Any prerequisite policy

For example, CustomHelpLink must be a REG_SZ value under SOFTWARE\Policies\Microsoft\Edge and requires a domain-joined or MDM-managed eligible Windows installation ^4^. By contrast, PreventTyposquattingPromptOverride requires Edge 121 or later and uses REG_DWORD ^5^.

Registry presence does not make an obsolete policy functional. For example, NewSmartScreenLibraryEnabled stopped working after Edge 107 ^6^, while UserAgentClientHintsGREASEUpdateEnabled stopped working after Edge 133 ^7^.

3. Confirm device eligibility

Some Edge policies are accepted only on:

Windows devices joined to Active Directory, or
Windows 10 Pro/Enterprise devices enrolled for device management.

This requirement is policy-specific, so check the policy-reference page rather than assuming every registry value is accepted. For policies with that restriction, manually creating a value on an unmanaged device does not satisfy the applicability requirement.

If edge://policy shows “This policy is blocked, its value will be ignored” rather than omitting the policy, also check the Edge version. Microsoft fixed an issue in Edge Stable 147.0.3912.86 where some policies incorrectly showed that message on eligible domain-joined or MDM-managed devices ^8^.

4. Refresh using the method appropriate to deployment

For Active Directory GPO deployment:

gpupdate /force

Then fully close and reopen Edge and select Reload policies on edge://policy. Local policies normally appear immediately, although some policies explicitly require a browser restart ^1^.

For Intune custom OMA-URI deployment, if the value is present but the policy remains absent, validate the OMA-URI and XML payload. Microsoft documents an incorrect OMA-URI or invalid XML value as a policy-delivery failure condition ^9^. For Settings Catalog deployment, check device enrollment/sync and conflicting profiles targeting the same setting ^10^.

References