Reliably Enabling Location Services on Intune-Enrolled Devices – My Production-Tested Solution

by

Devices enrolled in Microsoft Intune often have their location settings locked down by default — While administrators can (and often do) intentionally restrict location services for security and compliance reasons, the default behaviour in many Intune configurations ends up locking or graying out the setting even when it’s not strictly required.

The native Intune policies are often inconsistent — sometimes the toggle is completely grayed out, other times the setting reverts after a reboot, or location services simply don’t behave as expected. After dealing with these frustrations across many high-profile clients, I developed a robust, production-tested PowerShell solution that reliably enables location services on Intune-managed Windows devices.

The background of the issue

If you work in Intune-managed environments, especially within a Managed Service Provider (MSP), you have likely encountered the following restriction.

The frustrating dilemma with the image above is that this is not an enforced policy, but rather an irritating default setting for Intune-enrolled devices.

You may be thinking, well this isn’t that big of a deal. We know the local administrator credentials, we can just log in with the account, flip the toggle, sign back in as the standard user, and hooray! Everything works. This approach is fine if you manage a small fleet of devices, but for organisations that manage hundreds of devices, this simply is not feasible.

You might wonder why location services are even necessary and what their practical use is. Well when working with clients who schedule back-to-back meetings but also travel frequently, we have come across instances where their time zones don’t update automatically. This has caused them to miss meetings because the times still display in their home time zone rather than their current location.

This is where related issues occur—Automatic Timezone functionality is restricted behind Location Services being enabled, and ultimately requires User Account Control (UAC) permission to change the setting.

So why not just deploy an Intune policy?

While Intune can meet our objectives, in my experience and that of many colleagues, it requires location services to be enabled for all applications, without allowing standard users to disable them individually. This creates serious privacy and security issues, as location access is granted to every app by default rather than being restricted to only essential ones—resulting in a situation worse than having location services completely turned off.

So, if deploying an Intune policy won’t fix that frustrating default setting, where does that leave us? Registry changes? Powershell scripts to deploy registry changes?

Or do we just Grant Administrator rights to all users within your organisation…. absolutely not.

Registry changes have been recommended and implemented before—effective in the past but increasingly unreliable in late 2025 and early 2026. The reality is that the provided registry solution has not consistently delivered results, and this inconsistency removes all confidence when deploying it in an enterprise environment.

What if told you, this can be resolved by one magical command.

What is the command?

C:\WINDOWS\system32\SystemSettingsAdminFlows.exe SetCamSystemGlobal location 1 Code language: CSS (css)

Running this command in an administrative PowerShell will instantly toggle the location services on, better yet this allows the user full ability to configure which applications can use location – a vast improvement on the Intune deployed policy/configuration that gives you no freedom.

This command is not new; it has been available for some time if you’ve searched thoroughly. While the command works well, it doesn’t fully resolve all the issues. For instance, you still need to run it from an administrative PowerShell/CMD, which means it remains a manual process to execute it on each machine individually.

However, its presence enables us to expand, and when I discovered it for the first time, it helped me find a practical solution and proceed down an avenue I thought was blocked.

As for the TimeZone issues – do not worry, it has a brother which can achieve the same thing!

C:\WINDOWS\system32\SystemSettingsAdminFlows.exe SetTimeZoneAutoUpdate 1 Code language: CSS (css)

Registry still serves a purpose

While I noted inconsistencies with the registry changes, the effective solution still relies on the registry. This is because there is no reliable method to determine whether a device’s location is enabled or disabled using the previously mentioned command. For reference, the registry key in question is:

HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\CapabilityAccessManager\ConsentStore\location Value = Allow

Instead of relying on this as our complete solution, we can use it primarily as a detection tool. By automatically identifying devices that lack this key, we can pinpoint which devices require our command. Applying the registry change ensures that all future scans and detections will succeed.

