Skip to content
English
Go to senturo.com
  • There are no suggestions because the search field is empty.

How to Enable Windows Location Services via Group Policy and PowerShell

Ensure Senturo Can Reliably Report Device Locations on Domain-Joined Windows Devices

Overview

For Senturo to accurately track Windows device locations, the Windows Location Services stack must be enabled and permitted to share location data with applications. On domain-joined devices managed through Active Directory, this is best enforced using Group Policy Objects (GPOs) rather than relying on end users to configure their own settings.

This article covers two deployment methods for environments that use Active Directory Group Policy:

  • Group Policy — The recommended approach for domain-joined devices. Policies are applied at the computer level, enforced centrally, and survive user logon changes.
  • PowerShell Script — An alternative for scenarios where Group Policy is unavailable or impractical, or to supplement GPO deployment for settings that require direct registry or service configuration.

Both methods configure the same four areas required for reliable Senturo location reporting: the location consent store, the app privacy policy, the Location and Sensors policy, and the underlying Windows services (lfsvc and WlanSvc).

Looking for the Microsoft Intune method? See How to Enable Windows Location Services via Intune with Senturo.

Method 1: Group Policy

This method uses four GPO settings that together fully enable and lock Windows Location Services at the device level.

Step 1: Open the Group Policy Management Console

  1. On your domain controller or management workstation, press Win + R, type gpmc.msc, and press Enter.
  2. In the Group Policy Management Console, navigate to the OU containing your Windows devices.
  3. Right-click the OU and click on Create a GPO in this domain, and Link it here.
  4. Enter a name for the GPO, for example: Senturo – Enable Location Services.
  5. Click on OK, then right-click the newly created GPO and click on Edit.

Step 2: Configure Location and Sensors Policy

This setting ensures that the Windows location platform is not blocked by policy.

  1. In the Group Policy Management Editor, navigate to: Computer Configuration > Administrative Templates > Windows Components > Location and Sensors
  2. In the right pane, double-click on Turn off location.
  3. Set the policy to Disabled.
  4. Click on OK.

Why this matters: Setting "Turn off location" to Disabled means the policy is actively not blocking location — location services are permitted. If this policy were set to Enabled, Windows would block location system-wide regardless of other settings.

Step 3: Configure App Privacy Policy

This setting forces Windows apps and services to access location without requiring end-user approval.

  1. Navigate to: Computer Configuration > Administrative Templates > Windows Components > App Privacy
  2. Double-click on Let Windows apps access location.
  3. Set the policy to Enabled.
  4. Under Default for all apps, set the value to Force Allow.
  5. Click on OK.

Why this matters: This policy controls whether apps can access location data. Setting it to Force Allow ensures Senturo can access location without the user needing to grant permission manually, and prevents users from revoking access.

Step 4: Configure Registry Preference (Location Consent Store)

This sets the Windows location consent value to Allow at the machine level via Group Policy Preferences.

  1. Navigate to: Computer Configuration > Preferences > Windows Settings > Registry
  2. Right-click in the right pane and click on New > Registry Item.
  3. Configure the registry item with the following values:
    Field Value
    Action Update
    Hive HKEY_LOCAL_MACHINE
    Key Path SOFTWARE\Microsoft\Windows\CurrentVersion\CapabilityAccessManager\ConsentStore\location
    Value name Value
    Value type REG_SZ
    Value data Allow
  4. Click on OK.

Why this matters: The ConsentStore\location registry key is what Windows reads to determine whether the location toggle is on or off. Setting it to Allow via Group Policy Preferences ensures the master location toggle is on at the system level, complementing the policy settings applied in Steps 2 and 3.

Step 5: Configure Required Services

This ensures the Windows Location Service and Wi-Fi service start automatically and are running.

  1. Navigate to: Computer Configuration > Preferences > Control Panel Settings > Services
  2. Right-click and click on New > Service.
  3. Configure the first service entry:
    Field Value
    Service name lfsvc
    Startup type Automatic
    Service action Start
  4. Click on OK.
  5. Repeat the process to add a second service entry:
    Field Value
    Service name WlanSvc
    Startup type Automatic
    Service action Start
  6. Click on OK.

Why this matters: lfsvc is the Windows Geolocation Service — it must be running for location data to be collected and reported. WlanSvc (WLAN AutoConfig) enables Wi-Fi scanning, which is the primary method Senturo uses to determine the devices location. Both services should be running for the most accurate and reliable location reporting.

