As regulamentações em muitos setores exigem que os sistemas sejam rastreáveis para o UTC. Isso significa que a diferença de um sistema pode ser atestada com respeito ao UTC. Para habilitar cenários de conformidade regulatória, o Windows 10 (versão 1703 ou posterior) e o Windows Server 2016 (versão 1709 ou posterior) fornecem novos logs de eventos para oferecer uma visão da perspectiva do Sistema Operacional a fim de criar uma compreensão das ações executadas no relógio do sistema. Esses logs de evento são gerados continuamente para o Serviço de Horário do Windows e podem ser examinados ou arquivados para análise posterior.
Esses novos eventos permitem que as seguintes perguntas sejam respondidas:
- O relógio do sistema foi alterado
- A frequência do relógio foi modificada
- A configuração do Serviço de Horário do Windows foi modificada
Availability
Esses aprimoramentos estão incluídos no Windows 10 versão 1703 ou posterior e no Windows Server 2016 versão 1709 ou posterior.
Configuration
Nenhuma configuração é necessária para usar este recurso. Esses logs de eventos são habilitados por padrão e podem ser encontrados no visualizador de eventos no canal Applications and Services Log\Microsoft\Windows\Time-Service\Operational.
Lista de logs de eventos
A seção a seguir descreve os eventos registrados para uso em cenários de rastreabilidade.
Esse evento é registrado em log quando o Serviço de Horário do Windows (W32Time) inicia e registra informações em log sobre a hora atual, a contagem atual de tiques, a configuração do runtime, os provedores de horário e a taxa atual do relógio.
| Descrição do evento |
Início do Serviço |
| Details |
Ocorre na inicialização do W32time |
| Dados registrados |
- Hora atual em UTC
- Contagem atual de tiques
- Configuração do W32Time
- Configuração do Provedor de Tempo
- Taxa de Relógio
|
| Mecanismo de limitação |
None. Esse evento é disparado sempre que o serviço é iniciado. |
Example:
W32time service has started at 2018-02-27T04:25:17.156Z (UTC), System Tick Count 3132937.
Command:
Essas informações também podem ser consultadas usando os comandos a seguir
Configuração do W32Time e do Provedor de Tempo
w32tm.exe /query /configuration
Taxa de Relógio
w32tm.exe /query /status /verbose
Esse evento é registrado em log quando o Serviço de Horário do Windows (W32Time) está parando e registra em logs as informações sobre a contagem atual de tempo e de tiques.
| Descrição do evento |
Parada de Serviço |
| Details |
Ocorre no desligamento do W32time |
| Dados registrados |
- Hora atual em UTC
- Contagem atual de tiques
|
| Mecanismo de limitação |
None. Esse evento é disparado sempre que o serviço é interrompido. |
Texto de exemplo:W32time service is stopping at 2018-03-01T05:42:13.944Z (UTC), System Tick Count 6370250.
Esse evento registra periodicamente em log a lista atual de fontes de horário e a fonte de horário escolhida dele. Ele também registra a contagem de tiques atual. Esse evento não é disparado sempre que uma fonte de horário é alterada. Outros eventos listados mais adiante neste documento oferecem essa funcionalidade.
| Descrição do evento |
Status periódico do provedor de cliente NTP |
| Details |
Lista de fontes de horário usadas pelo cliente NTP |
| Dados registrados |
- Fontes de tempo disponíveis
- O servidor de tempo de referência escolhido no momento do registro em log
- Contagem atual de tiques
|
| Mecanismo de limitação |
Registrado a cada 8 horas. |
Texto de exemplo: Status periódico do provedor de cliente NTP:
O cliente NTP está recebendo dados de tempo dos seguintes servidores NTP:
server1.fabrikam.com,0x8 (ntp.m|0x8|[::]:123->[IPAddress]:123)server2.fabrikam.com,0x8 (ntp.m|0x8|[::]:123->[IPAddress]:123); e o servidor de horário de referência escolhido é o Server1.fabrikam.com,0x8 (ntp.m|0x8|[::]:123->[IPAddress]:123) (RefID:0x08d6648e63). Contagem de tiques do sistema 13187937
Comando Essas informações também podem ser consultadas usando os comandos a seguir
Identificar paresw32tm.exe /query /peers
| Descrição do evento |
Configuração e status do serviço de horário |
| Details |
O W32time registra em log periodicamente a configuração e o status dele. Esse é o equivalente de chamar:
w32tm /query /configuration /verbose
OR
w32tm /query /status /verbose |
| Mecanismo de limitação |
Registrado a cada 8 horas. |
Esse evento registra cada instância quando o Hora do Sistema é modificada usando a API SetSystemTime.
| Descrição do evento |
A Hora do Sistema foi definida |
| Mecanismo de limitação |
None. Esse evento deve acontecer raramente em sistemas com sincronização de tempo razoável e quando queremos registrar em log sempre que ocorrer. Ignoramos a configuração TimeJumpAuditOffset ao registrar esse evento em log porque essa configuração era destinada a limitar eventos no log de eventos do sistema do Windows. |
| Descrição do evento |
Frequência do relógio do sistema ajustada |
| Details |
A frequência do relógio do sistema é modificada constantemente pelo W32time quando o relógio está em uma sincronização próxima. Queremos capturar ajustes "razoavelmente significativos" feitos na frequência do relógio sem executar o log de eventos excessivamente. |
| Mecanismo de limitação |
Todos os ajustes de relógio abaixo de TimeAdjustmentAuditThreshold (mín. = 128 partes por milhão, padrão = 800 partes por milhão) não são registrados em log. A alteração de 2 PPM na frequência do relógio com granularidade atual gera uma alteração de 120 µsec/s na precisão do relógio. Em um sistema sincronizado, a maior parte dos ajustes fica abaixo desse nível. Se você quiser um acompanhamento mais preciso, essa configuração poderá ser ajustada, você poderá usar PerfCounters ou poderá fazer ambos. |
| Descrição do evento |
Alteração nas configurações do Serviço de Horário ou em uma lista de provedores de horário carregados. |
| Details |
A releitura das configurações do W32time pode fazer determinadas configurações críticas serem modificadas na memória, o que pode afetar a precisão geral da sincronização de tempo.
O W32time registra cada ocorrência em log ao reler as configurações, o que oferece o impacto potencial na sincronização de tempo. |
| Mecanismo de limitação |
None.
Esse evento ocorre somente quando uma atualização de administrador ou GP altera os provedores de horário e dispara o W32time. Queremos registrar cada instância de alteração de configurações. |
| Descrição do evento |
Alteração nas fontes de horário usadas pelo cliente NTP |
| Details |
O cliente NTP registra um evento com o estado atual dos servidores de tempo/pares quando o estado de um servidor de tempo/par é alterado (Pendente ->Sincronização, Sincronizar -> inacessível ou outras transições) |
| Mecanismo de limitação |
Frequência máxima – apenas uma vez a cada 5 minutos para proteger o log contra problemas transitórios e uma implementação de provedor inadequada. |
| Descrição do evento |
Alterações no número de estratos ou na fonte do Serviço de Horário |
| Details |
A fonte de horário e o número de estratos do W32time são fatores importantes na rastreabilidade de tempo. As alterações nelas devem ser registradas em log. Se o W32time não tiver nenhuma fonte de horário e você não tiver configurado como uma fonte de horário confiável, ele interromperá a publicidade como um servidor de horário e responderá a solicitações com alguns parâmetros inválidos, por padrão. Esse evento é essencial para acompanhar as alterações de estado em uma topologia de NTP. |
| Mecanismo de limitação |
None. |
| Descrição do evento |
Uma nova sincronização de tempo é solicitada |
| Details |
Essa operação é disparada:- Quando ocorrem alterações na rede
- O sistema retorna do modo de espera/hibernação conectado
- Quando não sincronizamos há muito tempo
- O administrador emite o comando resync
Essa operação resulta em perda imediata de precisão de sincronização de tempo refinada porque faz o cliente NTP apagar seus filtros. |
| Mecanismo de limitação |
Frequência máxima – uma vez a cada cinco minutos.
É possível que uma placa de rede incorreta (ou um script inadequado) possa disparar essa operação repetidamente e causar a sobrecarga dos logs. Daí a necessidade de restringir esse evento.
A sincronização de horário preciso leva muito mais do que 5 minutos para ser atingida e a limitação não perde informações sobre o evento original que resultou em perda de precisão de horário. |