Bonjour à tous,
 
Ce matin, j'ai 2 contrôleurs de domaine en 2012R2 chez 2 clients différents qui semblent
être repassés à l'heure d'hiver pendant le Week-end (à priori, la semaine dernière tout  
était OK).
 
J'ai vérifié les réglages de fuseaux horaires et de changement d'heure automatique, tout
à l'air OK ...  
 
Est-ce que certains d'entre vous ont rencontré ce problème ?
Est-ce que doit forcer une remise à l'heure ? Il me semblait que tout était automatique à
ce niveau ...
 
D'avance merci,
 
A+

Regarde si c'est des VMS qu'elle ne se synchronisent pas sur l'hyperviseur.
Utilise la commande w32tm pour vérifier la source de temps et relancer une synchro.
Je viens d'avoir cet erreur chez un client, c'était un problème au niveau de la case pour les horaire d'été.

Vérifie la source de temps. Si ce sont des VM désactiver la synchro avec l'hyperviseur.

Merci pour vos réponses, j'ai trouvé entre temps, c'était bien un problème de source de temps qui était l'horloge de la carte mère du serveur. Il y a peut être eu un conflit entre le passage à l'heure d'été du BIOS et celui de Windows. J'ai finalement forcé les 2 machines à se synchroniser sur time.windows.com.
 
