How the “Don’t run specified Windows applications” policy works

The User Configuration → Administrative Templates → System → “Don’t run specified Windows applications” setting is a simple “black‑list” that tells Windows Explorer to refuse launching any executable whose file name appears in the list.

When the policy is enabled Windows will:

1. Check the name of the program the user is trying to start.
2. If the name matches an entry in the DisallowRun list, Explorer shows the standard “This program has been blocked by your system administrator” message and the process never starts.

The check is performed before the executable is loaded, so the programme never gets a chance to run any of its code – a useful way of preventing unwanted or risky software from being used.

Why you might want to use it

How to configure it via Group Policy

1. Open the Group Policy Management Console (GPMC).
2. Right‑click the OU (or the domain) where the policy should apply → Create a GPO, give it a meaningful name (e.g. Block unwanted executables).
3. Edit the GPO:

   User Configuration → Administrative Templates → System → Don’t run specified Windows applications

1. Set the policy to Enabled.
2. Click the Show… button under List of disallowed applications and add each executable name, one per line, e.g.:

   msedge.exe
   msedgewebview2.exe

1. Link the GPO to the appropriate OU(s).
2. (Optional) Use Security Filtering or WMI Filtering to target only specific user groups or device types.

Tip: The policy only checks the file name, not the path. msedge.exe will be blocked wherever it lives on the system.

Setting the same restriction directly in the registry (no GP required)

If you prefer to push the setting with a script, SCCM, Intune, or a login script, you can write the required registry keys yourself.

Example PowerShell script (per‑user)

# Enable the DisallowRun policy
Set-ItemProperty -Path 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer' `
                 -Name DisallowRun -Value 1 -Type DWord

# Create the sub‑key if it doesn't exist
New-Item -Path 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\DisallowRun' -Force

# Add the executables to block
$apps = @('msedge.exe','msedgewebview2.exe')
for ($i = 0; $i -lt $apps.Count; $i++) {
    $name = ($i+1).ToString()
    Set-ItemProperty -Path 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\DisallowRun' `
                     -Name $name -Value $apps[$i] -Type String
}

Deploy the script via your favourite endpoint‑management tool, and the restriction will take effect the next time the user logs on (or after a gpupdate /force if you also have GP processing enabled).

When you might prefer the registry method

• Stateless or cloud‑based devices – where you push a baseline image and then apply customisations with scripts rather than maintaining many GPOs.
• Non‑domain‑joined machines – laptops or kiosks that are not members of Active Directory.
• Rapid testing – you can drop a .reg file or run a one‑off PowerShell command to see the effect before committing to a full GPO.

Other scenarios that fit this approach

The same mechanism can be re‑used for many different purposes:

Note: For more granular control (e.g. based on path, hash, publisher, or signed status) consider AppLocker (Windows 10/11 Enterprise) or Software Restriction Policies. Those solutions can allow/deny based on more than just the file name.

Best‑practice checklist before you roll it out

1. Test in a lab – verify that the blocked executable truly prevents the unwanted behaviour and does not break a critical business app.
2. Create an exception list – if a needed application shares the same name (rare, but possible), you may need to whitelist it via AppLocker instead.
3. Communicate to users – let them know why the change is happening to avoid confusion when they see the “blocked by your system administrator” prompt.
4. Document the list – keep a version‑controlled record of every entry and the reason for its inclusion.
5. Monitor Event Logs – blocked attempts generate Event ID 3000 in the Application log (source: Microsoft-Windows-GroupPolicy/Operational). Use this to confirm the policy is working and to spot any attempts to bypass it.
6. Review periodically – software inventories change; revisit the list every 3–6 months to add new unwanted binaries or remove obsolete ones.

Quick reference – one‑liner registry import

If you simply need to push the setting with a .reg file, the following will block msedge.exe and msedgewebview2.exe for the current user:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer]
"DisallowRun"=dword:00000001

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\DisallowRun]
"1"="msedge.exe"
"2"="msedgewebview2.exe"

Save as BlockEdgeApps.reg and double‑click on each workstation (or deploy via a script).

TL;DR

Enable the “Don’t run specified Windows applications” GPO (or the equivalent registry keys) to create a simple, name‑based blacklist of executables such as msedge.exe and msedgewebview2.exe. Use Group Policy for domain‑joined PCs, or write the same keys directly to the registry for non‑domain or script‑based deployments. This technique is ideal for blocking unwanted browsers, legacy tools, portable utilities, or any programme you wish to prevent from running for security, compliance or performance reasons. Test first, document the list, and monitor the Event Log to ensure the policy is having the intended effect.