Risoluzione dei problemi relativi alla replica della cartella pubblica – Parte 1: Risoluzione dei problemi relativi alla replica delle nuove modifiche

Articolo originale pubblicato lunedì 28 novembre 2011

Post originale su US blog: 17 gennaio 2006

Nota: questo post di blog è il primo di una serie sulla risoluzione dei problemi relativi alla cartella pubblica. Consultare anche le parti 2, 3 e 4 della serie.

Introduzione

Questa serie di post di blog si propone di fornire una guida alla risoluzione dei problemi relativi alla replica delle cartelle pubbliche. Sebbene non vengano affrontati tutti i possibili problemi di replica, viene spiegato come isolarli in modo da poter concentrare l'attenzione sul punto di errore. In altre parole, non viene più fornita una descrizione del problema del tipo "Impossibile replicare il contenuto del vecchio server al nuovo", ma una descrizione più dettagliata come "Il vecchio server non risponde alle richieste di stato inviate dal nuovo server, pertanto non è possibile sapere se mancano dati nel nuovo server in cui non viene effettuato alcun tentativo di recupero informazioni. Ciò significa che il problema riguarda il vecchio server." In questo post viene inoltre descritto come identificare alcuni dei problemi di replica più comuni. Prima di entrare nei dettagli della risoluzione dei problemi, verranno fornite informazioni generali sull'approccio adottato per questo tipo di problemi.

Il miglior strumento per la risoluzione dei problemi relativi alla replica della cartella pubblica è il registro applicazioni. Per isolare un problema di replica, è necessario essere in grado di seguire gli eventi di replica nel registro per risalire al punto esatto in cui il processo è stato interrotto. Prima di avviare la risoluzione dei problemi, è in genere consigliabile impostare la registrazione diagnostica sulla replica in ingresso e replica in uscita sul valore massimo. Ogni volta che dal servizio di archiviazione viene inviato o ricevuto un messaggio di replica, viene registrato un evento (purché la registrazione sia attivata). I diversi messaggi di replica sono distinguibili in base al 'Tipo' mostrato nella descrizione dell'evento. È preferibile concentrarsi sul Tipo anziché sull'ID evento per i motivi seguenti:

- Gli ID evento cambiano da una versione di Exchange a un'altra. In Exchange 5.5, ad esempio, una richiesta di recupero informazioni in uscita presentava l'ID 3014. In Exchange 2000 e 2003 l'ID è invece 3016.

- Gli ID evento in ingresso e in uscita cambiano per ogni tipo. L'ID di un messaggio di gerarchia in uscita è 3018, mentre quello di un messaggio in ingresso è 3028.

- Le richieste di stato e i messaggi di stato utilizzano gli stessi ID evento, anche se si tratta di tipi diversi di messaggi. Di conseguenza, non è possibile fare distinzione tra di essi solo in base all'ID evento.

Concentrarsi sul tipo implica quindi un minor numero di difficoltà. I tipi possono infatti essere messi in correlazione più facilmente agli ID evento esaminando il registro applicazioni. Esistono solo 7 tipi ed è possibile verificare se il messaggio è in ingresso o in uscita facendo riferimento alla Categoria dell'evento. Se ci si concentra sui tipi anziché sugli ID evento, è sufficiente ricordare i dati seguenti:

Gerarchia - 0x2

Contenuto - 0x4

Richiesta di recupero informazioni - 0x8

Risposta di recupero informazioni - 0x80000002 (per gerarchia) o 0x80000004 (per contenuto)

Stato - 0x10

Richiesta di stato - 0x20

Si noti inoltre che la registrazione degli errori di replica raramente si rivela utile. Anche quando la replica funziona regolarmente, nella maggior parte dei server vengono generati molti eventi di errore di replica, ad esempio l'ID evento 3093 che indica che si è verificato un errore durante la lettura di una proprietà. Nella maggior parte dei casi, la proprietà non ha alcun effetto sulla replica e l'errore può essere ignorato. È consigliabile lasciare impostata la registrazione degli errori di replica su Nessuna, a meno che non si cerchi un evento specifico, ad esempio il problema descritto in questo post di blog precedente.

Risoluzione dei problemi relativi alla replica delle nuove modifiche

Per risolvere i problemi relativi alla replica delle cartelle pubbliche, è necessario acquisire familiarità con il normale flusso messaggi previsto durante l'esecuzione della replica. In questo modo, sarà possibile identificare il punto di errore ogni volta che si verifica un problema. Prima di illustrare la risoluzione dei problemi relativi alla replica delle nuove modifiche, verrà descritto il comportamento previsto.

Replica della gerarchia

