Miglioramenti dell'accuratezza dell'ora per Windows Server 2016

Windows Server 2016 ha migliorato gli algoritmi che utilizza per correggere il tempo e per regolare l'orologio locale per sincronizzarsi con il Tempo Coordinato Universale (UTC). NTP (Network Time Protocol) utilizza quattro valori per calcolare l'offset dell'ora, in base ai timestamp del client richiesta/risposta e richiesta/risposta del server. Tuttavia, le reti sono rumorose e possono essere presenti picchi di dati dal NTP a causa della congestione della rete e altri fattori che influiscono sulla latenza di rete. Gli algoritmi di Windows Server 2016 calcolano la media di questo rumore utilizzando diverse tecniche che si traduce in un orologio stabile e accurato. L'origine che utilizziamo per l'accuratezza nel tempo fa riferimento anche a un'API migliorata che offre una migliore risoluzione. Grazie a questi miglioramenti, è possibile ottenere una precisione di 1 ms per quanto riguarda l'UTC in un dominio.

Hyper-V

Windows Server 2016 ha migliorato il servizio TimeSync Hyper-V. I miglioramenti includono un'ora iniziale più accurata sulla macchina virtuale (VM) per l'avvio o il ripristino della VM e la correzione della latenza di interrupt per gli esempi usati dal servizio Ora di Windows (W32time). Questo miglioramento consente di rimanere entro 10µs dall'host con una radice della media quadratica (che indica la varianza) pari a 50µs, anche in un computer con il 75% del carico. Per altre informazioni, vedi Architettura Hyper-V.

Nota

Il carico è stato creato utilizzando il benchmark prime95 mediante un profilo bilanciato.

Il livello Stratum che il sistema host riporta al sistema guest è più trasparente. In precedenza, l'host avrebbe presentato uno strato predefinito pari a 2, indipendentemente dalla relativa accuratezza. Con le modifiche apportate in Windows Server 2016, l'host segnala un Stratum 1 superiore rispetto a quello dell'host, migliorando così la sincronizzazione dell'ora per i guest virtuali. Lo Strato dell'host è determinato da W32Time attraverso metodi standard in base al relativo tempo di origine. I guest Windows Server 2016 appartenenti a un dominio trovano l'orologio più accurato anziché usare quello predefinito dell'host. Per questo motivo, è consigliabile disattivare manualmente il Provider di Tempo Hyper-V per computer che partecipano a un dominio in Windows Server 2012 R2 e versioni precedenti.

Monitoraggio

Sono stati aggiunti i contatori di Performance Monitor. Questi contatori consentono di stabilire una base di riferimento, monitorare e risolvere i problemi di accuratezza del tempo. Nella tabella seguente sono elencati i contatori.

Contatore	Descrizione
Offset ora calcolata	L'offset assoluto del tempo tra l'orologio di sistema e la fonte temporale scelta, come calcolato dal servizio W32Time, in microsecondi. Quando è disponibile un nuovo campione valido, il tempo calcolato viene aggiornato con la differenza di orario indicata nell'esempio. Questo tempo è l'offset effettivo dell'ora dell'orologio locale. W32Time avvia la correzione dell'orologio utilizzando questo offset e aggiorna l'ora calcolata tra i campioni con l'offset temporale residuo che deve essere applicato all'orologio locale. L'accuratezza dell'orologio può essere monitorata utilizzando questo contatore delle prestazioni con un intervallo di polling basso (ad esempio, 256 secondi o meno) e verificando che il valore del contatore sia inferiore al limite di accuratezza dell'orologio desiderato.
Regolazione della frequenza del clock	La regolazione assoluta della frequenza dell'orologio effettuata sul clock di sistema locale da W32Time in parti per miliardo. Questo contatore consente di visualizzare le azioni eseguite da W32Time.
Ritardo di andata e ritorno NTP	Ritardo di andata e ritorno più recente misurato per dal client NTP nel ricevere una risposta dal server in microsecondi. Questo ritardo è il tempo trascorso nel client NTP tra la trasmissione di una richiesta per il server NTP e la ricezione di una risposta valida dal server. Questo contatore consente di caratterizzare i ritardi esperti dal client NTP. I tempi di andata e ritorno più grandi o variabili possono aggiungere rumore ai calcoli dell'ora NTP, che potrebbe influenzare l'accuratezza della sincronizzazione dell'ora tramite NTP.
Conteggio delle fonti del Client NTP	Numero di fonti NTP attive utilizzate dal client NTP. Questo numero è un conteggio degli indirizzi IP distinti e attivi dei server di tempo che rispondono alle richieste di questo client. Questo numero potrebbe essere maggiore o minore dei peer configurati, a seconda della risoluzione DNS dei nomi dei peer e della raggiungibilità attuale.
Richieste in arrivo al Server NTP	Numero di richieste ricevute dal server NTP (richieste/sec).
Risposte in uscita del Server NTP	Numero di richieste di una risposta dal server NTP (risposte/sec).

I primi tre contatori puntano a scenari per la risoluzione dei problemi di accuratezza. Per maggiori informazioni, consultare la sezione Risolvere i problemi di accuratezza dell'ora e NTP più avanti in questo articolo. Gli ultimi tre contatori riguardano scenari server NTP e sono utili quando si determina il carico e si stabilisce un baseline delle prestazioni attuali.

Aggiornamenti della configurazione per ambiente

La tabella seguente descrive le modifiche apportate alla configurazione predefinita tra Windows Server 2016 e le versioni precedenti per ogni ruolo. Le impostazioni per Windows Server 2016 e Windows 10 Anniversary Update (build 14393) ora sono specifiche, pertanto vengono visualizzate come colonne separate.

Ruolo	Impostazione	Windows Server 2016	Windows 10	Windows Server 2012 R2 Windows Server 2008 R2 Windows 10
Server autonomo/Nano Server
	Server orario	time.windows.com	ND	time.windows.com
	Frequenza di interrogazione	64 - 1024 secondi	ND	Una volta alla settimana
	Frequenza di aggiornamento del clock	Una volta al secondo	ND	Una volta all'ora
