El tiempo de Windows sigue desviándose: la corrección de NTP que la gente olvida

Qué es realmente la deriva del tiempo (y por qué Windows es especial)

La deriva del tiempo es el desfase del reloj del sistema respecto de la «hora real». Suena filosófico hasta que intentas validar un certificado que aparece como «aún no válido» o «caducado» porque tu máquina cree que estamos en el martes pasado. La deriva es normal; los cristales no son perfectos, hay cambios de temperatura y las máquinas virtuales están a merced del jitter de planificación y de vCPUs pausadas.

Lo que no es normal es la deriva sin límite. NTP (Network Time Protocol) existe para que las máquinas puedan ajustarse de forma continua. Pero Windows no es un cliente NTP genérico como la gente espera. El servicio de tiempo de Windows (w32time) está diseñado principalmente para mantener coherencia en un dominio Windows, no para competir en precisión.

En un entorno de Active Directory, el diseño «correcto» es una jerarquía: estaciones de trabajo y servidores miembros sincronizan desde los controladores de dominio, los controladores de dominio sincronizan hacia arriba en la cadena y el PDC emulator del root del bosque es el que tratas como autoridad de tiempo (con fuentes NTP externas). Si combates ese modelo apuntando equipos miembros al azar a servidores NTP externos, puedes crear un reloj con cerebro dividido y pasar el resto del día explicando por qué Kerberos está enfadado.

Además: Windows tiene opiniones sobre el stepping vs slewing (saltar la hora frente a ajustarla gradualmente), sobre los intervalos de sondeo y sobre mantener la hora cuando una fuente es inestable. Encima de eso, los hipervisores y las herramientas de invitados a menudo «corrigen» el tiempo también—a veces de forma brutal. Dos guardianes del tiempo en una misma caja no es redundancia; es una disputa de custodia.

Broma #1: La deriva del tiempo es como la deuda técnica: se compone en silencio hasta tu próximo incidente, y entonces todo el mundo de repente tiene opiniones muy firmes al respecto.

Hechos e historia que puedes usar en un postmortem

Esto no es trivia por el placer de la trivia. Son pequeñas piezas de contexto que te ayudan a elegir la corrección adecuada y defenderla en una revisión de cambios.

1. NTP es antiguo (años 80) y probado en combate. Precede a la mayoría de los sistemas que ahora mantiene honestos. El protocolo evolucionó para tolerar redes con jitter y relojes imperfectos.
2. Windows Time (w32time) priorizó la corrección del dominio. Microsoft lo diseñó para mantener Kerberos y el AD felices, no para competir con demonios NTP de alta precisión usados en laboratorios.
3. Kerberos tiene una tolerancia estricta de desajuste de reloj. Si tu cliente y el DC discrepan más allá de una pequeña ventana, la autenticación falla de formas que parecen «fallos aleatorios de inicio de sesión».
4. La virtualización hizo la deriva más común. Las VMs pueden pausarse, migrarse, dejar de recibir CPU o reanudarse desde snapshots; todo eso puede confundir un reloj ingenuo.
5. La confusión SNTP vs NTP persiste. Muchos sistemas hablan consultas «NTP simples» pero no implementan por completo los algoritmos de disciplina NTP. w32time históricamente se comportó más cerca de SNTP en algunos escenarios.
6. Los segundos intercalares son un peligro operativo real. Diferentes plataformas los han manejado de formas distintas (saltarlos, difuminarlos o ignorarlos). Un manejo inconsistente puede crear discrepancias pequeñas pero agudas.
7. La sincronización horaria es una primitiva de fiabilidad y seguridad. Auditoría, forense, duraciones de tokens y validación de certificados asumen que los relojes no mienten.
8. Algunos entornos prohíben NTP saliente. Las empresas suelen restringir UDP/123. Esto obliga a usar fuentes de tiempo internas—and hace que la jerarquía no sea negociable.
9. Los relojes hardware varían enormemente. Osciladores baratos se desvían; la temperatura afecta la frecuencia; y los portátiles que duermen y despiertan hacen la sincronización horaria «creativa».

Guion de diagnóstico rápido (primero/segundo/tercero)

Si el tiempo se desvía, no empieces cambiando ajustes. Empieza por identificar a qué autoridad de reloj obedece realmente el sistema y si varias autoridades están peleando. Aquí está la ruta más rápida hacia el cuello de botella.

Primero: confirma el síntoma y el alcance

• ¿Es un host, una OU, un sitio o «todo el dominio»?
• ¿La deriva es continua o salta después de reanudar/migrar?
• ¿El impacto es autenticación (Kerberos), TLS, tareas programadas o logs?

