Managing Browser Auto Updates on Windows via Intune

If you have already read the macOS browser updates guide, this one will feel familiar. The reasoning, the values, and the user experience are the same: automatic updates in the background, a required relaunch prompt once an update is ready, and a 3-day grace period before the browser restarts itself. What changes is the delivery. Windows uses the registry, not managed preferences. Settings live in different places depending on the browser. And a couple of the macOS-specific quirks (the Firefox enterprise master switch, the Mac mobileconfig format) do not apply. This guide covers what is the same, what is different, and how to ship the equivalent policy through Intune on Windows.

What Is Different From the Mac Side

The end state is identical: Chrome, Brave, Edge and Firefox all kept current, with a humane but bounded relaunch prompt. The differences are all in how you get there.

Registry, not plists. Windows browser policies are written as registry values under HKLM\SOFTWARE\Policies\<vendor>\<product>. The reverse-DNS preference domains used on macOS have no equivalent on Windows; you target a registry path instead.

No single bundled file. On Mac, one .mobileconfig contains all five payloads in one upload. On Windows, each browser has its own registry location, and Intune has no single profile type that targets multiple vendors at once natively. The closest thing to a bundled deliverable is a single PowerShell script that writes all the values, deployed via Intune Platform Scripts.

Firefox loses its master switch. On macOS, Firefox ignores all policies unless EnterprisePoliciesEnabled is set to true. On Windows that key does not apply. Any value under HKLM\SOFTWARE\Policies\Mozilla\Firefox is enough to activate enterprise policy mode; the master switch idea is purely a Mac thing.

Data types change. The Mac plist uses integers and booleans (<integer>, <true/>). Windows uses DWORD values everywhere — including for things Firefox treats as booleans on Mac. AppAutoUpdate on Windows is a DWORD set to 1 or 0, not a boolean.

Brave's update story is fuzzier. Brave does not ship official ADMX templates for its updater, and its own admin documentation cheerfully admits this. The pragmatic answer is that Brave auto-updates by default on Windows via its own Omaha-based scheduled task, so the practical impact of the missing policy is small.

Period values are the same. RelaunchNotificationPeriod is still in milliseconds, still 259200000 for three days. RelaunchNotification is still 2 for required.

Where the Policies Live on Windows

Every value below is a DWORD in the Windows registry. Paths are case-insensitive in practice but it is conventional to keep the casing shown.

Google Chrome

Update delivery is handled by Google Update (the Windows equivalent of Keystone) under one path; the browser's own relaunch behaviour under another.

HKLM\SOFTWARE\Policies\Google\Update
    UpdateDefault                                           = 1
    Update{8A69D345-D564-463C-AFF1-A69D9E530F96}            = 1   ; Chrome's per-app GUID

HKLM\SOFTWARE\Policies\Google\Chrome
    RelaunchNotification                                    = 2
    RelaunchNotificationPeriod                              = 259200000

The per-app GUID is Chrome's specific app ID under Google Update. Setting it alongside the global UpdateDefault is belt-and-braces — if anything ever changes the global default, Chrome's per-app override still keeps it updating.

Brave

Brave's browser policies follow the same Chromium pattern with a different vendor path. The updater path exists by convention but is less reliably honoured; Brave's own docs note the lack of official updater templates. Brave auto-updates by default on Windows anyway, so this is largely belt-and-braces.

HKLM\SOFTWARE\Policies\BraveSoftware\Update
    UpdateDefault                                           = 1

HKLM\SOFTWARE\Policies\BraveSoftware\Brave
    RelaunchNotification                                    = 2
    RelaunchNotificationPeriod                              = 259200000

Microsoft Edge

Relaunch only. Update delivery for Edge is handled by Microsoft EdgeUpdate, which in most M365-managed fleets is already configured by an existing Office-related profile. Manage it here only if you have confirmed nothing else is. See the EdgeUpdate section below.

HKLM\SOFTWARE\Policies\Microsoft\Edge
    RelaunchNotification                                    = 2
    RelaunchNotificationPeriod                              = 259200000

Firefox

One path, two values. No relaunch keys (Firefox does not support them), no master switch (Windows does not need one).