Client autonomo
	Server orario	ND	time.windows.com	time.windows.com
	Frequenza di interrogazione	ND	Una volta al giorno	Una volta alla settimana
	Frequenza di aggiornamento del clock	ND	Una volta al giorno	Una volta all'ora
Controller di dominio
	Server orario	PDC/GTIMESERV	ND	PDC/GTIMESERV
	Frequenza di interrogazione	64 -1024 secondi	ND	1,024 - 32,768 secondi
	Frequenza di aggiornamento del clock	Una volta al secondo	ND	Una volta all'ora
Server membro di dominio
	Server orario	Controller di dominio	ND	Controller di dominio
	Frequenza di interrogazione	64 -1024 secondi	ND	1,024 - 32,768 secondi
	Frequenza di aggiornamento del clock	Una volta al secondo	ND	Una volta ogni 5 minuti
Client membro del dominio
	Server orario	ND	Controller di dominio	Controller di dominio
	Frequenza di interrogazione	ND	1,204 - 32,768 secondi	1,024 - 32,768 secondi
	Frequenza di aggiornamento del clock	ND	Una volta ogni 5 minuti	Una volta ogni 5 minuti
Guest di Hyper-V
	Server orario	Sceglie l'opzione migliore in base allo Strato dell'host e del server dell'ora	Sceglie l'opzione migliore in base allo Strato dell'host e del server dell'ora	Predefinito su host
	Frequenza di interrogazione	In base al ruolo precedente	In base al ruolo precedente	In base al ruolo precedente
	Frequenza di aggiornamento del clock	In base al ruolo precedente	In base al ruolo precedente	In base al ruolo precedente

Nota

Per Linux su Hyper-V, consultare la sezione Consentire a Linux di utilizzare l'ora dell'host Hyper-V.

Impatto dell'aumento del polling e della frequenza di aggiornamento dell'orologio

Per fornire un tempo più preciso, i valori predefiniti per le frequenze di polling e gli aggiornamenti dell'orologio sono aumentati, il che ci consente di apportare piccole modifiche più frequentemente. Questa modifica causa un maggior traffico UDP (User Datagram Protocol)/NTP. Questi pacchetti sono piccoli, quindi dovrebbe esserci poco o nessun effetto sui collegamenti a banda larga. Il vantaggio è che le prestazioni dovrebbero essere migliori su un'ampia gamma di hardware e ambienti.

Per i dispositivi con batteria di backup, un aumento della frequenza di polling può causare problemi. I dispositivi alimentati a batteria non memorizzano l'ora mentre sono spenti. Quando riprendono, potrebbero richiedere frequenti correzioni all'orologio. Un aumento della frequenza di polling causa l'instabilità dell'orologio e un maggiore utilizzo di energia. Consigliamo di non modificare le impostazioni predefinite di client.

I controller di dominio (DC) dovrebbero essere minimamente influenzati anche con l'effetto moltiplicato degli aggiornamenti aumentati dei client NTP in un dominio di Active Directory. NTP ha un consumo di risorse molto inferiore rispetto ad altri protocolli, con un effetto marginale. È più probabile raggiungere i limiti di altre funzionalità di dominio prima di essere influenzati dalle impostazioni aumentate di Windows Server 2016. Active Directory usa NTP sicuro, che tende a sincronizzare il tempo in modo meno accurato rispetto a NTP semplice. È stato verificato che è possibile aumentare le prestazioni fino ai client a due Strati lontano dal controller di dominio primario (PDC).

Un piano conservativo dovrebbe prevedere di riservare 100 richieste NTP al secondo per ogni core. Ad esempio, con un dominio costituito da quattro controller di dominio con quattro core ciascuno, dovresti essere in grado di servire 1600 richieste NTP al secondo. Se si dispone di 10.000 client configurati per sincronizzare l'ora ogni 64 secondi e le richieste vengono ricevute in modo uniforme nel tempo, si vedrebbero 10.000/64, ovvero circa 160 richieste al secondo, distribuite su tutti i controller di dominio. Questa cifra rientra facilmente nelle 1600 richieste NTP al secondo in questo esempio. Questi consigli di pianificazione sono prudenti e dipendono in gran parte dalla rete, dalla velocità del processore e dai carichi. Come sempre, impostare un punto di riferimento e testare nei tuoi ambienti.

Se i controller di dominio vengono eseguiti con un considerevole carico della CPU, superiore al 40%, tale carico quasi sicuramente aggiunge rumore alle risposte NTP e influenza la precisione dell'ora nel dominio. Anche in questo caso, è necessario eseguire il test nell'ambiente per comprendere i risultati effettivi.

Misurazioni dell'accuratezza del tempo

Per misurare l'accuratezza di tempo per Windows Server 2016, abbiamo utilizzato diversi strumenti, metodi e gli ambienti. È possibile utilizzare queste tecniche per misurare e ottimizzare l'ambiente e determinare se i risultati di accuratezza soddisfano i requisiti.

Metodologia

L'orologio di origine di dominio è costituito da due server NTP ad alta precisione con hardware GPS. Abbiamo utilizzato anche un computer di test di riferimento separato per le misurazioni, che dispone anche di hardware GPS ad alta precisione installato da un altro produttore. Per alcuni dei test, è necessaria una sorgente orologio accurata e affidabile da utilizzare come riferimento oltre alla sorgente orologio del dominio.

Abbiamo utilizzato quattro metodi diversi per misurare l'accuratezza con le macchine fisiche e virtuali. Diversi metodi forniscono mezzi indipendenti per convalidare i risultati.

1. Misurare l'orologio locale, che è sincronizzato con w32tm, rispetto al nostro computer di prova di riferimento, dotato di un sistema GPS separato.

2. Misura i ping NTP dal server NTP ai client usando il W32tm stripchart.

3. Misura i ping NTP dal client al server NTP usando il W32tm stripchart.

4. Misura i risultati di Hyper-V dall'host al guest utilizzando il Time Stamp Counter (TSC). Questo contatore viene condiviso tra le partizioni e l'ora di sistema in entrambe le partizioni. È stata calcolata la differenza tra l'ora di host e il tempo del client nella VM. Quindi abbiamo usato l'orologio TSC per interpolare l'ora dell'host rispetto al guest, in quanto le misurazioni non avvengono contemporaneamente. Inoltre, abbiamo usato l'orologio del volume segmentato nel tempo per tenere conto dei ritardi e della latenza nell'API.