La replica delle modifiche apportate alla gerarchia viene eseguita ogni volta che viene creata o eliminata una cartella o che viene apportata una modifica alle proprietà di una cartella pubblica, ad esempio l'elenco di repliche, le autorizzazioni client, la descrizione, la nota amministrativa o i limiti dello spazio di archiviazione. Non sono inclusi gli indirizzi di posta elettronica in una cartella che supporta la posta elettronica. Gli indirizzi di posta elettronica sono archiviati nell'oggetto directory in Active Directory, pertanto la loro modifica non comporta la replica della gerarchia. Solo la modifica delle proprietà archiviate nell'archivio pubblico comporta la replica della gerarchia.

Ogni 15 minuti (impostazione predefinita), eventuali modifiche apportate alle proprietà della cartella vengono trasmesse in uno o più messaggi di replica della gerarchia. Con la registrazione impostata sul valore massimo in replica in uscita, un evento simile a questo verrà visualizzato nel server in cui è stata modificata la gerarchia:

Tipo di evento: Informazioni

Origine evento:     MSExchangeIS Archivio pubblico

Categoria evento:   Messaggi di replica in uscita

ID evento:   3018

Descrizione:

È stato emesso un messaggio di replica in uscita.

Tipo: 0x2

ID messaggio: <91ACCD0758385549A56A10971798985572D5@bilongexch1.bilong.test>

Database "Primo gruppo di archiviazione\Archivio cartella pubblica (BILONGEXCH1)"

CN min: 1-72CF, CN max: 1-72D3

RFIs: 1

1) FID: 1-6994, PFID: 1-1, Offset: 28

      IPM_SUBTREE\NewFolder

Si noti il "Tipo: 0x2" all'inizio della descrizione che lo identifica come un messaggio di replica della gerarchia.

Un messaggio di replica della gerarchia viene inviato dal server di origine direttamente a tutti gli altri archivi pubblici. Non esiste alcun concetto di topologia per la replica delle nuove modifiche. Tutte le modifiche alla gerarchia vengono inviate direttamente dal server in cui sono state apportate le modifiche a tutti gli altri server per i quali un archivio pubblico è associato alla stessa gerarchia. In ogni altro server viene registrato un evento in ingresso del tipo 0x2 quando il messaggio di replica in ingresso viene elaborato correttamente.

Replica del contenuto

La replica del contenuto viene eseguita ogni volta che viene creato o eliminato un messaggio o che ne vengono modificate le proprietà. È possibile modificare gli orari in cui le modifiche del contenuto vengono trasmesse per una cartella modificando la pianificazione della replica per quella cartella, tuttavia per impostazione predefinita le modifiche verranno trasmesse ogni 15 minuti proprio come la gerarchia. Un messaggio di replica del contenuto è identificabile grazie al tipo 0x4 nella descrizione dell'evento. Anche in questo caso non esiste alcun concetto di topologia per la trasmissione delle nuove modifiche. Quando il contenuto di una cartella viene modificato in una replica, un messaggio 0x4 viene inviato direttamente a tutte le altre repliche della cartella. Di nuovo, in ogni server ricevente viene registrato un evento 0x4 in ingresso quando il messaggio in ingresso viene elaborato correttamente.

Passaggi della procedura di risoluzione dei problemi

Si tratta dei due scenari di replica più comuni. Quando le nuove modifiche alla gerarchia o al contenuto non vengono replicate da un server a un altro, la risoluzione dei problemi è molto semplice.

1. Nel server è stato generato un messaggio di replica in uscita?

È stata apportata una modifica a una cartella o è stato aggiunto del contenuto a una cartella in un server, ma tali modifiche non vengono replicate in altri server. Prima di tutto è necessario chiedersi se il server ha trasmesso le modifiche. Durante la risoluzione dei problemi, è importante tenere traccia del server con il quale si lavora quando si apportano modifiche. A tale scopo, è possibile procedere in diversi modi. In ESM è possibile fare clic con il pulsante destro del mouse sul nodo Cartelle pubbliche e scegliere "Connetti a" un archivio particolare. Nella maggior parte dei casi le modifiche vengono apportate nell'archivio specificato, con una eccezione: le autorizzazioni client. Prima di Exchange 2003 SP2, quando le autorizzazioni client venivano modificate attraverso ESM, la modifica veniva apportata in un archivio che ospitava una replica della cartella, anche se non era necessario poiché le autorizzazioni sono archiviate come proprietà della cartella nella gerarchia. Con la versione 2003 SP2 di ESM, la modifica viene apportata nella gerarchia a cui viene fatto riferimento. Quando si testa la replica della gerarchia apportando modifiche attraverso ESM, evitare di utilizzare le autorizzazioni per il testing poiché potrebbe essere difficile prevedere in quale archivio verrà apportata la modifica, a meno che ESM non sia eseguito da 2003 SP2. Se si utilizza Outlook e si desidera verificare a quale replica di una cartella si fa riferimento, è possibile utilizzare MFCMAPI o uno strumento simile per visualizzare la proprietà PR_REPLICA_SERVER della cartella. Verrà visualizzato il nome del server utilizzato da Outlook per accedere al contenuto di quella cartella.

