Fixing Time Zone Issues in Windows Autopilot

Patch My Pc | install & update thousands of apps

Deploying Windows devices using Autopilot can be challenging, especially when devices are shipped from a supplier in China to various global locations. These devices often boot up in the China time zone, causing all sorts of issues with the wrong time zone configured. This guide effectively addresses these issues.

Let’s find out how to solve this issue, shall we?

1. Time Zone Problems

When devices boot up after being shipped to the end user, they tend to boot up in the supplier’s local time zone, such as China. When you combine this with the fact that setting the time zone automatically is turned off by default, you are up for a treat!

The data & time settings shows us the wrong time zone after the autopilot enrollment. The time zone is configured to utc -8:00 while we are in the netherlands

This can lead to various issues, such as incorrect timestamps and synchronization problems, which are particularly problematic for companies shipping devices to multiple global locations. Will we ask the end user to change it manually from the old-school control panel?

We can manually change the time zone after the windows autopilot enrollment

As shown above, we don’t need admin permissions to do so, but that isn’t a really nice user experience, is it? How will we ensure that we don’t run into these Time Zone issues and that there is an excellent user experience?

2. Configuring the Time Zone in Intune

The first option is the simplest but also unsuitable for larger organizations. As I mentioned in a previous blog, we can configure the settings below to ensure the device is always in a specific time zone. This setting would configure the time zone to the W. Europe Standard Time.

Configuring the Time Zone in Intune by configuring a settings catalog

For everyone who loves PowerShell, we can also define the Time zone with one PowerShell line.

Tzutil /g “W. Europe Standard Time” 

But what if we don’t know where the device is being shipped to? As mentioned before, If our company has locations worldwide, how will we ensure each device has the proper time zone configured?

3. Autopilot Deployment Profile

When configuring the Autopilot Profile, we need to configure some additional settings. In this Autopilot profile, we defined the Privacy setting. We configured it to “Hide” to ensure the user doesn’t get additional prompts after the Autopilot enrollment.

Autopilot Privacy Settings

The default setting would hide the Privacy settings, but we could choose to show them. Once the user has completed the Autopilot enrollment, he/she will be prompted to choose the privacy settings for his/her device.

Choosing the privacy settings after windows Autopilot and enabling location services

Not many people seem to like this setting and choice to hide the privacy setting. What options are left to give the user a good user experience and making sure the device is in the right time zone?

4. Enable the Location Services with Intune

We could also develop a better idea instead of relying on the Autopilot profile settings to show the privacy setting or manually configuring the Time zone.

To do so, we need to ensure that the Location Services are turned on and that the apps can access the location.

As shown below, I configured two options in the settings catalog.

  1. Privacy: Let Apps Access Location: Force Allow
  2. System: Allow Location: Force Location On.
configure the let apps access location to force allow and System: Allow Location: Force Location On.

With these Intune settings configured above, we can ensure the apps have access to the location! Please note: When a user opens the Privacy and Security settings to check the location settings, he/she will notice that everything is greyed out.

windows privacy and security settings greyed out

Naturally, some users might not be comfortable with location services being enabled for all apps. To address this, you can limit access by changing the setting from ‘Force Allow’ to ‘User in Control.‘ This way, users can decide which apps have access to location services. Additionally, you can define specific apps that are forced allowed to use location services, ensuring a more tailored and user-friendly experience

Let Apps Access Location User In Control Of These Apps:

  • Microsoft.BingWeather_4.53.62621.0_neutral_~_8wekyb3d8bbwe
  • Microsoft.CompanyPortal_11.2.1002.0_neutral_~_8wekyb3d8bbwe
  • Microsoft.Teams_24277.3102.3183.2670_x64_8wekyb3d8bbwe
  • Microsoft.OutlookForWindows_1.2024.1023.300_x64_8wekyb3d8bbwe
  • Microsoft.WindowsMaps_2022.2403.4.0_neutral_~_8wekyb3d8bbwe
  • Microsoft.WindowsCamera_2022.2408.1.0_neutral_~_8wekyb3d8bbwe

5. Enable the Location Services with PowerShell

Besides configuring a new Intune policy to enable the location services with Intune, we could also create a PowerShell script to do the same. It will make the registry keys that correspond with the Let Apps Access location settings and some additional sensor settings as well.