W32tm è incorporato, ma gli altri strumenti utilizzati durante i test sono disponibili per il repository di Microsoft su GitHub come open source per i test e l'uso. Per maggiori informazioni su come usare gli strumenti per eseguire le misurazioni, consultare il Wiki sugli strumenti di calibrazione dell'ora di Windows.

I risultati del test mostrati di seguito sono un sottoinsieme delle misure che abbiamo eseguito in uno degli ambienti di test. Viene illustrata l'accuratezza mantenuta all'inizio della gerarchia temporale e il client del dominio figlio alla fine della gerarchia temporale. Questi risultati vengono confrontati con le stesse macchine in una topologia basata sul 2012 per il confronto.

Topologia

Per il confronto, abbiamo testato le topologie basate su Windows Server 2012 R2 e Windows Server 2016. Entrambe le topologie sono costituite da due macchine host fisiche Hyper-V che fanno riferimento a una macchina Windows Server 2016 con hardware dell'orologio GPS installato. Ogni host esegue tre guest jointe al dominio Windows, che vengono disposti secondo la topologia seguente. Le righe rappresentano la gerarchia ora e il protocollo/trasporto utilizzato.

Panoramica risultati grafici

I due grafici seguenti rappresentano l'accuratezza di tempo per due membri specifici di un dominio in base alla topologia precedente. Ogni grafico visualizza i risultati sovrapposti di Windows Server 2012 R2 e 2016, il che dimostra i miglioramenti in modo visivo. L'accuratezza è stata misurata dall'interno del computer guest rispetto all'host. I dati grafici rappresentano un sottoinsieme dell'intero set di test eseguiti e illustrano gli scenari del caso migliore e peggiore.

Prestazioni del PDC del dominio radice

Il root PDC viene sincronizzato con l'host Hyper-V (tramite VMIC), che è un Windows Server 2016 con hardware GPS che ha dimostrato di essere sia preciso che stabile. Questo requisito è fondamentale per un'accuratezza a 1 ms, che viene visualizzata come area ombreggiata identificata dal riquadro di richiamo.

Prestazioni del client del dominio figlio

Il client del dominio figlio è connesso a un PDC del dominio figlio che comunica con il PDC radice. Anche il tempo è conforme al requisito di 1 ms.

Test sulla lunga distanza

Il grafico seguente confronta un hop di rete virtuale a sei hop di rete fisica con Windows Server 2016. Due grafici sono sovrapposti tra loro con trasparenza per visualizzare i dati sovrapposti. Un aumento degli hop di rete implica una latenza maggiore e deviazioni temporali più ampie. Il grafico viene ingrandito e vengono ingranditi anche i limiti 1-ms, rappresentati dall'area ombreggiata. Come può notare, il tempo è ancora all'interno di 1 ms con più hop. Lo spostamento è in negativo e questo dimostra un'asimmetria di rete. Ciascuna rete è diversa e le misurazioni dipendono da svariati fattori ambientali.

Migliori pratiche per la misurazione accurata del tempo

Seguire queste migliori pratiche per la misurazione accurata del tempo.

Orologio a fonte stabile

L'ora di una macchina è precisa quanto l'orologio di origine con cui viene sincronizzata. Per ottenere 1 ms di precisione, è necessario avere un hardware GPS o un dispositivo per la sincronizzazione dell'ora sulla rete a cui fare riferimento come sorgente temporale principale. L'utilizzo del valore predefinito di time.windows.com potrebbe non fornire un'origine ora stabile e locale. Via via che ci si allontana dall'orologio origine, la rete influisce sulla precisione. Un orologio di origine master in ciascun data center è necessario per una maggiore accuratezza.

Opzioni hardware GPS

Diverse soluzioni hardware possono offrire l'ora esatta. In generale, le soluzioni oggi sono basate su antenne GPS. Le soluzioni radio e modem dial-up utilizzano linee dedicate. Si collegano alla rete come un appliance o al PC, ad esempio Windows, tramite un PCIe o un dispositivo USB. Diverse opzioni forniscono livelli diversi di precisione e come sempre, i risultati dipendono dall'ambiente. Le variabili che influiscono sull'accuratezza includono disponibilità del GPS, stabilità e carico di rete e hardware del PC. Questi fattori sono tutti importanti quando si sceglie un orologio origine, che rappresenta un requisito per ottenere un'ora stabile e accurata.

Dominio e sincronizzazione del tempo

I membri del dominio utilizzano la gerarchia dei domini per determinare quali computer utilizzano come origine per sincronizzare l'ora. Ogni membro del dominio trova un altro computer con cui eseguire la sincronizzazione e lo salva come fonte dell'ora. Ogni tipo di membro del dominio segue un insieme di regole differenti per trovare una fonte dell'orologio per la sincronizzazione dell'ora. Il PDC nella radice della foresta è la sorgente oraria predefinita per tutti i domini. Di seguito sono elencati diversi ruoli e descrizioni di livello elevato su come trovare un'origine:

• Controller di dominio con ruolo PDC: questa macchina è la fonte di tempo autorevole per un dominio. Ha il tempo più accurato disponibile nel dominio. Deve essere sincronizzato con un controller di dominio nel dominio padre, tranne nei casi in cui il ruolo GTIMESERV è abilitato.
• Qualsiasi altro controller di dominio: questo computer funge da origine dell'ora per i client e i server membri del dominio. Un controller di dominio può sincronizzare con il PDC del suo dominio o con qualsiasi controller di dominio del dominio padre.
• Client/server membro: questo computer può essere sincronizzato con qualunque DC o PDC del proprio dominio oppure con un DC o PDC del dominio padre.

Un sistema di punteggio in base ai candidati disponibili, viene utilizzato per trovare la migliore fonte di tempo. Il sistema prende in considerazione l'affidabilità della sorgente del tempo e la sua posizione relativa. Questo controllo si verifica una volta quando il servizio orario è stato avviato. Se è necessario disporre di un controllo più preciso del modo in cui si sincronizza il tempo, è possibile aggiungere buoni server orari in posizioni specifiche o aggiungere ridondanza. Per maggiori informazioni, consultare la sezione Specificare un servizio orario locale affidabile usando GTIMESERV.