Se la pianificazione della replica è impostata su Sempre per la cartella in questione (che è sempre vero per la gerarchia) e non viene visualizzato alcun messaggio in uscita 0x2 o 0x4 entro 15 minuti, si è verificato un errore nel server di origine. Se nel server non viene generata alcuna trasmissione di contenuto o gerarchia in uscita, è possibile che l'agente di replica non sia stato avviato. Uno degli scenari comuni viene descritto in KB272999. L'elemento importante da notare in questo caso è l'evento 3079:

ID evento: 3079

Origine: MSExchangeIS Public

Tipo: Errore

Categoria: Errori di replica

Descrizione:

Errore thread di replica imprevisto 0x3f0.

EcGetReplMsg

EcReplStartup

FReplAgent

Questo evento verrà registrato anche se la registrazione aggiuntiva non viene attivata quando si monta l'archivio pubblico. Se 3079 include la funzione "EcReplStartup", l'agente di replica non è stato avviato e nessuna nuova modifica verrà trasmessa finché il problema non verrà risolto e l'archivio non verrà nuovamente montato.

La replica della gerarchia è vulnerabile anche ad alcuni problemi correlati alle autorizzazioni se nell'organizzazione sono presenti archivi pubblici di Exchange 5.5. Quando un server di Exchange 2000 o 2003 invia un messaggio di replica della gerarchia a un server di Exchange 5.5, deve produrre una proprietà ptagACLData (autorizzazioni in stile 5.5 basate su legacyExchangeDN) dalla proprietà ptagNTSD (autorizzazioni in stile 2000 basate su SID). Ciò significa che ogni SID deve essere convertito in legacyExchangeDN. Questa conversione potrebbe però non riuscire per diversi motivi. Ad esempio, se un SID viene risolto in più di un utente, è possibile che venga generato un evento di questo tipo:

ID evento: 9528

Categoria: Generale

Origine: MSExchangeIS

Tipo: Errore

Descrizione:

Trovato il SID S-1-5-21-408248388-469072634-37170099-1391 per 2 utenti nel servizio directory, pertanto l'archivio non è in grado di eseguire il mapping di questo SID a un utente univoco.

Gli utenti interessati sono:

/DC=com/DC=company/CN=Users/CN=User1

/DC=com/DC=company/CN=Users/CN=User2

Poiché il SID non può essere convertito in legacyExchangeDN, non verrà generato alcun messaggio trasmesso della gerarchia in uscita.

2. Il messaggio è stato indirizzato al server che non ha ricevuto la modifica?

Se il messaggio in uscita è stato generato dal server di origine, il passaggio successivo consiste nell'assicurarsi che sia stato indirizzato al server che non ha ricevuto i dati. Il modo più semplice di effettuare questa verifica è tenere traccia del messaggio. Ai fini di questa verifica è sufficiente tenere traccia dell'ID messaggio indicato nell'evento di replica in uscita. Nella finestra Cronologia messaggi è visibile la riga A:. Se l'archivio che non ha ricevuto le modifiche non figura nell'elenco, il problema risiede con tutta probabilità nel server di origine. Porsi pertanto le seguenti domande: Questo server è visibile all'interno dell'organizzazione? Dispone di indirizzi di posta elettronica nel relativo oggetto archivio pubblico? L'archivio è visibile nell'elenco di repliche per la cartella in questione?

3. Il messaggio è giunto al server di destinazione?

Dopo avere verificato che il messaggio è stato indirizzato al server di destinazione, la domanda successiva è la seguente: il messaggio è giunto al server di destinazione? Per rispondere a questa domanda, eseguire una verifica messaggi. Se il messaggio è stato recapitato nell'archivio, ma nessun evento di replica in ingresso conferma il messaggio, vedere la sezione "Problemi comuni" nell'ultimo post di questa serie.

Nel post di blog successivo: Risoluzione dei problemi relativi alla replica di dati esistenti.

- Bill Long

Questo è un post di blog localizzato. L'articolo originale è disponibile in Public Folder Replication Troubleshooting – Part 1: Troubleshooting the Replication of New Changes