Améliorations apportées à la précision de l’heure dans Windows Server 2016

Windows Server 2016 a amélioré les algorithmes qu’il utilise pour corriger le temps et conditionner l’horloge locale pour se synchroniser avec le Temps Universel Coordonné (UTC). Le Protocole de Temps Réseau (NTP) utilise quatre valeurs pour calculer le décalage temporel basé sur les horodatages de la demande/réponse du client et de la demande/réponse du serveur. Cependant, les réseaux sont bruyants, et il peut y avoir des pics dans les données provenant du NTP à cause de la congestion du réseau et d’autres facteurs qui affectent la latence du réseau. Les algorithmes de Windows Server 2016 moyennent ce bruit en utilisant plusieurs techniques différentes, ce qui résulte en une horloge stable et précise. La source que nous utilisons pour le temps précis fait également référence à une API améliorée, qui nous donne une meilleure résolution. Avec ces améliorations, nous pouvons atteindre une précision de 1 ms par rapport à l’UTC à travers un domaine.

Hyper-V

Windows Server 2016 a amélioré le service TimeSync de Hyper-V. Les améliorations incluent un temps initial plus précis sur la machine virtuelle (VM) au démarrage ou à la restauration de la VM et une correction de la latence d’interruption pour les échantillons fournis au service Windows Time (W32Time). Cette amélioration nous permet de rester à moins de 10µs de l’hôte avec une racine carrée moyenne (qui indique la variance) de 50µs, même sur une machine avec 75 % de charge. Pour plus d’informations, consultez Architecture Hyper-V.

Le niveau de Stratum que l’hôte rapporte à l’invité est plus transparent. Auparavant, l’hôte présentait un Stratum fixe de 2, indépendamment de sa précision. Avec les changements dans Windows Server 2016, l’hôte rapporte un Stratum supérieur de 1 au Stratum de l’hôte, ce qui résulte en un meilleur temps pour les invités virtuels. Le Stratum de l’hôte est déterminé par W32Time par les moyens normaux basés sur son temps source. Les invités de Windows Server 2016 joints à un domaine trouvent l’horloge la plus précise plutôt que de se rabattre par défaut sur l’hôte. Pour cette raison, nous conseillons de désactiver manuellement le réglage Hyper-V Time Provider pour les machines participant à un domaine dans Windows Server 2012 R2 et les versions antérieures.

Surveillance

Des compteurs de Performance Monitor ont été ajoutés. Ces compteurs vous permettent d’établir une base de référence, de surveiller et de dépanner la précision du temps. Le tableau suivant liste les compteurs.

Compteur	Description
Décalage de temps calculé	Le décalage temporel absolu entre l’horloge système et la source de temps choisie, tel que calculé par le service W32Time en microsecondes. Quand un nouvel échantillon valide est disponible, le temps calculé est mis à jour avec le décalage de temps indiqué par l’échantillon. Ce temps est le décalage temporel réel de l’horloge locale. W32Time initie la correction de l’horloge en utilisant ce décalage et met à jour le temps calculé entre les échantillons avec le décalage temporel restant qui doit être appliqué à l’horloge locale. La précision de l’horloge peut être suivie en utilisant ce compteur de performance avec un intervalle d’interrogation bas (par exemple, 256 secondes ou moins) et en cherchant que la valeur du compteur soit inférieure à la limite de précision de l’horloge désirée.
Ajustement de fréquence d’horloge	Ajustement de fréquence d’horloge absolue apporté à l’horloge du système local par le service w32time (parties par milliard). Ce compteur aide à visualiser les actions prises par W32Time.
Délai de l’aller-retour NTP	Délai aller-retour le plus récent vécu par le client NTP en recevant une réponse du serveur en microsecondes. Ce délai est le temps écoulé sur le client NTP entre l’émission d’une demande au serveur NTP et la réception d’une réponse valide du serveur. Ce compteur aide à caractériser les délais expérimentés par le client NTP. Des allers-retours plus longs ou variables peuvent ajouter du bruit aux calculs temporels NTP, ce qui à son tour pourrait affecter la précision de la synchronisation temporelle à travers le NTP.
Nombre de sources de temps de client NTP	Nombre actif de sources de temps NTP utilisées par le client NTP. Ce nombre est un décompte d’adresses IP actives, distinctes, de serveurs de temps qui répondent aux demandes de ce client. Ce nombre pourrait être plus grand ou plus petit que les pairs configurés, selon la résolution DNS des noms de pairs et l’accessibilité actuelle.
Requêtes entrantes de serveur NTP	Nombre de demandes reçues par le serveur NTP (demandes/sec).
Réponses sortantes de serveur NTP	Nombre de réponses données par le serveur NTP (réponses/sec).

Les trois premiers compteurs ciblent des scénarios pour le dépannage des problèmes de précision. Pour plus d’informations, veuillez consulter la section Résolutions des problèmes de précision de l’horloge et du protocole NTP plus loin dans cet article. Les trois derniers compteurs couvrent les scénarios de serveur NTP et sont utiles lorsque vous déterminez la charge et établissez une référence de votre performance actuelle.

Mises à jour de configuration par environnement

Le tableau suivant décrit les changements dans la configuration par défaut entre Windows Server 2016 et les versions précédentes pour chaque rôle. Les réglages pour Windows Server 2016 et Windows 10 Anniversary Update (build 14393) sont maintenant uniques, c’est pourquoi ils sont montrés dans des colonnes séparées.

Role	Paramètre	Windows Server 2016	Windows 10	Windows Server 2012 R2 Windows Server 2008 R2 Windows 10
Autonome/Nano Server
	Serveur de temps	time.windows.com	NA	time.windows.com
	Fréquence d'interrogation	64 à 1 024 secondes	NA	Une fois par semaine
	Fréquence de mise à jour de l’horloge	Une fois par seconde	NA	Une fois par heure
Client autonome
	Serveur de temps	NA	time.windows.com	time.windows.com
	Fréquence d’interrogation	NA	Une fois par jour	Une fois par semaine
	Fréquence de mise à jour de l’horloge	NA	Une fois par jour	Une fois par heure