Ambienti del sistema operativo misti (Windows Server 2012 R2 e Windows Server 2008 R2)

Sebbene sia necessario un ambiente di dominio di Windows Server 2016 puro per una maggiore accuratezza, esistono comunque dei vantaggi in un ambiente misto. La distribuzione di Windows Server 2016 Hyper-V in un dominio di Windows Server 2012 offre vantaggi ai guest grazie ai miglioramenti accennati in precedenza, ma solo se i guest sono anch'essi su Windows Server 2016. Un PDC Windows Server 2016 è in grado di offrire un'ora più accurata a causa di algoritmi migliorati; quindi, si stratta di un'origine più stabile. Poiché la sostituzione del PDC potrebbe non essere un'opzione praticabile, è possibile invece aggiungere un controller di dominio di Windows Server 2016 con il ruolo GTIMESERV assegnato, il che rappresenterebbe un miglioramento dell'accuratezza per il dominio. Un controller di dominio Windows Server 2016 è in grado di offrire un'ora più accurata ai client ora downstream, tuttavia, questa è valida solo quanto la relativa ora NTP di origine.

Come indicato in precedenza, le frequenze di polling e di aggiornamento dell'orologio sono state modificate con Windows Server 2016. Queste frequenze possono essere modificate manualmente per i controller di dominio di livello inferiore o applicate tramite Criteri di Gruppo. Queste configurazioni non sono state testate, ma dovrebbero comportarsi correttamente in Windows Server 2008 R2 e Windows Server 2012 R2 e offrire alcuni vantaggi.

Versioni precedenti Windows Server 2016 presentavano dei problemi con la gestione accurata dell'orario, e ciò ha provocato la deviazione dell'ora di sistema immediatamente dopo una modifica apportata. A causa di questo problema, ottenere frequentemente campioni di tempo da una fonte NTP accurata e condizionare l'orologio locale con i dati porta a una minore deviazione negli orologi di sistema durante il periodo tra i campioni. Il risultato è una migliore gestione dell'orario nelle versioni del sistema operativo di livello inferiore. L'accuratezza migliore osservata è stata di circa 5 ms quando un client Windows Server 2012 R2 NTP, configurato con le impostazioni di elevata precisione, ha sincronizzato l'ora da un server NTP Windows Server 2016 preciso.

In alcuni scenari che coinvolgono i controller di dominio guest, i campioni di Hyper-V TimeSync possono interrompere la sincronizzazione dell'ora di dominio. Questo problema non deve più sussistere per i guest Windows Server 2016 in esecuzione sugli host di Windows Server 2016 Hyper-V.

Per disabilitare il servizio TimeSync Hyper-V in modo che non fornisca più esempi a W32Time, impostare la seguente chiave del registro guest:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\VMICTimeProvider "Enabled"=dword:00000000

Consentire a Linux di usare l'ora host Hyper-V

Per i guest Linux che eseguono su Hyper-V, i client sono in genere configurati per utilizzare il demone NTP per la sincronizzazione dell'ora contro i server NTP. Se la distribuzione Linux supporta il protocollo versione 4 TimeSync e il guest Linux ha abilitato il servizio di integrazione TimeSync, viene sincronizzato con l'ora dell'host. Questo scenario potrebbe comportare una gestione dell'orario incoerente se sono abilitati entrambi i metodi.

Per eseguire la sincronizzazione esclusivamente con l'ora dell'host, è consigliabile disabilitare la sincronizzazione dell'ora NTP con uno dei due metodi seguenti:

• Disabilitare tutti i server NTP nel file ntp.conf.
• Disabilitare il daemon NTP.

In questa configurazione, il parametro Time Server è questo host. La frequenza di Polling è 5 secondi e la frequenza di aggiornamento dell'orologio è 5 secondi.

Per sincronizzare esclusivamente tramite NTP, è consigliabile disabilitare il servizio di integrazione TimeSync nel guest.

Nota

Il supporto per l'ora esatta con i guest Linux richiede una funzionalità che è supportata solo nelle versioni più recenti dei kernel Linux upstream. La funzionalità non è ancora ampiamente disponibile in tutte le distribuzioni Linux. Per maggiori informazioni sulle distribuzioni supportate, consultare la sezione Macchine virtuali Linux e FreeBSD supportate per Hyper-V in Windows.

Specificare un servizio orario locale affidabile usando GTIMESERV

È possibile specificare uno o più controller di dominio come orologi origine accurati utilizzando il flag Good Time Server GTIMESERV. Ad esempio, specifici controller di dominio dotati di hardware GPS possono essere contrassegnati come GTIMESERV. Questo flag garantisce che il dominio faccia riferimento a un orologio in base all'hardware GPS.

Nota

Maggiori informazioni sui flag di dominio sono reperibili nella documentazione del protocollo MS-ADTS.

TIMESERV è un'altra bandiera correlata ai Servizi di dominio che indica se un computer è attualmente autorevole, qualora un controller di dominio perda la connessione. Un controller di dominio in questo stato restituisce Unknown Stratum quando viene interrogato tramite NTP. Dopo aver tentato più volte, il DC registra l'evento di sistema Time-Service Event 36.

Se si desidera configurare un controller di dominio come GTIMESERV, configurarlo manualmente usando il seguente comando. In questo caso, il controller di dominio usa un altro computer come l'orologio master. Questo computer potrebbe essere un appliance o un computer dedicato.

w32tm /config /manualpeerlist:"master_clock1,0x8 master_clock2,0x8" /syncfromflags:manual /reliable:yes /update

Nota

Per maggiori informazioni, consultare la sezione Configurare il servizio orario di Windows

Se il controller di dominio ha installato l'hardware GPS, usare i seguenti passaggi per disabilitare il client NTP e abilitare il server NTP.

Avviare disabilitando il client NTP e abilitare il server NTP usando queste modifiche chiave del registro:

reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\w32time\TimeProviders\NtpClient /v Enabled /t REG_DWORD /d 0 /f

reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\w32time\TimeProviders\NtpServer /v Enabled /t REG_DWORD /d 1 /f

A questo punto, riavviare il servizio Windows Time:

