Setting a custom NTP server for Microsoft Teams Rooms

This might not be a common query as many organistions will probably deploy Microsoft Teams Rooms (MTRs) with direct internet access or won't have many restrictions of the endpoints/URLs that th devices can access.

We all know that keeping devices time and date accurate is key to ensuring the smooth running of network services as a lot of authentication processes rely on confirmation of time and date between clients and servers.

There are going to be times though when you may come across environments where the devices do have restrictions on which sites/URls are routable or accessible by MTRs.

By default, MTRs will try and check/udpdate their time and date from time.windows.com as we can see from this screenshot from Windows settings.

Now this is fine if the device is able to access time.windows.com, nothing to see here, carry on, you can stop reading here! :)

However, if you're in an environment where that URL isn't accessible or you want to make sure you're devices are getting their time/date from an internal source for whatever reason you'll need another way of setting the time and date for the devices.

It's also worth mentioning that this may be more easily solved if you domain joined your MTRs to on premises AD or Hybrid-AAD join. This articles is written more for those that aren't joined to on premises AD, so joined directly to Azure AD.

When I came across this, my first thought was to simply push an Intune Configuration Profile to the device to enable an NTP server, specify the internal NTP server address and leave it at that. However, when I did this, nothing seemed to happen on the device. Intune reported the profile had succesfully been deployed but when I checked the device, it was still reporting that it was set to get its time/date from time.windows.com.

Here's the configuration profile that I deployed, specifying pool.ntp.org as the time server

We can see the profile has succesfully deployed to the device from Intune

But when we check back on the device itself, we can see it's still set to time.windows.com

What's going on? I can't claim too much credit here as most of what I discovered was from Googling the problem and putting a few things together.

Firstly, I found that for devices that are joined direcly to Azure AD, the Windows Time Service isn't set to auto-start, it stays as a manual start and also the service isn't running (this is the key bit, as you can see the service is stopped)

So, we need to fix that to begin with and then set the address of the internal server we want the device to get its time from.

Cue some more investigations and I came across a great little script on Github that did exactly that. Credit to Roberto Moir, the post/script can be found here: https://github.com/robertomoir/MTR-Time-Sync-tools/blob/main/mtr-timesync.ps1

Code is pasted below

sc.exe triggerinfo w32time start/networkon stop/networkoff

w32tm /config /manualpeerlist:"pool.ntp.org,0x9" /syncfromflags:MANUAL /reliable:yes /update

restart-service w32time

w32tm /resync

A brief explanation of what each line is doing. Firstly, it's setting the Windows Time Service to start based on a trigger of the network being "on". This basically means, if the device is assigned an IP address, the service starts.

The second line is then setting the NTP server you want it to use, replace "pool.ntp.org" with the FQDN of your server. Keep it in quotations.

The third and fourth lines are then just restarting the Windows Time Service so those changes take effect and then forcing a time sync to get the latest time.

So now we know how we'll set this, we just need the method. If your devices aren't AAD joined, you'll need a method of running those commands on the device(s). For this article, we're assuming they are AAD joined so we'll use Intune and push the commands using a PowerShell script

From Intune, we create a PowerShell script, attach the script we've created above and assign it to our devices. This assumes that you've already got a group created which contains the MTR devices we want to target with this script. If not, create one (then either directly assign the MTR device objects to it or create a dynamic AAD group based on a common attribute that will add the devices).

This is the PowerShell script created in Intune

Once the profile is created and assigned, the devices should run the script after their next check in and if you check the time/date settings you should see the time server now matching our updated settings and a recent time/date that it was last synced.

We can see on my test device, Intune shows the script as having succesfully deployed

Now if we look at the device as well, we can see it's now got the new time server address showing and a recent time sync as succesful

And the Windows Time service is also showing as running now, rather than in a stopped state

That's it, hope this was useful!