Eu tenho um controlador de domínio configurado para usar time.windows.com (com sinalizadores 0x09 definidos). Percebi que frequentemente o relógio dos sistemas é rápido - varia de 10 minutos a 45 minutos. Eu sempre tenho que redefinir a data/hora do sistema para o que deveria ser.
Quando executo "w32tm/query/source", ele me diz que está usando time.windows.com e, obviamente, confio que a Microsoft não fornecerá horários incorretos, mas por que o relógio do meu servidor está rápido?
EDITAR:
Existem alguns eventos de serviço de tempo no log do sistema:
ID do evento: 142
Mensagem: O serviço de horário parou de anunciar como fonte de horário porque o relógio local não está sincronizado.
ID do evento: 139
Mensagem: O serviço de horário começou a anunciar como fonte de horário.
Essas duas mensagens aparecem em pares a cada hora ou mais. O evento 142 aparece 14 a 16 minutos após o aparecimento do 139.
Voltando alguns meses, estes eventos aparecem:
ID do evento: 35
Mensagem: O serviço de horário agora está sincronizando a hora do sistema com a fonte de horário time.windows.com,0x9 (ntp.m|0x9|0.0.0.0:123->65.55.21.21:123).
ID do evento: 37
Mensagem: O provedor de horário NtpClient está recebendo dados de horário válidos de time.windows.com,0x9 (ntp.m|0x9|0.0.0.0:123->65.55.21.21:123).
ID do evento: 47
Mensagem: Provedor de tempo NtpClient: Nenhuma resposta válida foi recebida do peer configurado manualmente time.windows.com,0x9 após 8 tentativas de contatá-lo. Este peer será descartado como fonte de tempo e o NtpClient tentará descobrir um novo peer com este nome DNS. O erro foi: A amostra de horário foi rejeitada porque: O peer não está sincronizado ou já se passou muito tempo desde a última sincronização do peer.
Esses três eventos aparecem apenas uma vez no log, em outubro.
EDITAR:
Aqui está a saída 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
Responder1
Eu tive o mesmo problema e finalmente o resolvi esta manhã. Aqui está o que eu fiz:
Dê uma olhada no registro (todas as seções e chaves em HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\W32Time) no servidor com o problema de horário e em outro servidor membro que está sincronizando o NTP corretamente.
Encontrei algumas discrepâncias e exportei as chaves \ hives necessárias do servidor em funcionamento para o servidor quebrado. As seguintes chaves foram bagunçadas, aqui estão as chaves boas que exportei da caixa de trabalho para a quebrada. Observe que esses valores podem não ser iguais aos seus, portanto, não use as chaves abaixo:
O Hive de segurança estava faltando, então recriei com isto:
[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
E notei que o hive NtpServer tinha chaves faltando, isso foi corrigido 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
Em seguida, alterei as seguintes chaves existentes para reduzir a fase:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\W32Time\Config]
"MaxAllowedPhaseOffset"=dword:00000001
"SpecialPollInterval"=dword:00000005
"SpecialInterval"=dword:00000001
Quando tiver certeza de que o registro está correto, emita os seguintes comandos via linha de comando 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
Esperei alguns minutos e verifiquei a sincronização
w32tm /monitor /computers:YOURNTPSERVER-OR-DCHERE.YOURDOMAIN.COM
Deve ser um pouco assim:
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
Então verifique a fase:
w32tm /stripchart /computer:YOURNTPSERVER-OR-DCHERE.YOURDOMAIN.COM
Deveria ficar assim:
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 isto ajude!
Responder2
Este é o DC que mantém a função de emulador de PDC? Você só precisaria configurar aquele com a função de emulador de PDC com uma fonte de tempo externa - outros DCs serão sincronizados automaticamente com o PDC.
O status atual do serviço de horário pode ser obtido via w32tm /query /status /verbose- deve fornecer alguns detalhes sobre o status do seu relógio local, o desvio na última sincronização e a precisão. De acordo com os eventos registrados, o relógio local parece não ser confiável para a fonte de horário. O intervalo de sincronização w32time padrão seria de 1.024 segundos após algumas sincronizações bem-sucedidas - cerca de 17 minutos, que é aproximadamente a diferença de horário entre os eventos 139 e 142.
Se este for um sistema virtualizado, você deve procurar emulações alternativas de hardware de temporizador. VMWare publicou umartigo abrangente sobre este tópicoque vale a pena ler mesmo quando você usa diferentes produtos de virtualização.
Se este for um sistema físico, considere reduzir o MaxPollInterval para o serviço w32time como solução alternativa ou mover a função do emulador PDC para uma máquina diferente com um relógio mais confiável.
Editar: o problema dos "dados de tempo obsoletos" pode realmente ser um problema com o servidor de horário que você está tentando consultar. Tente substituir o "time.windows.com" padrão por um servidor do pool NTP público (<region>.pool.ntp.org) na sua configuração NTP (basta usar net time /setsntp:<servername>)