Windows Server 2022 : l’horloge repasse de PM à AM après redémarrage (NTP, w32time, GPO, Hyper‑V/VMware)

Après une migration vers Windows Server 2022, l’horloge repasse de PM à AM à chaque redémarrage ? Voici un guide complet et actionnable pour diagnostiquer w32time, NTP, GPO, BIOS/UEFI et virtualisation, et corriger durablement ce décalage de 12 heures.

Vue d’ensemble du problème

Symptôme observé : après mise à niveau d’un hôte Windows Server 2008 vers Windows Server 2022, l’heure système affiche correctement l’après‑midi (PM). Or, après chaque redémarrage, l’horloge revient au matin (AM), soit un saut de 12 heures. Le même matériel ne présentait pas ce comportement sous 2008.

Ce phénomène est typique d’un conflit de sources de temps (w32time, hyperviseur, BIOS/UEFI), d’un fuseau/DST mal appliqué, d’une GPO qui réécrit la configuration NTP, ou d’un firmware/CMOS défaillant. La bonne nouvelle : une approche structurée permet d’identifier la cause et de stabiliser l’horloge.

Réponse & solutions proposées

1. Vérifier le service Windows Time (w32time)
   • Ouvrir services.msc → Windows Time et s’assurer que le type de démarrage est Automatique et que l’état est En cours d’exécution.
   • Contrôler la santé et la source NTP : w32tm /query /status w32tm /query /configuration w32tm /query /peers sc qc w32time Astuce : si Type vaut NT5DS, la machine suit la hiérarchie de domaine. Si Type vaut NTP, elle suit la liste manuelle de pairs.
2. Contrôler la source de temps du domaine
   • Pour un membre du domaine Active Directory, la référence temporelle provient du PDC Emulator du domaine. Vérifier que ce contrôleur est correctement configuré et synchronisé.
   • Sur le PDC Emulator, définir des sources NTP publiques de confiance : powershell w32tm /config /manualpeerlist:"0.pool.ntp.org 1.pool.ntp.org" /syncfromflags:manual /reliable:yes /update net stop w32time && net start w32time && w32tm /resync
   • Sur les autres DC et membres, revenir à la hiérarchie de domaine : w32tm /config /syncfromflags:domhier /update w32tm /resync /rediscover
3. Mettre à jour le BIOS/UEFI et les pilotes
   • Un firmware ancien ou un microcode CPU obsolète peut générer des dérives ou une mauvaise interprétation du bit AM/PM du RTC (horloge matérielle).
   • Contrôler la pile CMOS (CR2032). Une batterie faible provoque une perte partielle de l’heure à l’extinction, d’où un retour « matinal » au boot.
4. Analyser les journaux d’événements
   • Ouvrir Observateur d’événements → Applications and Services Logs → Microsoft → Windows → Time‑Service (canal Operational).
   • Rechercher les erreurs W32Time (ID 36, 47, 129…) et corréler avec les redémarrages.
   • Activer l’audit des changements d’heure (ID 4616) pour identifier l’utilisateur/service qui modifie l’heure : Local Security Policy → Advanced Audit Policy Configuration System → Audit Other System Events → Success, Failure
5. Inspecter la stratégie de groupe (GPO)
   • Des GPO peuvent écraser la configuration NTP à chaque démarrage.
   • Contrôler : Computer Configuration → Policies → Administrative Templates → System → Windows Time Service.
   • Paramétrer Configure Windows NTP Client, Global Configuration Settings et Time Providers selon votre modèle (voir plus bas).
6. Tester en mode sans échec avec prise en charge réseau
   • Ce test élimine un agent tiers (sauvegarde, sécurité, inventaire, agent cloud) qui réécrit l’horloge au boot.
   • Après démarrage, exécuter : wevtutil qe Security /q:"*[System[(EventID=4616)]]" /c:10 /rd:true /f:text schtasks /query /fo LIST /v | findstr /i /c:"time" /c:"w32tm" /c:"tzutil"

Informations complémentaires utiles

