Out of Office Hours

Configuring time zones, part 2

As I mentioned in the preview blog, RFC 4833 describes a mechanism that delivers time zone information via DHCP, but Windows 10 doesn’t include a mechanism for automatically consuming this information.  But that doesn’t mean it can’t be used – it just requires some extra work.  The first challenge is adding the needed options to a Windows Server DHCP server.  That’s pretty simple to do, as you just need to add the option 100 (PCode) and 101 (TCode) definitions to the DHCP server.  You can add these by right-clicking on the IPv4 node in the DHCP admin tool, choosing “Set predefined options…”:

Then click the “Add..” button:

And fill in the needed details for both options:

Then you can add the values to the DHCP scopes.  I prefer the TCode (option 101) values because they are more user-friendly; you can find a list of those on the IANA web site.  For example, I would use value “America/Los_Angeles” for the Pacific time zone, or “America/Chicago” for the Central time zone.

That’s all it takes for the value to be delivered to the client.  The challenge then is to get the client to use them.  There are DHCP APIs available to help with that, but they aren’t particularly PowerShell-friendly (or even C#-friendly).  I had initially hoped that everything could be done without any compiled code, and with the PowerShell script published in 2013 by Ingmar Verheij, I thought I was in luck.  But it turns out it would only display the DHCP options that Windows had received, and Windows only retrieves the option values that it wants to act on.  So, some compiled code was required so that the client makes an additional DHCP request to get any additional option values.  But since the results are cached in the same place that the PowerShell script reads, it at least doesn’t require messy communication between the compiled code (and since that compiled code is in C#, I didn’t even need to marshal the results because I wasn’t using them anyway).

So, here are the pieces I put together to make this work:

With the PowerShell module doing the bulk of the work, the script to be deployed via Intune is pretty simple:

Install-Module DHCPClient -Force

$timeZone = Get-DHCPTimeZone
if ($timeZone)
{
     Set-TimeZone -Id $timeZone
}

Save that script to a file, add it to Intune, and deploy it to an appropriate group of devices and you should be all set.

I’m not sure what OSes do support RFC 4833 and these time zone values.  From what I can tell, they are most often used for IP phones and similar IoT-style devices that aren’t easily configured manually – they pick up their time and time zone settings from DHCP.  So don’t be surprised if you have already configured these DHCP options to support these sorts of devices.

It’s also worth repeating a comment made in a previous blog:  ESP can have issues when the time zone changes – it might prematurely time out because it thinks hours have past.  We’ve already fixed that for the Windows 10 2004 release (yes, it’s really called that).  It’s something we’ll investigate backporting.