Step 6: Verify Policy Application on a Device

Once the GPO has propagated (typically within 15–30 minutes, or after the next Group Policy refresh cycle):

  1. On a target Windows device, open Command Prompt as an administrator and run:
   gpupdate /force
  1. After the update completes, navigate to Settings > Privacy & security > Location.
  2. Confirm that:
    • Location services is set to On.
    • The banner "Some of these settings are managed by your organization" is displayed.
    • Let apps access your location is set to On.
  3. To verify policy receipt, open a browser and navigate to chrome://policy (if using Chrome) or run the following in Command Prompt:
   gpresult /r

Confirm the Senturo – Enable Location Services GPO appears under Applied Group Policy Objects.

Method 2: PowerShell Script

For environments where Group Policy is not available — or where you need to deploy location settings quickly outside of a domain context — Senturo provides a PowerShell script that applies the same configuration programmatically.

The script performs the following actions:

  1. Sets the Windows location consent store to Allow
  2. Forces apps to access location (LetAppsAccessLocation = 1)
  3. Sets the Location and Sensors policy to permit location (DisableLocation = 0)
  4. Configures lfsvc (Geolocation Service) to start automatically
  5. Configures WlanSvc (WLAN AutoConfig) to start automatically
  6. Logs all actions to C:\ProgramData\Senturo\Senturo-Location.log

Run as: Administrator or SYSTEM context. The script must be run with elevated privileges to modify HKLM registry keys and service startup types.

Script

Copy the code below, save it as a .ps1 file (e.g., Senturo-Enable-Location.ps1), and deploy it to your devices using your preferred mechanism (Intune, SCCM/MECM, logon script, or manual execution).

# =============================================================================
# Senturo - Force Enable Location + WiFi for Tracking
# What it does:
#   1. Turns Location Services ON
#   2. Allows apps to access location
#   3. Prevents end user from turning it off
#   4. Ensures Geolocation + WLAN services are running
# Run as: Administrator or SYSTEM
# =============================================================================

$ErrorActionPreference = 'Continue'

$LogFile = 'C:\ProgramData\Senturo\Senturo-Location.log'
$LogDir  = Split-Path $LogFile
if (-not (Test-Path $LogDir)) { New-Item -Path $LogDir -ItemType Directory -Force | Out-Null }

function Log {
    param([string]$msg)
    $line = "$(Get-Date -Format 'yyyy-MM-dd HH:mm:ss')  $msg"
    Add-Content -Path $LogFile -Value $line
}

Log "=== Senturo location script start on $env:COMPUTERNAME ==="

# --- 1. Turn the master Location toggle ON --------------------------------
$consent = 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\CapabilityAccessManager\ConsentStore\location'
try {
    if (-not (Test-Path $consent)) { New-Item -Path $consent -Force | Out-Null }
    Set-ItemProperty -Path $consent -Name 'Value' -Value 'Allow' -Type String -Force
    Log 'Location ConsentStore set to Allow'
} catch { Log "ERROR ConsentStore: $_" }

# --- 2. Allow apps to access location -------------------------------------
$appPrivacy = 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\AppPrivacy'
try {
    if (-not (Test-Path $appPrivacy)) { New-Item -Path $appPrivacy -Force | Out-Null }
    # 1 = Force Allow, 0 = User in control, 2 = Force Deny
    Set-ItemProperty -Path $appPrivacy -Name 'LetAppsAccessLocation' -Value 1 -Type DWord -Force
    Log 'LetAppsAccessLocation set to Force Allow (1)'
} catch { Log "ERROR AppPrivacy: $_" }

# --- 3. Lock the toggle so user cannot turn location off ------------------
# Note: DisableLocation = 0 means "policy present, location enabled and locked"
# (Setting DisableLocation = 1 would lock it OFF - opposite of what we want)
$locSensors = 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\LocationAndSensors'
try {
    if (-not (Test-Path $locSensors)) { New-Item -Path $locSensors -Force | Out-Null }
    Set-ItemProperty -Path $locSensors -Name 'DisableLocation' -Value 0 -Type DWord -Force
    Log 'DisableLocation set to 0 (enabled, user cannot change)'
} catch { Log "ERROR LocationAndSensors: $_" }

