none
Configurare correttamente il servizio ora via GPO. RRS feed

  • Domanda

  • Volevo configurare il servizio orario perchè prendesse le impostazioni via GPO. Ho pensato quindi di creare due diverse GPO, una per i DC ed altre per i client, in base alle esigenze.
     Ho modificato quindi la "Default domain controllers policy" sotto "Computer configuration" -> "Policies" -> "Adm Templates" -> "System" -> "Windows Time Service" come segue:
    "Global configuration settings": Tutto default, tranne "MaxNegPhaseCorrection" e "MaxPosPhaseCorrection" ridotte a 1800 secondi.

    In "General Parameters" ho impostato "AnnounceFlags" su 8 che, in base a quanto scritto qui dovrebbe far sì che il DC decida quando deve pubblicarsi come fonte oraria attendibile (se non ho capito male!)

     Ho poi configurato così la parte "Configure Windows NTP Client" ed impostato su "Enabled" sia "Enable Windows NTP Client" che "Enable Windows NTP Server".
    NtpServer    it.pool.ntp.org
    Type    NTP
    CrossSiteSyncFlags    2
    ResolvePeerBackoffMinutes    15
    ResolvePeerBackoffMaxTimes    7
    SpecialPollInterval    3600
    EventLogFlags    0

     Ho poi salvato la policy, ho lanciato un "gpupdate" sui DC, riavvio del servizio orario, w32tm /resync e questo è l'output del comando w32tm /query /status

    Leap Indicator: 0(no warning)
    Stratum: 3 (secondary reference - syncd by (S)NTP)
    Precision: -6 (15.625ms per tick)
    Root Delay: 0.0351563s
    Root Dispersion: 7.7968510s
    ReferenceId: 0xD42D9058 (source IP:  212.45.144.88)
    Last Successful Sync Time: 18/03/2011 18:39:02
    Source: it.pool.ntp.org
    Poll Interval: 6 (64s)

     Se faccio un w32tm /monitor ottengo su DC1 (Win2008 R2 FSMO) una cosa del genere che dovrebbe andare bene (a parte l'IP del DC in IPv6 ma è una novità di adesso):
    DC2.dominio.lan[192.168.10.3:123]:
        ICMP: 0ms
        NTP: +0.0096768s

        RefID: (unknown) [0xF2626753]
    DC1.dominio.lan *** PDC ***[[::1]:123]:
        ICMP: 0ms
        NTP: +0.0000000s 

        RefID: vodka.sublink.ORG [212.45.144.88]

    Invece su DC2 che è Windows 2003 ottengo questo:
    resolving referer 83.103.98.242 (1 of 2)...
    resolving referer 212.45.144.88 (2 of 2)...
    DC2.dominio.lan [192.168.10.3]:
        ICMP: 0ms delay.
        NTP: -0.0034102s offset from DC1.dominio.lan
            RefID: gw-ge.esaote.com [83.103.98.242]
    DC1.dominio.lan *** PDC *** [192.168.10.60]:
        ICMP: 0ms delay.
        NTP: +0.0000000s offset from DC1.dominio.lan
            RefID: vodka.sublink.org [212.45.144.88]

     E mi sembra che vada bene.

     

    Se invece lancio un DcDiag per verificare lo stato di AD ottengo:

     Testing server: Nome-predefinito-primo-sito\DC1
     Starting test: Advertising
     Warning: DC1 is not advertising as a time server.
     ......................... DC1 failed test Advertising

     e poi

    Running enterprise tests on : dominio.lan
    Starting test: LocatorCheck
    Warning: DcGetDcName(TIME_SERVER) call failed, error 1355
    A Time Server could not be located.
    The server holding the PDC role is down.
    Warning: DcGetDcName(GOOD_TIME_SERVER_PREFERRED) call failed, error 1355
    A Good Time Server could not be located.
    ......................... dominio.lan failed test LocatorCheck

     

     Cosa sbaglio?


    venerdì 18 marzo 2011 17:57

Tutte le risposte

  •  Grazie del suggerimento. Come dicono nella guida, la documentazione disponibile è molto più che abbondante e ne ho letta parecchia ma ancora non riesco a capire cosa stò sbagliando oppure se l'errore in dcdiag è in realtà sintomo di qualcos'altro.

     Effettivamente mi sembra che la gerarchia di sincronizzazione di AD stia funzionando correttamente in quanto il comando w32tm /monitor lanciato sul server FSMO restituisce "NTP: +0.0000000s offset from DC1.dominio.lan" (con RefID un host appartenente al pool ntp indicato nella GPO) e il comando w32tm /monitor lanciato sul secondo DC restituisce "NTP: -0.0034102s offset from DC1.dominio.lan" sempre con RefID l'host appartenente al pool ntp indicato quindi non capisco perchè di dcdiag relativo al servizio ora fallisca.

     

     Il sunto è che io ho due DC uno dei quali, in quanto detentore dei ruoli fsmo, dovrebbe anche presentarsi come PDCE. In base allo schema presente nel link che mi hai messo, in teoria solo quel server dovrebbe sincronizzarsi con la fonte attendibile e l'altro DC dovrebbe sincronizzarsi su di lui. Forse è questo l'errore: configurando la GPO per sincronizzare i DC sulla medesima origine esterna i DC cercano di riconoscere nel test dcdiag un server orario che non appartiene alla mia AD e che quindi non è il loro "PDCE". Forse è meglio configurare manualmente i DC?


    domenica 20 marzo 2011 14:38
  • ma questo http://support.microsoft.com/kb/272686

    l'hai già verificato ?


    Edoardo Benussi - Microsoft® MVP
    Management Infrastructure - Systems Administration
    https://mvp.support.microsoft.com/Profile/Benussi
    Windows Server Italian Forum Moderator
    edo[at]mvps[dot]org
    lunedì 21 marzo 2011 09:33
    Moderatore
  •  Non avevo visto l'articolo ma sì, il servizio ora di Windows è avviato ed impostato per l'avvio automatico.

     Direi anche funzionante, visto che i client si prendono l'orario da DC1... Però ho impostato una policy per i client in cui specifico DC1,0x1 e DC2,0x1 come fonti orarie attandibili quindi probabilmente stanno usando DC1 non tanto perchè così stabilisce la gerarchia del dominio quanto perchè la policy glielo indica.

    lunedì 21 marzo 2011 11:51
  • Il sunto è che io ho due DC uno dei quali, in quanto detentore dei ruoli fsmo, dovrebbe anche presentarsi come PDCE. In base allo schema presente nel link che mi hai messo, in teoria solo quel server dovrebbe sincronizzarsi con la fonte attendibile e l'altro DC dovrebbe sincronizzarsi su di lui. Forse è questo l'errore: configurando la GPO per sincronizzare i DC sulla medesima origine esterna i DC cercano di riconoscere nel test dcdiag un server orario che non appartiene alla mia AD e che quindi non è il loro "PDCE".

     Il problema sembra essere proprio questo.

     Ho disattivato la configurazione del servizio orario nella "Default domain controllers policy" e riavviato il servizio w32time. Il comando w32tm /resync ora fallisce perchè non c'è alcuna sorgente oraria configurata ed il comando w32tm /query /status riporta che il sistema stà utilizzando l'orologio CMOS come sorgente ma il test dcdiag non riporta più alcun errore.

     Per curiosità e cultura personale: In una situazione con unico dominio e DC controller distribuiti in due siti di AD, come configurereste il servizio ora sul PDCE e sui DC?


    [EDIT:]

     Configurato il PDCE per la sincronizzazione con una sorgente esterna ed ora sembra tutto in ordine. Intanto ho modificato anche la policy di configurazione dei client: Come sorgente ho impostato "miodominio.lan,0x1", Type NT5DS e CrossSiteSyncFlags a 2.

     L'impostazione "miodominio.lan,0x1" dovrebbe restituire come valore l'IP del DC preferenziale per il sito AD, è corretto? Non ho trovato un altro valore che possa risultare equivalente a "domhier". Per ora sembra funzionare, i client risolvono la sorgente oraria con l'IP del DC preferenziale che, in questo caso, è il PDCE. Può andare bene?


    martedì 22 marzo 2011 11:10
  •  Per curiosità e cultura personale: In una situazione con unico dominio e DC controller distribuiti in due siti di AD, come configurereste il servizio ora sul PDCE e sui DC?

    io ho i dc che prendono tutti l'orario da un server ntp esterno però non ho i problemi che indichi tu e non mi sono mai neppure preoccupato di andare a gestire con le policies l'impostazione del servizio orario sui clients (che, a quanto ricordo, si sincronizzano automaticamente con il dc). non ho capito come mai ti sei posto questo problema.
    Edoardo Benussi - Microsoft® MVP
    Management Infrastructure - Systems Administration
    https://mvp.support.microsoft.com/Profile/Benussi
    Windows Server Italian Forum Moderator
    edo[at]mvps[dot]org
    martedì 22 marzo 2011 16:30
    Moderatore
  •  Sì, per quanto riguarda i client effettivamente per impostazione predefinita si dovrebbero sincronizzare con il DC. Tutto è nato probabilmente per una questione di ignoranza, perchè a breve mi troverò a dover mettere un DC in una sede remota e mi sono posto il problema di come gestire diverse cose tra cui anche il servizio orario. Inoltre ho 4/5 sedi minori, tutte collegate a noi in VPN, ed in cui per vari motivi non posso/voglio mettere un server in locale: volevo però cercare di organizzare la struttura creando delle policy ad hoc per ogni sede.

     L'idea di sincronizzare tutti i DC con una sorgente oraria esterna invece che con il solo PDCE quindi non è del tutto assurda, ho probabilmente solo sbagliato il modo di farlo... L'idea di gestire il tutto tramite delle policy anche sui DC è nata per cercare di fare il lavoro una volta, avere le impostazioni di tutte le macchine il più possibile uguali e standardizzate senza dover ripetere a mano su ogni macchina la configurazione. Ma probabilmente ho sbagliato il modo di farlo...

    • Proposto come risposta Alberto Ausenda martedì 6 novembre 2012 10:06
    • Proposta come risposta annullata Alberto Ausenda martedì 6 novembre 2012 10:06
    martedì 22 marzo 2011 17:03