Synchronisation de l'heure Domaine AD 2008

[Résolu/Fermé]
Signaler
Messages postés
8
Date d'inscription
lundi 21 juillet 2014
Statut
Membre
Dernière intervention
28 septembre 2015
-
Messages postés
3023
Date d'inscription
vendredi 18 juin 2004
Statut
Contributeur
Dernière intervention
27 juillet 2021
-
Bonjour,

J'ai problème de synchronisation entre mon PDC, les DCs et les ordinateurs du domaine, chacun d'entre eux a une heure différente des autres.
j'ai resynchroniser manuellement rien n'a changé..

Quelqu'un pourrait m'aider s'il vous plait?

Merci d'avance.
A voir également:

3 réponses

Messages postés
3023
Date d'inscription
vendredi 18 juin 2004
Statut
Contributeur
Dernière intervention
27 juillet 2021
417
Alors, pour la petite histoire,

Au Maroc, l'horloge change souvent avec les périodes du Ramadan, et c'est très souvent problématique pour la gestion de l'heure; il y a d'autres pays dans ce type de situation, le cas n'est pas isolé; mais j'ai travaillé sur cette problématique avec le Maroc; sans compter que le changement d'heure peut être décidé ou même repoussé à la dernière minute... pour nous informaticiens c'est gênant à gérer.

Mais avant tout, ne changez jamais l'heure sur vos postes ou vos serveurs lors des périodes de chgt d'heure été/hiver + période Ramadan; il faut seulement changer le fuseau horaire, mais pas l'heure.

La référence de l'heure reste UTC, et on vient modifier le fuseau, c'est tout.
Le fuseau c'est juste de "l'affichage" en gros sur les machines.

Et lors de ces périodes de chgt d'heure, Microsoft prévoit des patchs pour prendre en compte le changement du fuseau. On utilise uniquement ces patchs sur les machines pour prendre en compte heure été/hiver/ramadan etc ... mais l'heure UTC on ne la change pas.

Quelques liens pour se tenir informé :
https://docs.microsoft.com/en-us/archive/blogs/

et en l'occurrence pour cet été 2015 au Maroc post ramadan:
https://support.microsoft.com/en-us/help/3062741/2015-morocco-ramadan-dst-changes-end-date-hotfix

Il faut que les machines serveurs+clients aient ces mises à jour. Faites le test dans un premier temps avec un machine qui a le problème pour vérifier que ça fonctionne.

Le souci c'est que certains postes sont à l'heure mais utilise un fuseau horaire "différent ou non patché" ; en voyant la machine on "croit" qu'elle n'est pas à l'heure, donc on modifie l'heure en pensant bien faire...ce qu'il ne fallait pas faire ;-)

-
Analyse pour le w32tm /monitor :

1. Le PDC srvmail se synchronise avec personne.
Dans le résultat on a pour le PDC "RefID: (inconnu) [0x6A86D168]" ; ce qui n'est pas bon du tout.

-> Il faut configurer/vérifier la synchro de temps NTP externe uniquement sur le PDC, à savoir sur srvmail.

2. srvappl : aucun problème, il sync l'heure depuis le PDC.
3. srvfiles : aucun problème, il sync l'heure depuis le PDC.

4. mail : problème !! Lui il est dans les choux. Il est complètement décalé, et surtout on arrive pas à avoir les infos, ni même un Ping. Il doit y avoir un probleme de connectivité avec ce serveur. (notamment entre la machine où vous avez fait le w32tm /monitor et ce serveur mail).

Il a un décalage de l'heure 4 jours tout pile.
Il y a un risque d'avoir des problèmes de réplication sur ce serveur.


-> Est ce que ce serveur est toujours d'actualité ?
-> Est ce qu'il a des soucis de connectivité / Firewall /etc ...
-> il faut re paramétrer la date et l'heure dessus manuellement. Après on verra pour la synchro temps.


-
Comment configurer la synchro externe sur le PDC :

1. Se connecter sur srvmail avec un compte disposant de droits administrateurs domaine/enterprise.

2. Lancer une invite de commande en tant qu'administrateur (CMP prompt with admin privileges).

3. Lancer la commande suivante (une seule ligne):

w32tm /config /manualpeerlist:"0.fr.pool.ntp.org 1.fr.pool.ntp.org 2.fr.pool.ntp.org 3.fr.pool.ntp.org" /syncfromflags:manual /reliable:yes /update


4. On redémarre le service de temps pour être "sur"
 net stop w32time && net start w32time


5. on surveille ensuite avec :
w32tm /monitor


Ne pas hésiter à faire le /monitor plusieurs fois d'affilée, car la synchro prend des dizaine de secondes, ça permet de refresh les résultats...