HKLM\SOFTWARE\Policies\Mozilla\Firefox
    AppAutoUpdate                                           = 1
    DisableAppUpdate                                        = 0

Setting DisableAppUpdate explicitly to 0 is defensive — it overrides any earlier policy that might have set it to 1.

Two Deployment Paths in Intune

On Windows there is no native equivalent of dropping a bundled .mobileconfig into a single Custom profile. You have two reasonable paths, both reaching the same end state.

Option A is the PowerShell script approach. One file, deployed via Intune Platform Scripts, writes all the registry values in one shot. Closest analogue to the bundled mobileconfig on Mac. Fastest to set up. Less visible in the Intune UI because the script is opaque to Intune — you do not see the individual settings in the dashboard the way you do with Settings Catalog. Good for getting moving quickly and treating the policy as code.

Option B is the Settings Catalog plus ADMX approach. More Intune-native, cleaner for ongoing management, but more setup. After a one-time ADMX upload, all four browsers' settings appear in the Settings Catalog and can be configured through Intune's standard UI. Better when you want each setting visible in the console and auditable as a first-class Intune entity.

Neither is wrong. Pick based on whether you value speed of setup or ongoing UI manageability.

Option A — the PowerShell Script Approach

The script writes the registry values described above. It is idempotent (safe to re-run), logged (writes to %ProgramData%\IntuneScriptLogs\browser-update-policy.log), and ships with a matching uninstall script that removes only the values it created.

Deploy from Intune:

Go to Devices → Scripts and remediations → Platform scripts, then Add for Windows 10 and later.
Name the script (something like Windows — Apply Browser Update Policy) and upload Apply-BrowserUpdatePolicy.ps1.
Configure the settings:
- Run this script using the logged on credentials: No (run as SYSTEM)
- Enforce script signature check: No
- Run script in 64 bit PowerShell host: Yes
Assign to a group containing a single test machine first.
Save.

On the device's next sync, the script runs as SYSTEM and writes the values. To force a sync, on the device go to Settings → Accounts → Access work or school, click the work account, click Info, then Sync.

Platform Scripts run once

Unlike a configuration profile, a Platform Script does not automatically re-apply if a user later removes the values. For most environments this is fine because HKLM is admin-write only, so a standard user cannot remove the policy. If you need guaranteed reapplication, look at Proactive Remediations (detection + remediation), or use Option B.

Option B — Settings Catalog Plus ADMX

This is the more Intune-native path. After a one-time ADMX ingestion, all the policies appear in the Settings Catalog and can be configured through Intune's standard UI like any first-party setting.

Edge and Chrome browser policies are already in the Settings Catalog without any ingestion. Google Update, Brave (browser), and Firefox all need their ADMX templates imported first. Brave's updater has no official ADMX; if you need to manage it that way you would have to fork the Chrome Update template, which is rarely worth the effort.

Ingest the templates once:

Download Chrome Enterprise Bundle (contains chrome.admx and GoogleUpdate.admx), Brave's policy templates from their support article, and the Firefox policy templates from mozilla.github.io/policy-templates.
In Intune go to Devices → Configuration → Import ADMX and upload each pair of .admx + .adml files. For Firefox, import mozilla.admx before firefox.admx — the second has a dependency on the first.

Then create a single Settings Catalog profile:

Devices → Configuration → Create → New policy.
Platform Windows 10 and later, profile type Settings catalog.
Name the profile (e.g. Windows — Browser Update and Relaunch Policy).
Click Add settings and search for each category in turn:
- Microsoft Edge → set Relaunch notification to Required (value 2) and Set the time period for update notifications to 259200000.
- Google Chrome → same two settings.
- Google Update (after ADMX import) → Update policy override default to Always allow updates.
- Brave Software\Brave (after ADMX import) → same relaunch settings.
- Mozilla\Firefox (after ADMX import) → DisableAppUpdate to Disabled, AppAutoUpdate to Enabled.
Scope to one test machine first.
Save.

The result is one Intune profile holding all the browser settings in one place, just like the Jamf approach on Mac. The downside compared to Option A is that you need the one-time ADMX ingestion ceremony, plus a fallback for Brave Update if you want belt-and-braces on Brave's updater (Custom OMA-URI or a small supplementary script).

