Windows Server 2022: la hora cambia de PM a AM tras reiniciar (solución paso a paso)

Tras migrar de Windows Server 2008 a 2022, algunos servidores “se van” 12 horas atrás o adelante (de PM a AM) cada vez que reinician. En esta guía encontrará causas probables, pasos de diagnóstico y una ruta de corrección definitiva para entornos con y sin dominio, físicos y virtualizados.

Índice

Resumen rápido del caso

Síntoma: después de actualizar a Windows Server 2022, la hora cambia exactamente 12 horas (AM ⇄ PM) tras cada reinicio. El administrador afirma haber hecho “todas las comprobaciones”.

Lectura recomendada: aunque el salto se vea como “solo” un cambio AM/PM, no es un problema de formato. Es un cambio real del reloj del sistema (offset de 12 horas), normalmente provocado por zona horaria/DST incorrectos, una sincronización NTP mal definida, interferencias de virtualización o un RTC/BIOS inconsistente.

Síntomas y cómo confirmarlos

Salto exactamente de 12 h tras un reinicio o al cabo de unos minutos después del arranque.
Eventos en “Visor de eventos → Registros de Windows → Sistema” con origen W32Time o Kernel-General indicando que la hora del sistema fue cambiada.
Origen de tiempo inesperado (origen: host de virtualización, reloj local, NTP externo no deseado, etc.).
El problema desaparece si se corrige manualmente la hora, pero vuelve tras reiniciar.

Comprobaciones rápidas

tzutil /g
w32tm /query /status
w32tm /query /source
w32tm /query /peers
sc query w32time

Si el source no es el esperado (por ejemplo, “Local CMOS Clock”, “VM IC Time Synchronization Provider”, o un NTP externo no autorizado), está el origen del problema.

Causas probables (ordenadas por frecuencia)

Zona horaria/DST mal configurada o forzada por GPO. Un huso equivocado (p. ej., UTC+12 en vez de UTC) explica un salto exacto de 12 h.
Windows Time (w32time) mal configurado o sin una fuente NTP estable. En un dominio, el tipo correcto suele ser NT5DS (jerarquía AD), no NTP manual.
Sincronización de dominio defectuosa (PDC Emulator mal configurado). Si el PDC falla, los miembros del dominio heredarán una hora mala.
Interferencia de virtualización o software de terceros que reescribe la hora al arrancar (Hyper‑V/VMware, agentes cloud, utilidades NTP de terceros).
RTC/BIOS/UEFI desactualizado o con hora incorrecta. Si el reloj de hardware (RTC) está a +12 h/−12 h, Windows puede “heredar” ese error al inicio.
GPO que sobrescribe la configuración local (Time Providers).
Clave de registro “RealTimeIsUniversal” habilitada indebidamente. Mezclar RTC en UTC con servicios de sincronización puede generar offsets grandes.

Plan de corrección recomendado (paso a paso)

1) Verificar zona horaria y DST

Asegure la zona horaria correcta y, si aplica, “Ajustar automáticamente al horario de verano”.

tzutil /g
tzutil /s "Nombre de la zona horaria"

Ejemplos frecuentes: "Pacific SA Standard Time", "SA Pacific Standard Time", "UTC", "GMT Standard Time", etc. Compruebe también que ninguna GPO fuerce otro huso.

2) Comprobar el servicio de tiempo (w32time)

El servicio debe estar en Automático y En ejecución.

sc qc w32time
sc query w32time

w32tm /query /status
w32tm /query /source
w32tm /query /peers

Observe Stratum, Phase Offset, Last Successful Sync Time y si el Source coincide con su diseño (dominio o NTP autorizados).

3) Fijar una fuente de tiempo estable

Si el servidor pertenece a un dominio (y no es PDC Emulator):

w32tm /config /syncfromflags:domhier /update
net stop w32time &amp; net start w32time
w32tm /resync /rediscover

Si es el PDC Emulator (o un servidor independiente): configure NTP externos confiables.

w32tm /config /manualpeerlist:"time.windows.com,0x9 time.cloudflare.com,0x9 time.nist.gov,0x9" ^
  /syncfromflags:manual /reliable:yes /update
