![WS2008 NTP: uso de time.windows.com, 0x9: el tiempo siempre está sesgado hacia adelante](https://rvso.com/image/568258/WS2008%20NTP%3A%20uso%20de%20time.windows.com%2C%200x9%3A%20el%20tiempo%20siempre%20est%C3%A1%20sesgado%20hacia%20adelante.png)
Tengo un controlador de dominio configurado para usar time.windows.com (con indicadores 0x09 configurados). He notado que frecuentemente el reloj de los sistemas es rápido: varía desde 10 minutos hasta incluso 45 minutos. Siempre tengo que seguir restableciendo la fecha/hora del sistema a lo que debería ser.
Cuando ejecuto "w32tm /query /source" me dice que está usando time.windows.com y, obviamente, confío en que Microsoft no mostrará horas incorrectas, pero ¿por qué el reloj de mi servidor está rápido?
EDITAR:
Hay algunos eventos de servicio de tiempo en el registro del sistema:
ID de evento: 142
Mensaje: El servicio de hora dejó de anunciarse como fuente de hora porque el reloj local no está sincronizado.
ID de evento: 139
Mensaje: El servicio de hora ha comenzado a anunciarse como fuente de hora.
Estos dos mensajes aparecen en pares aproximadamente cada hora. El evento 142 aparece de 14 a 16 minutos después de que aparece el 139.
Retrocediendo unos meses, aparecen estos eventos:
ID de evento: 35
Mensaje: El servicio de hora ahora está sincronizando la hora del sistema con la fuente de hora time.windows.com,0x9 (ntp.m|0x9|0.0.0.0:123->65.55.21.21:123).
ID de evento: 37
Mensaje: El proveedor de hora NtpClient actualmente recibe datos de hora válidos de time.windows.com,0x9 (ntp.m|0x9|0.0.0.0:123->65.55.21.21:123).
ID de evento: 47
Mensaje: Proveedor de tiempo NtpClient: no se ha recibido ninguna respuesta válida del par configurado manualmente time.windows.com,0x9 después de 8 intentos de contactarlo. Este par se descartará como fuente de tiempo y NtpClient intentará descubrir un nuevo par con este nombre DNS. El error fue: La muestra de tiempo fue rechazada porque: El par no está sincronizado o ha pasado demasiado tiempo desde la última sincronización del par.
Estos tres eventos sólo aparecen una vez en el registro, allá por octubre.
EDITAR:
Aquí está el resultado de w32tm /query /status /verbose:
enter code here
C:\Users\Administrator>w32tm /query /status /verbose
Leap Indicator: 3(last minute has 61 seconds)
Stratum: 3 (secondary reference - syncd by (S)NTP)
Precision: -6 (15.625ms per tick)
Root Delay: 0.1794868s
Root Dispersion: 4.6419912s
ReferenceId: 0x41371515 (source IP: 65.55.21.21)
Last Successful Sync Time: 2011-12-05 23:25:18
Source: time.windows.com,0x9
Poll Interval: 6 (64s)
Phase Offset: 0.0000695s
ClockRate: 0.0156243s
State Machine: 1 (Hold)
Time Source Flags: 0 (None)
Server Role: 0 (None)
Last Sync Error: 2 (The computer did not resync because only stale time data was available.)
Time since Last Good Sync Time: 1281.9919104s
Respuesta1
Tuve el mismo problema y finalmente lo resolví esta mañana. Aquí esta lo que hice:
Eche un vistazo al registro (todas las colmenas y claves en HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\W32Time) tanto en el servidor con el problema de hora como en otro servidor miembro que sincroniza ntp correctamente.
Encontré algunas discrepancias y exporté las claves \ colmenas requeridas del servidor en funcionamiento al que estaba roto. Las siguientes claves estaban estropeadas, aquí están las claves buenas que exporté de la caja de trabajo a la rota. Tenga en cuenta que estos valores pueden no ser los mismos que los suyos, así que no utilice las siguientes claves:
Faltaba el Hive de seguridad, así que lo recreé con esto:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\W32Time\Security]
"Security"=hex:01,00,04,80,84,00,00,00,90,00,00,00,00,00,00,00,14,00,00,00,02,\
00,70,00,05,00,00,00,00,00,14,00,fd,01,02,00,01,01,00,00,00,00,00,05,12,00,\
00,00,00,00,18,00,ff,01,0f,00,01,02,00,00,00,00,00,05,20,00,00,00,20,02,00,\
00,00,00,14,00,8d,01,02,00,01,01,00,00,00,00,00,05,04,00,00,00,00,00,14,00,\
8d,01,02,00,01,01,00,00,00,00,00,05,06,00,00,00,00,00,14,00,9d,01,02,00,01,\
01,00,00,00,00,00,05,13,00,00,00,01,01,00,00,00,00,00,05,12,00,00,00,01,01,\
00,00,00,00,00,05,12,00,00,00
Y noté que a la colmena NtpServer le faltaban claves, esto se solucionó importando:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\W32Time\TimeProviders\NtpServer]
"DllName"=hex(2):25,00,73,00,79,00,73,00,74,00,65,00,6d,00,72,00,6f,00,6f,00,\
74,00,25,00,5c,00,73,00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,5c,00,77,\
00,33,00,32,00,74,00,69,00,6d,00,65,00,2e,00,64,00,6c,00,6c,00,00,00
"Enabled"=dword:00000000
"InputProvider"=dword:00000000
"AllowNonstandardModeCombinations"=dword:00000001
"EventLogFlags"=dword:00000000
"ChainEntryTimeout"=dword:00000010
"ChainMaxEntries"=dword:00000080
"ChainMaxHostEntries"=dword:00000004
"ChainDisable"=dword:00000000
"ChainLoggingRate"=dword:0000001e
Luego modifiqué las siguientes claves existentes para reducir la fase:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\W32Time\Config]
"MaxAllowedPhaseOffset"=dword:00000001
"SpecialPollInterval"=dword:00000005
"SpecialInterval"=dword:00000001
Una vez que esté seguro de que el registro es correcto, ejecute los siguientes comandos a través de la línea de comandos como administrador:
w32tm /config /manualpeerlist:"YOURNTPSERVER-OR-DCHERE.YOURDOMAIN.COM,0x01" /syncfromflags:MANUAL /update
net stop w32time && net start w32time
w32tm /resync /computer:YOURNTPSERVER-OR-DCHERE.YOURDOMAIN.COM /rediscover
Esperó unos minutos y luego verificó la sincronización.
w32tm /monitor /computers:YOURNTPSERVER-OR-DCHERE.YOURDOMAIN.COM
Debería verse un poco así:
YOURNTPSERVER-OR-DCHERE.YOURDOMAIN.COM[IPOFYOUR.NTP.OR.DC:123]:
ICMP: 0ms delay
NTP: +0.0496804s offset from local clock
RefID: YOURNTPSERVER-OR-PDCHERE [IPOFYOUR.NTP.OR.PDC]
Stratum: 3
Luego verifique la fase:
w32tm /stripchart /computer:YOURNTPSERVER-OR-DCHERE.YOURDOMAIN.COM
Debe tener un aspecto como este:
10:08:42 d:+00.0000000s o:+00.0139224s [ * ]
10:08:44 d:+00.0000000s o:-00.0015659s [ * ]
10:08:46 d:+00.0000000s o:-00.0014534s [ * ]
10:08:48 d:+00.0000000s o:-00.0013418s [ * ]
10:08:50 d:+00.0000000s o:-00.0012421s [ * ]
¡Espero que esto ayude!
Respuesta2
¿Es este el DC que desempeña la función de emulador de PDC? Solo necesitará configurar el que tiene la función de emulador de PDC con una fuente de hora externa; otros DC se sincronizarán automáticamente con el PDC.
El estado actual del servicio de hora se puede obtener a través de w32tm /query /status /verbose
: debería brindarle algunos detalles sobre el estado de su reloj local, la desviación en la última sincronización y la precisión. Según los eventos registrados, su reloj local parece ser demasiado poco confiable para la fuente horaria. El intervalo de sincronización predeterminado de w32time sería de 1024 segundos después de algunas sincronizaciones exitosas; esto es alrededor de 17 minutos, que es aproximadamente la diferencia de tiempo entre los eventos 139 y 142.
Si se trata de un sistema virtualizado, debería buscar emulaciones de hardware de temporizador alternativas. VMWare ha publicado undocumento completo sobre este temaque vale la pena leer incluso cuando utiliza diferentes productos de virtualización.
Si se trata de un sistema físico, considere reducir MaxPollInterval para el servicio w32time como solución alternativa o mover la función del emulador de PDC a una máquina diferente con un reloj más confiable.
Editar: el problema de los "datos de tiempo obsoletos" podría ser un problema con el servidor de tiempo que está intentando consultar. Intente reemplazar el "time.windows.com" predeterminado por un servidor del grupo NTP público (<region>.pool.ntp.org
) en su configuración NTP (solo use net time /setsntp:<servername>
)