try {
# Create or access the AppPrivacy key and set the LetAppsAccessLocation property
$appPrivacyPath = "HKLM:\SOFTWARE\Policies\Microsoft\Windows\AppPrivacy"
New-Item -Path $appPrivacyPath -Force | Out-Null
Set-ItemProperty -Path $appPrivacyPath -Name "LetAppsAccessLocation" -Value 1 -Type DWord -Force
Write-Output "Set LetAppsAccessLocation to 1 in $appPrivacyPath"

# Create or access the CapabilityAccessManager ConsentStore location key and set the Value property
$consentStorePath = "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\CapabilityAccessManager\ConsentStore\location"
New-Item -Path $consentStorePath -Force | Out-Null
Set-ItemProperty -Path $consentStorePath -Name "Value" -Type String -Value "Allow"
Write-Output "Set Value to Allow in $consentStorePath"

# Set the SensorPermissionState property for the specified sensor override
$sensorOverridePath = "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Sensor\Overrides\{BFA794E4-F964-4FDB-90F6-51056BFE4B44}"
Set-ItemProperty -Path $sensorOverridePath -Name "SensorPermissionState" -Type DWord -Value 1 -Force
$LocationServiceConfigurationKey = "HKLM:\SYSTEM\CurrentControlSet\Services\lfsvc\Service\Configuration"
Set-RegistryValue -Path $LocationServiceConfigurationKey -Name "Status" -Value 1 -Type "DWord"
Start-Service -Name "lfsvc"
Write-Output "Set SensorPermissionState to 1 in $sensorOverridePath"

} catch {
Write-Error "An error occurred: $_"
}
# Define the service name
$serviceName = "tzautoupdate"
# Get the service status
$service = Get-Service -Name $serviceName -ErrorAction SilentlyContinue
# Check if the service exists

if ($null -eq $service) {
Write-Output "Service '$serviceName' does not exist."
} else {
# Check the start type of the service
$startType = (Get-Service -Name $serviceName).StartType
if ($startType -ne "Automatic") {
Write-Output "Service '$serviceName' is not set to start automatically. Configuring it to start automatically."
# Set the service to start automatically
Set-Service -Name $serviceName -StartupType Automatic
} else {
Write-Output "Service '$serviceName' is already set to start automatically."
}
#Start the service if it is not running
if ($service.Status -ne 'Running') {
Write-Output "Starting the service '$serviceName'."
$serviceName
} else {
Write-Output "Service '$serviceName' is already running."
}
}

Please ensure you deploy this PowerShell script as 64 bits and assign it to a device group.

6. Configuring the Time Zone based on location

Another option we have up in our sleeves is to create a remediation script that would detect the current time zone by invoking a web request to worldtimeapi.org (with a couple of retries until it receives data)

Please Note: https://worldtimeapi.org/ has a rate-limit

With the current IANA timezone in our pocket, we still need to map it to the Windows time zone.

A screenshot of a computer  Description automatically generated

With the IANA time zones mapped to the time zones that Windows understands, it is time to check the current Time Zone and update it if it doesn’t match

A screenshot of a computer code  Description automatically generated

Easy does it. Feel free to download the remediation files :

Conclusion

Deploying Windows devices using Autopilot globally can be challenging due to time zone issues when devices boot up in the supplier’s local time zone, like China. This guide addresses these challenges with detailed steps to configure time zones in Intune, set up Autopilot profiles, and enable location services using both Intune and PowerShell. These solutions ensure devices are correctly configured regardless of their destination, enhancing the user experience. By following this guide, organizations can achieve a smooth and efficient deployment process for their global workforce.

5 thoughts on “Fixing Time Zone Issues in Windows Autopilot

  1. Hi Rudy,
    Since some users might not appreciate having Location Services enabled for all apps, we use the below combination of settings in a device group targetted config to solve the time zone issue:
    Let Apps Access Location : User in control.
    Let Apps Access Location Force Allow These Apps : windows.immersivecontrolpanel_cw5n1h2txyewy

    regards,
    David

    1. Hehehe yep.. some people wouldnt like that at all πŸ™‚ … i also noticed the same thing :). Its added now.. thanks for the headsup

  2. Hello.
    So it seems if you hide Privacy settings in Autopilot Profile, Location Services will now be turned off and cannot be changed by the user.
    On the other hand, if you then push a policy with the “User in control” setting, it asks for Localadmin (UAC) to change it.

    Surely this cannot be by design? 😐 – I would like to hide Privacy from Autopilot, but turn on Location Services and let users change it for individual apps – but they are not Local admin.

Leave a Reply

Your email address will not be published. Required fields are marked *

5  +  1  =  

Proudly powered by WordPress | Theme: Wanderz Blog by Crimson Themes.