net stop w32time &amp; net start w32time
w32tm /resync

Nota clave: en un dominio, solo el PDC del bosque debe marcarse como /reliable:yes y hablar con NTP externo. Los demás heredan del dominio (NT5DS).

4) Revisar GPO que puedan forzar hora/fuentes

Revise en la GPMC:

Computer Configuration → Policies → Administrative Templates → System → Windows Time Service → Time Providers

Directivas típicas:

Enable Windows NTP Client (Habilitado).
Configure Windows NTP Client (defina NtpServer, Type, SpecialPollInterval, etc.).
Enable Windows NTP Server en el PDC si quiere que actúe como servidor para su dominio.

Tras cambios:

gpupdate /force
w32tm /resync /rediscover

5) Auditar el Visor de eventos

Busque en Sistema los orígenes W32Time y Kernel-General. Filtre por mensajes del tipo “La hora del sistema se cambió” y registre la causa (origen NTP, proveedor de virtualización, RTC…).

6) Firmware/BIOS y hardware

Actualice BIOS/UEFI y drivers de chipset.
Antes de arrancar Windows, entre a BIOS y verifique que el RTC esté correcto.
Si hay baterías CMOS agotadas, sustitúyalas.

7) Virtualización o software de terceros

Evite que el host reescriba la hora si el invitado ya se sincroniza con AD/NTP:

Hyper‑V: en la configuración de la VM, desmarque “Time synchronization” (sincronización de hora) o coordine cuidadosamente su uso. En controladores de dominio invitados, suele recomendarse desactivar la sync host→guest y dejar a w32time gestionar el tiempo.
VMware: desactive la opción de sincronizar con el host (VMware Tools) o el parámetro equivalente. Evite habilitarla junto con w32time.
Agentes cloud / utilidades NTP de terceros: si usa un demonio NTP distinto (p. ej., Meinberg), deshabilite w32time para impedir conflictos, o viceversa.

8) Aislar interferencias

Pruebe un Arranque en Modo seguro con funciones de red. Si el salto desaparece, la causa está en un servicio/controlador añadido. Revise software de gestión, agentes, herramientas de sincronización de terceros y servicios de integración del hipervisor.

Comandos de recuperación (si la configuración está corrupta)

net stop w32time
w32tm /unregister
w32tm /register
net start w32time

Después, reconfigure según su rol (dominio/independiente) y ejecute w32tm /resync. Si usa dominio, aplique /syncfromflags:domhier; si es PDC o stand‑alone, defina pares NTP externos confiables como se indicó.

Validación y criterio de éxito

Tras reiniciar, w32tm /query /status muestra un origen esperado (dominio o NTP).
El phase offset es razonable (estable y pequeño, no cientos de segundos).
La hora permanece correcta después de varios reinicios; no hay saltos de 12 h ni eventos de cambios bruscos de tiempo.

Guía de configuración recomendada (tabla de referencia)

Rol del servidor	Parámetro Type	NtpServer	AnnounceFlags	Notas
Miembro de dominio (no DC)	`NT5DS`	N/A (hereda)	`10` (por defecto)	Hereda del DC según jerarquía AD.
Controlador de dominio (no PDC)	`NT5DS`	N/A (hereda)	`10` (por defecto)	Sin NTP externo directo.
PDC Emulator (raíz de bosque)	`NTP`	Lista de NTP externos confiables	`5`	Único que marca `/reliable:yes`.
Servidor independiente	`NTP`	Lista de NTP externos confiables	`10`	Sincroniza directamente con NTP público/privado.

Buenas prácticas y puntos finos