Piste supplémentaire	Pourquoi c’est pertinent	Commande / action rapide
Fuseau horaire & DST	Un fuseau erroné ou un DST désactivé peut décaler l’affichage et provoquer des « retours » en AM.	tzutil /g puis tzutil /s "Pacific Standard Time" (ex.)
Virtualisation	En Hyper‑V/VMware, la VM peut répliquer l’horloge de l’hôte ; un double pilotage (hôte+NTP) crée des bascules.	Désactiver la sync de l’outil d’intégration ou aligner la source NTP hôte/VM
Correctifs Microsoft récents	Des CU 2023‑2024 ont corrigé des anomalies NTP/w32time et mis à jour des règles DST/fuseaux.	Installer les derniers correctifs Windows Update
Forcer une resynchronisation	Valide rapidement la communication avec le serveur NTP et corrige un drift ponctuel.	w32tm /resync /force

Architecture et causes fréquentes

Windows Server utilise le service w32time pour l’horodatage, essentiel à Kerberos/AD. Dans un domaine, les membres suivent la hiérarchie de domaine (Type = NT5DS) : chaque machine se synchronise sur un DC, et le PDC Emulator fait autorité. En poste autonome, le service est en mode NTP vers des pairs définis (NtpServer).

Après une migration vers 2022, plusieurs changements peuvent introduire une bascule 12 heures :

• Double pilotage : w32time corrige l’heure, puis l’hyperviseur réimpose l’horloge hôte (ou l’inverse) au boot.
• GPO héritées de 2008 qui réécrivent NtpServer, Type ou SpecialPollInterval à chaque démarrage.
• RTC/BIOS : pile CMOS faible ou firmware qui interprète mal l’horloge matérielle (mode 12h/24h) et renvoie une valeur matinale.
• Paramètre RealTimeIsUniversal (cohabitation Linux/Windows) mal adapté : Windows interprète l’RTC en local time par défaut ; ce hack force l’UTC et peut provoquer un décalage si la politique NTP ne suit pas.
• Règles DST/fuseau mises à jour : sans les derniers correctifs, l’offset peut être recalculé au boot.

Diagnostic pas à pas

Contrôles de base

tzutil /g
systeminfo | findstr /i "Time Zone"
w32tm /query /status
w32tm /query /configuration
reg query HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Parameters /v Type
reg query HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Parameters /v NtpServer

Points d’attention :

• Type doit être NT5DS (membre AD) ou NTP (autonome). Un NTP non désiré sur une machine jointe au domaine est un signe de GPO ou de script de démarrage obsolète.
• NtpServer : en mode NT5DS, cette valeur peut être vide. En mode NTP, elle doit contenir des pairs fiables avec ,0x8 pour le mode de sondage spécial. Ex : "0.pool.ntp.org,0x8 1.pool.ntp.org,0x8".

Tester la qualité de la source de temps

w32tm /stripchart /computer:pdc-emulator.domaine.local /samples:10 /dataonly
w32tm /monitor /domain

Une variation importante (latence instable, dérive supérieure à quelques centaines de ms) révèle un problème de connectivité ou de fiabilité de la source.

Vérifier la virtualisation

Plateforme	Ce qu’il faut vérifier	Commande / UI
Hyper‑V	Désactiver « Time synchronization » sur les contrôleurs de domaine (recommandé). Aligner la politique NTP hôte/VM pour les autres rôles.	Get-VMIntegrationService -VMName "NomVM" Disable-VMIntegrationService -VMName "NomVM" -Name "Time Synchronization"
VMware	Dans VMware Tools, désactiver la synchronisation périodique hôte↔VM si NTP est actif dans l’OS invité.	VMware Tools → Options → Time sync (désactiver), ou paramètres avancés du .vmx
Autres hyperviseurs	Éviter le double pilotage. Un seul maître : soit l’hyperviseur, soit NTP/w32time.	Consulter la console d’administration de l’hyperviseur et unifier la politique.

Contrôler et réparer w32time

Modèle recommandé (membre de domaine) :

w32tm /config /syncfromflags:domhier /update
w32tm /resync /rediscover

Modèle recommandé (PDC Emulator) :

reg add HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpServer /v Enabled /t REG_DWORD /d 1 /f
reg add HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Config /v AnnounceFlags /t REG_DWORD /d 5 /f
w32tm /config /manualpeerlist:"0.pool.ntp.org 1.pool.ntp.org" /syncfromflags:manual /reliable:yes /update
net stop w32time && net start w32time
w32tm /resync /force

Inspecter le BIOS/UEFI et la pile CMOS