PS : si ça ne synchronise pas :
- Il est possible que NTP soit filtré, demandez aux équipes réseaux d'ouvrir le flux NTP pour ce PDC vers la liste de serveurs mentionnés.
- Il est aussi possible que vous ayez déja un serveur NTP (boitier réseau généralement) qui fasse office de référence NTP fiable. Dans ce cas synchronisez le PDC sur ces boitiers.


ps : j'ai consciemment mis des serveurs NTP français, car les temps de réponse avec le Maroc sont bons, contrairement aux serveurs NTP de la plaque africaine, notamment en SA c'est moins bon.
Tu peux mettre n'importe quelle liste de serveur NTP en remplacement. pool.NTP.Org a des serveurs listés en Tunisie au mieux, mais pas au maroc.
Il faut garder à l'esprit que les temps de réponses doivent être corrects pour avoir une bonne synchro fiable.
http://www.pool.ntp.org/zone/africa

-

Résumé des actions à mener :

1. Préparer les patchs sur des machines en test.
2. Revoir la configuration de la synchro NTP externe sur le PDC srvmail.
3. Corriger manuellement la date et l'heure sur le serveur mail.
4. Vérifier la connectivité entre le serveur mail et les autres DCs.


On verra après pour la suite.

Messages postés
8
Date d'inscription
lundi 21 juillet 2014
Statut
Membre
Dernière intervention
28 septembre 2015

Bonjour,

J'ai resynchronisé la synchro externe sur le PDC et le résultat est bon maintenant!
Résultat du w32tm/ monitor:

C:\Users\Administrateur.E>w32tm /monitor
Obtention de la liste de contrôleurs de domaine Active Directory pour le
domaine par défaut...
srvappl.e.intra[192.168.2.101:123]:
ICMP: 0ms retard
NTP: +0.0128442s Décalage de srvmail.e.intra
RefID: srvmail.e.intra [192.168.2.102]
Couche: 4
srvmail.e.intra *** PDC ***[[fe80::8971:a5c2:c56d:bcfc%10]:123]:
ICMP: 0ms retard
NTP: +0.0000000s Décalage de srvmail.e.intra
RefID: www.mindstudios.com [195.154.71.176]
Couche: 3
srvfiles.e.intra[192.168.2.103:123]:
ICMP: 0ms retard
NTP: +0.0036665s Décalage de srvmail.e.intra
RefID: srvmail.e.intra [192.168.2.102]
Couche: 4
mail.e.intra[192.168.2.15:123]:
ICMP: erreur IP_REQ_TIMED_OUT - Aucune réponse dans 1000ms
NTP: erreur ERROR_TIMEOUT - Aucune réponse du serveur dans 1000ms
APP.e.intra[192.168.2.120:123]:
ICMP: 0ms retard
NTP: -345728.2366811s Décalage de srvmail.e.intra
RefID: (non spécifié/non synchronisé) [0x00000000]
Couche: 0

Attention :
La résolution de nom inverse est conseillée. Une erreur peut
se produire car le champ d'ID de référence des paquets de temps diffère entre
les implémentations NTP et peut ne pas utiliser les adresses IP.

-Pour les patchs j'ai essayé de les installer sur des machines et sur un serveur et j'ai un message disant :" La mise à jour ne s'applique pas à votre système".

c'est le serveur APP qui a un problème de synchro et non pas mail. Mail n'existe plus je dois le supprimer.
Pour le APP l'heure affiché est exactement la même que sur le srvmail, srvappl... La date Aussi.. Le ping entre APP et srvmail passe sans problème et il n y'a pas de soucis de firewall ou autre.
La réplication dessus ne marche pas bien évidement a cause du problème d'horloge.


Merci.
Messages postés
8
Date d'inscription
lundi 21 juillet 2014
Statut
Membre
Dernière intervention
28 septembre 2015

Re bonjour,

Le problème de synchronisation venait du fait qu' il y' avait un décalage énorme entre le Serveur APP (virtuel) et le serveur physique tournant sous ESXI.
J'ai réglé l'heure sur le ESXI et il s'est synchronisé automatiquement et le problème de réplication est résolu.

Maintenant reste a ce que toutes les machines clientes et quelques serveurs se synchronisent eux aussi avec le PDC ( décalage de -1h).
J'ai redémarré le service Temps Windows sur ma machine et j'ai toujours un décalage d'1 heure de moins.

Ci après le résultat du W32tm/ monitor:

C:\Users\administrateur.E>w32tm /monitor
Obtention de la liste de contrôleurs de domaine Active Directory pour le
domaine par défaut...
srvappl.e.intra[192.168.2.101:123]:
ICMP: 0ms retard
NTP: +0.0493755s Décalage de srvmail.e.intra
RefID: srvmail.e.intra [192.168.2.102]
Couche: 4
srvmail.e.intra *** PDC ***[192.168.2.102:123]:
ICMP: 0ms retard
NTP: +0.0000000s Décalage de srvmail.e.intra
RefID: www.mindstudios.com [195.154.71.176]
Couche: 3
mail.e.intra[192.168.2.15:123]:
ICMP: erreur IP_REQ_TIMED_OUT - Aucune réponse dans 1000ms
NTP: erreur ERROR_TIMEOUT - Aucune réponse du serveur dans 1000ms
srvfiles.e.intra[192.168.2.103:123]:
ICMP: 0ms retard
NTP: -0.0571013s Décalage de srvmail.e.intra
RefID: srvmail.e.intra [192.168.2.102]
Couche: 4
APP.e.intra[[fe80::cdc7:ed72:4838:1374%10]:123]:
ICMP: 0ms retard
NTP: +0.1431140s Décalage de srvmail.e.intra
RefID: srvmail.e.intra [192.168.2.102]
Couche: 4

Attention :
La résolution de nom inverse est conseillée. Une erreur peut
se produire car le champ d'ID de référence des paquets de temps diffère entre
les implémentations NTP et peut ne pas utiliser les adresses IP.


Je reste à l'attente de vos commentaires.
Merci.
Messages postés
3023
Date d'inscription
vendredi 18 juin 2004
Statut
Contributeur
Dernière intervention
27 juillet 2021
417
Bonjour,

Une petite note pour les Contrôleurs de domaine virtualisés, notamment sur ESXi etc ...

1. Sur des DC virtualisés, il faut toujours désactiver la synchro de l'heure via les "VM Tools". (ceci s'applique uniquement pour les controleurs de domaine virtualisés, on désactive la synchro VMware pour ces machines uniquement).

2. il faut aussi synchroniser le host ESX, car quand les VMs démarrent, leur BIOS virtuel synchro l'heure avec l'hote ESX. Si l'hote ESX est décalé, on fait démarré les VMS avec un décalage, après elles se mettront à jour une fois démarrée.
Mais lorsque le décalage est trop important, la synchronisation n'est plus possible sous windows. (notamment à cause du temps décalé qui induit un problème dans l'authentification Kerberos, la machine n'est pas authentifiée correctement dans le domaine ... et cet effet est "pire" pour un DC ...)

3. Le PDC ne doit pas être virtualisé, mais physique.Microsoft ne préconise pas un PDC virtualisé, notamment pour les problèmes exposés ci dessus.


NB : désolé je n'avais pas vu la ligne pour le serveur APP, en effet c'était lui qui était décalé de 4 jours.
Le serveur mail a mal été décomissionné s'il n'est plus contrôleurs de domaine. Il apparait toujours en tant que DC pour les autres DC.

-

Pour les machines avec 1H de décalage, plusieurs possibilités :

- problème de fuseau horaire et application ou non de l'heure d'été/hiver. Ce n'est que de l'afficahge, l'heure est bonne deriière ...
Par contre si on voit toujours les pbs cités au début liés à l'authentification, ce n'est pas la bonne piste. (redémarrer la machine et se reconnecter dessus est un bon test avant de voir si il y a pb d'authentification).

- Installez les patchs en question en prenant soin de choisir la bonne version de windows. Si c'est du XP -> ce n'est plus supporté...
et Redémarrez les machines.

- si ça a été modifié manuellement, il faut redémarrer les machines, pour voir si elles se resynchro ... sinon re modifier l'heure manuellement pour qu'elle puisse de nouveau se synchro avec les DCs.

Sachant que les machines clientes/serveurs se synchronisent avec n'importe quel DC et pas le PDC forcément.

S'il y a un décalage trop important, les machines ne peuvent se synchroniser avec Active Directory, car elles ont besoin d'être authentifiées. Kerberos admet un décalage de 5 minutes max pour valider l'authentification. Comme ici on a un décalage plus grand, l'authentification est KO, donc tout ce qui nécessite une authentification ne marche plus.


Using a registry "compactor" on top of a registry "cleaner" would be equivalent to rinsing your throat with a swig of Jack Daniels after swallowing a pint of snake oil....
Messages postés
8
Date d'inscription
lundi 21 juillet 2014
Statut
Membre
Dernière intervention
28 septembre 2015

Bonjour Kelux,

Le problème est finalement réglé et les soucis d'authentification ne se posent plus.
Je vous remercie infiniment pour votre aide précieuse.

A bientôt :)
Messages postés
3023
Date d'inscription
vendredi 18 juin 2004
Statut
Contributeur
Dernière intervention
27 juillet 2021
417 >
Messages postés
8
Date d'inscription
lundi 21 juillet 2014
Statut
Membre
Dernière intervention
28 septembre 2015