Segundo: identifica la fuente activa de tiempo y la última sincronización

• En la máquina afectada: ¿qué dice w32tm /query /status para Source y Last Successful Sync Time?
• En miembros del dominio: ¿se sincronizan desde el dominio (lo esperado), o desde un par externo (normalmente incorrecto)?
• En DCs: ¿el PDC emulator se sincroniza externamente y los demás DCs lo hacen desde él?

Tercero: busca proveedores de tiempo en competencia

• Hyper-V: ¿está habilitado el servicio de integración de sincronización de tiempo?
• VMware: ¿están activadas las funciones de sincronización de tiempo de VMware Tools?
• Veeam/herramientas de backup: ¿las restauraciones/snapshots causan saltos de tiempo?
• GPO/baseline de seguridad: ¿un push de políticas cambió ajustes NTP o deshabilitó proveedores?

Si solo recuerdas una cosa: la deriva del tiempo suele ser un problema de plano de control, no un problema de física. Arregla la cadena de autoridad y la pelea se detiene. Entonces la física es manejable.

La jerarquía de tiempo en Windows: quién debe sincronizarse con quién

En un dominio Windows, deja de pensar en «configuración de servidor NTP» como algo que aplicas a cada máquina. Ese enfoque es como conseguir un dominio en el que cada nodo cree en un reloj distinto, y entonces Kerberos empieza a rechazar tickets porque tu flota no se pone de acuerdo sobre qué minuto es.

Miembros del dominio (estaciones de trabajo, servidores miembros)

Deben sincronizarse desde el dominio. Eso normalmente significa que usan el modo NT5DS, lo que indica a Windows que siga automáticamente la jerarquía del dominio. Su «servidor NTP» no es un pool público; es el DC con el que están hablando.

Controladores de dominio

Los DCs que no son PDC deben sincronizarse desde la jerarquía del dominio (ultimadamente desde el PDC emulator). No deberían estar todos apuntando a Internet. Eso crea flapping de fuentes de tiempo y dificulta razonar sobre la corrección.

PDC emulator del root del bosque (el jefe)

Este es el que debería tener fuentes ascendentes explícitas y fiables. Si configuras NTP externo, hazlo aquí. Si estás en un entorno regulado, usa appliances internos stratum-1/2 o fuentes con GPS. Si no, elige un par de servidores NTP internos estables y deja que ellos lleguen al upstream—luego apunta el PDC a esos.

Máquinas independientes (no unidas al dominio)

Aquí es el Lejano Oeste. En estos casos, configurar pares directamente está bien—pero aún tienes que vigilar la interferencia del hipervisor y los intervalos de sondeo poco razonables.

La corrección NTP que la gente olvida: fuentes de tiempo en competencia

La mayoría de los incidentes de «deriva en Windows» que he visto no se resolvieron añadiendo más servidores NTP. Se resolvieron eliminando la segunda (y tercera) fuente de tiempo que silenciosamente estaba pisoteando la disciplina de w32time.

La pelea clásica: w32time vs sincronización del hipervisor

Los hipervisores a menudo ofrecen un mecanismo de sincronización «útil». Puede ser estupendo para VMs Linux sin dominio y terrible para servidores Windows unidos a un dominio. ¿Por qué? Porque tiende a step el reloj (saltar), especialmente después de pause/resume, revert de snapshot o migración en vivo. Mientras tanto w32time intenta slew gradualmente basado en muestras NTP. Terminas con:

• Saltos de tiempo repentinos periódicos (la herramienta del VM corrige)
• Luego corrección lenta de la deriva (w32time intenta estabilizar)
• Luego otro salto (la herramienta corrige otra vez)

Desde afuera, parece que «NTP está roto». Por dentro, simplemente lo están minando.

Otra pelea: GPO que establece pares NTP en miembros de dominio

Alguien escribe una política bien intencionada: «Todas las máquinas Windows deben sincronizarse desde time.company.local». La aplican a toda la OU. Felicidades: acabas de sobrescribir la jerarquía del dominio y crear una dependencia en un único servidor (o peor, en una IP que no es alcanzable desde cada sitio). Los miembros del dominio no deberían necesitar pares explícitos. Necesitan una cadena de tiempo de dominio funcional.

La pelea sutil: «optimización» cambiando intervalos de sondeo

