Risoluzione dei problemi relativi alla replica delle cartelle pubbliche – Parte 3: Risoluzione dei problemi comuni e di quelli relativi all'eliminazione di una replica
Articolo originale pubblicato lunedì 28 novembre 2011
Post originale su US blog: 24 gennaio 2006
Terzo post di blog relativo alla risoluzione dei problemi relativi alla replica delle cartelle pubbliche. Nel primo post è stata illustrata la risoluzione dei problemi relativi alla replica delle nuove modifiche. Nel secondo post di blog è stata illustrata la risoluzione dei problemi relativi alla replica di dati esistenti. In questo post verrà illustrata la risoluzione dei problemi comuni e di quelli relativi all'eliminazione di una replica. Per un quadro generale, leggere tutto il materiale di riferimento.
Risoluzione dei problemi relativi all'eliminazione di una replica
È stato rimosso un server non utilizzato dall'elenco di repliche di tutte le cartelle. Tuttavia, quando si accede a istanze della cartella pubblica per l'archivio precedente in ESM, saranno ancora presenti alcune cartelle. Il problema riguarda il processo di eliminazione della replica. Nella versione Exchange 2003 SP2 di ESM, se si tenta di eliminare un archivio pubblico in questo stato, viene visualizzata una finestra di dialogo con il messaggio seguente:
"Non è possibile cancellare questa cartella pubblica poiché contiene repliche di cartelle. Per evitare la perdita di dati, fare clic con il tasto destro sulla cartella pubblica e usare l'opzione per spostare le repliche per spostare le repliche su un server differente. Potrebbero essere necessarie diverse ore per replicare il contenuto sul nuovo server e rimuovere le repliche in locale."
Quando si rimuove un archivio dall'elenco di repliche di una cartella, i dati non vengono eliminati immediatamente, ma a tutte le altre repliche viene inviata una richiesta di stato 0x20 speciale. Questa richiesta, nota come RDPSR (Replica Delete Pending Status Request), non è distinguibile da una normale richiesta di stato nel registro applicazioni. Una RDPSR contiene un flag che indica che la replica è in attesa di essere eliminata. Quando gli altri archivi ricevono questo evento 0x20, rispondono con uno speciale evento 0x10 noto come RDPA (Replica Delete Pending Ack). L'RDPA indica che è possibile procedere all'eliminazione di questi dati, tuttavia gli altri archivi inviano questo evento 0x10 solo se dispongono già di tutti i CN di cui dispone la replica in attesa di eliminazione. La replica verrà eliminata solo dopo che l'archivio avrà ricevuto un evento 0x10 in cui è indicato che altri utenti sono in possesso dei dati.
Ciò significa che se l'archivio viene eliminato prima che le istanze della cartella pubblica siano vuote, è possibile che si verifichi una perdita di dati. Solo 2003 SP2 ESM è in grado di evitare questa situazione: nelle versioni precedenti è necessario verificare manualmente le istanze della cartella pubblica per sapere se è possibile procedere con l'eliminazione dell'archivio. Verificare sempre le istanze della cartella pubblica prima di eliminare un archivio pubblico. Quando in 2003 SP2 ESM viene visualizzato questo avviso, non tentare di ignorarlo o di trovare una soluzione alternativa, cercare invece di risolvere i problemi relativi al processo di eliminazione della replica.
Si noti che prima di Exchange 2003 SP2, il server rimosso dall'elenco di repliche invia una sola volta la richiesta RDPSR. Se non ottiene alcuna risposta, la cartella rimane nella istanze della cartella pubblica per un tempo indefinito, a meno che l'archivio non venga riaggiunto all'elenco di repliche e quindi nuovamente rimosso, causando l'invio di una richiesta RDPSR. 2003 SP2 ha modificato questo comportamento in modo che ogni ora l'archivio effettui un tentativo finché non riceve una richiesta RDPA.
Risoluzione dei problemi
La procedura equivale a quella necessaria per risolvere i problemi relativi al processo di recupero informazioni.
1. La replica in attesa di eliminazione ha inviato un evento 0x20?
Impossibile rispondere a questa domanda se al momento di rimuovere la replica la registrazione non era attivata. Fortunatamente, è possibile aggiungere la replica e rimuoverla. Verificare se nel registro applicazioni compare l'evento 0x20.
2. L'evento 0x20 ha raggiunto le altre repliche?
Ormai si dovrebbe sapere come procedere. Verificare i registri applicazioni delle altre repliche per sapere se hanno ricevuto l'evento 0x20.
3. Altre repliche hanno risposto a un evento 0x10?
Questa è la parte su cui sarà con tutta probabilità necessario concentrarsi. Se una replica ha ricevuto l'evento 0x20 dalla replica in attesa di eliminazione, ma non ha risposto con un evento 0x10, significa che la replica in attesa di eliminazione contiene dati di cui l'altra replica è priva. Poiché si sa che ha appena ricevuto un evento 0x20 da tale replica, si sa anche di quali dati non dispone. Di conseguenza, ci si dovrebbe aspettare una richiesta di recupero informazioni per quella cartella ogni 24-48 ore. Vedere il registro applicazioni e procedere alla risoluzione dei problemi esattamente come per il normale processo di recupero informazioni descritto in precedenza.
4. La replica in attesa di eliminazione ha ricevuto l'evento 0x10?
Quando ogni altra replica dispone di tutti i dati, tale replica dovrebbe rispondere con l'evento 0x10. Quando la replica in attesa di eliminazione riceve l'evento 0x10, i dati vengono eliminati. Ciò non significa tuttavia che accadrà immediatamente. Se la replica è utilizzata da client, i dati verranno eliminati solo in seguito, durante la manutenzione online. Se si desidera, è possibile accelerare questo processo smontando e montando l'archivio per disconnettere i client.
Problemi comuni
È possibile che da un server sia stato inviato un qualche tipo di messaggio di replica a un altro server, ma che nel server ricevente il messaggio in arrivo non sia mai stato registrato nel registro applicazioni. Tuttavia, secondo la verifica il messaggio è stato recapitato localmente all'archivio in quel server. Questo comportamento indica in genere un problema con la tabella Replication State o con le autorizzazioni nel server virtuale SMTP.
Se un messaggio di replica in arrivo viene ignorato dal server ricevente, si è verificato un problema con la tabella relativa allo stato della replica o ReplState. Un problema con la tabella ReplState potrebbe anche impedire al server di emettere richieste di recupero informazioni (0x8) per alcune cartelle, pertanto queste informazioni riguardano anche a questa situazione. In ogni archivio pubblico la tabella ReplState viene utilizzata per tenere traccia dello stato della replica di tutte le cartelle replicate. La tabella contiene più righe per ogni cartella, una per replica. È possibile che le righe della tabella ReplState perdano la sincronizzazione con l'elenco di repliche e che quindi il numero di righe non corrisponda più. Talvolta, per riacquisire la sincronizzazione è sufficiente apportare una modifica, ad esempio rimuovere un server dall'elenco di repliche, applicare la modifica, quindi riaggiungerlo nuovamente all'elenco, ma questa soluzione non sempre funziona. Fortunatamente, è stato aggiunto un test ReplState a isinteg. Vedere KB889331 per Exchange 2003 o KB892485 per Exchange 2000. Purché isinteg.exe e store.exe siano i più aggiornati, è possibile utilizzare isinteg per correggere il problema con la tabella ReplState. Se si effettua solo il test ReplState, la procedura è molto veloce, meno di un minuto anche su un archivio pubblico di grandi dimensioni. Dopo avere eseguito isinteg, potrebbe ancora essere necessario tornare indietro e apportare una modifica alla cartella in modo che la tabella ReplState venga sincronizzata con l'elenco di repliche. Una volta riacquisita la sincronizzazione, il server dovrebbe essere in grado di elaborare i messaggi di replica in ingresso o di emettere normalmente le richieste di recupero informazioni.
L'altro problema comune a causa del quale un messaggio di replica in arrivo viene ignorato riguarda in modo specifico Exchange 2003. Un server di Exchange 2003 richiede che il server di invio disponga del diritto Invia come per il server virtuale SMTP ricevente. Questo significa che se il serverA è un server di Exchange 2003 e il serverB invia un messaggio di replica PF al serverA, il serverB deve disporre del diritto Invia come per il server virtuale SMTP del serverA. In caso contrario, il messaggio di replica in ingresso non verrà elaborato dal serverA. Questa autorizzazione viene in genere concessa attraverso i gruppi Exchange Domain Servers. Se il problema risiede nel diritto Invia come, tutti i messaggi di replica in ingresso da un determinato server avranno esito negativo. Il problema può essere facilmente identificato tramite una traccia di rete acquisita nel corso del trasferimento di un messaggio di replica da un server a un altro. La conversazione dovrebbe essere simile alla seguente:
ServerA: 220 ServerA.microsoft.com Microsoft ESMTP MAIL Service...
ServerB: EHLO ServerB.microsoft.com
ServerA: 250-ServerA.microsoft.com Hello
250-TURN
250-SIZE
250-ETRN
250-PIPELINE
250-DSN
250-ENHANCEDSTATUSCODES
250-8bitmime
250-BINARYMIME
250-CHUNKING
250-VRFY
250-X-EXPS GSSAPI NTLM LOGIN
250-X-EXPS=LOGIN
250-AUTH GSSAPI NTLM LOGIN
250-AUTH=LOGIN
250-X-LINK2STATE
250-X-EXCH50
250 OK
L'elemento importante è che nel serverA devono essere visualizzati gli avvisi relativi alle opzioni GSSAPI NTLM LOGIN. Se nella risposta a EHLO del serverA questi avvisi non sono visibili, è possibile che l'Autenticazione integrata di Windows sia stata deselezionata nel server virtuale SMTP. Questa situazione è riportata nel passaggio 1 di KB843106 e nel passaggio 3 di KB842273. Purché questi verbi di autenticazione siano presenti, il serverB dovrebbe tentare di utilizzarli:
ServerB: X-EXPS GSSAPI
ServerA: 334 GSSAPI supported
ServerB: <a bunch of base64 encoded data>
ServerA: 334 <more base64 encoded stuff>
ServerB: CRLF
ServerA: 235 2.7.0 Authentication successful.
Se l'autenticazione non viene effettuata, è possibile che si sia verificato un problema con kerberos o con l'account computer per il serverB. A questo punto, i server trasmetteranno le informazioni sullo stato del collegamento, dopodiché procederanno al trasferimento della posta elettronica:
ServerB: MAIL FROM:<ServerB-IS@microsoft.com>
ServerA: 250 2.1.0 ServerB-IS@microsoft.com....Sender OK
ServerB: RCPT TO:<ServerA-IS@microsoft.com> NOTIFY=NEVER
ServerA: 250 2.1.5 ServerA-IS@microsoft.com
ServerB: XEXCH50 2404 2
ServerA: 354 Send binary data
È quest'ultima risposta al verbo XEXCH50 a essere importante. Se la risposta è "354 Send binary data", tutto procede bene, almeno per quanto riguarda le autorizzazioni al server virtuale SMTP. Se gli avvisi relativi alle opzioni GSSAPI NTLM LOGIN non sono stati visualizzati o se il tentativo di autenticazione non è riuscito, si prevede che il serverA risponderà con "504 Need to authenticate". Se invece questi passaggi vengono effettuati correttamente, ma la risposta del serverA è ancora "504 Need to authenticate" anziché "354 Send binary data", il serverB non dispone del diritto Invia come per il server virtuale SMTP del serverA. Questa situazione può avere diverse cause. Quando si delegano diritti quali Amministratore completo di Exchange in ESM, quell'utente o gruppo eredita un rifiuto per il diritto Invia come. Di conseguenza, l'utilizzo di ESM per delegare i diritti di amministrazione all'account computer, il gruppo Exchange Domain Servers o altri gruppi che contengono i server di Exchange comporta l'interruzione della replica della cartella pubblica. Un'altra possibilità è che l'account computer non si trovi nel gruppo Exchange Domain Servers, attraverso il quale ottiene in genere il diritto Invia come. Sarà necessario valutare le autorizzazioni per il server virtuale SMTP e determinare perché l'account computer per il server di invio non dispone dei diritti appropriati. Per ulteriori dettagli sul problema "504 Need to authenticate", vedere KB843106 e KB842273.
Conclusione
Leggendo questo documento appare chiaro che SP2 per Exchange 2003 contiene importanti miglioramenti per impedire che si verifichino problemi di replica e per migliorarne la risoluzione. SP2 comporta grandi vantaggi per gli ambienti caratterizzati da più archivi pubblici, in particolar modo nell'ambito dello spostamento di repliche tra server, nonché dell'aggiunta e della rimozione di archivi pubblici.
Spero di essere stato utile. Grazie a Dave Whitney per la sua revisione.
Questo è un post di blog localizzato. L'articolo originale è disponibile in Public Folder Replication Troubleshooting – Part 3: Troubleshooting Replica Deletion and Common Problems