Par contre sur un 2008 (ni contrôleur, ni membre d'un domaine), j'ai eu le même soucis ce matin alors qu'il était bien en syncro auto sur time.windows.com. Il a fallu que je force la syncro plusieurs fois avant que ça revienne à la normale.
 
A l'occasion, il faudra que j'aille voir ce qu'il y a dans le BIOS de ces machines au niveau de la date/heure.
 
A+

Ce n'est pas bon du tout ça, tes machines ne doivent pas se synchro avec time.windows.com mais vers ta source de temps interne (le PDC pour les DC, un DC pour un serveur membre). Tu dois creuser de ce côté-là avant d'avoir encore plus de problèmes.

C'est bien le(s) PDC(s) que je synchronise avec time.windows.com, pas les PCs / serveurs membres du domaine.
 
Quand je dis "les 2 machines" je parles des 2 PDCs de 2 clients différents qui avançaient d'une heure depuis ce week-end.  
Ce matin, les machines membres des domaines étaient bien syncro avec l'heure (fausse) de leurs PDCs respectifs.
 
 
 
 

Ah je supposais qu'il ne s'agissait pas de PDC Tu les as bien configuré comme source de temps avec w32tm ?

Bonjour,
 
Donc, même blague ce matin ...  
 
Au moins 2 PDCs (physiques) différents sont repassés à l'heure d'hiver pendant le WE (un des 2 n'existait pas l'an dernier).
 
J'ai commencé à faire qq test sur 1 des machines :
- Un w32tm /query /status me renvoie time.windows.com en serveur de temps.
- Je redémarre la machine.
- Nouveau w32tm /query /status, cette fois il m'indique Local CMOS Clock comme serveur de temps. Par contre, dans la base de registre, c'est toujours bien time.windows.com qui apparait.
- Si je fais un w32tm /resync, il me dit que "l'ordinateur ne s'est pas resynchronisé car aucune donnée de temps n'était disponible"  ...
- Dans les paramètres de l’horloge il me dit bien qu'il va repasser à l'heure d'hiver le 29 octobre, il se considère donc bien à l'heure d'été.
 
Quelqu'un a une piste ?
Le souci n'est pas tant de corrigé le problème que d'être certain qu'il ne réapparaisse pas dans 6mois / 1 an ...
 
Merci, A+

fait voir la conf plutôt

Tu veux quoi comme conf ? La sortie de w32tm /query /status ?  
 
Indicateur de dérive : 0(Aucun avertissement)
Couche : 1 (Référence principale, synchronisée par l'horloge du réveil)
Précision : -6 (15.625ms par battement)
Délai de racine : 0.0000000s
Dispersion de racine : 10.0000000s
ID de référence : 0x4C4F434C (Nom de la source :  "LOCL" )
Heure de la dernière synchronisation réussie : 03/04/2017 13:03:51
Source : Local CMOS Clock
Intervalle d'interrogation : 6 (64s)
 
Comme indiqué plus haut avant le redémarrage j'avais "time.windows.com" comme Source ...
 

 

Il se synchronise avec le BIOS, si c'est un membre de domaine ou un PDC ce n'est pas bon comme config.

 
Ça j'ai bien saisi, sauf qu'il était justement censé se synchroniser avec time.windows.com
Avant redémarrage, c'est d'ailleurs ce que j'avais dans w32tm /query /status et dans la BDR à HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\W32Time\Parameters ...
 
A défaut de mieux, j'ai refait la config avec la commande win32tm adaptée en lui mettant fr.pool.ntp.org comme serveur de temps  et tout rentre dans l'ordre. Le pb c'est que je ne suis pas certain qu'il ne reprenne pas l’idée de
repasser à l'heure CMOS l'an prochain à +/- la même date ...    
 
Question subsidiaire : vaut il mieux utiliser time.windows.com ? fr.pool.ntp.org ? autre ? peu importe ?
 
Merci, A+

Tu entres quoi comme commande pour tes PDC ?
 
time.windows.com provoque parfois des problèmes, mieux vaut l'éviter au profit de pool.ntp.org oui.
 

 
w32tm /config /manualpeerlist:"fr.pool.ntp.org" /syncfromflags:manual
 
je relance ensuite le service et force une syncro.
 

 
OK, merci.
 
 

w32tm /query /status ça affiche le ... status, pas la conf. Pour ça il y a ...  w32tm /query /configuration
Autant sur certaines commandes c'est pas clair, autant là je vois pas comment on peut faire plus clair

Bonjour,
 
Même problème sur plusieurs pc ce matin.
Quel est la marque des Pcs affectés ?  
 
Merci

 
Rajoute /reliable:yes /update à la première ligne et ça devrait être bon.

xaxaWOW >> Ça me rassure un peu ...    
Tous les serveurs affectés sont des Fujitsus.
Je viens par contre de voir que j'avais au moins un PC (hors domaine / chez un autre client) touché, c'est un portable Asus sous Windows 10 pro.
 

 
En effet oui ...      
 
Donc sur les PDCs j'ai fait les modifs je pense donc que la conf n'est plus pertinente, par contre j'ai la conf du PC Win 10 dont je parle ci-dessus :
 
[Configuration]
 

 
Il est bien en heure auto / changement d'heure auto / sur le bon fuseau horaire ...
 
nebulios >> Merci, je vais voir pour le "/reliable:yes" , si je ne me trompe pas le /update fait +/- la même chose que de relancé le service puis faire un w32tm /resync.
 
A+

eusebius >>
 
Les pcs touchés dans l'entreprise sont aussi des Fujitsus.
Je ne peut rien apporter de plus comme réponse mais cela me rassure un peu.

Tu parles de "les PDCs" mais tu as plusieurs domaines ? Dans le cas contraire tu en as qu'un seul.
La règle c'est :
Les PC et les DCs sauf le PDC du domaine root ==> Synchro de type NT5DS (là déjà on voit que tu es en NTP, c'est pas bon)
Le PDC du domaine root => Synchro de type NTP sur un serveur de temps externe (ou puce GPS si équipé ou autre équipement NTP que tu aurais)

Si DC virtuels : désactiver la synchro du temps avec l'hote pour n'utiliser que le NT5DS/NTP (pour le pdc hein uniquement)

 
Oui, je parles de plusieurs "PDCs" au sens où j'ai plusieurs clients ...  
Les domaines de mes différents clients n'ont aucune relation entre eux.
 
J'ai 2 PDCs sur les 3 que je gère qui merdaient ce matin.
En plus de ça j'ai le pb sur -au moins- un 2008R2 "isolé" et un PC hors domaine sous Win10 pro.
 

 
Tout à fait ...
 

 
Non, comme indiqué, ça ce sont les réglages d'un PC hors domaine (chez un autre clients), qui "merde" également au niveau de l'heure depuis hier.  
 
A+
 
 
PS : Voici la config du 2008R2 (ni DC ni membre d'un domaine), que je n'ai pas encore basculé sur fr.pool.ntp.org :
 

 
Son état :
 

Pour résumer, la seule machine où tu dois entrer une conf manuellement dans un domaine, c'est le PDC. Pour tout le reste tout est automatique et bien configuré par défaut, il n'y a rien à modifier  

 
J'ai bien compris, sauf que visiblement il y a autre chose ...
 
Serait-il possible que restant durablement sans réponse de time.windows.com (qui n'a pas l'air de répondre souvent), les machines rebasculent sur le temps CMOS ?
 
A+
 
PS : Au cas où il y ai un doute, vous avez bien noté que la première partie de ce topic date de 2016 et la fin de 2017.
Le problème est le même -à la même période- mais les machines impactées sont différentes (même si il y a des recoupements).

Un truc intéressant dans les journaux d'événements d'un des PDCs qui a merdé :
 
Fournisseur de temps NtpClient : aucune réponse valide n’a été reçue de l’homologue manuellement configuré time.windows.com après 8 tentatives pour le contacter. Cet utilisateur sera rejeté en tant que source de temps et NtpClient va tenter de découvrir un nouvel utilisateur avec ce nom DNS. Erreur signalée : L’homologue est inaccessible.

Oui, quand la source de temps n'est pas dispo, il va en chercher une autre (ici, la seule dispo était ton BIOS visiblement)

 
OK, donc c'est probablement bien çà ...
 
Si on ne peux pas faire confiance à time.windows.com est-ce que le remplacer par fr.pool.ntp.org suffit ? Faut-il mettre les 2 ?
 
"Mon" troisième PDC -celui qui n'a pas merdé de matin- est en statu "free-running system clock", ça na me semble pas être très bon signe ...
Il est aussi censé se synchroniser sur time.windows.com ...
 
A+

http://www.silicon.fr/ntp-horloge- [...] 71427.html