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:

• A new DHCPClient PowerShell module available on the PowerShell Gallery.  This is a simplified version of Ingmar’s script, turned into a module that can be easily installed on the fly.  It also includes a simple function to help translate the IANA time zone strings (PCode option 101) into something that Windows can understand – but due to the effort involved in doing that mapping, the module only includes mappings for a few time zones, so beware.  (I hard-coded the module to return “Arab Standard Time” if it doesn’t find a valid time zone – it should then be very obvious when you have a DHCP scope that isn’t configured as expected, unless of course you wanted “Arab Standard Time.”  If I get some more energy, I’ll work on adding more time zone values, but feel free to make the changes yourself and submit a pull request to me and I’ll integrate them quickly.)
• A simple DHCPClient_TZ executable written in C# and published to GitHub.  This uses the available Windows DHCP client APIs to request the option 100 (PCode) and 101 (TCode) values.  It doesn’t do anything with the results (as mentioned before), but they will be cached into the registry so that the DHCPClient module can easily retrieve the values.  (The executable itself is embedded into the DHCPClient PowerShell module and called automatically when needed.  Because this can cause a new query to the DHCP server, it can take a couple of seconds to execute.)
• A simple PowerShell script that can be deployed via Intune (see below) that leverages the above pieces to get the DHCP value and translate it to something Windows can understand, then sets the time zone to that value.

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.