# --- 4. Geolocation Service (lfsvc) ---------------------------------------
try {
    Set-Service -Name 'lfsvc' -StartupType Automatic -ErrorAction Stop
    Start-Service -Name 'lfsvc' -ErrorAction SilentlyContinue
    Log 'lfsvc set to Automatic and started'
} catch { Log "WARN lfsvc: $_" }

# --- 5. WLAN AutoConfig (WlanSvc) - needed for WiFi positioning -----------
try {
    $wlan = Get-Service -Name 'WlanSvc' -ErrorAction Stop
    Set-Service -Name 'WlanSvc' -StartupType Automatic -ErrorAction Stop
    Start-Service -Name 'WlanSvc' -ErrorAction SilentlyContinue
    Log 'WlanSvc set to Automatic and started'
} catch { Log "INFO WlanSvc not present or unavailable (desktop without WiFi): $_" }

Log "=== Done. Reboot recommended. ==="

Deployment Notes

  • Intune: Deploy as a PowerShell script under Devices > Scripts and remediations. Set Run this script using the logged-on credentials to No (run as SYSTEM).
  • SCCM/MECM: Deploy as a script or package with Run as: System and Allow users to interact with this program unchecked.
  • Manual / Testing: Right-click the .ps1 file and click on Run with PowerShell, or run from an elevated Command Prompt:
  powershell.exe -ExecutionPolicy Bypass -File "C:\Path\To\Senturo-Enable-Location.ps1"
  • Reboot: A device restart is recommended after the script runs for all changes to take full effect.

Reviewing the Log

The script writes a timestamped log to C:\ProgramData\Senturo\Senturo-Location.log. Review this file to confirm each step completed without errors. A successful run will end with:

=== Done. Reboot recommended. ===

Troubleshooting

Policy is not applying to devices: Confirm the GPO is linked to the correct OU and that the target devices are members of that OU. Run gpresult /r on a device to verify which GPOs are applied. Check for any WMI filters or security filtering on the GPO that may be excluding devices.

Location still shows as Off after GPO applies: Ensure no conflicting GPO or Intune policy is setting DisableLocation = 1 or overriding the App Privacy setting. Run gpresult /h C:\gpresult.html for a full policy report and check for conflicts. A device reboot may also be required.

lfsvc service fails to start: Some Windows security baselines disable lfsvc explicitly. Check Services (services.msc) to confirm the startup type and current state. If the service is missing, the Windows installation may be damaged — run sfc /scannow from an elevated Command Prompt.

WlanSvc not present: This is expected on desktop computers without a Wi-Fi adapter. The script handles this gracefully and logs an informational message rather than an error.

Script completes but location remains Off on the device: Verify the script ran as Administrator or SYSTEM. Check the log at C:\ProgramData\Senturo\Senturo-Location.log for any ERROR entries. A reboot is required after the script runs — location registry changes do not always take effect until the next Windows session.

Conclusion

Enabling Windows Location Services via Group Policy or PowerShell ensures that Senturo can consistently collect and report accurate device locations across your Windows fleet. The Group Policy method is the most durable approach for domain-joined environments, applying settings centrally and enforcing them across device restarts and user logon changes. The PowerShell script provides a flexible alternative for non-domain or hybrid scenarios, and can also be used to validate or remediate individual devices.

Once deployed, devices should begin reporting location data in Senturo. If Senturo location data is still not appearing after configuration, refer to the troubleshooting section above or contact support at support@senturo.com.

FAQs

Q: Which method should I use — Group Policy or PowerShell? A: If your devices are domain-joined and managed via Active Directory, Group Policy is the recommended approach as it enforces settings persistently and centrally. Use the PowerShell script if GPO is not available, for quick remediation of individual devices, or as a complement to GPO for service startup configuration.

Q: Do I need to configure all four GPO settings, or will one setting be enough? A: All four settings work together. The App Privacy policy controls whether apps can access location. The Location and Sensors policy controls whether the platform is blocked. The Registry Preference sets the system-level consent toggle. The Services settings ensure the underlying Windows services are running. Missing any one of these can result in incomplete or unreliable location reporting.

Q: Will these settings affect end users in any way? A: Users will see the message "Some of these settings are managed by your organization" in Settings > Privacy & security > Location, and will not be able to turn location off. This is expected behavior in a managed environment.

Q: What if WlanSvc is not present on a device? A: Desktop computers without a Wi-Fi adapter will not have WlanSvc. This is handled gracefully by both the Group Policy Services preference (it will simply not apply) and the PowerShell script (which logs an informational message).