No confunda formato con hora real: cambiar 12/24h solo altera la visualización, no el reloj. Si ve un salto exacto de 12 h, hay un ajuste de hora real.
Evite doble sincronización: no combine w32time+VMware/Hyper‑V Tools+otro NTP. Elija uno como autoridad.
Clave RealTimeIsUniversal: no la habilite salvo escenarios muy controlados (mixtos Windows/Linux/UTC en RTC). En entornos comunes de Windows Server suele ser innecesaria y causa sorpresas.
Coherencia entre host e invitado: si decide que el host dicte la hora a la VM, desactive w32time como cliente en el invitado (o viceversa). En dominios AD, deje que w32time gobierne.
Registre los cambios: anote qué política GPO toca el tiempo y documente el rol del PDC. Evite “ajustes manuales” ad‑hoc en múltiples servidores.

Diagnóstico ampliado (cuando el problema persiste)

1) Revisar parámetros críticos en registro

reg query HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Parameters
reg query HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Config

Parámetros clave:

Type: NT5DS (dominio) o NTP (manual).
NtpServer: lista de pares con flags (p. ej., 0x9 para SpecialPoll, Client).
AnnounceFlags: 5 en PDC fiable; por defecto 10 en otros.
SpecialPollInterval: intervalo de sondeo (seg.).

2) Habilitar logging de w32time temporalmente

w32tm /debug /enable /file:C:\Temp\w32time.log /size:5242880 /entries:0-300
:: Reproducir el reinicio / salto
w32tm /debug /disable

Analice el archivo para ver qué proveedor (NTP, VM, RTC) causa el ajuste de 12 h.

3) Confirmar si la VM recibe la hora del host

En Hyper‑V, busque el servicio de integración de tiempo; en VMware, revise la política de sincronización de VMware Tools. Si un proveedor de virtualización aparece como source, desactívelo mientras pruebe con w32time.

4) Verificar hora en BIOS/RTC y coherencia UTC/local

Si el RTC estuviera 12 h desplazado (p. ej., UTC en RTC pero Windows asume local), el sistema puede moverse 12 h al arrancar. Asegure una sola estrategia y manténgala en todos los hosts/VMs.

Playbook de corrección (paso a paso, listo para aplicar)

Elija el rol del servidor (miembro de dominio, DC, PDC, independiente).
Compruebe zona horaria con tzutil y ajuste correctamente.
Examine w32time y su source; corrija el Type (NT5DS/NTP) y el NtpServer según la tabla.
En un dominio, configure NTP externo solo en el PDC y marque /reliable:yes.
Revise/ajuste GPO de Time Providers. Aplique gpupdate /force.
Deshabilite sincronización de virtualización si compite con w32time.
Verifique RTC/BIOS. Actualice firmware si procede.
Reinicie y valide con w32tm /query /status. Repetir en todos los servidores afectados.

Comandos útiles (PowerShell y CMD)

PowerShell (consulta y ajuste rápidos)

# Estado del servicio de tiempo
Get-Service w32time | Format-List *

Miembro de dominio o workgroup

(Get-WmiObject Win32\_ComputerSystem).PartOfDomain

Zona horaria

Get-TimeZone
Set-TimeZone -Name "Nombre de la zona"

Re-sincronizar

w32tm /resync /rediscover

CMD (config estándar)

:: Miembro de dominio (no PDC)
w32tm /config /syncfromflags:domhier /update
net stop w32time & net start w32time
w32tm /resync /rediscover

\:: PDC/independiente con NTP externo
w32tm /config /manualpeerlist:"time.windows.com,0x9 time.cloudflare.com,0x9 time.nist.gov,0x9" ^
/syncfromflags\:manual /reliable\:yes /update
net stop w32time & net start w32time
w32tm /resync

Checklist final (use antes de dar por resuelto)

Zona horaria correcta y DST conforme a la región.
w32time en Automático/en ejecución.
Rol definido y Type coherente (NT5DS en miembros/DC; NTP en PDC/stand‑alone).
NTP externo solo en PDC (y /reliable:yes).
GPO revisadas: ningún valor inesperado sobrescribe la configuración.
Sincronización de virtualización deshabilitada o alineada (no compite con w32time).
RTC/BIOS correctos y actualizados.
Sin eventos de cambios bruscos tras varios reinicios; source esperado y phase offset estable.

Preguntas frecuentes (FAQ)