A Note on EdgeUpdate

On the Mac side we deliberately did not manage Microsoft AutoUpdate because there was an existing profile, very likely deployed with Microsoft 365 or Office, already doing it. The Windows equivalent is Microsoft EdgeUpdate. In an M365-heavy fleet, something else is very probably already managing it. Before adding it to your browser update profile, check on a representative machine:

Get-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft\EdgeUpdate" -ErrorAction SilentlyContinue

If that returns values — especially a non-empty UpdateDefault — an existing policy is managing EdgeUpdate. Leave it alone and let the existing profile own it. If it returns nothing, you can safely add EdgeUpdate management to your own profile.

The default in the PowerShell script and .reg file leaves EdgeUpdate alone, matching the Mac decision. Both have clear comments showing where to uncomment if you want to manage it from this profile too.

Verifying It Worked

As on Mac, verify at two levels: the values are present on the device, and the browsers are actually honouring them.

On the device

The Windows equivalent of defaults read is Get-ItemProperty on the registry path:

Get-ItemProperty "HKLM:\SOFTWARE\Policies\Google\Update"
Get-ItemProperty "HKLM:\SOFTWARE\Policies\Google\Chrome"
Get-ItemProperty "HKLM:\SOFTWARE\Policies\BraveSoftware\Update"
Get-ItemProperty "HKLM:\SOFTWARE\Policies\BraveSoftware\Brave"
Get-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft\Edge"
Get-ItemProperty "HKLM:\SOFTWARE\Policies\Mozilla\Firefox"

For a friendlier output, ship the Verify-BrowserPolicies.ps1 script alongside the apply script. It reads every relevant path and reports the values in colour, highlighting the ones that match the expected configuration.

In the browser

Same in-app policy pages as on Mac. These do not care which OS or MDM delivered the policy.

Browser	Policy page
Microsoft Edge	`edge://policy`
Google Chrome	`chrome://policy`
Brave	`brave://policy`
Firefox	`about:policies`

Troubleshooting and Gotchas

The script ran but the registry values are not there

Check the log at %ProgramData%\IntuneScriptLogs\browser-update-policy.log. If it shows successful writes, the values are there — check you are looking at the right registry view. HKLM\SOFTWARE\Policies is not redirected to WOW6432Node, so you should not need to switch views, but it is worth ruling out.

Policies appear in chrome://policy but with status "Pending"

Means Chrome read the policy but has not applied it yet, typically because Chrome was already running when the script wrote the value. Restart Chrome and the status changes to OK.

Firefox shows no policies at about:policies

Confirm the registry values were written to HKLM\SOFTWARE\Policies\Mozilla\Firefox and not just HKLM\SOFTWARE\Policies\Mozilla. Firefox needs values under the Firefox subkey specifically. Unlike on Mac, no master switch is required — if the values exist in the right place, Firefox honours them.

Brave does not auto-update even with the registry values set

Brave's updater honours the policies inconsistently due to the missing official ADMX. The good news is Brave already auto-updates by default on Windows via a scheduled task; the registry values are belt-and-braces. The actual update mechanism is the BraveSoftwareUpdateTaskMachineUA scheduled task running hourly and checking every five hours. If Brave is not updating, check that task is enabled.

EdgeUpdate values conflict with another policy

Exactly the situation we are trying to avoid by leaving EdgeUpdate unmanaged by default. If you enabled EdgeUpdate management in this profile and now have conflicting values somewhere, identify the other policy via the HKLM:\SOFTWARE\Microsoft\PolicyManager tree or by checking installed configuration profiles in Settings → Accounts → Access work or school. Remove one or the other.

Stale registry values after editing the policy

The same cache trap as on Mac, in a different form. If you change values in Intune and run Get-ItemProperty immediately, you may see the previous values. Force a sync (Settings → Accounts → Access work or school → Info → Sync) and wait a minute before re-reading.

The Windows Command Reference

Follows the same template-then-examples pattern as the macOS command reference. The variable parts are highlighted.

