This was such an annoying issue to solve, but I learned a lot from figuring it out.
This story is what inspired me to create this blog in the first place, to help others, hopefully you enjoy!
The Problem:
We have a customer with an office located in Brisbane, Australia, who has a pretty standard setup – Windows 11 Laptops, Cisco Networking, ZScaler for Internet Security, Ethernet to every desk, a common IT SOE.
However, a couple of weeks ago we started seeing hints of an issue with some of the laptops, users were reporting that their device timezone kept changing to Adelaide (which is 2 hours behind), and then back to Brisbane randomly.
This seemed like just a temporary thing at first, but it started getting worse, it went from 1 to 2 laptops, to 5, to 10, to the whole office, it was obvious something had gone wrong, so I started looking into it.
How are Timezones automatically updated on Windows?
You ask a Desktop Support guy this question, and they’d probably say “oh it’s from AD/GPO”, or “it’s from the NTP server”, or “it’s from the switch/DHCP server”, but is that actually true? – Nope – Turns out Windows Exclusively uses location for automatic Timezones.
Specifically, the below are used:
- GPS : accurate within approximately 10 meters. You won’t find many (if any) corporate laptops with GPS built-in, so I haven’t spent much time poking at this path.
- Wi-Fi : accurate within approximately 30 meters – 500 meters. This method works by scanning the surrounding Network at all times when Wi-Fi is turned on (even if you aren’t actually connected to Wi-Fi), Windows also doesn’t care if you are using Ethernet, it will still scan.
There is ZERO public documentation of the “algorithm” or “scoring logic” that Windows uses for this, we just know that it looks at nearby BSSID’s (usually the same as the MAC address, though Microsoft only ever calls them MAC’s) then checks the Microsoft geolocation database which we aren’t allowed to even see – at least not anymore. - Cell towers : accurate within approximately 300 meters – 3,000 meters. This is a good one, it might not be the most precise, but it’s highly likely to be accurate, of course this is only available on devices with a cellular modem, however it apparently does not require an active service or even a SIM card, it uses the Microsoft Geolocation Database similar to the Wi-Fi method.
- IP address: accurate within approximately 1,000 meters – 5,000 meters. As many IT folks know, IP‑based location services aren’t very precise and can be wrong at times – IP addresses change often, and IP‑to‑location databases quickly become outdated. Microsoft maintains its own database for this, but in my experience, Windows only falls back to it when WI‑Fi based location is low-confidence/accuracy.
The system automatically selects the most appropriate location source based on availability, accuracy requirements, and power consumption considerations. – Microsoft
How Timezones are NOT updated on Windows:
- NTP – So the thing about Network Time Protocol, is it has zero concept of timezones, it uses UTC time, always, it leaves timezone settings up to the OS of the client. Interestingly, Windows actually uses UTC behind the scenes for everything and just applies your timezone offset to stuff that is user facing, who knew.
- Active Directory – AD actually has a protocol for syncing time from DC’s that is built off of (but also distinct to) NTP, it’s barely documented, but it’s called MS-SNTP. MS-SNTP is enabled by default in AD for all clients, except if you are running under a hypervisor (then Windows shrugs and uses the HV), but both will never set timezones, only time.
- DHCP – If you are well versed in DHCP options, you may know about option 101, which allows you to configure a timezone to be available from DHCP. However, rather annoyingly, Windows won’t ever request this option from the DHCP server, not on its own. There’s a good doc here about getting Windows to pull this from DHCP and actually use it, but by default the data never goes to the Windows client, so… nope.
- Network switches/firewalls – Fairly obvious, these don’t play any part in Timezones being set, if a switch clock is set to Antarctica it doesn’t matter (looking at you network engineers). Similarly to DHCP, the 802.11v protocol does have some capability to advertise timezones (from WAP’s in this case), but this is rarely implemented in networking hardware, OpenWRT appears to support it, but Windows does not use it anyway.
- Group Policies/Intune – Timezones are rarely set by Group Policy, it would only make sense if you have a single office location and/or had a robust policy that applied based on user/device location. We haven’t seen any customers with a setup like this, so in 90% of cases I would immediately rule out any policies as being the source of your device Timezones. That being said, it can be done.
So what’s causing our problem?
This is the tricky part, figuring out what location source Windows is getting the wrong information from.
Let’s start with logs, in addition to the notification the user gets, the following event is logged (event ID 1). As you can see, the change is coming from svchost.exe, so this is almost certainly the “Auto Time Zone Updater” service completing its regular check-in.
Alright, so we know when changes are happening, but we don’t know why. Let’s check for more logs, right? – Nope. This is it.
Windows keeps its location tracking methods close to the chest. It won’t tell you which source it used, and it offers no real diagnostics. So when something goes sideways, we’re essentially on our own.
Screw it, I’ll make my own troubleshooting tool.
I wasn’t going to sit in front of a laptop all day, wait for the device timezone/location to be wrong and then quickly troubleshoot for the few minutes I had each time, there had to be a better way.
So I spun up PowerShell ISE and wrote a script to monitor the issue and collect data for troubleshooting. This is what is does:
It’s fairly barebones, it uses GeoCoordinateWatcher to pull coordinates, looks them up against OpenStreetMap, and simultaneously scans nearby access points with netsh to capture BSSIDs. It grabs this data every 15 seconds. It’s a bit of a patchwork tool, and there’s plenty of room for refinement, but it collected exactly what I needed.
Add-Type -AssemblyName System.Device
$watcher = New-Object System.Device.Location.GeoCoordinateWatcher
$watcher.Start()
Start-Sleep 2
# CSV log files
$logFile = "$env:USERPROFILE\location_log.csv"
$alertFile = "$env:USERPROFILE\location_alerts.csv"
# Create CSV headers if files don't exist
if (-not (Test-Path $logFile)) {
"Timestamp,Latitude,Longitude,Accuracy,City,State,Country,Source,PublicIP,SSIDs,BSSIDs" | Out-File $logFile -Encoding UTF8
}
if (-not (Test-Path $alertFile)) {
"Timestamp,Latitude,Longitude,Accuracy,City,State,Country,Source,PublicIP,SSIDs,BSSIDs" | Out-File $alertFile -Encoding UTF8
}
while ($true) {
# Wait for a valid location fix
$loc = $watcher.Position.Location
if ($loc -eq $null -or ($loc.Latitude -eq 0 -and $loc.Longitude -eq 0)) {
Write-Host "Waiting for location fix..."
Start-Sleep 5
continue
}
$accuracy = $loc.HorizontalAccuracy
$lat = $loc.Latitude
$lon = $loc.Longitude
# Source Classification
if ($accuracy -le 20) {
$source = "GPS"
}
elseif ($accuracy -le 80) {
$source = "Likely WiFi"
}
elseif ($accuracy -le 300) {
$source = "WiFi"
}
elseif ($accuracy -le 600) {
$source = "WiFi/Cell"
}
elseif ($accuracy -le 1200) {
$source = "Likely Cell"
}
elseif ($accuracy -le 2500) {
$source = "Cell/IP"
}
elseif ($accuracy -le 5000) {
$source = "Likely IP"
}
else {
$source = "Unknown/Hybrid"
}
# Public IP
try {
$publicIP = (Invoke-RestMethod -Uri "https://api.ipify.org?format=json").ip
} catch {
$publicIP = "Unavailable"
}
# Wi-Fi SSID + BSSID scan
try {
$wifiScan = netsh wlan show networks mode=bssid
$ssidMatches = @()
$bssidMatches = @()
foreach ($line in $wifiScan) {
if ($line -match '^\s*SSID\s+\d+\s+:\s+(.*)$') {
$ssidMatches += $Matches[1].Trim()
}
elseif ($line -match '^\s*BSSID\s+\d+\s+:\s+([0-9a-fA-F:]+)') {
$bssidMatches += $Matches[1].Trim()
}
}
if (-not $ssidMatches) { $ssidMatches = @("None found") }
if (-not $bssidMatches) { $bssidMatches = @("None found") }
$ssidCSV = '"' + ($ssidMatches -join "; ") + '"'
$bssidCSV = '"' + ($bssidMatches -join "; ") + '"'
} catch {
$ssidCSV = "Unavailable"
$bssidCSV = "Unavailable"
}
# Reverse geocoding
try {
$geo = Invoke-RestMethod -Uri "https://nominatim.openstreetmap.org/reverse?format=json&lat=$lat&lon=$lon"
if ($geo.address.city) { $city = $geo.address.city }
elseif ($geo.address.town) { $city = $geo.address.town }
elseif ($geo.address.suburb) { $city = $geo.address.suburb }
else { $city = "Unknown" }
if ($geo.address.state) { $state = $geo.address.state } else { $state = "Unknown" }
if ($geo.address.country) { $country = $geo.address.country } else { $country = "Unknown" }
# Normalise specific cities
if ($city -match 'Brisbane') { $city = "Brisbane" }
} catch {
$city = $state = $country = "Unknown"
}
# Construct CSV line
$csvLine = "{0},{1},{2},{3},{4},{5},{6},{7},{8},{9},{10}" -f `
(Get-Date -Format "yyyy-MM-dd HH:mm:ss"), $lat, $lon, $accuracy, $city, $state, $country, $source, $publicIP, $ssidCSV, $bssidCSV
# Output to console
Write-Host $csvLine
# Append to CSV logs
Add-Content -Path $logFile -Value $csvLine
if ($city -ne "Brisbane") { Add-Content -Path $alertFile -Value $csvLine }
Start-Sleep 15
}So I found a few affected users, set it to run quietly in the background, and logged about an hour’s worth of data.
Before I wrote this script, I had a hunch that the issue was somehow ZScaler related, since they don’t have any Brisbane datacentres (at least with our contract right now) and our egress IP through ZIA appeared in Sydney. We raised a ticket with them early on, (because it couldn’t hurt) and 2 days later got a response from them.
We have confirmed that this issue is not related to Zscaler, as Zscaler does not set or modify user timezones.
we recommend checking with your internal IT team, specifically focusing on your Windows/Active Directory (AD) settings, as these are the most likely sources of the timezone changes.
It seems that they didn’t really understand the issue, which was a common problem when trying to get any engineering/vendor help on this. If our Timezone was changing to Sydney instead of Adelaide, we would have pushed them further as this would be directly caused by ZIA.
Anyway, from my script it was pretty clear that the public IP address was not changing at all, which ruled out ZScaler, and based on the accuracy field, it aligned perfectly with the Wi-Fi scanning accuracy expected in metres.
So if we disable Wi-Fi it should stop scanning, and we can see if the issue goes away? Yep, I turned off WLAN on the affected devices and none of them changed their location from Brisbane, perfect.
So this means that Microsoft’s Wi-Fi location database is wrong for this location, but if that’s the case it should be affecting the business next door too, right?
So I spoke to the IT team from the business next door, and confirmed that they have the exact same issue, with Adelaide as well, and they have a completely separate network to us, wild.
Now, how do we fix this?
Well, for most customers, it’d be pretty simple, just disable automatic Timezones on Windows, you could push this via Intune or GPO pretty easily, it’s well documented.
For our customer, though, this wasn’t a valid option, for these reasons:
- Users travel a lot as part of their roles, and the customer would like Timezones to be automatically updated for them.
- Users are not comfortable managing the system Timezone themselves.
- Service Desk don’t have the capacity to be fielding calls for incorrect system times.
- The customer would like the core issue to be resolved rather than using a band-aid solution (fair enough).
Let’s get Microsoft to fix the Geolocation Database.
This is the next logical step, log a support ticket with Microsoft, tell them the problem, give them any data they need, and they should be able to fix it just fine, people seemed to have luck with this, though apparently it’s quite a long and painful process.
So we logged an MS ticket, SEV B (as we’ve since had a second location affected), and we’ll see where it goes.
Thank you. Your request was successfully submitted to Microsoft Support.
We actually logged our ticket through SoftwareOne, which handles vendor management for this customer via their USMV program, they helped a little at getting this through to MS.
This cost our customer some of their USMV credits, which is kind of wild to think about, considering this is a Microsoft issue and we don’t actually need technical support – we just need Microsoft to fix their problem, but this is basically our only channel to go through.
SoftwareOne had us get a bunch of things, the usual rubbish:
- When did the issue start?
- Has it happened before?
- Timestamp when the timezone flipped
- Whether the device roamed between APs
Microsoft’s first actual response was:
Are all the impacted machines Windows 11 24H2?
Does timezone change for all devices to the same location or random?
Was there any Wi-Fi access point from one location to another?
Please collect the below TSS logs.
Here we go, now we’re getting somewhere, the TSS logs gather exactly what Microsoft needs to fix the problem, and (annoyingly) a bunch of the other system information we have already provided.
So we just downloaded the file here. Ran the command requested below, and then uploaded the logs to a file transfer link they provided.
.\TSS.ps1 -NET_GeoLocation5 days pass
I have analysed the logs, please refer them and advise a timeframe to discuss with you.
Please could you refer to the below BSSIDs and MAC’s, verify and confirm if they belong to your office network.
Attached were a bunch of logs, with a row similar to below, that had 79 different BSSID’s.
WifiMACs=aa11bb22cc01,-36,aa11bb22cc02,-35,aa11bb22cc0e,-52,aa11bb22cc0f,-52,bb22cc33dd10At the end of the post I’ll also go into some findings from these logs 🙂
Our Network Engineer replied back, and we’re now waiting for a new response, with Christmas approaching soon we expect some more delays here.
Update 2:
1 day later
Can you provide the Latitude and Longitude of the office?
Sure.
another day passes…
Here is a confirmation of the change we will be making, including the BSSID’s that will be updated.
Sounds good, let’s do it.
4 business days pass, reply comes in on christmas eve..
The changes have been implemented at our backend database. It normally takes 72 hours to propagate the changes at your end.
You can verify after 72 hours if the changes are reflecting, if not then run the below commands from the admin prompt to delete the geolocation cache manually.
net stop lfsvc del C:\ProgramData\Microsoft\Windows\LfSvc\Cache /s /q net stop lfsvc
Alright cool.
I was on leave so my first opportunity to test was 2 weeks later, and it was all looking good!
So yes, Microsoft did fix this for us but keep in mind:
- It took 12 business days of emails with them.
- We needed to allocate our own resources to gather data for Microsoft, from the Desktop Support and Networking side.
- Contacting Microsoft required us to use paid support credits, other channels would likely be much slower.
- Microsoft requested we confirm which BSSID’s we owned, implying that we can’t fix problematic AP’s/BSSID’s that are not company owned, however they do not seem to verify ownership in any way, and a BSSID scan from the site was sufficient.
- This was an issue in Microsoft’s commercial database, which we helped them improve by allocating our own time and resources, to gather logs and confirm Network data.
- Our work here will benefit Microsoft (commercially) and impact any other business (or Windows Device) in range of the impacted BSSID’s as well.
- A separate Microsoft ticket was required to be raised for each additional site that was affected (this may incur fees).
What else could we have done?
Well, if you don’t want to go the Microsoft route, there’s a few things you can try.
- If you have an Android device, you can apparently run this app and walk around your building for 10 minutes, a poster claimed that this resolved the geolocation database issue for Windows about 2 weeks later.
- You could set up windows to use a different geolocation database from the Microsoft one, this wasn’t feasible for us as it’s a bit too hacky, and we’d end up in a 6 week long conversation about which database to use.
- You could swap your entire laptop fleet to models that include Cellular radios and/or GPS (good luck).
- You can configure a “Default Location” on Windows via settings, which can override the location provided by Windows other built-in location providers, however documentation from Microsoft here is very lacking. All Microsoft says is that this is used “when a more exact location can’t be detected”, maybe it just applies in low confidence/accuracy scenarios then, we don’t know. It also doesn’t appear to be possible to configure this via a policy, as the data is seemingly not stored in the registry and can’t be identified by Process Monitor.
- You can request to exclude the nearby WAP’s BSSID’s from the Microsoft geolocation database, which I’m not sure is even legal if you don’t own all the nearby hardware. Microsoft may completely ignore your request “if it seems problematic”, and apparently, this also isn’t a permanent fix.
- If you have patience, you could wait for the issue to resolve itself. No, seriously, the database gets updated by Windows devices all the time as they scan the area, so eventually it might just be fixed. Logically, if you have a Windows device with cellular and/or GPS in the area, the location accuracy should also improve, and faster.
- If your users only travel between different company offices, you could configure Timezones via DHCP and force Windows to use them, but this would only work on your Networks and would need manual intervention from users/IT anywhere else.
- If users workflow allows, you could disable Wi-Fi entirely, to force Windows to rely purely on IP based location, if you use a proxy/internet security service like ZScaler though you’ll need to make sure the egress IP is in the desired Timezone.
- You can always build your own geolocation database, perhaps make a policy/script that has a list of known IP addresses, SSID’s, whatever you like and force timezones from that, however this is only possible if you know every location that a user might need to work from.
- The last option is to just deal with the issue, if it’s not that impactful to your environment then you can choose to ignore it.
Undocumented Findings:
Our response from Microsoft included some logs from our device that are not visible in event viewer, and it reveals a bit about how the location service works (this guy had luck pulling them too). I won’t post our whole output, as it’d take me a while to anonymise it, but here are some interesting findings.
1. Windows Prioritises Wi-Fi over IP
Although Microsoft mentions that Windows uses “Wi-Fi, IP address, Cellular, and GPS,” the logs show a clear priority order and a provider evaluation system called PE’s. I saw this in practice as our office IP was very rarely used for location, lfsvc almost always uses Wi-Fi.
[Debug ] [Cpe] TotalPeCount=5, AvailPes=[Wifi,IpAddr,Unknown,Unknown,Unknown]
[Debug ] Acquire[...] SelectedPes: PrimaryPe=Wifi2. Windows treats consent from users and policies differently
We can see here that Windows records whether location consent was provided via policy or via users. What Windows does with that information is unknown.
[Microsoft.Geolocation.Service] [Permission_IsLocationServiceHasAccessThroughGlobalSwitchOrPolicy] consentGranted=1, consentGrantedByPolicy=03. Windows also captures RSSI and channels for Wi-Fi based Location
We can see that Windows is sending the RSSI and channel information of nearby WAP’s (in addition to the BSSID’s) to the server http://inference.location.live.com
[Microsoft.Geolocation.Service.PII] [WebproxyRequest] RequestId=random, RequestType=2, serviceUrl=https://inference.location.live.net/inferenceservice/v21/pox/GetLocationUsingFingerprint, TrackingId=dd159-redacted-removed, RequestPayload=<?xml version="1.0" encoding="UTF-8"?>
BeaconFingerprint><Detections><Wifi7 cf="2412" BssId="08:7b:87:se:cr:et" rssi="-36" /><Wifi7 cf="2412" BssId="08:7b:87:se:cr:et" rssi="-35" /><Wifi7 cf="5240" BssId="08:7b:87:se:cr:et" rssi="-52" /><Wifi7 cf="5240" BssId="08:7b:87:se:cr:et" rssi="-52" /><Wifi7 cf="2462" BssId="08:7b:87:se:cr:et" rssi="-45" /><Wifi7 cf="2462" BssId="08:7b:87:se:cr:et" rssi="-43" /><Wifi7 cf="5500" BssId="08:7b:87:se:cr:et" rssi="-43" /><Wifi7 cf="5500"4. Windows sends a lot of information about your endpoint to Microsoft.
The location service captures the following information about your computer.
- OS Version (the specific build number)
- Device type and platform architecture (e.g. PC, x86/ARM)
- Device ID (uniquely identifies your device on their servers)
- Device Manufacturer (e.g. Lenovo)
- Your exact device model (e.g. 20VYS2VH00)
<GetLocationUsingFingerprint xmlns="http://inference.location.live.com" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"><RequestHeader><Timestamp>2025-12-05T02:49:30.980+00:00</Timestamp><Authorization /><TrackingId>dd159-redacted-removed</TrackingId><ApplicationId>redacted-and-removed-caf98-98dasd-9a8sdua8</ApplicationId><DeviceProfile OSVersion="26100.1.amd64fre.ge_release.240331-1435" LFVersion="4.0" DeviceType="PC" Platform="" DeviceId="redacted-aaf2-removed-for-post" ExtendedDeviceInfo="LENOVO/20VYS2VH00" ClientGuid="00000000-0000-0000-0000-000000000000" /></RequestHeader><BeaconFingerprint><Detections><Wifi7 cf="2412" BssId="08:7b:87:se:cr:et" rssi="-36" /><Wifi7 cf="2412" BssId="08:7b:87:se:cr:et" rssi="-35" /><Wifi7 cf="5240" BssId="08:7b:87:se:cr:et" rssi="-52" /><Wifi7 cf="5240" BssId="c8:9e:43:se:cr:et" rssi="-73" /></Detections></BeaconFingerprint></GetLocationUsingFingerprint>5. The problematic database is provided by Qualcomm..
In the logs we can see the below.
<ResolverStatus Status="Success" Source="SkyhookExternal"/>This is the source of the location data Windows is using in our setup, and other environments.
We can read more about Skyhook Wireless here, they were acquired by Qualcomm around 2022, and they provide “Qualcomm Aware Positioning Services”.
Again, this is all undocumented, Windows might use different databases in different locations around the world, and accuracy can vary, I am just documenting what I’ve seen with our environment.
Sidenote, I’ve contacted Qualcomm using the form here, which has options to create technical support requests, but I get the feeling it all goes to their sales team. If we can go through them to get the database updated that would help a lot, I’ll update on how I go.
Update on contacting Qualcomm:
I got some replies from their sales team, who seemed very confused at first with what I was asking.
We can’t seem to find any record of a commercial contract with your organization.
Could you please confirm if you operate under a different entity or share a copy of the commercial agreement under which your company is using our service?
I then explained the issue, and asked if there were options to submit improvements to the database, or even if there was paid support available.
No response.
I guess Qualcomm is too important for us, even if we’re just here to improve their product, at no cost to them.
6. Windows Applies Rate Limiting “Budgets”) to Location Requests
This behaviour is completely undocumented. Logs show a budget system, presumably to prevent excessive scanning:
[Budget_Replenished] remainingBudget=3, maxBudget=3, timeWindowS=10And that’s it.
As of writing this, our problem is ongoing, we’ve passed the issue on to Microsoft and once we hear back I’ll update this article. Our customer isn’t particularly interested in any of the available workarounds, so that leaves us standing around, for now.
Leave a Reply