net stop w32time && net start w32time

Infine, indica che questa macchina dispone di un'origine orario affidabile.

w32tm /config /reliable:yes /update

Per verificare che le modifiche sono state eseguite correttamente, eseguire i comandi seguenti che influiscono sui risultati mostrati qui:

w32tm /query /configuration

Value|Expected Setting|
----- | ----- |
AnnounceFlags| 5 (Local)|
NtpServer |(Local)|
DllName |C:\WINDOWS\SYSTEM32\w32time.DLL (Local)|
Enabled |1 (Local)|
NtpClient| (Local)|

w32tm /query /status /verbose

Value| Expected Setting|
----- | ----- |
Stratum| 1 (primary reference - syncd by radio clock)|
ReferenceId| 0x4C4F434C (source name: "LOCAL")|
Source| Local CMOS Clock|
Phase Offset| 0.0000000s|
Server Role| 576 (Reliable Time Service)|

Windows Server 2016 su piattaforme virtuali di terze parti

Quando Windows viene virtualizzato, per impostazione predefinita, l'Hypervisor è responsabile della fornitura dell'ora. I membri aggiunti al dominio devono tuttavia essere sincronizzati con il controller di dominio per consentire il corretto funzionamento di Active Directory. È consigliabile disabilitare la virtualizzazione dell'ora tra il guest e l'host di qualsiasi piattaforma virtuale di terze parti.

Scoprire la gerarchia

Poiché la gerarchia temporale verso la sorgente dell'orologio master è dinamica in un dominio e negoziata, è necessario eseguire una query sullo stato di un particolare computer per comprenderne l'origine tempo e la catena fino alla sorgente dell'orologio master. Queste informazioni consentono di diagnosticare problemi di sincronizzazione dell'ora.

Se si desidera risolvere i problemi relativi a un client specifico, il primo passaggio consiste nel comprendere l'origine dell'orario utilizzando il seguente comando w32tm:

w32tm /query /status

Tra le altre cose, i risultati mostrano l'origine. L'origine indica con chi viene sincronizzato l'orario nel dominio. Questa è la prima fase di questa gerarchia temporale della macchina. Successivamente, usare la voce sorgente dal comando precedente e quindi il parametro /stripchart per trovare la fonte temporale successiva nella catena.

w32tm /stripchart /computer:MySourceEntry /packetinfo /samples:1

Anche utile, il comando seguente elenca ogni controller di dominio che trova nel dominio specificato e visualizza un risultato che permette di determinare ogni partner. Questo comando include i computer che sono stati configurati manualmente.

w32tm /monitor /domain:my_domain

Usando l'elenco, è possibile tracciare i risultati tramite il dominio e comprendere la gerarchia e l'offset temporale a ogni passaggio. Individuando il punto in cui la differenza di orario peggiora in modo significativo, è possibile individuare la radice dell'errore. Da qui, puoi provare a capire perché quell'orario non è corretto attivando il log w32tm.

Usare Criteri di gruppo

È possibile usare Criteri di gruppo per ottenere una maggiore accuratezza, ad esempio assegnando i client per l'uso di server NTP specifici, o per controllare come sono configurati i sistemi operativi di versione precedente in caso di virtualizzazione. Di seguito è riportato un elenco di possibili scenari e impostazioni di criteri di gruppo pertinenti:

Domini virtualizzati: per controllare i controller di dominio virtualizzati in Windows Server 2012 R2 in modo che sincronizzino l'ora con il relativo dominio, anziché con l'host Hyper-V, è possibile disabilitare questa voce del registro. Per il PDC, non conviene disabilitare l'impostazione perché l'host Hyper-V fornisce l'origine temporale più stabile. La voce del registro richiede di riavviare W32Time dopo che è stata modificata.

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\VMICTimeProvider] "Enabled"=dword:00000000

Carichi sensibili all'accuratezza: per i carichi sensibili all'accuratezza temporale, è possibile configurare gruppi di computer per impostare i server NTP e le relative impostazioni di tempo, ad esempio il polling e la frequenza di aggiornamento dell'orologio. Questa attività è normalmente gestita dal dominio, ma per un maggiore controllo è possibile indirizzare macchine specifiche per puntare direttamente all'orologio master.

Impostazione di Criteri di gruppo	Nuovo valore
NtpServer	ClockMasterName, 0x8
MinPollInterval	6-64 secondi
MaxPollInterval	6
UpdateInterval	100 – una volta al secondo
EventLogFlags	3 – Tutte le registrazioni speciali del tempo

Nota

Le impostazioni NtpServer e EventLogFlags si trovano in System\Windows Time Service\Time Providers usando le impostazioni Configura client NTP Windows. Le altre tre si trovano in System\Windows Time Service usando le impostazioni Configurazione globale.

Carichi sensibili all'accuratezza remoti: Per i sistemi nei domini di filiale, come il Retail e il settore dei Pagamenti con Carte (PCI), Windows utilizza le informazioni del sito corrente e il DC Locator per trovare un controller di dominio locale, a meno che non sia configurata manualmente un'origine dell'ora NTP. Questo ambiente richiede un'accuratezza di 1 secondo, utilizzando una convergenza più rapida verso l'ora esatta. Questa opzione consente a W32Time di spostare l'orologio indietro. Se questo comportamento è accettabile e soddisfa le esigenze, è possibile creare i criteri seguenti. Come con qualsiasi ambiente, assicurati di testare e stabilire i parametri di riferimento della rete.

Impostazione di Criteri di gruppo	Nuovo valore
MaxAllowedPhaseOffset	1, ma se più di un secondo, impostare l'orologio all'ora corretta.

L'impostazione MaxAllowedPhaseOffset si trova sotto System\Windows Time Service usando le impostazioni Configurazione globale.

Nota

Per maggiori informazioni su Criteri di gruppo e le voci correlate, consultare la sezione Strumenti di Windows Time e l'articolo Impostazioni su TechNet.

Considerazioni di Azure e Windows IaaS

Di seguito sono riportati alcuni punti da considerare per Iaas (Infrastructure as a service) di Azure e Windows.

Macchina virtuale di Azure: Active Directory Domain Services