Hello,

Merci pour votre retour, content que ces soucis soient résolus !

Au plaisir, bonne journée ;-)

ps : surveillez de près pour décommisionner le DC "mail", ne le laissez pas dans cet état trop longtemps sans lui enlever au moins le rôle de DC, vous risquerez d'introduire des lingering objects.
Messages postés
8
Date d'inscription
lundi 21 juillet 2014
Statut
Membre
Dernière intervention
28 septembre 2015

Bonjour Kelux,
Je reviens vers vous pour vous demander si vous pouvez m'aider à appliquer une règle GPO qui pourra automatiser la mise à jour de l'heure sur l'ensemble des postes clients sans pour autant changer le fuseau horaire chez chacun d'entre eux manuellement...
Merci de votre aide.
Messages postés
3023
Date d'inscription
vendredi 18 juin 2004
Statut
Contributeur
Dernière intervention
27 juillet 2021
417 >
Messages postés
8
Date d'inscription
lundi 21 juillet 2014
Statut
Membre
Dernière intervention
28 septembre 2015

Ba faut voir ...
Mise à jour de l'heure et changement de fuseau horaire, ce n'est pas la même chose, comme je l'ai expliqué dans ce post ; il faut bien distinguer les deux !

Par contre, si une machine n'est pas synchronisée, elle ne peut pas s'authentifier correctement dans le domaine et par conséquent ne peut recevoir les GPOs proprement.

De toute façon, de base la synchro de l'heure se fait automatiquement, et par Active Directory dans notre cas.
Messages postés
3023
Date d'inscription
vendredi 18 juin 2004
Statut
Contributeur
Dernière intervention
27 juillet 2021
417
Bonjour,

j'ai resynchroniser manuellement rien n'a changé..

Comment ? Qu'avez vous fait "manuellement" ?


Qui n'est pas synchronisé avec qui ? Donnez quelques précisions svp.
Dire que "PDC+DCs+postes" pas synchronisés, ne permet pas de cibler le problème.


En admin du domaine (ou enterprise admin), dans une console CMD, que donne un
w32tm /monitor



Messages postés
8
Date d'inscription
lundi 21 juillet 2014
Statut
Membre
Dernière intervention
28 septembre 2015

Bonjour,

Merci de votre réponse.

J'ai resynchronisée a l'aide d'un w32tm/resync.

J'ai un PDC et 3 Dcs et un ensemble de poste utilisateurs.
Entre le PDC et 2 DC la synchronisation de l'heure passe sans problème et automatiquement.
Un DC est en décalage par rapport au PDC et c'est le même cas pour les postes utilisateurs ( -1h de différence)

Pour régler le problème de décalage d'heure, il a fallut modifier chez les utilisateurs manuellement.
ce décalage engendre beaucoup de problèmes notamment les partages inaccessible avec un message disant :" l'horloge n'est pas synchronier..." ou bien des déconnexion depuis Outlook pour la messagerie Exchange (2007)

Ci après le résultat du w32tm/monitor:

C:\Users\Administrateur.E>w32tm /monitor
Obtention de la liste de contrôleurs de domaine Active Directory pour le
domaine par défaut...
srvappl.e.intra[192.168.2.101:123]:
ICMP: 0ms retard
NTP: -0.3055391s Décalage de srvmail.e.intra
RefID: srvmail.e.intra [192.168.2.102]
Couche: 4
srvmail.e.intra *** PDC ***[[fe80::8971:a5c2:c56d:bcfc%10]:123]:
ICMP: 0ms retard
NTP: +0.0000000s Décalage de srvmail.e.intra
RefID: (inconnu) [0x6A86D168]
Couche: 3
srvfiles.e.intra[192.168.2.103:123]:
ICMP: 0ms retard
NTP: -0.0873014s Décalage de srvmail.e.intra
RefID: srvmail.e.intra [192.168.2.102]
Couche: 4
mail.e.intra[192.168.2.15:123]:
ICMP: erreur IP_REQ_TIMED_OUT - Aucune réponse dans 1000ms
NTP: erreur ERROR_TIMEOUT - Aucune réponse du serveur dans 1000ms
APP.e.intra[192.168.2.120:123]:
ICMP: 2ms retard
NTP: -345721.3461970s Décalage de srvmail.e.intra
RefID: (non spécifié/non synchronisé) [0x00000000]
Couche: 0

Attention :
La résolution de nom inverse est conseillée. Une erreur peut
se produire car le champ d'ID de référence des paquets de temps diffère entre
les implémentations NTP et peut ne pas utiliser les adresses IP.


Merci.