Reading any policy registry value

# Read all values under a policy path
Get-ItemProperty "HKLM:\SOFTWARE\Policies\<vendor>\<product>"

# Read a single value
Get-ItemPropertyValue "HKLM:\SOFTWARE\Policies\<vendor>\<product>" -Name "<value-name>"

Forcing a sync

# GUI: Settings -> Accounts -> Access work or school -> account -> Info -> Sync

# Command line: trigger via the Intune Management Extension
Get-ScheduledTask -TaskName "PushLaunch" -TaskPath "\Microsoft\Windows\EnterpriseMgmt\*\" | Start-ScheduledTask

Inspecting which policies have been applied

# Generate a full applied-policy report in HTML
gpresult /h C:\Temp\policy-report.html

# See the MDM Diagnostic Information report (includes Intune-delivered settings)
mdmdiagnosticstool.exe -area DeviceEnrollment -zip C:\Temp\mdm-diag.zip

Looking at the Intune Management Extension log

This is where Platform Script results land. Useful when a script ran but the outcome is unclear.

notepad "$env:ProgramData\Microsoft\IntuneManagementExtension\Logs\IntuneManagementExtension.log"

Quick-Action Checklist

For when you just need to do it. Each step links back to the section above with the detail.

Pick a deployment path. PowerShell Platform Script (faster setup, one file) or Settings Catalog + ADMX (cleaner long-term, more setup). For first deployments, the script is usually right.
Check for an existing EdgeUpdate policy on a test machine before doing anything:
```
Get-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft\EdgeUpdate" -ErrorAction SilentlyContinue
```
If it returns values, leave EdgeUpdate alone — another profile is already managing it. If it returns nothing, you can manage EdgeUpdate from your script if you want.
For the PowerShell path: in Intune, Devices → Scripts and remediations → Platform scripts → Add (Windows 10/11) → upload Apply-BrowserUpdatePolicy.ps1 → Run as SYSTEM, no signature check, 64-bit host. Full steps here.
For the Settings Catalog path: download and ingest ADMX templates (Chrome Enterprise Bundle, Brave policy_templates, Firefox policy-templates). For Firefox, import mozilla.admx before firefox.admx — dependency order matters. Then create one Settings Catalog profile and configure the per-vendor settings. Full steps here.
Scope to one test machine first. Always.
Force a sync: Settings → Accounts → Access work or school → click the work account → Info → Sync. Then wait a minute.

Verify at registry level.

Get-ItemProperty "HKLM:\SOFTWARE\Policies\Google\Update"
Get-ItemProperty "HKLM:\SOFTWARE\Policies\Google\Chrome"
Get-ItemProperty "HKLM:\SOFTWARE\Policies\BraveSoftware\Brave"
Get-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft\Edge"
Get-ItemProperty "HKLM:\SOFTWARE\Policies\Mozilla\Firefox"

Or run Verify-BrowserPolicies.ps1 for colour-coded output.

Verify at application level. Open each browser and check the policy page (chrome://policy, edge://policy, brave://policy, about:policies). Keys present, status OK.
If the script ran but values are absent, check the log at %ProgramData%\IntuneScriptLogs\browser-update-policy.log and the Intune Management Extension log under %ProgramData%\Microsoft\IntuneManagementExtension\Logs.
Roll out to the wider fleet once the previous step succeeded.
Send user comms. Same message as Mac (auto-update, 3-day relaunch window, tabs restored). If you have a mixed Mac/Windows fleet, time the rollouts so both sides reach 3 days at the same time — otherwise different users get different experiences.

Closing Thoughts

The Windows side of this story has more moving parts than the Mac side, but no individual piece is hard. The mental shift is realising that "configuration profile" on Windows is not a single bundled artefact — it is either a script that writes registry values, or a Settings Catalog profile that targets them through Intune's UI, or both. Once that lands, the same discipline applies as on Mac: check for existing policies before you push, test on one machine, verify at both the registry and the browser level, and remember the cache trap. Done well, you end up with a fleet where every Windows browser keeps itself current, users get a fair relaunch window, and the policy stays consistent with the Mac side of the same fleet.

← All guides