{"id":3158,"date":"2026-03-14T20:12:37","date_gmt":"2026-03-14T20:12:37","guid":{"rendered":"https:\/\/modern-workplace.uk\/?p=3158"},"modified":"2026-03-14T20:12:39","modified_gmt":"2026-03-14T20:12:39","slug":"microsoft-intune-taking-back-control-of-geolocation-in-edge-one-site-at-a-time","status":"publish","type":"post","link":"https:\/\/modern-workplace.uk\/?p=3158","title":{"rendered":"Microsoft Intune: Taking Back Control of Geolocation in Edge, One Site at a Time"},"content":{"rendered":"\n

<\/p>\n\n\n\n

Organisations that manage Microsoft Edge through Intune, at some point, could have configured the DefaultGeolocationSetting<\/span> policy. <\/p>\n\n\n\n

It gives you three options: allow geolocation for all sites, block it for all sites, or prompt the user every time. That’s been the extent of the available control for a while: a single global switch with no per-site granularity.<\/p>\n\n\n\n


The March 2026 Intune service release added two new settings to the Windows Settings Catalog that change this: Allow precise geolocation on these sites<\/span> and Block geolocation on these sites<\/span>. Both are Microsoft Edge policies surfaced through the Catalog under Microsoft Edge > Content settings.
They allow you to define per-URL exceptions on top of the global default, which is what most real-world deployments actually need.<\/p>\n\n\n\n

\n\n\n\n

Why the global setting isn’t enough<\/strong><\/p>\n\n\n\n


If you manage devices used for a mix of internal web applications and general internet browsing, the global setting forces you into an uncomfortable choice.
If you block geolocation entirely, you risk breaking internal applications that legitimately depend on location (like warehouse management tools, field service portals, maps integrations inside an intranet). If you allow it globally, however, you give every external site the ability to prompt the user for location access with no admin control over which sites can actually get it.
<\/p>\n\n\n\n

In practice, many tenant admins compromise with AskGeolocation (the default) which prompts the user each time) and leave it at that. This means the user makes the decision, not the policy. In a regulated environment or one with a strict data handling posture, that’s not always acceptable.
The two new per-site settings solve this properly.<\/p>\n\n\n\n

\n\n\n\n

What the settings actually do<\/strong><\/p>\n\n\n\n


Allow precise geolocation on these sites<\/em>
Policy name: PreciseGeolocationAllowedForUrls<\/span>
Microsoft’s documentation describes it as follows: this policy lets you specify a list of URL patterns for sites that are allowed to access the user’s high-accuracy geolocation without prompting for permission. If the policy is not configured, the DefaultGeolocationSetting value applies, or the user’s personal setting is used.
Reference: https:\/\/learn.microsoft.com\/en-us\/deployedge\/microsoft-edge-browser-policies\/precisegeolocationallowedforurls<\/a>
The key phrase here is without prompting: the site gets location access with no browser prompt shown to the user. That makes it appropriate only for internal applications you explicitly trust.<\/p>\n\n\n\n


Block geolocation on these sites<\/em>
Policy name: GeolocationBlockedForUrls<\/span>
This policy defines a list of URL patterns for sites that are blocked from accessing the user’s geolocation. According to the documentation, these sites also cannot prompt the user for location permissions at all: the permission request is suppressed entirely.
Reference: https:\/\/learn.microsoft.com\/en-us\/deployedge\/microsoft-edge-browser-policies\/geolocationblockedforurls<\/a><\/p>\n\n\n\n


If neither policy is configured for a given site, DefaultGeolocationSetting applies as the fallback.<\/p>\n\n\n\n

\n\n\n\n

The policy hierarchy<\/strong>
It is worth being explicit about the order of precedence, as misconfiguration here produces unexpected behaviour:<\/p>\n\n\n\n