¿Por qué es un salto de 12 horas exactas?
Porque hay una incoherencia de huso (p. ej., UTC vs UTC+12, o Samoa/Islas de la Línea) o un proveedor de tiempo está imponiendo un desplazamiento de medio día. El formato 12h/24h no cambia la hora real: solo cómo se muestra.

¿Puedo dejar activada la sincronización de Hyper‑V o VMware y w32time a la vez?
Técnicamente sí, pero es una mala práctica. Dos “dueños” del reloj compiten y causan saltos. Elija uno.

Uso un NTP de terceros (Meinberg).
Perfecto, pero entonces deshabilite w32time para evitar conflictos, o configure que uno sea el único proveedor efectivo.

¿Qué valores de GPO son seguros?
En dominio, habilite el cliente NTP y, en la GPO aplicada solo al PDC, configure Configure Windows NTP Client con sus pares externos. No fuerce NTP manual en los miembros: deben heredar (Type=NT5DS).

¿Puede afectar al cluster, SQL, AD?
Sí. La deriva de tiempo impacta Kerberos, certificados, clusters y replicación. Por eso es crítico normalizar la configuración del tiempo antes de poner en producción.

Plantillas de comandos de referencia

Miembro de dominio (no DC)

w32tm /config /syncfromflags:domhier /update
w32tm /config /reliable:no
net stop w32time &amp; net start w32time
w32tm /resync /rediscover

PDC Emulator

w32tm /config /manualpeerlist:"ntp1.suempresa.com,0x9 ntp2.suempresa.com,0x9" ^
  /syncfromflags:manual /reliable:yes /update
reg add HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Config /v AnnounceFlags /t REG_DWORD /d 5 /f
net stop w32time &amp; net start w32time
w32tm /resync

Servidor independiente

w32tm /config /manualpeerlist:"time.cloudflare.com,0x9 time.nist.gov,0x9" ^
  /syncfromflags:manual /reliable:no /update
net stop w32time &amp; net start w32time
w32tm /resync

Conclusión

Un cambio de 12 horas en Windows Server 2022 después de reiniciar es, casi siempre, el resultado de configuración incoherente del tiempo (zona horaria, jerarquía NTP/AD) o de interferencias de virtualización. Siguiendo el plan anterior —normalizar huso/DST, definir un único proveedor de tiempo, configurar PDC/miembros correctamente y eliminar sincronizaciones redundantes— el reloj permanecerá estable tras cada reinicio.

Anexo: Guía paso a paso rápida (para “apagar incendios”)

Corrija la zona horaria: tzutil /s "SA Pacific Standard Time"
Repare w32time: net stop w32time w32tm /unregister w32tm /register net start w32time
Configure según rol (uno de los tres bloques siguientes):
- Miembro/No DC: w32tm /config /syncfromflags:domhier /update w32tm /resync /rediscover
- PDC: w32tm /config /manualpeerlist:"time.windows.com,0x9 time.cloudflare.com,0x9" ^ /syncfromflags:manual /reliable:yes /update w32tm /resync
- Independiente: w32tm /config /manualpeerlist:"time.nist.gov,0x9" ^ /syncfromflags:manual /reliable:no /update w32tm /resync
Desactive sync de virtualización (si compite).
Compruebe: w32tm /query /status w32tm /query /source
Reinicie y confirme que no hay salto de 12 h ni eventos de cambio brusco.

Apéndice: comandos de verificación adicionales

:: Mostrar todas las zonas horarias disponibles
tzutil /l

\:: Ver estado detallado de sincronización
w32tm /query /configuration
w32tm /query /verbose

\:: Forzar detección de controladores de dominio (en dominio)
w32tm /resync /rediscover

\:: Comprobar historial de eventos de tiempo (PowerShell)
Get-WinEvent -LogName System | Where-Object {$\_.ProviderName -in @("W32Time","Kernel-General")} |
Select-Object TimeCreated, Id, ProviderName, Message -First 50

Criterio de éxito final: Después de reinicios repetidos, w32tm /query /status reporta el origen previsto (dominio o NTP), el phase offset es estable/pequeño y la hora permanece correcta sin saltos de 12 horas.