Contrôleur de domaine
	Serveur de temps	PDC/GTIMESERV	NA	PDC/GTIMESERV
	Fréquence d’interrogation	64 à 1 024 secondes	NA	1,024-32,768 secondes
	Fréquence de mise à jour de l’horloge	Une fois par seconde	NA	Une fois par heure
Serveur membre du domaine
	Serveur de temps	DC	NA	DC
	Fréquence d'interrogation	64 à 1 024 secondes	NA	1,024-32,768 secondes
	Fréquence de mise à jour de l’horloge	Une fois par seconde	NA	Une fois toutes les 5 minutes
Client membre du domaine
	Serveur de temps	NA	DC	DC
	Fréquence d'interrogation	NA	1,204-32,768 secondes	1,024-32,768 secondes
	Fréquence de mise à jour de l’horloge	NA	Une fois toutes les 5 minutes	Une fois toutes les 5 minutes
Invité Hyper-V
	Serveur de temps	Choisit la meilleure option basée sur les strates de l’hôte et le serveur de temps	Choisit la meilleure option basée sur les strates de l’hôte et le serveur de temps	Par défaut sur l’hôte
	Fréquence d'interrogation	Basé sur le rôle ci-dessus	Basé sur le rôle ci-dessus	Basé sur le rôle ci-dessus
	Fréquence de mise à jour de l’horloge	Basé sur le rôle ci-dessus	Basé sur le rôle ci-dessus	Basé sur le rôle ci-dessus

Impact de l’augmentation des fréquences d’interrogation et de mise à jour de l’horloge

Pour fournir un temps plus précis, les valeurs par défaut pour les fréquences d’interrogation et les mises à jour de l’horloge sont augmentées, ce qui nous permet de faire de petits ajustements plus fréquemment. Ce changement provoque plus de trafic UDP/NTP. Ces paquets étant petits, il devrait y avoir peu ou pas d’effet sur les liens à large bande. L’avantage est que le temps devrait être meilleur sur une plus grande variété de matériel et d’environnements.

Pour les dispositifs alimentés par batterie, augmenter la fréquence d’interrogation peut poser des problèmes. Les appareils sur batterie ne stockent pas l’heure quand ils sont éteints. Lorsqu’ils reprennent, ils pourraient nécessiter des corrections fréquentes à l’horloge. L’augmentation de la fréquence d’interrogation rend l’horloge instable et pourrait également utiliser plus de puissance. Nous vous recommandons de ne pas modifier les paramètres par défaut du client.

Les contrôleurs de domaine (DC) devraient être affectés de manière minimale même avec l’effet multiplié des mises à jour accrues des clients NTP dans un domaine Active Directory. Le NTP a une consommation de ressources beaucoup plus faible par rapport à d’autres protocoles et un effet marginal. Il est plus probable que vous atteigniez les limites pour d’autres fonctionnalités de domaine avant d’être affecté par les paramètres accrus pour Windows Server 2016. Active Directory utilise tout de même le NTP sécurisé, qui tend à synchroniser le temps moins précisément que le NTP simple. Nous avons vérifié qu’il peut être mis à l’échelle vers des clients à deux strates du contrôleur de domaine principal (PDC).

En guise de plan minimal, vous devez réserver 100 demandes NTP par seconde par cœur. Par exemple, avec un domaine composé de quatre DC avec quatre cœurs chacun, vous devriez pouvoir servir 1 600 demandes NTP par seconde. Si vous avez 10 000 clients configurés pour synchroniser le temps une fois toutes les 64 secondes, et que les demandes sont reçues uniformément dans le temps, vous verriez 10 000/64, soit environ 160 demandes/seconde, réparties sur tous les DC. Cette quantité tombe facilement dans notre limite de 1 600 demandes NTP/sec basée sur cet exemple. Ces recommandations de planification sont prudentes et dépendent largement de votre réseau, de la vitesse des processeurs et des charges. Comme toujours, établissez une base de référence et effectuez des tests dans vos environnements.

Si vos DC fonctionnent avec une charge CPU considérable, supérieure à 40 %, cette charge ajoute presque certainement du bruit aux réponses NTP et affecte la précision de l’heure dans votre domaine. Là encore, vous devez tester dans votre environnement pour comprendre les résultats réels.

Mesures de précision temporelle

Pour mesurer la précision temporelle pour Windows Server 2016, nous avons utilisé divers outils, méthodes et environnements. Vous pouvez utiliser ces techniques pour mesurer et ajuster votre environnement et déterminer si les résultats de précision répondent à vos besoins.

Méthodologie

Notre horloge source de domaine était constituée de deux serveurs NTP haute précision avec matériel GPS. Nous avons également utilisé une machine de test de référence séparée pour les mesures, qui avait également un matériel GPS haute précision installé provenant d’un fabricant différent. Pour certains tests, vous avez besoin d’une source d’horloge précise et fiable à utiliser comme référence en plus de votre source d’horloge de domaine.

Nous avons utilisé quatre méthodes différentes pour mesurer la précision avec des machines physiques et virtuelles. Plusieurs méthodes ont fourni des moyens indépendants de valider les résultats.

1. Mesurez l’horloge locale, qui est conditionnée par w32tm, par rapport à notre machine de test de référence, qui a un matériel GPS séparé.

2. Mesurez les pings NTP du serveur NTP vers les clients en utilisant le diagramme à bandes W32tm.

3. Mesurez les pings NTP du client vers le serveur NTP en utilisant le diagramme à bandes W32tm.

4. Mesurez les résultats Hyper-V de l’hôte vers l’invité en utilisant le Time Stamp Counter (TSC). Ce compteur est partagé entre les deux partitions et l’heure système dans les deux partitions. Nous avons calculé la différence entre l’heure de l’hôte et l’heure du client dans la VM. Ensuite, nous avons utilisé l’horloge TSC pour interpoler l’heure de l’hôte à partir de l’invité car les mesures ne se produisent pas en même temps. De plus, nous avons utilisé l’horloge de volume segmenté dans le temps pour éliminer les retards et la latence dans l’API.

