Fixing Time Zone Issues in Windows Autopilot

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!

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?

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.

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.

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.

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.

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.

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

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.

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

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.