La gente ve deriva y sube el sondeo a valores agresivos, pensando que más muestras equivalen a mejor tiempo. A veces sí. A menudo solo aumenta la carga, provoca limitación de tasa en upstream y hace que w32time trate la fuente como inestable. O mantiene el reloj oscilando porque efectivamente estás sobrecorregiendo.

Qué hacer: elige una autoridad por capa. Deshabilita o restringe el resto. Mantén la jerarquía limpia. Si necesitas sincronización del hipervisor, úsala intencionalmente (típicamente para el PDC emulator no quieres stepping del hipervisor; para algunas cargas aisladas, sí puedes necesitarlo).

Una idea de confiabilidad parafraseada: John Allspaw argumenta que la fiabilidad viene de entender cómo fallan los sistemas en condiciones reales, no de creer los diagramas del camino feliz.

Tareas prácticas con comandos: verificar, decidir, arreglar

No corriges la deriva por intuición. Lo haces leyendo lo que el sistema cree que está haciendo, luego cambiando una cosa a la vez y validando. Abajo hay tareas prácticas. Cada una incluye (1) un comando, (2) salida de ejemplo, (3) qué significa y (4) la decisión que tomas a partir de ello.

Task 1: Check the active time source on a Windows machine

cr0x@server:~$ w32tm /query /status
Leap Indicator: 0(no warning)
Stratum: 3 (secondary reference - syncd by (S)NTP)
Precision: -23 (119.209ns per tick)
Root Delay: 0.0312500s
Root Dispersion: 0.1015625s
ReferenceId: 0xC0A8010A (source IP:  192.168.1.10)
Last Successful Sync Time: 2/5/2026 9:42:11 AM
Source: DC01.corp.local
Poll Interval: 10 (1024s)

Significado: La máquina se está sincronizando desde DC01. Eso suele ser correcto para un miembro de dominio. Poll Interval muestra con qué frecuencia hace el sondeo.

Decisión: Si esto es un miembro de dominio y la fuente es un DC, bien. Si apunta a un servidor NTP externo o a «Local CMOS Clock», tienes un problema de configuración/autoridad.

Task 2: Identify whether the machine is domain-hierarchy mode or manual peers

cr0x@server:~$ w32tm /query /configuration
[TimeProviders]
NtpClient (Local)
DllName: C:\Windows\system32\w32time.dll
Enabled: 1
InputProvider: 1

[Parameters]
NtpServer: time.company.local,0x9
Type: NTP

Significado: Type: NTP significa que hay pares manuales configurados. En un miembro de dominio, esto suele anular la cadena de tiempo prevista del dominio.

Decisión: Para miembros de dominio: cambia Type de vuelta a NT5DS (jerarquía del dominio). Para el PDC emulator: los pares manuales son apropiados.

Task 3: Force a resync and see if it succeeds

cr0x@server:~$ w32tm /resync /force
Sending resync command to local computer...
The command completed successfully.

Significado: El cliente contactó su fuente y actualizó la hora (o al menos cree que lo hizo).

Decisión: Si el resync falla, ve directo a conectividad, firewall y logs de evento. Si tiene éxito pero la deriva continúa, sospecha fuentes de tiempo en competencia o upstream malo.

Task 4: Measure offset to a specific peer

cr0x@server:~$ w32tm /stripchart /computer:DC01.corp.local /samples:5 /dataonly
09:45:01, +00.0123456s
09:45:03, +00.0119023s
09:45:05, +00.0121011s
09:45:07, +00.0124420s
09:45:09, +00.0122104s

Significado: El cliente tiene ~12ms de adelanto respecto a DC01. Eso está bien para la mayoría de necesidades empresariales.

Decisión: Si ves offsets de segundos, entras en territorio de «Kerberos puede romperse». Si los offsets varían mucho entre muestras, sospecha jitter de red, upstream inestable o efectos de pausa/resume de VM.

Task 5: Confirm the Windows Time service is running

cr0x@server:~$ sc query w32time
SERVICE_NAME: w32time
        TYPE               : 20  WIN32_SHARE_PROCESS
        STATE              : 4  RUNNING
        WIN32_EXIT_CODE    : 0  (0x0)
        SERVICE_EXIT_CODE  : 0  (0x0)
        CHECKPOINT         : 0x0
        WAIT_HINT          : 0x0

Significado: El servicio está en ejecución.

Decisión: Si está STOPPED o inestable, arregla eso primero (política, dependencias o corrupción). Sin servicio, no hay sincronización.

Task 6: Review time service events (quick filter)