• Si l’heure avant l’amorçage est correcte mais devient « AM » immédiatement après POST/boot, suspecter l’RTC/BIOS.
• Éteindre complètement, débrancher, entrer dans le setup UEFI : si l’heure affichée là a « glissé », remplacez la pile CMOS et mettez à jour le firmware.
• Éviter le hack RealTimeIsUniversal sauf cas de dual‑boot avec Linux. S’il est activé par le passé : reg query HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation /v RealTimeIsUniversal reg delete HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation /v RealTimeIsUniversal /f

Traquer les changements d’heure non désirés

Activer l’audit 4616 et exploiter les journaux :

Événement	Source	Signification	Action
4616	Security	Changement d’heure détecté (qui, quoi, avant/après)	Identifier l’utilisateur/service ou processus fautif
36	Time‑Service	Le service de temps n’a pas pu atteindre un pair	Vérifier réseau/pare‑feu/peer NTP
47	Time‑Service	Le service a changé de source	Revoir GPO/paramètres NTP
129	Time‑Service	Grande correction appliquée	Diagnostiquer drift ou double pilotage

Modèles de GPO de référence

Pour des environnements homogènes, centraliser la configuration via GPO évite les divergences :

Paramètres globaux

Chemin GPO	Paramètre	Valeur conseillée	Remarques
Computer Configuration → Administrative Templates → System → Windows Time Service	Global Configuration Settings	MaxPosPhaseCorrection = 3600 MaxNegPhaseCorrection = 3600	Limiter les corrections brusques à ±1 h pour éviter un « saut » de 12 h silencieux
… → Time Providers	Enable Windows NTP Client	Enabled	Obligatoire pour membres hors DC
… → Time Providers	Configure Windows NTP Client	Type = NT5DS (membre AD) ou NTP (autonome) SpecialPollInterval = 3600 NtpServer = vos pairs,0x8	Mettre en NTP uniquement si la machine n’est pas jointe au domaine
… → Time Providers	Enable Windows NTP Server (sur PDC)	Enabled	Le PDC annonce un service fiable

Validation après correctifs

1. Forcer la découverte et la resynchronisation : w32tm /resync /rediscover w32tm /query /status w32tm /stripchart /computer:votre-pair /samples:15 /dataonly
2. Redémarrer le serveur et vérifier que l’heure reste cohérente pendant 10–15 minutes après boot (fenêtre où les agents tiers se lancent).
3. Surveiller l’événement 4616 (aucun changement inattendu) et les ID 47/129 dans Time‑Service.
4. Dans un domaine, valider la cohérence avec : w32tm /monitor /domain:votre-domaine.local

Cas d’école et signaux faibles

• Snapshots/rollbacks de VM : au retour d’un snapshot, l’horloge reflète un état ancien. Couper la sync hyperviseur & forcer w32tm /resync /force à l’issue du rollback.
• Agents de sauvegarde avec option de « quiesce time » : vérifier la documentation et désactiver la modification d’heure.
• Scripts hérités (net time, time.exe, tzutil) dans les scripts de démarrage : schtasks /query /fo LIST /v permet de repérer les tâches suspectes.
• Erreur de fuseau : l’horloge système est correcte, mais l’affichage en format 12h + mauvais TZ semble « remettre en AM ». Confirmer avec Get-Date -Format o en PowerShell (UTC) et tzutil.

Procédure de remise à zéro complète

Quand plusieurs couches ont laissé des traces contradictoires, réinitialiser proprement w32time est souvent le plus rapide.

1. Réinitialiser la configuration du service de temps (à exécuter en invite élevée) : net stop w32time w32tm /unregister w32tm /register sc config w32time start= auto net start w32time
2. Choisir une source fiable (PDC Emulator ou pairs NTP explicites) : :: Membre du domaine w32tm /config /syncfromflags:domhier /update \:: Serveur autonome ou PDC qui sort vers Internet w32tm /config /manualpeerlist:"0.pool.ntp.org 1.pool.ntp.org" /syncfromflags\:manual /reliable\:yes /update
3. Resynchroniser et vérifier : w32tm /resync /force w32tm /query /status
4. Redémarrer le serveur et confirmer que l’heure reste stable (plus de bascule PM→AM).

Jeu de commandes prêt à l’emploi (copier‑coller)

:: Statut & configuration
tzutil /g
w32tm /query /status
w32tm /query /configuration
w32tm /query /peers

\:: Source domaine → hiérarchie
w32tm /config /syncfromflags\:domhier /update
w32tm /resync /rediscover

