none
Errore NETLOGON id 5719 + ID 7031 servizio Archivio informazioni di Exchange arrestato in modo imprevisto RRS feed

  • Domanda

  • Salve a tutti,

    ho un' infrastruttura così configurata:

    Su un host esx risiede una Virtual Machine Win 2008R2 con ruolo di DC e su un altro host fisico due VM sempre S.O. win2008 R2 di cui una è il secondo DC e l'altra Un Server Exchange 2010 SP3.

    Dopo quasi un anno di attività funzionale è qualche settimana che sul server Exchange compaiono i due messagi d' errore riportati nel titolo ( ID 5719 e ID 7031 ). Il server Exchange termina i servizi e smette di funzionare per diversi minuti per poi ripristinarsi automaticamente nella migliore delle ipotesi o a volte bisogna eseguire anche diversi riavvia prima del ripristino delle attività.

    Da un'analisi fatta abbiamo evidenziato che potrebbe essere un problema di sincronizzazione tra i vari server in oggetto in quanto gli orari degli host esx erano sfasati di circa 15 minuti.

    Se qualcuno ha già riscontrato un problema simile vorrei sapere se con la configurazione di un time-server si potrebbe risolvere la questione ed in piu' vorrei avere principalmente una conferma:

    il time- server era uno dei requisiti al momento dell'installazione iniziale?

    Per ora tutti gli orari dei server sono stati impostati manualmente.

    Grazie mille anticipatamente.

    Saluti 

    giovedì 19 febbraio 2015 10:16