cr0x@server:~$ wevtutil qe System /q:"*[System[Provider[@Name='Microsoft-Windows-Time-Service']]]" /c:5 /rd:true /f:text
Event[0]:
  Provider Name: Microsoft-Windows-Time-Service
  Event ID: 35
  Level: Error
  Description: The time service has not synchronized the system time for 86400 seconds because no time data was available.

Significado: w32time no está recibiendo muestras utilizables. Podría ser NTP bloqueado, fuente equivocada, problemas DNS o upstream muerto.

Decisión: Valida la ruta de red hacia la fuente y luego valida la propia fuente. No ajustes los intervalos de sondeo hasta que tengas un upstream sano.

Task 7: Check the domain controller time role (PDC emulator)

cr0x@server:~$ netdom query fsmo
Schema master               DC01.corp.local
Domain naming master        DC01.corp.local
PDC                         DC02.corp.local
RID pool manager            DC01.corp.local
Infrastructure master       DC01.corp.local
The command completed successfully.

Significado: DC02 es el PDC emulator del dominio (la «raíz» de tiempo para la jerarquía del dominio en la práctica).

Decisión: Centra tu configuración NTP externa y monitorización en DC02. Si configuraste pares en el DC equivocado, puedes obtener autoridad de tiempo inconsistente.

Task 8: Check which DC a client is using (and whether it’s sane)

cr0x@server:~$ nltest /dsgetdc:corp.local
           DC: \\DC03.corp.local
      Address: \\192.168.50.23
     Dom Guid: 9e2b7a9d-1a5b-4c42-9f1a-0d1c7e6c1a11
     Dom Name: corp.local
  Forest Name: corp.local
 Dc Site Name: BRANCH-01
Our Site Name: BRANCH-01
The command completed successfully.

Significado: El cliente está usando un DC del sitio local (bien). Si está seleccionando un DC de sitio remoto, la latencia/jitter y el firewall pueden perjudicar la estabilidad del tiempo.

Decisión: Si el DC seleccionado es remoto, revisa la configuración de AD Sites/Subnets. Los problemas de tiempo a veces empiezan porque «tu topología de sitio está mintiendo».

Task 9: Verify UDP/123 connectivity to an NTP server (basic test)

cr0x@server:~$ w32tm /stripchart /computer:time.company.local /samples:3 /dataonly
09:47:01, +00.0000000s
09:47:03, +00.0000000s
09:47:05, +00.0000000s

Significado: Obtienes respuestas. Si se cuelga o da error, UDP/123 puede estar bloqueado o la resolución de nombres rota.

Decisión: Si está bloqueado, arregla las reglas de firewall entre la capa adecuada de tu jerarquía, no desde cada endpoint hacia Internet.

Task 10: Configure the PDC emulator to use manual peers (the right place to do it)

cr0x@server:~$ w32tm /config /manualpeerlist:"time1.company.local,0x8 time2.company.local,0x8" /syncfromflags:manual /reliable:yes /update
The command completed successfully.

Significado: Has establecido pares explícitos, indicado a Windows que los use y marcado este host como fiable para otros.

Decisión: Haz esto en el PDC emulator (típicamente el root del bosque). No lo hagas en DCs aleatorios y definitivamente no en clientes.

Task 11: Configure domain members back to domain hierarchy mode

cr0x@server:~$ w32tm /config /syncfromflags:domhier /update
The command completed successfully.

Significado: El cliente seguirá la jerarquía de tiempo de AD.

Decisión: Si tu entorno está unido al dominio, esta es la opción por defecto que quieres, salvo que tengas una excepción explícita y justificada.

Task 12: Restart time service and force rediscovery (when config changes)

cr0x@server:~$ net stop w32time
The Windows Time service was stopped successfully.
cr0x@server:~$ net start w32time
The Windows Time service was started successfully.
cr0x@server:~$ w32tm /resync /rediscover
Sending resync command to local computer...
The command completed successfully.

Significado: Aplicaste cambios de configuración y forzaste que redescubriera fuentes.

Decisión: Usa esto después de cambiar Type, pares o ajustes por GPO. Si sigue sin sincronizar, tienes problemas de upstream o conectividad.

Task 13: Confirm what the time service thinks its peers are

cr0x@server:~$ w32tm /query /peers
#Peers: 2

Peer: time1.company.local,0x8
State: Active
Time Remaining: 734s
Mode: 3 (Client)
Stratum: 2

Peer: time2.company.local,0x8
State: Active
Time Remaining: 734s
Mode: 3 (Client)
Stratum: 2

Significado: El PDC ve dos pares y están activos. Bien.