W32tm est intégré, mais les autres outils que nous avons utilisés lors de nos tests sont disponibles dans le référentiel Microsoft sur GitHub en tant que logiciel libre pour vos tests et votre utilisation. Pour plus d’informations sur l’utilisation des outils pour effectuer des mesures, veuillez consulter la rubrique Wiki sur les outils d’étalonnage de l’heure Windows.

Les résultats des tests présentés sont un sous-ensemble des mesures que nous avons effectuées dans l’un des environnements de test. Ils illustrent la précision maintenue au début de la hiérarchie temporelle et du client de domaine à la fin de la hiérarchie temporelle. Ces résultats sont comparés aux mêmes machines dans une topologie basée sur 2012 pour la comparaison.

Topologie

Pour comparer, nous avons testé des topologies basées sur Windows Server 2012 R2 et Windows Server 2016. Les deux topologies sont constituées de deux ordinateurs hôtes Hyper-V physiques qui font référence à une machine Windows Server 2016 sur laquelle le matériel d’horloge GPS est installé. Chaque hôte exécute trois invités Windows joints au domaine, qui sont disposés selon la topologie suivante. Les lignes représentent la hiérarchie temporelle et le protocole/transport utilisé.

Aperçu graphique des résultats

Les deux graphiques suivants représentent la précision de l’horloge pour deux membres spécifiques dans un domaine basé sur la topologie précédente. Chaque graphique affiche à la fois les résultats de Windows Server 2012 R2 et 2016 superposés, ce qui permet de visualiser les améliorations. La précision a été mesurée depuis la machine invitée par rapport à l’hôte. Les données graphiques représentent un sous-ensemble de l’ensemble des tests que nous avons effectués et montrent les scénarios de meilleur et de pire cas.

Performance du PDC du domaine racine

Le PDC racine est synchronisé sur l’hôte Hyper-V (en utilisant VMIC), qui est un serveur Windows Server 2016 avec un matériel GPS qui s’est avéré à la fois précis et stable. Cette exigence est cruciale pour une précision de 1 ms, comme le montre la zone grisée identifiée par la légende.

Performance du client du domaine enfant

Le client du domaine enfant est attaché à un PDC du domaine enfant qui communique avec le PDC racine. Son heure est également dans les exigences de 1 ms.

Test à longue distance

Le graphique suivant compare un saut de réseau virtuel à six sauts de réseau physique avec Windows Server 2016. Deux graphiques sont superposés avec une certaine transparence pour afficher les données qui se chevauchent. Un nombre croissant de sauts réseau signifie une latence plus élevée et des écarts de temps plus importants. Le graphique est agrandi, donc les limites de 1 ms, représentées par la zone grisée, sont plus grandes. Comme vous pouvez le voir, l’heure garde une précision de 1 ms avec plusieurs sauts. Elle est décalée dans les négatifs, ce qui illustre une asymétrie réseau. Chaque réseau est différent, et les mesures dépendent de nombreux facteurs environnementaux.

Bonnes pratiques pour une synchronisation précise de l’heure

Suivez ces bonnes pratiques pour une synchronisation précise de l’heure.

Horloge à source fiable

L’heure d’une machine n’est aussi bonne que l’horloge source avec laquelle elle se synchronise. Pour atteindre une précision de 1 ms, vous avez besoin d’un matériel GPS ou d’un appareil de temps sur votre réseau que vous référencez comme l’horloge source maître. L’utilisation de la valeur par défaut de time.windows.com pourrait ne pas fournir une source d’heure stable et locale. À mesure que vous vous éloignez de l’horloge source, le réseau affecte la précision. Avoir une horloge source maître dans chaque centre de données est nécessaire pour obtenir la meilleure précision.

Options matérielles GPS

Diverses solutions matérielles peuvent offrir une heure précise. En règle générale, les solutions actuelles sont basées sur des antennes GPS. Les solutions radio et modem à composition utilisent des lignes dédiées. Elles se connectent à votre réseau en tant qu’appareil ou se branchent sur un PC, par exemple, Windows via un périphérique PCIe ou USB. Différentes options offrent différents niveaux de précision, et comme toujours, les résultats dépendent de votre environnement. Les variables qui affectent la précision comprennent la disponibilité du GPS, la stabilité et la charge du réseau, et le matériel PC. Ces facteurs sont tous importants lorsque vous choisissez une horloge source, ce qui est une exigence pour une heure stable et précise.

Domaine et synchronisation de l’heure

Les membres du domaine utilisent la hiérarchie de domaine pour identifier l’ordinateur qu’ils utilisent comme source pour synchroniser l’heure. Chaque membre du domaine trouve une autre machine avec laquelle se synchroniser et la sauvegarde en tant que source d’horloge. Chaque type de membre du domaine suit un ensemble différent de règles pour trouver une source d’horloge pour la synchronisation de l’heure. Le PDC dans la racine de la forêt est la source d’horloge par défaut pour tous les domaines. Voici différentes fonctions et descriptions générales de la manière dont elles trouvent une source :

• Contrôleur de domaine avec le rôle de PDC : cette machine est la source d’heure de référence pour un domaine. Elle dispose de l’heure la plus précise disponible dans le domaine. Elle doit se synchroniser avec un DC dans le domaine parent, sauf dans les cas où le rôle GTIMESERV est activé.
• Tout autre contrôleur de domaine : cette machine agit comme une source d’heure pour les clients et les serveurs membres dans le domaine. Un DC peut se synchroniser avec le PDC de son propre domaine ou avec n’importe quel DC de son domaine parent.
• Clients/serveurs membres : cette machine peut se synchroniser avec n’importe quel DC ou PDC de son propre domaine ou avec un DC ou PDC dans le domaine parent.