\:: PDC → NTP publics
w32tm /config /manualpeerlist:"0.pool.ntp.org 1.pool.ntp.org" /syncfromflags\:manual /reliable\:yes /update
net stop w32time && net start w32time && w32tm /resync

\:: Debug avancé (désactiver après analyse)
w32tm /debug /enable /file\:c:\windows\temp\w32time.log /size:20000000 /entries:0-300
\:: pour couper
w32tm /debug /disable

\:: Audit des modifications d’heure
wevtutil qe Security /q:"\*\[System\[(EventID=4616)]]" /c:20 /rd\:true /f\:text 

Optimisations et bonnes pratiques

• Un seul maître : dans chaque couche (hôte/VM), définir une autorité de temps. Éviter : VM → NTP et en même temps Hyper‑V/VMware → sync hôte.
• PDC Emulator protégé : surveiller sa dérive et ses événements w32time. Mettre ce DC sur un hôte stable (latence réseau, ressources CPU).
• Correctifs réguliers : installer les mises à jour cumulatives pour bénéficier des correctifs NTP/DST.
• Limitation de correction : paramétrer MaxPosPhaseCorrection et MaxNegPhaseCorrection pour prévenir les corrections trop agressives au boot.

Exemple d’analyse orientée « 12 heures »

Vous voyez exactement un saut de 12 heures au démarrage (PM→AM), pas 1, 2 ou 5 minutes ? Orientez l’analyse ainsi :

1. RTC/BIOS : si l’UEFI affiche une heure matinale, remplacer la pile CMOS et mettre à jour le firmware.
2. Double pilotage : désactiver la synchronisation temps de l’hyperviseur et laisser NTP corriger.
3. GPO héritée : rechercher une GPO qui écrit time.exe, w32tm /config ou tzutil au démarrage.
4. Paramètre RealTimeIsUniversal : supprimer s’il n’est pas requis.

Foire aux questions

Pourquoi le format d’affichage 12h/24h ne suffit pas à expliquer la bascule ?
Parce que l’horodatage interne est en 24h. Un simple changement de format n’altère pas l’heure système. Un retour à AM traduit une écriture de l’heure, pas du format.

Une dérive NTP peut‑elle provoquer un saut de 12 h ?
Non. NTP corrige par petits pas ou par saut maîtrisé, mais un shift de 12 h indique plutôt une source autoritaire erronée (RTC/hyperviseur/script).

Que se passe‑t‑il si l’écart dépasse la tolérance Kerberos ?
Au‑delà de 5 minutes d’écart, authentification Kerberos et accès réseau peuvent échouer. D’où l’importance de stabiliser l’horloge rapidement.

Conclusion

Dans la quasi‑totalité des cas, la bascule PM→AM sous Windows Server 2022 après redémarrage se résout en :

• réaffirmant une unique chaîne d’autorité (PDC Emulator bien configuré, ou NTP autonome),
• éliminant le double pilotage lié à l’hyperviseur,
• mettant à jour BIOS/UEFI et, si nécessaire, la pile CMOS,
• nettoyant les GPO/scripts hérités et en activant l’audit 4616.

Appliquez les procédures de ce guide (notamment la remise à zéro de w32time et la vérification du PDC Emulator) et validez par les commandes de contrôle. Vous éliminerez durablement les retours intempestifs de AM/PM sur Windows Server 2022.

---

Résumé opératoire

1. Confirmer le fuseau/DST : tzutil /g, tzutil /s ....
2. Vérifier w32time actif/auto : services.msc, w32tm /query /status.
3. Sur PDC, configurer des pairs NTP fiables et /reliable:yes.
4. Sur membres, /syncfromflags:domhier + /rediscover.
5. Désactiver la sync temps de l’hyperviseur si NTP est utilisé dans l’OS.
6. Mettre à jour BIOS/UEFI et remplacer la pile CMOS si doute.
7. Activer l’audit 4616, inspecter Time‑Service (36, 47, 129).
8. Si besoin, réinitialiser w32time, resynchroniser, redémarrer et revérifier.

Procédure de remise à zéro (résumé)

1. Réinitialiser la configuration Time Service : net stop w32time w32tm /unregister w32tm /register
2. Choisir une source NTP fiable (PDC ou serveur autonome).
3. Redémarrer le service puis re‑synchroniser.
4. Redémarrer le serveur et contrôler que l’heure reste cohérente.