Decisión: Si los pares están «Pending» o «Unknown», resuelve DNS, firewall o la salud del servicio NTP upstream.

Task 14: Check for virtualization time sync features that can step the clock (Hyper-V example)

cr0x@server:~$ powershell -NoProfile -Command "Get-VMIntegrationService -VMName 'APP01' | Where-Object {$_.Name -eq 'Time Synchronization'} | Format-List Name,Enabled"
Name    : Time Synchronization
Enabled : True

Significado: La sincronización de tiempo de Hyper-V está habilitada para la VM APP01. Eso puede estar bien, o puede ser la razón oculta de que tu reloj salte.

Decisión: Para servidores Windows unidos al dominio, considera deshabilitar este servicio de integración y deja que w32time haga su trabajo—especialmente en DCs. Hazlo de forma intencional, con control de cambios, y verifica el comportamiento después de eventos de mantenimiento del host.

Task 15: Detect large time jumps via event logs (symptom hunting)

cr0x@server:~$ wevtutil qe System /q:"*[System[(EventID=1 or EventID=37) and Provider[@Name='Microsoft-Windows-Time-Service']]]" /c:10 /rd:true /f:text
Event[0]:
  Provider Name: Microsoft-Windows-Time-Service
  Event ID: 37
  Level: Warning
  Description: The time provider NtpClient is configured to acquire time from one or more time sources, however none of the sources are currently accessible.

Significado: Esto a menudo se correlaciona con el inicio de la deriva: el cliente no puede alcanzar sus fuentes y empieza a funcionar en modo libre.

Decisión: Si ves esto alrededor del comienzo del incidente, arregla la alcanzabilidad primero. Si coincide con ventanas de mantenimiento del host, sospecha cambios de firewall o ACLs de routing.

Tres microhistorias corporativas desde las trincheras

1) El incidente causado por una suposición equivocada: «NTP es como DNS; apunta a todos al mismo servidor.»

Una gran empresa desplegó una GPO de «endurecimiento del tiempo». La intención era buena: hacer el tiempo consistente, facilitar las auditorías y reducir la deriva. La suposición también era común: «Si todos los endpoints apuntan a un host NTP central, tendremos una sola fuente de verdad.»

Lo aplicaron de forma amplia: clientes, servidores miembros e incluso algunos controladores de dominio. De la noche a la mañana, el helpdesk empezó a ver fallos de autenticación. No todos a la vez. Fue peor en oficinas remotas y vino en oleadas. Los usuarios VPN fueron los más afectados, porque su ruta al servidor NTP elegido era… complicada.

Los fallos de Kerberos parecían problemas de contraseña de usuario. Los equipos de aplicaciones persiguieron certificados caducados. El equipo de logging juró que la canalización de ingestión del SIEM había «perdido eventos» porque las marcas temporales eran inconsistentes. Todos se culparon unos a otros, que es señal de que estás en un incidente real.

El verdadero modo de fallo: los miembros del dominio ya no seguían la jerarquía del dominio. Algunos pudieron alcanzar el servidor NTP central, otros no. Cuando no pudieron, funcionaron en modo libre. Mientras tanto, seguían autenticándose contra DCs con tiempo derivado de una ruta diferente. Reloj con cerebro dividido a escala.

La corrección fue aburrida: revertir clientes y servidores miembros a NT5DS, configurar pares externos solo en el PDC emulator y asegurar que los DCs de sucursal tuvieran conectividad limpia hacia upstream dentro del dominio. El incidente terminó no con un comando heroico, sino con un rollback silencioso y una lección: la jerarquía del dominio no es arquitectura opcional; forma parte del modelo de seguridad.

2) La optimización que salió mal: «Sondear cada 64 segundos, así la deriva no puede pasar.»

Un equipo preocupado por el rendimiento notó que algunos servidores Windows se desviaban por unos cientos de milisegundos en largos periodos. No les gustó. Alguien encontró entradas de registro relacionadas con el intervalo de sondeo, las interpretó como «más rápido es mejor» y aplicó un sondeo agresivo a una flota de servidores de aplicación vía gestión de configuración.

Al principio, los dashboards mejoraron: actualizaciones más frecuentes, offsets a corto plazo más pequeños. Luego los servidores de tiempo upstream empezaron a comportarse como «no fiables». Los clientes comenzaron a registrar advertencias sobre fuentes inaccesibles o que no proporcionaban tiempo usable. Algunos dispositivos upstream empezaron a limitar la tasa de respuestas NTP. Los firewalls internos marcaron el patrón de tráfico como sospechoso porque parecía ruido UDP de baja calidad.