Se la VM di Azure che esegue Active Directory Domain Services fa parte di una foresta Active Directory locale esistente, è necessario disabilitare TimeSync (VMIC). Questa azione consente a tutti i controller di dominio della foresta, sia fisici che virtuali, di usare una gerarchia di sincronizzazione del tempo unica. Per maggiori informazioni, consultare la sezione Esecuzione di controller di dominio in Hyper-V.

Macchina virtuale di Azure: Connessa al dominio

Se si ospita una macchina unita a un dominio in una foresta di Active Directory esistente, virtuale o fisica, la procedura consigliata è disattivare TimeSync per il guest e verificare che W32Time sia configurato per la sincronizzazione con il suo Domain Controller tramite la configurazione del tempo per Type=NTP5.

Macchina virtuale di Azure: Computer del gruppo di lavoro autonomo

Se la VM di Azure non è associata a un dominio e non è un controller di dominio, è consigliabile mantenere la configurazione dell'ora predefinita in modo che la VM si sincronizzi con l'host.

L'applicazione Windows richiede l'ora esatta

Di seguito alcune azioni che è possibile eseguire se l'applicazione Windows richiede l'ora accurata.

Timestamp API

I programmi che richiedono la massima accuratezza in relazione a UTC, e non il semplice trascorrere del tempo, devono usare l'API GetSystemTimePreciseAsFileTime. Usare questa API garantisce che l'applicazione ottenga l'orario di sistema, che è condizionato dal servizio Windows Time.

Prestazioni UDP

Se si dispone di un'applicazione che usa la comunicazione UDP per le transazioni ed è importante ridurre al minimo la latenza, esistono alcune voci correlate del registro che è possibile usare per configurare un intervallo di porte da escludere dal motore di filtro base. Questa azione migliora la latenza e aumenta la velocità effettiva. Tuttavia, le modifiche al Registro di sistema devono essere limitate agli amministratori esperti. Questa soluzione alternativa esclude le porte dalla protezione da parte del firewall. Per maggiori informazioni, consultare i riferimenti seguenti.

Per Windows Server 2012 e Windows Server 2008, si dovrà installare prima un hotfix. Per maggiori informazioni, consultare la sezione Perdita di datagrammi quando viene eseguita un'applicazione ricevitore multicast in Windows 8 e in Windows Server 2012.

Aggiornare i driver di rete

Alcuni fornitori di rete dispongono di aggiornamenti di driver che migliorano le prestazioni per quanto riguarda la latenza di driver e memorizzare nel buffer i pacchetti UDP. Contattare il fornitore della rete per verificare se sono disponibili aggiornamenti per facilitare la velocità effettiva UDP.

Registrazione per scopi di controllo

Per garantire la conformità alle normative di tracciamento orario, è possibile archiviare manualmente i log w32tm, i log eventi e informazioni di Performance Monitor. In un secondo momento, le informazioni archiviate consente di attestare la conformità in un momento specifico in passato. I seguenti fattori vengono utilizzati per indicare l'accuratezza:

1. L'accuratezza dell'orologio mediante l'uso del contatore Computed Time Offset del Performance Monitor. Questo contatore mostra l'orologio con l'accuratezza desiderata.
2. Origine orologio alla ricerca di Peer Response from nei log w32tm. Dopo il testo del messaggio vi è l'indirizzo IP o VMIC, che descrive l'origine dell'orario e quella successiva nella catena di orologi di riferimento per la convalida.
3. Stato delle condizioni dell'orologio utilizzando i log w32tm per convalidare che ClockDispl Discipline: \*SKEW\*TIME\* si stia verificando. Questo stato indica che w32tm è attivo al momento.

Registrazione degli eventi

Per ottenere la storia completa, sono necessario anche le informazioni del registro eventi. Raccogliendo il registro eventi di sistema e filtrando i dati in base a Time-Server, Microsoft-Windows-Kernel-Boot, Microsoft-Windows-Kernel-General, potresti riuscire a scoprire se esistono altri fattori che hanno modificato l'ora, ad esempio terze parti. Questi registri potrebbero essere necessari per escludere interferenze esterne. I criteri di gruppo possono influire su quali registri di eventi vengono scritti nel log. Per maggiori informazioni, consultare la sezione precedente Usare criteri di gruppo.

Registrazione debug di W32Time

Per abilitare w32tm per scopi di controllo, il comando seguente consente di abilitare una registrazione che visualizza gli aggiornamenti periodici dell'orologio e indica l'orologio di origine. Riavviare il servizio per abilitare la nuova registrazione dei log.

Per maggiori informazioni, consultare la sezione Attivare la registrazione debug nel servizio di Windows Time.

w32tm /debug /enable /file:C:\Windows\Temp\w32time-test.log /size:10000000 /entries:0-73,103,107,110

Monitoraggio prestazioni

Il servizio Windows Time di Windows Server 2016 espone i contatori delle prestazioni che possono essere usati per la raccolta di registri per la verifica. Questi contatori possono essere registrati in locale o in remoto. È possibile registrare i contatori Computer Time Offset e Round Trip Delay. Come un contatore delle prestazioni, è possibile monitorarli in modalità remota e creare avvisi usando System Center Operations Manager. Ad esempio, è possibile utilizzare un avviso per avvertirti quando l'Offset dell'ora si discosta dalla precisione desiderata. Per maggiori informazioni, consultare la sezione System Center Management Pack.

Esempio di tracciabilità Windows

Dai file di log w32tm, si desidera convalidare due tipi di informazioni. La prima è un'indicazione che il file di log è attualmente un orologio delle condizioni. Questa indicazione dimostra che l'orologio è stato condizionato dal servizio Windows Time all'ora contestata.

 151802 20:18:32.9821765s - ClockDispln Discipline: *SKEW*TIME* - PhCRR:223 CR:156250 UI:100 phcT:65 KPhO:14307
 151802 20:18:33.9898460s - ClockDispln Discipline: *SKEW*TIME* - PhCRR:1 CR:156250 UI:100 phcT:64 KPhO:41
 151802 20:18:44.1090410s - ClockDispln Discipline: *SKEW*TIME* - PhCRR:1 CR:156250 UI:100 phcT:65 KPhO:38