En fonction des candidats disponibles, un système de scoring est utilisé pour rechercher la meilleure source de temps. Ce système prend en compte la fiabilité de la source de temps et de son emplacement relatif. Cette vérification se produit une fois lorsque le service d’heure démarre. Si vous avez besoin de plus de contrôle sur la synchronisation de l’heure, vous pouvez ajouter des serveurs de temps appropriés à des emplacements spécifiques ou ajouter une redondance. Pour plus d’informations, veuillez consulter la section Spécifier un service d’heure local fiable en utilisant GTIMESERV.

Environnements mixtes (Windows Server 2012 R2 et Windows Server 2008 R2)

Bien qu’un environnement de domaine purement Windows Server 2016 soit requis pour obtenir la meilleure précision, il existe toujours des avantages dans un environnement mixte. Le déploiement de Windows Server 2016 Hyper-V dans un domaine Windows Server 2012 bénéficie aux invités en raison des améliorations que nous avons mentionnées, mais seulement si les invités sont également sur Windows Server 2016. Un PDC Windows Server 2016 peut fournir une heure plus précise en raison des algorithmes améliorés, il est donc une source plus stable. Parce que le remplacement de votre PDC peut ne pas être une option, vous pouvez plutôt ajouter un DC Windows Server 2016 avec le rôle GTIMESERV défini, ce qui serait une amélioration de la précision pour votre domaine. Un DC Windows Server 2016 peut fournir une heure meilleure aux clients de temps en aval, mais il n’est aussi bon que son heure NTP source.

Comme indiqué, les fréquences d’interrogation de l’horloge et de rafraîchissement ont été modifiées avec Windows Server 2016. Ces fréquences peuvent être modifiées manuellement sur vos DC en aval ou appliquées via la stratégie de groupe. Nous n’avons pas testé ces configurations, mais elles devraient bien se comporter sous Windows Server 2008 R2 et Windows Server 2012 R2 et apporter quelques avantages.

Les versions antérieures à Windows Server 2016 présentaient plusieurs problèmes de synchronisation précise de l’heure, ce qui entraînait un décalage immédiat de l’heure système après un ajustement. En raison de ce problème, l’obtention fréquente d’échantillons de temps à partir d’une source NTP précise et la conditionnement de l’horloge locale avec les données conduisent à un plus petit décalage dans leurs horloges système pendant la période intra-échantillonnage. Le résultat est une meilleure synchronisation de l’heure sur les versions OS en aval. La précision observée la plus élevée était d’environ 5 ms lorsque qu’un client NTP Windows Server 2012 R2, configuré avec les paramètres de haute précision, synchronisait son heure à partir d’un serveur NTP Windows Server 2016 précis.

Dans certains scénarios impliquant des DC invités, les échantillons Hyper-V TimeSync peuvent perturber la synchronisation de l’heure du domaine. Cet problème ne devrait plus exister pour les invités Windows Server 2016 exécutés sur des hôtes Hyper-V Windows Server 2016.

Pour désactiver le service Hyper-V TimeSync afin qu’il ne fournisse pas d’échantillons à W32Time, définissez la clé de registre suivante sur l’invité :

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\VMICTimeProvider "Enabled"=dword:00000000

Autoriser Linux à utiliser l’heure de l’hôte Hyper-V

Pour les invités Linux exécutés dans Hyper-V, les clients sont généralement configurés afin d’utiliser le démon NTP pour la synchronisation de l’heure sur les serveurs NTP. Si la distribution Linux prend en charge le protocole TimeSync version 4 et que l’invité Linux a le service d’intégration TimeSync activé, il se synchronise avec l’heure de l’hôte. Ce scénario pourrait entraîner une synchronisation de l’heure incohérente si les deux méthodes sont activées.

Pour se synchroniser exclusivement avec l’heure de l’hôte, nous vous recommandons de désactiver la synchronisation NTP de l’une des deux manières suivantes :

• Désactiver tous les serveurs NTP dans le fichier ntp.conf.
• Désactiver le daemon NTP.

Dans cette configuration, le paramètre de serveur de temps est cet hôte. Sa fréquence d’interrogation est de 5 secondes et la fréquence de mise à jour de l’horloge est également de 5 secondes.

Pour se synchroniser exclusivement via NTP, nous vous recommandons de désactiver le service d’intégration TimeSync dans l’invité.

Spécifier un service d’heure fiable local en utilisant GTIMESERV

Vous pouvez spécifier un ou plusieurs DC comme horloges source précises en utilisant l’indicateur de serveur de temps fiable GTIMESERV. Par exemple, des DC spécifiques équipés de matériel GPS peuvent être marqués comme GTIMESERV. Cet indicateur garantit que votre domaine fait référence à une horloge basée sur le matériel GPS.

TIMESERV est un autre indicateur de services de domaine lié qui indique si une machine est actuellement autoritaire, ce qui peut changer si un DC perd la connexion. Un DC dans cet état renvoie Unknown Stratum lorsqu’il est interrogé via NTP. Après plusieurs tentatives, le DC enregistre l’événement de service de temps système 36.

Si vous souhaitez configurer un DC en tant que GTIMESERV, configurez-le manuellement en utilisant la commande suivante. Dans ce cas, le DC utilise une autre machine comme horloge maîtresse. Cette machine peut être un appareil ou une machine dédiée.

w32tm /config /manualpeerlist:"master_clock1,0x8 master_clock2,0x8" /syncfromflags:manual /reliable:yes /update

Si le DC a le matériel GPS installé, utilisez les étapes suivantes pour désactiver le client NTP et activer le serveur NTP.

Commencez par désactiver le client NTP et activez le serveur NTP en apportant ces modifications de clé de registre :

reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\w32time\TimeProviders\NtpClient /v Enabled /t REG_DWORD /d 0 /f

reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\w32time\TimeProviders\NtpServer /v Enabled /t REG_DWORD /d 1 /f

Ensuite, redémarrez le service Windows Time :

net stop w32time && net start w32time

Enfin, vous indiquez que cette machine dispose d’une source d’heure fiable :

w32tm /config /reliable:yes /update

Pour vérifier que les modifications ont été effectuées correctement, exécutez les commandes suivantes, qui affectent les résultats affichés ici :