Ahora el entorno tenía un nuevo problema: durante pequeñas turbulencias de red, los clientes rápidamente decidían que las fuentes estaban mal y pasaban a libre ejecución, o cambiaban de fuente con demasiada frecuencia. En lugar de una deriva lenta y estable, tenían oscilación. Algunos servidores terminaron saltando la hora más agresivamente cuando finalmente se resincornizaron, que es precisamente lo que no quieres en sistemas con muchas transacciones.

La corrección no fue «subir aún más el sondeo». Fue volver a valores razonables, añadir fuentes de tiempo internas más fiables y monitorizar offset en lugar de intentar eliminarlo por completo. La lección: si persigues precisión sin entender bucles de realimentación, puedes construir un reloj técnicamente «más activo» y operativamente peor.

3) La práctica aburrida pero correcta que salvó el día: «Trata al PDC emulator como infraestructura crítica.»

Otra organización tenía una costumbre que nunca recibió aplausos: monitorizaban su cadena de tiempo de dominio igual que DNS. El PDC emulator tenía pares explícitos, fuentes ascendentes redundantes y alertas sobre «tiempo desde la última sincronización» y umbrales de offset. También tenían una regla: los DCs no usan stepping de tiempo del hipervisor. Punto.

Durante una ventana de mantenimiento del centro de datos, movieron un clúster de VMs entre hosts. Algunos servidores de aplicación vieron advertencias de salto de tiempo. El equipo de operaciones lo notó de inmediato porque los eventos del servicio de tiempo ya estaban en su radar. El riesgo mayor eran los DCs; si el tiempo de los DCs se volvía loco, todo se vendría abajo.

Comprobaron el PDC emulator primero. Estaba estable y sincronizado. Revisaron un par de DCs no PDC; también estables. Eso significó que la espina dorsal del tiempo del dominio estaba intacta. Luego revisaron unas cuantas VMs de aplicación afectadas y encontraron que la sincronización de tiempo del hipervisor se había vuelto a habilitar por una actualización de plantilla.

La remediación fue quirúrgica: deshabilitar la sincronización de tiempo de integración en servidores Windows unidos al dominio, resincronizar y listo. Sin reconfiguración masiva, sin GPO de pánico, sin «que todos apunten a pool.ntp.org». El mantenimiento terminó con una nota de ticket ordenada, y el incidente que no llegó a ser siguió siendo eso.

Broma #2: Nada vuelve más espiritual a un board de cambios que descubrir que «el tiempo en sí» está fuera de cumplimiento.

Errores comunes: síntoma → causa raíz → solución

1) Síntoma: errores de Kerberos, fallos intermitentes de inicio de sesión, «KRB_AP_ERR_SKEW»

Causa raíz: La hora del cliente difiere de la del DC más allá de la tolerancia, a menudo porque los clientes usan pares NTP manuales mientras los DCs siguen la jerarquía del dominio.

Solución: En clientes/servidores miembros, establece /syncfromflags:domhier y elimina pares manuales; verifica la cadena de tiempo de los DCs y el upstream del PDC.

2) Síntoma: la hora está bien después de reiniciar, pero deriva en horas/días

Causa raíz: w32time no se está sincronizando (UDP/123 bloqueado hacia la fuente elegida, o fuente inalcanzable), así que el reloj funciona en modo libre hasta que la deriva es notable.

Solución: Usa w32tm /query /status y los logs del Time-Service para confirmar la última sincronización; arregla la alcanzabilidad y DNS; luego resync.

3) Síntoma: saltos de tiempo repentinos, especialmente tras migración de VM o revert de snapshot

Causa raíz: El hipervisor/herramientas de invitados sincronizan el tiempo y hacen stepping del reloj mientras w32time también corre.

Solución: Deshabilita la sincronización de tiempo del invitado para servidores Windows unidos al dominio (especialmente DCs), o configúrala para evitar stepping; luego valida con stripcharts y logs de eventos.

4) Síntoma: solo un sitio/sucursal tiene problemas de deriva

Causa raíz: La topología de sitio o reglas de firewall obligan a los clientes a sincronizarse desde DCs remotos; o el DC local no puede alcanzar al PDC/upstream.

Solución: Confirma la selección de DC con nltest; arregla AD Sites/Subnets; asegúrate de que los DCs locales pueden sincronizar upstream; evita NTP directo a Internet desde sucursales.

5) Síntoma: «The time provider NtpClient is configured… none of the sources are accessible»

Causa raíz: Pares manuales definidos pero inalcanzables; a veces causado por un host NTP desmantelado o DNS obsoleto.