In my role, we use the RMM software NinjaOne to handle a wide range of patching and maintenance tasks. Why we prefer this over Intune when it comes to patching and solutions like these is due to its configurability, speed, and seamless integration with our ticketing system, allowing efficient alerting and management. However, I don’t see why a standard detection/remediation script within Intune won’t achieve the same thing.

Our Evaluation (NinjaRMM) or Detection (Intune) script

While the specific code seen below is designed for NinjaRMM (hence the exit codes) I am sure with a little tweaking it can be adapted to an Intune Detection script that serves the same purpose.

<#
.SYNOPSIS
    Check if Location Services and Automatic Time Zone are enabled
.DESCRIPTION
    Evaluates:
    1. Location consent
    2. Location policy
    3. Automatic timezone detection
.NOTES
    Exit 0 = Compliant
    Exit 1 = Non-compliant
    Author = Dylan Peterson
#>

function Test-LocationAndTimezone {

    try {
        $isCompliant = $true

        # ----------------------------------------
        # 1. Location Consent
        # ----------------------------------------
        $consentPath = "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\CapabilityAccessManager\ConsentStore\location"

        if (Test-Path $consentPath) {
            $consent = (Get-ItemProperty -Path $consentPath -ErrorAction Stop).Value
            Write-Output "Location Consent: $consent"

            if ($consent -ne "Allow") {
                Write-Output "Exception: Location services not allowed"
                $isCompliant = $false
            }
        }
        else {
            Write-Output "Exception: Location consent registry path missing"
            $isCompliant = $false
        }

        # ----------------------------------------
        # 2. Location Policy
        # ----------------------------------------
        $policyPath = "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System"

        if (Test-Path $policyPath) {
            $policy = (Get-ItemProperty -Path $policyPath -Name EnableLocation -ErrorAction SilentlyContinue).EnableLocation
            Write-Output "EnableLocation Policy: $policy"

            if ($policy -eq 0) {
                Write-Output "Exception: Location disabled via policy"
                $isCompliant = $false
            }
        }

        # ----------------------------------------
        # 3. Automatic Time Zone
        # ----------------------------------------
        $tzPath = "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\DateTime"

        if (Test-Path $tzPath) {
            $tz = (Get-ItemProperty -Path $tzPath -ErrorAction Stop).AutoTimeZoneUpdate
            Write-Output "AutoTimeZoneUpdate: $tz"

            if ($tz -ne 1) {
                Write-Output "Exception: Automatic timezone not enabled"
                $isCompliant = $false
            }
        }
        else {
            Write-Output "Exception: DateTime registry path missing"
            $isCompliant = $false
        }

        # ----------------------------------------
        # Final Result
        # ----------------------------------------
        if ($isCompliant) {
            Write-Output "COMPLIANT: Location and timezone settings are correct"
            exit 0
        }
        else {
            Write-Output "NON-COMPLIANT: One or more checks failed"
            exit 1
        }

    }
    catch {
        Write-Output "Fatal Exception: $($_.Exception.Message)"
        exit 1
    }
}

# Run check
Test-LocationAndTimezoneCode language: PHP (php)

What exactly is this script doing?
Well remember I said we still needed the registry, this utilises those values to determine if remediation is required.

  1. Location Consent – The old “solution” it will search for the location key and see if Value is set to ‘Allow’, if the key doesn’t exist or the value is ‘Deny’, it will return Non-Compliant.
  2. Location Policy – As a fail safe, we check if a (GP) policy is present and if so report non-compliant.
  3. Automatic Time Zone – The last check is for our Automatic TimeZone configuration, again if the key is different/missing it will return non-compliant.

If any steps return Non-Compliant, our remediation script will fire.

Our Remediation (NinjaRMM/Intune)

$registryPath = "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\CapabilityAccessManager\ConsentStore\location"
$valueName    = "Value"
$desiredValue = "Allow"

$adminFlowExe = "$env:SystemRoot\System32\SystemSettingsAdminFlows.exe"