w32tm /query /configuration

Value|Expected Setting|
----- | ----- |
AnnounceFlags| 5 (Local)|
NtpServer |(Local)|
DllName |C:\WINDOWS\SYSTEM32\w32time.DLL (Local)|
Enabled |1 (Local)|
NtpClient| (Local)|

w32tm /query /status /verbose

Value| Expected Setting|
----- | ----- |
Stratum| 1 (primary reference - syncd by radio clock)|
ReferenceId| 0x4C4F434C (source name: "LOCAL")|
Source| Local CMOS Clock|
Phase Offset| 0.0000000s|
Server Role| 576 (Reliable Time Service)|

Windows Server 2016 sur des plates-formes virtuelles tierces

Lorsque Windows est virtualisé, par défaut, l’hyperviseur est responsable de la fourniture de l’heure. Mais les membres joints au domaine doivent être synchronisés avec le DC pour qu’Active Directory fonctionne correctement. Il est préférable de désactiver toute virtualisation de l’heure entre l’invité et l’hôte de toutes les plates-formes virtuelles tierces.

Découvrez la hiérarchie

Parce que la chaîne de hiérarchie temporelle vers la source d’horloge maîtresse est dynamique dans un domaine, et négociée, vous devez interroger l’état d’une machine particulière pour comprendre sa source d’heure et sa chaîne jusqu’à la source d’horloge maîtresse. Cette information peut aider à diagnostiquer les problèmes de synchronisation de l’heure.

Si vous souhaitez dépanner un client spécifique, la première étape est de comprendre sa source d’heure en utilisant cette commande w32tm :

w32tm /query /status

Les résultats affichent la source, entre autres. La source indique avec qui vous synchronisez l’heure dans le domaine. C’est la première étape de la hiérarchie temporelle de cette machine. Ensuite, utilisez l’entrée source de la commande précédente et utilisez le paramètre /stripchart pour trouver la prochaine source d’heure dans la chaîne.

w32tm /stripchart /computer:MySourceEntry /packetinfo /samples:1

Également utile, la commande suivante répertorie chaque DC qu’elle peut trouver dans le domaine spécifié et imprime un résultat qui vous permet de déterminer chaque partenaire. Cette commande inclut les machines configurées manuellement.

w32tm /monitor /domain:my_domain

En utilisant la liste, vous pouvez suivre les résultats à travers le domaine et comprendre la hiérarchie et le décalage horaire à chaque étape. En localisant le point où le décalage de temps est nettement pire, vous pouvez identifier la cause de l’heure incorrecte. À partir de là, vous pouvez essayer de comprendre pourquoi cette heure est incorrecte en activant la journalisation w32tm.

Utiliser la stratégie de groupe

Vous pouvez utiliser la stratégie de groupe pour obtenir une précision plus stricte en, par exemple, attribuant aux clients l’utilisation de serveurs NTP spécifiques ou en contrôlant la configuration des systèmes d’exploitation de niveau inférieur lorsqu’ils sont virtualisés. Voici une liste de scénarios possibles et des paramètres de stratégie de groupe pertinents :

Domaines virtualisés : pour contrôler les DC virtualisés dans Windows Server 2012 R2 afin qu’ils synchronisent l’heure avec leur domaine, plutôt qu’avec l’hôte Hyper-V, vous pouvez désactiver cette entrée de registre. Pour le PDC, vous ne voulez pas désactiver l’entrée car l’hôte Hyper-V fournit la source d’heure la plus stable. L’entrée de registre nécessite de redémarrer W32Time après sa modification.

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\VMICTimeProvider] "Enabled"=dword:00000000

Charges sensibles à la précision : pour les charges de travail sensibles à la précision de l’heure, vous pourriez configurer des groupes de machines pour définir les serveurs NTP et tout paramètre de temps connexe, comme la fréquence de sondage et de mise à jour de l’horloge. Cette tâche est normalement gérée par le domaine, mais pour plus de contrôle, vous pourriez cibler des machines spécifiques pour pointer directement vers l’horloge maîtresse.

Paramètre de stratégie de groupe	Nouvelle valeur
NtpServer	ClockMasterName,0x8
MinPollInterval	6 à 64 secondes
MaxPollInterval	6
UpdateInterval	100, une fois par seconde
EventLogFlags	3, journalisation de toutes les heures spéciales

Charges sensibles à la précision à distance: pour les systèmes dans les domaines distants, par exemple, le commerce de détail et l’industrie du paiement par carte (PCI), Windows utilise les informations de site actuelles et le localisateur de DC pour trouver un DC local, sauf s’il existe une source de temps NTP manuelle configurée. Cet environnement nécessite une précision de 1 seconde, qui utilise une convergence plus rapide jusqu’à l’heure correcte. Cette option permet à W32Time de reculer l’horloge. Si ce comportement est acceptable et répond à vos besoins, vous pouvez créer la politique suivante : Comme avec n’importe quel environnement, veillez à tester et à planifier votre réseau.

Paramètre de stratégie de groupe	Nouvelle valeur
MaxAllowedPhaseOffset	1, mais si plus d’une seconde, régler l’horloge sur l’heure correcte.

Le paramètre MaxAllowedPhaseOffset se trouve sous Système\Windows Time Service en utilisant les paramètres de configuration globale.

Éléments relatifs à Azure et IaaS Windows à prendre en considération

Voici quelques points à considérer pour Azure et l’infrastructure en tant que service (IaaS) Windows.

Machine virtuelle Azure : Services de domaine Active Directory

Si la machine virtuelle Azure exécutant les Services de domaine Active Directory fait partie d’une forêt Active Directory existante sur site, alors TimeSync (VMIC) doit être désactivé. Cette action permet à tous les DC de la forêt, à la fois physiques et virtuels, d’utiliser une hiérarchie de synchronisation du temps unique. Pour plus d’informations, veuillez consulter la rubrique Exécution des contrôleurs de domaine dans Hyper-V.

Machine virtuelle Azure : Machine jointe à un domaine