Solución: Elimina pares muertos; usa al menos dos fuentes fiables en el PDC; valida la resolución de nombres y el enrutamiento UDP/123.

6) Síntoma: el offset oscila violentamente (sobrecorrección)

Causa raíz: Sondeo/ajustes agresivos o upstream inestable; a veces ambas cosas.

Solución: Vuelve a sondeos sensatos; estabiliza el upstream; mide offset y jitter en lugar de intentar «fijar» la hora perfectamente.

7) Síntoma: los controladores de dominio discrepan en la hora

Causa raíz: Más de un DC configurado como «fuente de tiempo fiable» o múltiples DCs apuntando manualmente a diferentes pares externos.

Solución: Haz del PDC emulator la fuente fiable; configura pares externos solo allí; hace que los demás DCs sigan la jerarquía del dominio.

8) Síntoma: servidor independiente no se mantiene sincronizado incluso con pares manuales

Causa raíz: Inestabilidad del reloj hardware, peculiaridades de gestión de energía o comportamiento de pausa/suspensión de la VM; NTP no puede disciplinar un reloj que sigue siendo steppeado por detrás.

Solución: Deshabilita sincronizaciones en competencia, evita revert de snapshots sin estrategia de corrección de tiempo y monitoriza saltos; considera configuración a nivel de host si es una VM.

Listas de verificación / plan paso a paso

Checklist A: Arreglar la deriva en un solo miembro del dominio sin romper el dominio

1. Ejecuta w32tm /query /status y anota Source, Last Successful Sync Time y Poll Interval.
2. Ejecuta w32tm /query /configuration y confirma si Type es NT5DS (preferido para miembros de dominio).
3. Si Type: NTP en un miembro de dominio, restablécelo:

   cr0x@server:~$ w32tm /config /syncfromflags:domhier /update
   The command completed successfully.
   

4. Reinicia el servicio de tiempo y redescubre:

   cr0x@server:~$ net stop w32time
   The Windows Time service was stopped successfully.
   cr0x@server:~$ net start w32time
   The Windows Time service was started successfully.
   cr0x@server:~$ w32tm /resync /rediscover
   Sending resync command to local computer...
   The command completed successfully.
   

5. Valida el offset frente al DC elegido usando stripchart. Si el offset es de segundos, escala a comprobaciones de la cadena de DC.
6. Comprueba si la sincronización de tiempo de virtualización está habilitada. Si esta máquina está en el dominio y ve saltos tras operaciones del host, deshabilita la sincronización del hipervisor (según tu estándar de plataforma).
7. Vigila los eventos del Time-Service durante la siguiente hora. Buscas advertencias de «fuente inaccesible» y correcciones repetidas.

Checklist B: Arreglar la columna vertebral de tiempo del dominio (el enfoque correcto empresarial)

1. Identifica el PDC emulator:

   cr0x@server:~$ netdom query fsmo
   Schema master               DC01.corp.local
   Domain naming master        DC01.corp.local
   PDC                         DC02.corp.local
   RID pool manager            DC01.corp.local
   Infrastructure master       DC01.corp.local
   The command completed successfully.
   

2. En el PDC emulator, comprueba la fuente actual y los peers con w32tm /query /status y /query /peers.
3. Configura al menos dos pares manuales en el PDC y márcalo como fiable:

   cr0x@server:~$ w32tm /config /manualpeerlist:"time1.company.local,0x8 time2.company.local,0x8" /syncfromflags:manual /reliable:yes /update
   The command completed successfully.
   

4. Reinicia w32time y resync/rediscover en el PDC.
5. En otros DCs, asegúrate de que no están marcados como fiables y usan la jerarquía del dominio.
6. En clientes/servidores miembros, elimina cualquier GPO que fuerce pares manuales (a menos que la máquina sea intencionalmente independiente).
7. Verifica en cada sitio que los clientes seleccionan DCs locales (nltest) y que esos DCs pueden sincronizar upstream.
8. Monitoriza: alerta por «tiempo desde la última sincronización exitosa», además de umbrales de offset en el PDC y DCs representativos por sitio.

Checklist C: Reglas de sentido común para virtualización (para evitar stepping de tiempo)

