[Intune] Validation of W32Time (NTP) behavior with "AllSync" via Intune for full-Entra ID Joined devices

Julien GOMBERT 20 Points de réputation
2026-05-28T15:00:14.4166667+00:00

Hello Microsoft Community,

I am using Intune to deploy a time configuration profile across our Windows 10/11 fleet. I am configuring this via Administrative Templates: System > Windows Time Service > Time Providers > Configure Windows NTP Client.

To maintain a single configuration profile that manages both our Hybrid Joined and fully cloud-joined (Entra ID) devices, I am planning to use the following parameters:

Type: AllSync

NtpServer: time.windows.com, 0x9

SpecialPollInterval: 3600

CrossSiteSyncFlags: 2

My question specifically concerns our "Microsoft Entra ID Joined" devices (which do not have a local Domain Controller): Can anyone confirm that if an Entra ID Joined device receives this AllSync configuration, the W32Time service will cleanly and automatically fallback to the external NtpServer without generating unnecessary network requests, looping Kerberos/LDAP traffic, or causing recurring errors in the Event Viewer?

Thank you in advance for your insights!

Windows pour les entreprises | Client Windows pour les professionnels de l’informatique | Appareils et déploiement | Autre
0 commentaires Aucun commentaire

Réponse acceptée par l’auteur(e) de la question
Chen Tran 13,190 Points de réputation Conseiller(ère) indépendant(e)
2026-05-28T15:53:37.1733333+00:00

Bonjour Julien,

Merci d'avoir posé votre question sur le forum Microsoft Windows !

Eh bien ! J'aimerais partager avec vous mon réflexion sur l'explication plausible de votre question.

Lorsque vous configurez le service W32Time avec Type : AllSync, vous demandez au client temporel d'utiliser à la fois la hiérarchie de domaine (NT5DS) et le serveur NTP de secours que vous avez spécifié. Alors qu'un appareil Entra ID Joint peut revenir avec succès à time.windows.com et maintenir une heure précise, utiliser AllSync sur une machine non jointe au domaine introduit des frictions mineures mais récurrentes sous forme de bruit de l'Observateur d'événements et de requêtes DNS inutiles.

Concernant l'impact du trafic réseau. Vous ne verrez pas de trafic Kerberos ou LDAP en boucle car le processus de découverte échoue au niveau DNS. Cependant, il peut générer des requêtes DNS SRV inutiles et récurrentes à chaque fois que W32Time initie un cycle de synchronisation. En revanche, le système enregistrera régulièrement les avertissements dans le journal des événements système. Vous verrez fréquemment l'ID d'événement 131 (et parfois l'ID d'événement 129) provenant de la source Time-Service, indiquant quelque chose comme « NtpClient n'a pas pu définir un pair de domaine comme source temporelle à cause d'une erreur de découverte. NtpClient réessaiera dans X minutes et doublera l'intervalle de retransmission par la suite. » Si vous ingérez les journaux d'événements Windows dans un SIEM ou les surveillez pour détecter des anomalies, cet avertissement récurrent sur toute votre flotte d'identifiants Entra créera des bruits inutiles.

Pour maintenir un environnement propre sans générer de faux positifs dans le journal d'événements, la meilleure pratique est de considérer la séparation de la configuration à l'aide des filtres d'attribution Intune plutôt que de dépendre du mécanisme de secours de W32Time.

J'espère que les **informations ci-dessus vous seront utiles **! Si c'est le cas. Ne vous laissez pas aller sur « Accepté » pour bénéficier à d'autres personnes dans la communauté qui ont la même question.

Cette réponse vous a-t-elle été utile?

2 personnes ont trouvé cette réponse utile.
0 commentaires Aucun commentaire

0 réponses supplémentaires

Trier par : Plus ancien

Votre réponse

Les réponses peuvent être marquées comme « Acceptées » par l’auteur(e) de la question et « Recommandées » par les modérateurs, ce qui aide les utilisateurs à savoir que la réponse a résolu le problème de l’auteur(e).