try {
    # ------------------------------------------------
    # Enable app-level location consent
    # ------------------------------------------------
    if (-not (Test-Path $registryPath)) {
        throw "Registry path not found: $registryPath"
    }

    $currentValue = (Get-ItemProperty -Path $registryPath -Name $valueName -ErrorAction Stop).$valueName
    Write-Output "Current registry value: $currentValue"

    if ($currentValue -ne $desiredValue) {
        Set-ItemProperty -Path $registryPath -Name $valueName -Value $desiredValue -ErrorAction Stop
        Write-Output "Updated registry value to '$desiredValue'"
    }
    else {
        Write-Output "Registry already set correctly."
    }

    # ------------------------------------------------
    # Enable system-wide Location Services
    # ------------------------------------------------
    if (-not (Test-Path $adminFlowExe)) {
        throw "SystemSettingsAdminFlows.exe not found"
    }

    Write-Output "Enabling global Location Services..."
    Start-Process `
        -FilePath $adminFlowExe `
        -ArgumentList "SetCamSystemGlobal location 1" `
        -NoNewWindow `
        -Wait

    Write-Output "Location Services enabled."

    # ------------------------------------------------
    # Enable Automatic Time Zone Detection
    # ------------------------------------------------
    Write-Output "Enabling automatic time zone detection..."
    
    if (-not (Test-Path $adminFlowExe)) {
        throw "SystemSettingsAdminFlows.exe not found"
    }
    
    # Enable via SystemSettingsAdminFlows (preferred modern method)
    Start-Process `
        -FilePath $adminFlowExe `
        -ArgumentList "SetTimeZoneAutoUpdate 1" `
        -NoNewWindow `
        -Wait
    
    Write-Output "SystemSettingsAdminFlows Auto Time Zone command executed."
    
    # Ensure tzautoupdate service is enabled (Manual / Trigger Start)
    Set-ItemProperty `
        -Path "HKLM:\SYSTEM\CurrentControlSet\Services\tzautoupdate" `
        -Name "Start" `
        -Type DWord `
        -Value 3 `
        -Force
    
    # Ensure registry flag is set (fallback/consistency)
    New-Item `
        -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\DateTime" `
        -Force | Out-Null
    
    Set-ItemProperty `
        -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\DateTime" `
        -Name "AutoTimeZoneUpdate" `
        -Type DWord `
        -Value 1 `
        -Force
    
    # Restart service
    Restart-Service tzautoupdate -ErrorAction SilentlyContinue
    
    Write-Output "Automatic time zone detection configured."
}
catch {
    Write-Error "Failed to configure Location / Time Zone settings. $_"
    exit 1
}Code language: PHP (php)

Without delving into and explaining every line, we will just highlight the key functionality

App-level Location Consent It directly updates the Windows Capability Access Manager registry key to set location access to “Allow”. This ensures subsequent runs of our detection script will return compliant. This guarantees that our detection script will report compliance on subsequent runs. Since our ‘magic command’ is executed during remediation, we can confidently confirm that location services will be enabled.

System-wide Location Services This utilises Microsoft’s official SystemSettingsAdminFlows.exe to programmatically enable Location Services at the OS level—the same process used by Windows Settings. This approach is far more reliable than simply modifying registry keys.

Automatic Time Zone Detection The script activates this feature using the latest method and ensures the tzautoupdate service is correctly configured and running. We also ensure to configure the registry keys to stop ensure future runs of our detection script return compliant.

Final Thoughts

That’s it! If you’ve read the whole post, thank you — I really appreciate it. If you’ve already taken the script and put it into your own environment, that’s even better. Location services being locked or inconsistent has been a long-standing frustration in my day-to-day work, so finally having a reliable fix feels pretty good.

I’m sharing this because I know how painful these Intune quirks can be. If this helps even a few other technicians or MSPs save some time and headaches, then it’s done its job.

If you end up using the script and have any improvements, suggestions, or find edge cases I haven’t covered, please feel free to drop a comment below. I’m always happy to refine it further.

Thanks for reading, and happy deploying!

Leave a Comment