1. Para controladores de dominio: deshabilita el stepping de tiempo del hipervisor. Los DCs deben ser disciplinados por la cadena de tiempo del dominio, no por un host que puede estar fuera por segundos durante mantenimiento.
2. Para servidores miembros del dominio: considera seriamente deshabilitar la sincronización de tiempo del hipervisor a menos que tengas una razón documentada para mantenerla.
3. Para appliances independientes y VMs aisladas: la sincronización del hipervisor puede ser aceptable, pero elige un método y mantenlo.
4. Después de cualquier cambio de plantilla, verifica que el ajuste no haya revertido (esta es una fuente común de regresión).

FAQ

1) ¿Por qué la hora de Windows se desvía incluso cuando NTP está configurado?

Porque «configurado» no es «efectivo». La máquina puede no llegar a su fuente, puede usar la fuente equivocada o una herramienta/hipervisor puede estar saltando la hora a espaldas de w32time.

2) ¿Debería cada máquina Windows apuntar al mismo servidor NTP?

No, no en un dominio. Los miembros del dominio deben seguir la jerarquía del dominio. Configura pares externos en el PDC emulator (y solo allí, como postura por defecto).

3) ¿Cuál es la única cosa que la gente olvida y que causa más dolor?

Las fuentes de tiempo en competencia. Una función de sincronización del guest que hace stepping junto con w32time intentando disciplinarla es receta para caos de deriva y saltos.

4) ¿Puedo simplemente deshabilitar w32time y confiar en el hipervisor?

Para sistemas Windows unidos al dominio, eso suele ser mala idea. Quieres que el servicio de tiempo del SO esté alineado con el modelo de seguridad del dominio. La sincronización del hipervisor puede ser un suplemento en algunos casos, pero no reemplaces el servicio de tiempo a la ligera.

5) ¿Cómo sé si el PDC emulator es el problema?

Si muchas máquinas en distintos sitios derivan en la misma dirección, o los DCs discrepan, revisa el w32tm /query /status del PDC y sus logs de eventos. Si el PDC no se sincroniza de forma fiable, todo el dominio hereda esa incertidumbre.

6) ¿Qué offset es «demasiado»?

Para operaciones empresariales generales, decenas de milisegundos están bien. Una vez en segundos, te arriesgas a problemas de autenticación y validación de certificados. Para trading/telemetría/control industrial, los requisitos pueden ser mucho más estrictos.

7) ¿Por qué los problemas de tiempo aparecen como errores de certificados?

Los certificados TLS tienen ventanas de validez. Si tu reloj está mal, un certificado perfectamente válido puede parecer caducado o no aún válido. Entonces la gente culpa a PKI, y el reloj sigue riéndose en silencio.

8) ¿Necesito acceso NTP a Internet desde cada servidor?

Usualmente no. Es más limpio tener un pequeño número de fuentes de tiempo internas con acceso ascendiente controlado, y luego distribuir el tiempo vía la jerarquía del dominio.

9) Si ejecuto w32tm /resync y tiene éxito, ¿ya estoy hecho?

No necesariamente. Una sincronización puntual no prueba estabilidad. Revisa Last Successful Sync Time durante horas, busca eventos de «fuente inaccesible» y vigila saltos después de eventos de ciclo de vida de VM.

10) ¿Los segundos intercalares siguen importando?

Sí, porque diferentes plataformas y fuentes upstream los manejan distinto. Tu objetivo es consistencia en todo el entorno. Si haces smear, hazlo de forma consistente; si haces step, hazlo de forma consistente. El comportamiento mixto es donde nace lo raro.

Próximos pasos que deberías hacer esta semana

• Audita tu jerarquía. Identifica el PDC emulator y confirma que tiene pares ascendentes estables y redundantes. Todos los demás deben seguir mayoritariamente la jerarquía del dominio.
• Busca sincronizaciones en competencia. En tu plataforma de virtualización, verifica que las plantillas o «defaults útiles» no hayan habilitado el stepping de tiempo. Pon especial atención en los controladores de dominio.
• Elimina ajustes de GPO blanket que pongan pares en miembros del dominio. Si debes usar GPO, aplícalo con precisión: configuración para el PDC, no una lista de pares one-size-fits-all.
• Instrumenta las señales aburridas. Genera alertas por «tiempo desde la última sincronización exitosa» y por umbrales de offset significativos para el PDC y unos cuantos DCs representativos por sitio.
• Practica el drill de resync. Asegúrate de que tu personal on-call pueda ejecutar los comandos clave, interpretarlos y saber cuándo escalar a redes o al equipo de virtualización.

Si haces esas cinco cosas, la mayoría de los tickets de «deriva de tiempo en Windows» desaparecen. No porque el tiempo deje de ser difícil, sino porque dejas de permitir que tres sistemas distintos discutan sobre qué hora es.