Il punto principale è che si visualizzano messaggi preceduti dal prefisso ClockDispln Discipline, che prova che W32Time interagisce con l'orologio di sistema.

Successivamente, è necessario trovare l'ultimo report nel log precedente all'ora contestata che riporta il computer sorgente attualmente utilizzato come orologio di riferimento. Questa informazione potrebbe corrispondere a un indirizzo IP, a un nome computer o al provider VMIC, il che indica che viene eseguita la sincronizzazione con l'host per Hyper-V. L'esempio seguente fornisce l'indirizzo IPv4 10.197.216.105:

151802 20:18:54.6531515s - Response from peer 10.197.216.105,0x8 (ntp.m|0x8|0.0.0.0:123->10.197.216.105:123), ofs: +00.0012218s

Ora che è stato convalidato il primo sistema della catena ora di riferimento, è necessario analizzare il file di log nell'origine ora di riferimento e ripetere gli stessi passaggi. Questo processo continua finché non viene visualizzato un orologio fisico, ad esempio GPS o un'origine ora nota come NIST. Se l'orologio di riferimento è hardware GPS, potrebbero essere necessari anche i log dal produttore.

Considerazioni per la rete

Gli algoritmi di protocollo NTP presentano una dipendenza da simmetria della rete. Man mano che aumenta il numero di hop di rete, aumenta anche la probabilità di asimmetria. Per questo motivo, è difficile prevedere quali tipi di accuratezza verranno visualizzati negli specifici ambienti in uso.

Per valutare l'accuratezza del tuo ambiente e creare linee di base, possono essere utilizzati Performance Monitor e i nuovi contatori di tempo di Windows in Windows Server 2016. Inoltre, è possibile eseguire la risoluzione dei problemi per determinare l'offset corrente di qualsiasi computer della rete.

Sono disponibili due standard generale per ora esatta in rete:

• Protocollo Precision Time Protocol - IEEE 1588(PTP): PTP ha requisiti più rigorosi nell'infrastruttura di rete, ma spesso può fornire un'accuratezza submicroseconda.
• Protocollo ora di rete - RFC 1305(NTP): NTP funziona su un'ampia gamma di reti e ambienti, semplificando la gestione.

Per impostazione predefinita, per le macchine non appartenenti al dominio, Windows supporta NTP semplice (RFC2030). Per macchine appartenenti al dominio, utilizziamo un NTP sicuro chiamato MS-SNTP, che sfrutta segreti negoziati a livello di dominio che forniscono un vantaggio di gestione rispetto all'NTP autenticato, come descritto in RFC1305 e RFC5905.

Sia i protocolli collegati al dominio che quelli non collegati richiedono la porta UDP 123. Per maggiori informazioni sulle pratiche migliori attuali dell'NTP, fare riferimento alla bozza IETF delle Best Current Practices del Network Time Protocol.

Orologio hardware affidabile (RTC)

Windows non tiene conto del tempo che passa, a meno che non vengono superati determinati limiti, ma piuttosto disciplina l'orologio. Ciò significa che w32tm regola la frequenza dell'orologio a intervalli regolari, utilizzando l'impostazione Clock Update Frequency, che dà come valore predefinito una volta al secondo con Windows Server 2016. Se l'orologio è indietro, esso accelera la frequenza. Se è avanti, rallenta la frequenza. Tuttavia, durante l'intervallo di tempo tra le modifiche della frequenza, l'orologio hardware è sotto controllo. Se si verifica un problema con il firmware o il clock hardware, l'ora del computer può diventare meno accurata.

Questo scenario rappresenta un altro motivo per cui è necessario testare e definire un punto di riferimento nel proprio ambiente. Se il contatore delle prestazioni Computed Time Offset non si stabilizza all'accuratezza desiderata, si consiglia di verificare che il firmware sia aggiornato. Come in un altro test, è possibile scoprire se l'hardware duplicato restituisce lo stesso problema.

Risoluzione dei problemi relativi all'accuratezza degli orari e NTP

È possibile utilizzare la sezione Discover the hierarchy per comprendere l'origine dell'ora incorretta. Osservando lo scostamento temporale, trova il punto della gerarchia in cui l'ora differisce di più dalla sua origine NTP. Dopo aver compreso la gerarchia, è opportuno provare a comprendere perché quella sorgente temporale non riceve l'ora corretta.

Concentrandosi sul sistema con orario divergente, è possibile utilizzare i seguenti strumenti per raccogliere maggiori informazioni che aiutano a identificare il problema e trovare una soluzione. Il riferimento UpstreamClockSource è l'orologio individuato tramite w32tm /config /status:

• Log eventi di sistema
• Abilitare la registrazione tramite w32tm logs - w32tm /debug /enable /file:C:\Windows\Temp\w32time-test.log /size:10000000 /entries:0-300
• chiave del registro w32Time HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time
• Tracce di rete locale
• Contatori delle prestazioni (dal computer locale o UpstreamClockSource)
• W32tm /stripchart /computer:UpstreamClockSource
• PING UpstreamClockSource per comprendere la latenza e il numero di passaggi fino all'origine
• Tracert UpstreamClockSource

Problema	Sintomi	Risoluzione
L'orologio TSC locale non è stabile.	Utilizzo di Perfmon - Computer fisico: sincronizzazione stabile dell'orologio, ma si vede comunque che ogni 1-2 minuti ci sono diversi 100µs.	Aggiornare il firmware o verificare che un hardware diverso non visualizzi lo stesso problema.
Latenza di rete.	Lo stripchart w32tm visualizza RoundTripDelay di più di 10 ms. La variazione del ritardo può causare rumore grande quanto la metà del tempo di andata e ritorno, ad esempio un ritardo che si verifica solo in una direzione. UpstreamClockSource è costituito da più salti, come indicato dal comando PING. Il TTL dovrebbe essere vicina a 128. Usare Tracert per trovare la latenza in ogni hop.	Trova una sorgente di orologio più vicina per il tempo. Una soluzione consiste nell'installare un orologio di origine nello stesso segmento o scegliere manualmente orologio di origine geograficamente più vicino. Per uno scenario di dominio, aggiungere un computer con il ruolo GTimeServ.
Impossibile raggiungere in modo affidabile l'origine NTP.	W32tm /stripchart restituisce in modo intermittente il messaggio "Richiesta scaduta".	L'origine NTP non risponde.
L'origine NTP non risponde.	Controllare i contatori Perfmon per il conteggio di origine del Client NTP, le richieste in arrivo del Server NTP e le risposte in uscita del Server NTP, e determinare l'utilizzo rispetto alle linee di base.	Usando i contatori delle prestazioni del server, determinare se il carico è cambiato rispetto ai valori di riferimento. Ci sono problemi di congestione della rete?
Il controller di dominio non utilizza l'orologio più accurato.	Modifiche nella topologia o orologio master aggiunto di recente.	W32tm /Resync. /rediscover
Gli orologi client stanno divergendo.	Evento del servizio ora 36 nel registro eventi di sistema e/o nel file di log testo che descrive che il contatore NTP Client Time Source Count passa da 1 a 0.	Risolvere i problemi dell'origine upstream e verificare eventuali problemi di prestazioni.