Risposte

  • Ciao,

    Tratto da http://www.vmware.com/files/pdf/solutions/Virtualizing-Active-Directory-Domain-Services-on-VMware-vSphere.pdf

    By default, domain-joined Windows systems use the domain hierarchy for time keeping. In virtual machines, this setup might conflict with VMware Tools periodic clock synchronization. The result is two time services, one pointing to a reliable time source, the other pointing to a non-reliable time source, thereby updating the time to inaccurate values. For this reason, the recommendation is to standardize on one tool. For domain-joined Windows machines, the Windows Time Service is the preferred method.

    Per tradurre in breve: Imposta le macchine virtuali per non sincronizzare il loro orologio con la macchina host.
    Il prerequisito era questo. Non il time server.

    Se gli orologi degli host si sfasano così tanto e così in fretta, c'è qualcosa che non va.

    Ciao
    Gabriele


    -- Gabriele Tansini [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights"

    giovedì 19 febbraio 2015 12:26

Tutte le risposte

  • Ciao,

    Tratto da http://www.vmware.com/files/pdf/solutions/Virtualizing-Active-Directory-Domain-Services-on-VMware-vSphere.pdf

    By default, domain-joined Windows systems use the domain hierarchy for time keeping. In virtual machines, this setup might conflict with VMware Tools periodic clock synchronization. The result is two time services, one pointing to a reliable time source, the other pointing to a non-reliable time source, thereby updating the time to inaccurate values. For this reason, the recommendation is to standardize on one tool. For domain-joined Windows machines, the Windows Time Service is the preferred method.

    Per tradurre in breve: Imposta le macchine virtuali per non sincronizzare il loro orologio con la macchina host.
    Il prerequisito era questo. Non il time server.

    Se gli orologi degli host si sfasano così tanto e così in fretta, c'è qualcosa che non va.

    Ciao
    Gabriele


    -- Gabriele Tansini [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights"

    giovedì 19 febbraio 2015 12:26
  • Ho avuto anche io la problematica simile su dei DC, aggiungo al consiglio di Gabriele, che, basta sincronizzare i tuoi esx con lo stesso NTP time server. Siccome le macchine prendono le impostazioni da esx (se non le deflagghi), per quel che mi riguarda preferisco avere 2 esx sincronizzati sullo stesso NTP in modo che le macchine prendono per forza tutte lo stesso orario piuttosto che disattivarlo e far synchare le VM tutte su time...se ne hai anche solo 3 con 2 esx hai un punto di sync in meno...se hai 5-6 vm sulle strutture...be'...hai già capito. Le soluzioni sono entrambe valide, ma la mia preferenza è quella di far sincronizzare l'hypervisor così le VM sono obbligate a prendersi quell'orario...visti i continui problemi dei sync di windows sulle ore in generale.

    Ciao.

    A.

    giovedì 19 febbraio 2015 13:10
    Moderatore
  • Grazie per le risposte tempestive.

    siccome il problema è sorto con il server Exchange vorrei meglio capire ,ed avere conferma , che esso non dipende nello specifico dal servizio di Exchange ma sarrebbe sorto anche con altri Server aventi servizi differenti basati su AD.

    Oppure ci sono incompatibilità di sorta o problemi noti tra la sincronizzazione di Exchange con il DC?

    Grazie


    giovedì 19 febbraio 2015 14:16
  • Ciao Alessandro,

    purtroppo il mio non è un consiglio. E' così che si deve fare per essere supportati (da VMWare e da Microsoft).

    Ecco un esempio che mi è molto caro :-)

    Devi scendere da un grattacielo. Ingegneri, architetti, muratori, etc... ti dicono che l'unico modo per farlo è usare l'ascensore. Dopo averci pensato su, deciditi di buttarti dal tetto alla faccia del parere di tutti quelli che hanno costruito il palazzo. Non solo arriverai a terra, farai anche più velocemente dell'ascensore. Questo ti rende più furbo ?

    Morale: Continuo sempre a non capire come mai la gente si ostina a non seguire le best practices (di ben 2 vendor separati in questo caso) per fare le sue.

    Ciao
    Gabriele


    -- Gabriele Tansini [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights"

    giovedì 19 febbraio 2015 14:46
  • Ciao,

    L'errore 5719 è generato da Netlogon. Un servizio che è presente su qualsiasi macchina Windows (con o senza Exchange)

    L'evento 7031 indica un servizio terminato in maniera inaspettata (in questo caso è Exchange ma potrebbe anche essere il server di Quake per quello che vale per il S.O.)

    Direi che questo vale come conferma che l'unica sfortuna/coinvolgimento di Exchange è che è il fatidico uccellino nella miniera di qualsiasi infrastruttura AD. :-(

    Exchange non si sincronizza con i DC.

    Per funzionare correttamente, Exchange passa il suo tempo a fare query LDAP al DC (che gli dovrebbe rispondere :-))

    Se le richieste falliscono per qualsiasi motivo il servizio di ferma con un generico evento 7031 (anche se probabilmente il servizio MS Exchange AD Access si è segnato qualcosa).

    I DC rispondono alle query LDAP solo dopo che il richiedente si è autenticato.
    Quando Exchange manda le query, chi si autentica è il computer.
    Il protocollo di autenticazione usato è Kerberos.
    Kerberos non funziona se la differenza di orario tra DC e qualsiasi computer è superiore a 15 minuti.
    Se Kerberos non funziona, la macchina non si autentica, la query fallisce, Exchange alza le mani e si ferma.

    Morale/Root Cause Analysis: Il problema è la differenza d'orario tra i server. Se la differenza di tempo tra DC e un computer è superiore a 15 minuti, qualunque richiesta da quel pc al DC non sarà valida. A malapena riuscirai a farci logon (a meno che il profilo non sia già in cache), figuriamoci far funzionare Exchange.

    I membri di un Dominio usano come sorgente autoritativa per l'ora il DC con FSMO role PDC emulator. C'è un motivo se da 15 anni a questa parte (ben prima della virtualizzazione) si consiglia di far puntare a un time server solo il PDC emulator e lasciare che il resto del Dominio si sincronizzi con lui invece di far puntare tutte le macchine a un time server esterno.

    Ciao
    Gabriele


    -- Gabriele Tansini [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights"

    giovedì 19 febbraio 2015 15:10
  • presumo che sia perchè spesso le best practise non vengono nemmeno lette il più delle volte :-) Ad ogni modo la mia era un'integrazione, in effetti gli amici VmWare sono un po ambigui...a che serve mettere un sync NTP server sull'hypervisor se poi devi disabilitarlo se usi sistemi MS? Solo per linux e similari? Va però considerato che noi viviamo dall'altra parte della "barricata" del vendor e ci sono tante cose che funzionano senza dover per forza seguire le linee guida che purtroppo il più delle volte a causa di mancanza di risorse devono essere ignorate, a volte per scendere dal palazzo c'è anche la terza soluzione: un paracadute :-)  certo poi se non siamo in grado di aprirlo allora è meglio usare l'ascensore. :-)

    Buon lavoro a tutti.

    A.

    giovedì 19 febbraio 2015 16:01
    Moderatore