Si vous hébergez une machine qui est jointe à un domaine dans une forêt Active Directory existante, virtuelle ou physique, la bonne pratique est de désactiver TimeSync pour l’invité et de vous assurer que W32Time est configuré pour se synchroniser avec son DC via la configuration du temps pour Type=NTP5.

Machine virtuelle Azure : Machine autonome de groupe de travail

Si la machine virtuelle Azure n’est pas jointe à un domaine et qu’elle n’est pas un DC, nous vous recommandons de conserver la configuration de temps par défaut et de faire en sorte que la machine virtuelle se synchronise avec l’hôte.

Application Windows nécessitant une heure précise

Voici quelques actions que vous pouvez prendre si votre application Windows nécessite une heure précise.

API d’horodatage

Les programmes qui nécessitent la plus grande précision par rapport à UTC, et non le passage du temps, doivent utiliser l’API GetSystemTimePreciseAsFileTime. En utilisant cette API, votre application obtient l’heure système, qui est conditionnée par le service Windows Time.

performances du UDP ;

Si vous avez une application qui utilise la communication UDP pour les transactions et qu’il est important de minimiser la latence, il existe quelques entrées de registre connexes que vous pouvez utiliser pour configurer une plage de ports à exclure du moteur de filtrage de base de port. Cette action améliore à la fois la latence et augmente votre débit. Toutefois, les modifications apportées au Registre doivent être réservées aux administrateurs expérimentés. Cette solution exclut les ports de la sécurisation par le pare-feu. Pour plus d’informations, veuillez consulter la référence suivante.

Pour Windows Server 2012 et Windows Server 2008, vous devez d’abord installer un hotfix. Pour plus d’informations, veuille consulter la rubrique Perte de datagramme lors de l’exécution d’une application de réception multicast dans Windows 8 et dans Windows Server 2012.

Mise à jour des pilotes réseau

Certains fournisseurs de réseau proposent des mises à jour de pilotes qui améliorent les performances en termes de latence des pilotes et de mise en mémoire tampon des paquets UDP. Contactez votre fournisseur de réseau pour voir s’il existe des mises à jour pour améliorer le débit UDP.

Journalisation à des fins d’audit

Pour respecter les réglementations en matière de traçabilité temporelle, vous pouvez archiver manuellement les journaux w32tm, les journaux d’événements et les informations du Moniteur de performances. Plus tard, les informations archivées peuvent être utilisées pour certifier la conformité à un moment précis dans le passé. Les facteurs suivants sont utilisés pour indiquer la précision :

1. Précision de l’horloge en utilisant le compteur de performances Décalage temporel calculé. Ce compteur montre l’horloge dans la précision désirée.
2. Source de l’horloge recherchant Peer Response from dans les journaux w32tm. Suite au texte du message se trouve l’adresse IP ou VMIC, qui décrit la source de temps et la suivante dans la chaîne d’horloges de référence à valider.
3. État de la condition de l’horloge en utilisant les journaux w32tm pour valider que ClockDispl Discipline: \*SKEW\*TIME\* se produit effectivement. Cet état indique que w32tm est actif à ce moment-là.

Journalisation des événements

Pour obtenir l’histoire complète, vous avez également besoin d’informations de journal d’événements. En collectant le journal d’événements système et en filtrant sur Time-Server, Microsoft-Windows-Kernel-Boot, et Microsoft-Windows-Kernel-General, vous pourriez découvrir si d’autres influences ont modifié l’heure, par exemple, des tiers. Ces journaux peuvent être nécessaires pour éliminer les interférences externes. La stratégie de groupe peut affecter les journaux d’événements qui sont écrits dans le journal. Pour plus d’informations, veuillez consulter la section précédente Utilisation de la stratégie de groupe.

Journalisation de débogage de W32Time

Pour activer w32tm à des fins d’audit, la commande suivante active la journalisation qui montre les mises à jour périodiques de l’horloge et indique l’horloge source. Redémarrez le service pour activer la nouvelle journalisation.

Pour plus d’informations, veuillez consulter la rubrique Activer la journalisation de débogage dans le service Windows Time.

w32tm /debug /enable /file:C:\Windows\Temp\w32time-test.log /size:10000000 /entries:0-73,103,107,110

Analyseur de performances

Le service Windows Time de Windows Server 2016 expose des compteurs de performances, qui peuvent être utilisés pour collecter des journaux à des fins d’audit. Ces compteurs peuvent être enregistrés localement ou à distance. Vous pouvez enregistrer les compteurs Décalage temporel de l’ordinateur et Délai de retour. Comme tout compteur de performances, vous pouvez les surveiller à distance et créer des alertes en utilisant System Center Operations Manager. Par exemple, vous pouvez utiliser une alerte pour vous avertir lorsque le décalage temporel dévie de la précision désirée. Pour plus d’informations, veuillez consulter le Pack de gestion System Center.

Exemple de traçabilité Windows

À partir des fichiers journaux w32tm, vous souhaitez valider deux informations. La première est une indication que le fichier journal est actuellement une horloge de condition. Cette indication prouve que votre horloge était conditionnée par le service Windows Time au moment du litige.

 151802 20:18:32.9821765s - ClockDispln Discipline: *SKEW*TIME* - PhCRR:223 CR:156250 UI:100 phcT:65 KPhO:14307
 151802 20:18:33.9898460s - ClockDispln Discipline: *SKEW*TIME* - PhCRR:1 CR:156250 UI:100 phcT:64 KPhO:41
 151802 20:18:44.1090410s - ClockDispln Discipline: *SKEW*TIME* - PhCRR:1 CR:156250 UI:100 phcT:65 KPhO:38

Le point principal est que vous voyez des messages préfixés par ClockDispln Discipline, ce qui prouve que W32Time interagit avec votre horloge système.

Ensuite, vous devez trouver le dernier rapport dans le journal avant l’heure contestée qui rapporte l’ordinateur source, qui est actuellement utilisé comme horloge de référence. Cette information pourrait être une adresse IP, un nom d’ordinateur, ou le fournisseur VMIC, ce qui indique qu’il se synchronise avec l’hôte pour Hyper-V. L’exemple suivant fournit une adresse IPv4 de 10.197.216.105 :