Impostazione del tempo di riferimento

Stabilire un riferimento è importante per comprendere le prestazioni e l'accuratezza della rete e confrontarle con il riferimento in futuro, quando si verificano problemi. È opportuno definire una linea di base per il PDC radice o qualsiasi computer contrassegnato con GTIMESRV. Sarebbe inoltre consigliabile stabilire il PDC in ogni foresta. Infine, scegliere i controller di dominio o le macchine che dispongono di caratteristiche interessanti, come la distanza o i carichi elevati, e stabilire una baseline per questi.

È utile inoltre eseguire la baseline di Windows Server 2016 rispetto a 2012 R2. Tuttavia, si dispone solo dello strumento w32tm /stripchart, che è possibile usare per eseguire un confronto, perché Windows Server 2012 R2 non dispone di contatori delle prestazioni. Selezionare due computer con le stesse caratteristiche o aggiornare un computer e confrontare i risultati dopo l'aggiornamento. Il supplemento Windows Time Measurements contiene informazioni più dettagliate su come eseguire misurazioni tra il 2016 e il 2012.

Usando tutti i contatori di prestazioni W32Time, raccogliere i dati per almeno una settimana. Questi dati garantiscono che si disponga di un numero sufficiente di riferimenti per tenere conto delle variazioni nella rete nel tempo e un'esecuzione sufficiente per fornire fiducia che la precisione temporale sia stabile.

Ridondanza del server NTP

Per la configurazione manuale del server NTP utilizzato con macchine non appartenenti al dominio o il PDC, avere più di un server è una buona misura di ridondanza in caso di indisponibilità. È inoltre possibile fornire una migliore accuratezza, supponendo che tutte le origini siano accurate e stabili. Tuttavia, se la topologia non è ben progettata o le fonti temporali non sono stabili, l'accuratezza risultante potrebbe essere inferiore, quindi è consigliabile prestare attenzione. Il limite dei server a orario supportato a cui W32Time può fare manualmente riferimento è 10.

Secondi intercalari

Il periodo di rotazione della terra varia nel tempo a causa di eventi climatici e geologici. In genere, la variazione è di circa un secondo ogni due anni. Ogni volta che la variazione dall'ora atomica diventa eccessiva, viene inserita una correzione di un secondo (verso l'alto o verso il basso), nota come secondo intercalare. Questo inserimento viene eseguito in modo che la differenza non supera mai 0,9 secondi. Questa correzione viene annunciata sei mesi prima che venga effettivamente apportata. Prima di Windows Server 2016, il servizio orario di Microsoft non era consapevole dei secondi intercalari, ma si basava sul servizio orario esterno. Con la maggiore accuratezza temporale di Windows Server 2016, Microsoft sta lavorando a una soluzione più adatta per il problema del secondo intercalare.

Sincronizzazione sicura dell'ora

W32time in Server 2016 include una funzionalità per Secure Time Seeding. Questa funzionalità determina l'ora corrente approssimativa dalle connessioni SSL in uscita. Questo valore relativo all'ora viene usato per monitorare il clock di sistema locale e correggere gli errori particolarmente evidenti. Per altre informazioni su questa funzionalità, leggi questo post di blog. Nelle distribuzioni con una o più sorgenti temporali affidabili e macchine ben monitorate che includono la rilevazione degli scostamenti temporali, puoi decidere di non utilizzare la funzione Secure Time Seeding e basarti invece sull'infrastruttura esistente.

Per disabilitare la funzionalità di ripristino accelerato del database:

1. Usare Criteri di gruppo per gestire SecureTimeSeeding. Consultare la sezione che fa riferimento all'impostazione UtilizeSslTimeData: Ulteriori informazioni: Policy CSP - ADMX_W32Time.

2. In alternativa, è possibile impostare manualmente il valore del registro. Impostare il valore di configurazione del registro UtilizeSSLTimeData su 0 in un computer specifico

   reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\w32time\Config /v UtilizeSslTimeData /t REG_DWORD /d 0 /f
   

3. Se non si riesce a riavviare il computer immediatamente, è possibile notificare W32Time dell'aggiornamento di configurazione. Questa notifica interrompe il monitoraggio e l'applicazione dell'ora in base ai dati temporali provenienti dalle connessioni SSL.

   W32tm.exe /config /update
   

4. Il riavvio del computer rende immediatamente effettiva l'impostazione e interrompe la raccolta dei dati temporali dalle connessioni SSL. La seconda parte comporta un sovraccarico ridotto e non dovrebbe incidere sulle prestazioni.

5. Per applicare questa impostazione in un intero dominio, imposta il valore UtilizeSSLTimeData nell'impostazione Criteri di gruppo W32time su 0 e pubblicare l'impostazione. Quando l'impostazione viene prelevata da un client di Criteri di gruppo, viene inviata una notifica a W32Time, che interromperà il monitoraggio e l'applicazione dell'ora in base ai dati temporali SSL. La raccolta dei dati temporali SSL si interrompe al riavvio di ogni computer. Se il dominio include tablet o portatili slim e altri dispositivi, è opportuno escludere tali computer dalla modifica dei criteri. Questi dispositivi si trovano ad affrontare l'esaurimento della batteria e necessitano della funzionalità Secure Time Seeding per impostare l'ora esatta durante l'avvio.