PREMESSA

Non intendo inserire in questo articolo la configurazione del servizio in oggetto, ci ha già pensato il buon Luca; siccome mi capita sempre più di frequente un troublshooting del servizio Windows Time, sia lato client, sia lato server e siccome spesso, mi trovo in difficoltà perchè non ho mai trovato una documentazione chiara ed esaustiva sull’ordine dei passi da seguire per individuare la fonte di un dato problema, ho deciso di mettere per iscritto due righe con l’elenco dei tips che mi hanno aiutato con notevole soddisfazione a risolvere l’ultimo problema di Sync presso un dominio Active Directory.

Assumo che il lettore abbia già conoscenza della configurazione base del Windows Time Service e delle sue chiavi di registry fondamentali.

PROBLEMA

Un cliente mi segnala che circa il 20% delle sue postazioni macchina (tutte Windows XP) ha l’orologio con una media differenza di ben 10 minuti da quella del server. Mi segnala anche che questo, a dispetto di quello che dovrebbe essere il funzionamento del kerberos, non gli sta causando blocchi, ma vorrebbe risolvere il problema prima che accada.

Troubleshooting tips

La prima cosa che viene in mente è verificare che i server siano correttamente allineati tra loro. Il dominio in questione include solamente due domain controllers, e controllando il PDC Emulator, il cliente aveva correttamente configurato le chiavi del registry per puntare a ntp1.ien.it

Riavviando il w32time, il server registra la corretta sincronizzazione con il server NTP. Anche il secondo domain controller, al riavvio, sincronizza la corretta ora con il PDC Emulator. Quindi il problema potrebbe risiedere sui client.

Localizziamo il primo client e notiamo immediatamente l’anomalia. Orario con uno skew di ben 9 minuti.

1) Riavvio del Windows Time Service. Il servizio riparte, ma nell’SystemLog non compare il solito messaggio di sync con il domain controller (come quello qui sotto)

Event Type:       Information
Event Source:    W32Time
Event Category: None
Event ID:          35
Date:                14/03/2008
Time:                15.14.28
User:                N/A
Computer:         CLIENT
Description:
The time service is now synchronizing the system time with the time
source dc.bsuiness.it (ntp.d|192.168.32.1:123->192.168.30.4:123).

2) Verifichiamo quindi lo stato di Discovery del client. Sul client, esecuzione di

>w32tm /resync /rediscover
Error: The computer did not resync because no time data was available.

Nel support di Microsoft l’errore è referenziato, ma nessuna delle cause era nel nostro scenario e, cosa molto più importante, nessuna delle soluzioni proposte ha risolto il problema.

Cercando quindi nella command line del W32TM ho scoperto uno switch che ho sempre ignorato (ovviamente perchè non ne avevo mai avuto necessità) che permette al client di riprendere in considerazione la sincronia secondo la gerarchia di dominio.  

w32tm /config /syncfromflags:DOMHIER

Quindi una volta verificato che il comando ha avuto successo, ho comandato l’allineamento:

w32tm /config /update

E qui parte il comportamento simpatico, infatti se si apre l’orologio si vede che la lancetta dei secondi scorre più velocemente degli effettivi secondi :-) certo viene spontaneo chiedersi perchè non fare un allineamento immediato. 
La conferma dell’allineamento si può avere anche con un simpatico comando che mostra l’allineamento con un server di riferimento (nell’esempio con il PDC Emulator). 
Come si vede, al trascorrere dei secondi sulla macchina locale –estrema sinistra- corrisponde uno skew sempre minore –centro dello schermo- . Simpatico anche il fatto che man mano che ci si avvicina all’allineamento, la velocità dell’allineamento è sempre minore: tradotto, quando lo skew è elevato, ad ogni secondo “reale” Windows ne fa trascorrere 3 o 4 “virtuali”, mentre quando lo skew si abbassa ad un secondo reale ne corrisponde 1,5 “virtuale” e cosi calando.

w32tm /stripchart /computer:DC
Tracking DC [192.168.30.4].
The current time is 14/03/2008 17.16.17 (local time).
17:16:23 d:+00.0000000s o:+540.8036502s  [                         |                         *  ]
17:16:25 d:+00.0000000s o:+538.7975830s  [                         |                        *   ]
17:16:27 d:+00.0000000s o:+536.7915158s  [                         |                       *    ]
17:16:29 d:+00.0000000s o:+535.7854486s  [                         |                   *        ]
17:16:31 d:+00.0000000s o:+530.7793814s  [                         |                  *         ]
17:16:33 d:+00.0000000s o:+526.7733142s  [                         |                 *          ]
....
17:33:41 d:+00.0000000s o:-00.7490454s  [                         * |                           ]
17:33:43 d:+00.0000000s o:-00.7429782s  [                         * |                           ]

A questo punto, giusto per scrupolo, un bel riavvio del w32time e al comando:

w32tm /resync /rediscover

È corrisposto il realtivo evento di sync con il PDC Emulator.

Note Aggiuntive
Il problema è stato risolto, ma non è stata risolta la cosa più importante almeno dal mio punto di vista: individuare la causa che ha fatto perdere ai client la TimeDomainHierarchy. Soprattuto il cliente non è stato in grado di dirmi se il problema c’è sempre stato dalla nascita del dominio oppre se si è presentato di recente (gli eventi non sono stati d’aiuto in questo). Purtroppo nessun articolo pubblico mi ha saputo spiegare “come mai” un client possa smettere di sincronizzarsi col dominio; chissà se nella KB privata di Microsoft c’è qualcosa :-)