151802 20:18:54.6531515s - Response from peer 10.197.216.105,0x8 (ntp.m|0x8|0.0.0.0:123->10.197.216.105:123), ofs: +00.0012218s

Maintenant que vous avez validé le premier système dans la chaîne de temps de référence, vous devez enquêter sur le fichier journal sur la source de temps de référence et répéter les mêmes étapes. Ce processus se poursuit jusqu’à ce que vous atteigniez une horloge physique, comme le GPS, ou une source de temps connue, comme le NIST. Si l’horloge de référence est un matériel GPS, les journaux du fabricant peuvent également être nécessaires.

Considérations relatives au réseau

Les algorithmes du protocole NTP dépendent de la symétrie de votre réseau. À mesure que vous augmentez le nombre de sauts réseau, la probabilité d’asymétrie augmente. C’est pour cette raison qu’il est difficile de prédire les types de précisions que vous pouvez voir dans vos environnements spécifiques.

L’Analyseur de performances et les nouveaux compteurs de temps Windows dans Windows Server 2016 peuvent être utilisés pour évaluer la précision de vos environnements et créer des bases de référence. Vous pouvez également effectuer un dépannage pour déterminer le décalage actuel de n’importe quelle machine sur votre réseau.

Il existe deux normes générales pour une heure précise sur le réseau :

• Protocole de temps de précision - IEEE 1588 (PTP) : PTP a des exigences plus strictes sur l’infrastructure réseau, mais peut souvent fournir une précision de sous-microseconde.
• Protocole de temps réseau : RFC 1305 (NTP) : NTP fonctionne sur un plus grand nombre de réseaux et d’environnements, ce qui facilite la gestion.

Windows prend en charge le NTP simple (RFC2030) par défaut pour les machines non jointes à un domaine. Pour les machines jointes à un domaine, nous utilisons un NTP sécurisé appelé MS-SNTP, qui utilise des secrets négociés par le domaine offrant un avantage de gestion par rapport au NTP authentifié décrit dans les RFC1305 et RFC5905.

Les protocoles joints et non joints au domaine nécessitent tous les deux le port UDP 123. Pour plus d’informations sur les meilleures pratiques NTP, veuillez consulter l’ébauche IETF sur les bonnes pratiques actuelles du protocole de temps réseau.

Horloge matérielle fiable (RTC)

Windows n’ajuste pas l’heure, sauf si certains seuils sont dépassés, mais discipline plutôt l’horloge. Cela signifie que w32tm ajuste la fréquence de l’horloge à intervalles réguliers en utilisant le paramètre de fréquence de mise à jour de l’horloge, qui est par défaut une fois par seconde avec Windows Server 2016. Si l’horloge est en retard, il accélère la fréquence. S’il est en avance, il ralentit la fréquence. Cependant, pendant le temps entre les ajustements de fréquence de l’horloge, l’horloge matérielle est sous contrôle. En cas de problème avec le microprogramme ou l’horloge matérielle, l’heure de l’ordinateur peut devenir moins précise.

Ce scénario est une autre raison pour laquelle vous devez tester et baser vos configurations dans votre environnement. Si le compteur de performances Décalage temporel calculé ne se stabilise pas à la précision que vous visez, vous voudrez peut-être vérifier que votre micrologiciel est à jour. Comme autre test, vous pouvez voir si un matériel différent reproduit le même problème.

Dépanner la précision temporelle et le NTP

Vous pouvez consulter la section Découvrir la hiérarchie pour comprendre la source de l’heure incorrecte. En regardant le décalage horaire, trouvez le point dans la hiérarchie où l’heure diverge le plus de sa source NTP. Lorsque vous comprenez la hiérarchie, vous voulez essayer de comprendre pourquoi cette source de temps particulière ne reçoit pas d’heure précise.

En vous concentrant sur le système avec un temps divergent, vous pouvez utiliser les outils suivants pour recueillir plus d’informations pour vous aider à déterminer le problème et trouver une solution. La référence UpstreamClockSource est l’horloge découverte en utilisant w32tm /config /status:

• Les journaux d’événements système
• Activer la journalisation en utilisant w32tm logs - w32tm /debug /enable /file:C:\Windows\Temp\w32time-test.log /size:10000000 /entries:0-300
• Clé de Registre w32Time HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time
• Traces de réseau local
• Les compteurs de performances (de la machine locale ou UpstreamClockSource)
• W32tm /stripchart /computer:UpstreamClockSource
• PING UpstreamClockSource pour comprendre la latence et le nombre de sauts jusqu’à la source
• Tracert UpstreamClockSource

Problème	Symptômes	Résolution
L’horloge TSC locale n’est pas stable.	Utilisation de l’Analyseur de performances - Ordinateur physique : synchronisation de l’horloge stable, mais vous voyez toujours ce message toutes les 1 à 2 minutes de plusieurs 100 μs.	Mettre à jour le micrologiciel ou valider qu’un matériel différent n’affiche pas le même problème.
Latence du réseau.	Le diagramme à bandes w32tm affiche RoundTripDelay plus de 10 ms. La variation dans le délai peut provoquer du bruit jusqu’à la moitié du temps aller-retour, par exemple, un délai qui n’est que dans une direction. UpstreamClockSource est multi-saut, comme indiqué par PING. La durée de vie doit être proche de 128. Utilisez Tracert pour rechercher la latence au niveau de chaque saut.	Trouvez une source d’horloge plus proche pour l’heure. Une des solutions consiste à installer une horloge source sur le même segment ou à pointer manuellement vers une horloge source géographiquement plus proche. Pour un scénario de domaine, ajoutez un ordinateur avec le rôle GTimeServ.
Impossible d’atteindre de manière fiable la source NTP.	W32tm /stripchart retourne par intermittence « La requête a expiré ».	La source NTP n’est pas réactive.
La source NTP n’est pas réactive.	Vérifiez les compteurs Perfmon pour NTP Client Source Count, NTP Server Incoming Requests et NTP Server Outgoing Responses et déterminez votre utilisation par rapport à vos références.	En utilisant les compteurs de performances du serveur, déterminez si la charge a changé par rapport à vos références. Existe-t-il des problèmes de surcharge du réseau ?
Contrôleur de domaine n’utilisant pas l’horloge la plus précise.	Modifications de la topologie ou de l’horloge maître récemment ajoutée.	w32tm /resync /rediscover
Les horloges des clients dérivent.	Événement 36 du service de temps dans le journal des événements système et/ou texte dans le fichier journal décrivant que le compteur NTP Client Time Source Count passe de 1 à 0.	Résolvez les problèmes de la source amont et voyez si elle rencontre des problèmes de performances.

