Remove Web Browsers from Windows Domain Controllers

What the multi-browser uninstaller does

This Automox Worklet™ silently uninstalls every web browser the script knows about from a Windows endpoint, in a single policy run. The target list covers Google Chrome, Mozilla Firefox, Microsoft Edge (Chromium), Internet Explorer, Opera, and Vivaldi. The Worklet scans the Uninstall registry keys under HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall and the Wow6432Node 32-bit hive, walks every loaded HKCU hive for per-user installs, and runs the QuietUninstallString for each match. After remediation, the endpoint has no browser binary available.

The Worklet handles per-user Chrome installs (the silent installer that ships in the AppData\Local\Google\Chrome path with no HKLM uninstall entry), Edge updates that ship a versioned uninstall folder, and Firefox standalone profiles that survive the uninstall by default. After the official uninstall path runs, the script cleans up the lingering ProgramData, AppData, and Start menu shortcut paths so an admin reviewing the endpoint sees a clean slate, not a shell of half-removed browser folders.

Evaluation walks the Uninstall registry hive and every loaded HKCU hive against the six browser DisplayName patterns before any QuietUninstallString runs, so endpoints with no browsers installed exit 0 immediately. Apply this Worklet to the Domain Controller and hardened-server endpoint groups so endpoints where an admin or an installer added a browser since the last run are flagged and stripped on the next pass, and the hardened-endpoint baseline holds for the policy's lifetime.

Why strip browsers from infrastructure endpoints

A web browser is the most capable download tool an attacker can land on. On a domain controller, a jump host, or a hardened management endpoint, the presence of any browser binary expands the attack surface in ways that no monitoring control fully closes. An admin who lands on the box to investigate a ticket can be socially engineered into opening a malicious link; a compromised script can use the browser's own download capability as a living-off-the-land path; a Microsoft Edge update on a domain controller can re-introduce executable surfaces the security baseline expected to be missing.

Scheduling this Worklet against the domain controller and management group enumerates Chrome, Firefox, Edge, Internet Explorer, Opera, and Vivaldi in the Uninstall hive on every host at evaluation time, then calls each registered UninstallString or msiexec /x ProductCode silently. A browser that shows up between policy runs (a Microsoft Edge update redistributed on a DC, a Chrome install during a vendor troubleshooting session) is caught and stripped on the next pass, so the CIS hardening control written into the runbook actually applies across the infrastructure tier. Pair it with a browser-install Worklet for the user-facing tiers where browsers belong.

How multi-browser uninstall works

1. Evaluation phase: The Worklet runs Get-ItemProperty against the Uninstall registry hives (64-bit and Wow6432Node 32-bit), filters by DisplayName -like patterns for each target browser, and walks the loaded user hives to catch per-user Chrome and Edge installs. It collects DisplayName, UninstallString, and QuietUninstallString for every match. If at least one browser entry is found, the endpoint is flagged for remediation. Endpoints with no matches are reported compliant and skipped.

2. Remediation phase: The remediation script iterates the candidate list and runs each QuietUninstallString, falling back to UninstallString with the appropriate silent switch (/S, /silent, /uninstall --force-uninstall, depending on the browser). After each uninstall, the script removes any leftover ProgramData and per-user AppData browser directories with Remove-Item -Recurse -Force and deletes orphaned Start menu shortcut .lnk files. Exit 0 on success or non-zero with the offending browser name in stderr if a removal failed.

Multi-browser uninstall requirements

• Windows Server 2016, 2019, 2022, 2025, or a hardened Windows 10 or 11 SKU acting as a management endpoint

• Local administrator or SYSTEM privileges for the Automox agent (the default agent context satisfies this) so the script can uninstall per-user browser installs and remove user-profile directories

• A scoped policy group that targets infrastructure endpoints only; running this Worklet against a general user-facing fleet will strip browsers users actively need

• Microsoft Edge handling reviewed before the rollout; on Windows Server 2022 and later, Edge is a bundled component that the script removes through the Edge updater binary rather than a standard uninstall

• End user notification or runbook entry explaining the hardened-endpoint policy so admins who land on a DC and notice the missing browser do not file a ticket asking for it back

Expected browser state after uninstall

After successful remediation, the Apps and Features list on the endpoint contains no Chrome, Firefox, Edge, Internet Explorer, Opera, or Vivaldi entries. The Program Files and ProgramData directories contain no browser folders. The Start menu and per-user profile shortcuts no longer reference any browser binaries. Subsequent Automox policy runs report the endpoint as compliant unless an admin has re-installed a browser between runs, at which point the next evaluation catches it and removes it.

Validate by running Get-Package -Provider Programs on a remediated domain controller and confirming the browser entries are gone. For audit evidence, capture the before-and-after package list and store it with the policy run identifier. If a browser reappears after a feature update or a Windows Server cumulative update, the cause is usually that the update re-installed the bundled Edge as part of a servicing operation; that path is intentional in Microsoft's servicing model, and the next Worklet run removes Edge again without a separate intervention.