Best way to configure Time settings for MTR devices InTune?

Question

Large number of Windows IoT devices that are Entra Joined and on InTune (not domain joined). The time is not syncing on any of the devices which is down to 2 reasons:

1. The time service on all devices is set to Manual(TriggerStart) by default
2. The devices are unable to sync with time.windows.com, so an alternative is needed (pool.ntp.org)

I understand that I could set a configuration profile in InTune to set the NTP server. However, this wouldn't resolve the time service not starting. In that case, would the best option be to use a remediation script that sets the service to automatic and sets the desired NTP server? Completely new to InTune and looking for any useful advice.

Answer 1

Hello,

For Entra joined, Intune managed Windows IoT devices this scenario is common and the recommended approach is to combine a configuration profile with an Intune remediation rather than relying on one alone. Use an Intune Settings Catalog or Administrative Template profile to explicitly enable the Windows NTP client and point it to a reachable and trusted source such as pool.ntp.org or an internal NTP server, because Entra joined devices do not inherit any domain time hierarchy and time.windows.com is often blocked or unreachable in restricted networks. In parallel, use Intune Remediations to enforce the Windows Time service state by detecting whether the W32Time service is stopped or not able to sync and remediating by setting the service startup type to Automatic, restarting it, and triggering a resync using w32tm, which avoids fighting the default Manual TriggerStart behavior on stand alone or IoT systems and keeps devices self healing over time. This pattern is considered best practice for Entra joined endpoints because remediations continuously correct drift or service failures instead of applying a one time script, and it scales cleanly across large fleets. Relevant guidance can be found in the Microsoft Intune Remediations documentation, Windows Time Service configuration documentation, and Intune based NTP configuration examples at https://learn.microsoft.com/en-us/intune/intune-service/fundamentals/remediations, https://learn.microsoft.com/en-us/windows-server/networking/windows-time-service/windows-time-service-tools-and-settings.

Answer 2

For Entra-joined Windows devices, the most robust approach is:

1. Use a reliable, authoritative time source
   • In a domain/enterprise environment, best practice is to synchronize from an authoritative time server in the hierarchy rather than each device going directly to an Internet NTP pool.
   • The forest root PDC emulator (or another designated authoritative time server) should be configured to use a reliable external or hardware time source, then all other domain members sync from the domain hierarchy.
   • Authoritative external sources (for example, NIST or pool-based NTP) should be configured on that authoritative server, not individually on every endpoint, where possible.
2. Understand the default hierarchy and behavior
   • In an AD DS/Entra hybrid environment, domain members and domain controllers synchronize time using the domain hierarchy:
     • Clients → authenticating domain controller
     • Domain controllers → PDC emulator
     • Forest root PDC emulator → authoritative time source
   • The PDC emulator at the forest root becomes the authoritative time server for the organization and should be configured to collect time from a hardware or trusted external source.
3. Configure the authoritative time server correctly
   • On the forest root PDC (or designated authoritative server):
     • Configure Windows Time (W32Time) to sync with a hardware source or a trusted external NTP source (for example, NIST or pool.ntp.org) using NTP.
     • Ensure the synchronization type is set appropriately (for example, a manually specified synchronization source rather than the domain hierarchy for the PDC).
     • Recommended: use a hardware source where possible; when using Internet time sources, be aware that manual mode has no authentication.
4. Let domain/Entra-joined devices use hierarchy-based sync
   • For domain controllers and member servers inside the domain, the synchronization type is typically NT5DS, meaning they sync from the domain hierarchy and accept time changes from that hierarchy.
   • For Entra-joined devices that can reach the domain controllers, configure them (via Intune) to use the domain hierarchy or a designated internal NTP server instead of time.windows.com.
   • This avoids each MTR device needing direct access to time.windows.com or pool.ntp.org.
5. Handling large offsets and reliability
   • Ensure the authoritative time server is reliable and reachable from all MTR devices to avoid large time offsets that can break Kerberos and sign-in.
   • If large offsets occur, adjust Windows Time service parameters (for example, MaxPosPhaseCorrection/MaxNegPhaseCorrection) via policy so that devices can correct time even when the offset is significant.
6. About the Time service startup mode
   • Windows Time (W32Time) is required for Kerberos and domain operations; in a properly configured domain hierarchy, it runs and maintains time automatically.
   • If devices show the service as Manual(TriggerStart) but are not syncing, focus first on:
     • Ensuring they have a reachable, authoritative time source (internal NTP/domain hierarchy).
     • Ensuring the PDC/authoritative server is correctly configured.
   • If policy or configuration has disabled or misconfigured the service, a remediation script or Intune configuration profile can be used to:
     • Set the service startup type appropriately.
     • Point the device to the correct NTP source (preferably internal, not time.windows.com, if that is unreachable).

In summary, the best practice is to configure a reliable forest root PDC (or designated authoritative time server) to sync from a trusted external or hardware source, then have all MTR devices synchronize via the domain hierarchy or an internal NTP server. Use Intune to enforce the correct NTP configuration and, if necessary, remediate the Windows Time service startup settings, but prioritize fixing the hierarchy and authoritative time source rather than configuring each device to use pool.ntp.org directly.

---

References:

• Recommendation - Configure the Root PDC with an Authoritative Time Source and Avoid a Widespread Time Skew
• Configure the Root PDC with an Authoritative Time Source and Avoid a Widespread Time Skew - Microsoft Engage Center
• How the Windows Time Service works
• How to configure the Windows Time service against a large time offset
• When SpecialPollInterval is used as a polling interval, the Windows Time service does not correct the time if the service gets into Spike state