Établir une ligne de base temporelle

Établir une ligne de base est important afin que vous puissiez comprendre les performances et la précision de votre réseau, puis les comparer avec la ligne de base à l’avenir lorsque des problèmes surviennent. Vous souhaitez établir une ligne de base pour le PDC racine ou pour toutes les machines marquées avec GTIMESRV. Nous recommandons également d’établir une ligne de base pour le PDC dans chaque forêt. Enfin, sélectionnez quelques DC critiques ou des machines ayant des caractéristiques intéressantes, comme la distance ou des charges élevées, et établissez une ligne de base pour celles-ci.

Il est également utile d’établir une ligne de base entre Windows Server 2016 et 2012 R2. Cependant, vous n’avez que w32tm /stripchart comme outil que vous pouvez utiliser pour comparer car Windows Server 2012 R2 n’a pas de compteurs de performances. Vous devriez choisir deux machines ayant les mêmes caractéristiques ou mettre à niveau une machine et comparer les résultats après la mise à jour. L’addendum Mesures de temps Windows contient plus d’informations sur la façon d’effectuer des mesures détaillées entre 2016 et 2012.

En utilisant tous les compteurs de performances de W32Time, collectez des données pendant au moins une semaine. Ces données garantissent que vous disposez d’une référence suffisante pour tenir compte des variations du réseau au fil du temps et d’une exécution suffisante pour avoir confiance en la stabilité de votre précision temporelle.

Redondance des serveurs NTP

Pour la configuration manuelle des serveurs NTP utilisée avec des machines non jointes à un domaine ou le PDC, avoir plus d’un serveur est une bonne mesure de redondance en cas d’indisponibilité. Cela pourrait également offrir une meilleure précision, en supposant que toutes les sources sont précises et stables. Cependant, si la topologie n’est pas bien conçue ou si les sources de temps ne sont pas stables, la précision résultante pourrait être pire, donc la prudence est de mise. La limite des serveurs de temps pris en charge par W32Time pouvant être référencés manuellement est de 10.

Secondes intercalaires

La période de rotation de la Terre varie avec le temps en raison d’événements climatiques et géologiques. Typiquement, la variation est d’environ une seconde tous les deux ans. Chaque fois que la variation par rapport au temps atomique devient trop importante, une correction d’une seconde (en plus ou en moins) est insérée, ce qui est appelé une seconde intercalaire. Cette insertion est faite de manière à ce que la différence ne dépasse jamais 0,9 seconde. Cette correction est annoncée six mois avant la correction réelle. Avant Windows Server 2016, le service de temps Microsoft n’était pas conscient des secondes intercalaires mais s’appuyait sur le service de temps externe pour gérer ce problème. Avec l’amélioration de la précision de l’heure de Windows Server 2016, Microsoft travaille sur une solution plus appropriée pour le problème de seconde intercalaire.

Secure Time Seeding

W32Time dans Server 2016 inclut la fonctionnalité Secure Time Seeding. Cette fonctionnalité détermine l’heure actuelle approximative à partir des connexions SSL sortantes. Cette valeur de temps est utilisée pour superviser l’horloge système locale et corriger les erreurs grossières. Pour plus d’informations sur cette fonctionnalité, consultez ce billet de blog. Dans les déploiements avec des sources de temps fiables et des machines bien surveillées comprenant une surveillance des décalages temporels, vous pouvez choisir de ne pas utiliser la fonctionnalité Secure Time Seeding et de vous fier à votre infrastructure existante à la place.

Pour désactiver la fonctionnalité :

1. Utilisez la stratégie de groupe pour gérer SecureTimeSeeding. Voir la section qui se réfère au paramètre UtilizeSslTimeData : Apprentissage : Paramètres CSP - ADMX_W32Time.

2. Vous pouvez également définir manuellement la valeur du Registre. Définissez la valeur de configuration UtilizeSSLTimeData sur 0 sur une machine spécifique :

   reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\w32time\Config /v UtilizeSslTimeData /t REG_DWORD /d 0 /f
   

3. Si vous ne pouvez pas redémarrer immédiatement la machine, vous pouvez informer W32Time de la mise à jour de configuration. Cette notification arrête la surveillance du temps et l’application basée sur les données de temps collectées à partir des connexions SSL.

   W32tm.exe /config /update
   

4. Le redémarrage de l’ordinateur rend le paramètre immédiatement effectif et l’amène également à arrêter la collecte des données de temps à partir des connexions SSL. La seconde partie a un faible impact et ne devrait pas poser de problème de performance.

5. Pour appliquer ce paramètre dans un domaine entier, réglez la valeur UtilizeSSLTimeData dans le paramètre de stratégie de groupe W32Time sur 0 et publiez le paramètre. Lorsque le paramètre est pris en compte par un client de stratégie de groupe, W32Time est informé et arrête la surveillance du temps et l’application par l’utilisation des données de temps SSL. La collecte de données de temps SSL s’arrête lorsque chaque machine redémarre. Si votre domaine comprend des ordinateurs portables/tablettes légers et d’autres appareils, vous voudrez peut-être exclure ces machines de ce changement de stratégie. Ces appareils finissent par être déchargés de leur batterie et ont besoin de la fonctionnalité Secure Time Seeding pour amorcer leur temps.