Risoluzione dei problemi relativi alle repliche delle cartelle pubbliche - Parte 4: Suggerimenti per Exchange Server 2007/2010

Articolo originale pubblicato lunedì 28 novembre 2011

Post originale su US blog: 11 gennaio 2008

Due anni fa, ho inserito una serie di tre post sulla risoluzione dei problemi relativi alle repliche delle cartelle pubbliche. Nella parte 1 veniva discussa la replica di nuovi dati, nella parte 2 veniva illustrata la replica di dati esistenti e nella parte 3 venivano presentati il processo di eliminazione delle repliche e alcuni problemi comuni rilevati in Exchange 2003. Con questo post, aggiornerò la serie per Exchange 2007.

In Exchange 2007 la replica delle cartelle pubbliche non presenta fondamentalmente molte differenze rispetto alle versioni precedenti. I passaggi della risoluzione dei problemi illustrati nelle prime tre parti della serie sono applicabili anche a questa versione. Sono stati tuttavia modificati gli strumenti di amministrazione e i problemi comuni rilevati in Exchange 2007 sono leggermente diversi. Questi saranno gli argomenti di questo post.

Modifiche degli strumenti di amministrazione

Il registro eventi è ancora lo strumento migliore per ridurre un problema di replica a un determinato punto di errore. Nella parte 1 suggerivo di attivare la registrazione sulla replica in ingresso e sulla replica in uscita sul valore massimo. Questa soluzione è ancora applicabile, con la differenza che in Exchange 2007 si utilizza il cmdlet Set-EventLogLevel per impostare "MSExchangeIS\9001 Public\Replication Incoming Messages" e "MSExchangeIS\9001 Public\Replication Outgoing Messages" sul livello avanzato.

Nella parte 2, ho descritto come utilizzare le opzioni Sincronizza gerarchia e Sincronizza contenuto in ESM per forzare un messaggio di stato e attivare il timeout di tutte le voci di recupero informazioni in sospeso. Anche in Exchange 2007 è possibile eseguire questa operazione tramite i cmdlet Update-PublicFolderHierarchy e Update-PublicFolder. Questi cmdlet sono anche disponibili nello strumento di gestione della cartella pubblica di SP1, come Aggiorna gerarchia quando è selezionata la radice Cartelle pubbliche e Aggiorna contenuto quando è selezionata una determinata cartella pubblica. Poiché queste opzioni possono essere utilizzate dalla riga di comando, sono molto più flessibili delle opzioni di Exchange 2003. Ad esempio, è più semplice attivare il timeout delle voci di recupero informazioni per ogni cartella che dispone di una replica nel server di Exchange 2007 con un comando "Get-PublicFolderStatistics | Update-PublicFolder". Per ottenere lo stesso risultato in Exchange 2003 sono necessarie più operazioni.

Nella parte 3 ho descritto come utilizzare la visualizzazione delle istanze della cartella pubblica per verificare il completamento dell'eliminazione di una replica. In Exchange 2007 per ottenere tali informazioni si utilizza il comando Get-PublicFolderStatistics.

Problemi comuni in Exchange 2007

Il sintomo più comune finora rilevato è un errore del driver di archivio. Ad esempio, una risposta di recupero informazioni verrà inviata a un server Exchange 2007, ma nel registro applicazioni sul lato 2007 non sarà mai visualizzato l'evento di replica in ingresso. Dalla verifica dei messaggi risulta che il messaggio di replica è arrivato al server trasporto hub, quindi si è verificato un errore nel driver di archivio.

Ciò può essere dovuto a diversi motivi e, fortunatamente, non è particolarmente difficile risolvere questo problema. L'approccio ottimale in questo caso consiste nell'utilizzare le funzionalità di traccia della pipeline e di traccia della conversione del contenuto disponibili nel server trasporto hub. Se si esegue "Get-TransportServer | fl" vengono visualizzate alcune impostazioni correlate:

PipelineTracingEnabled : False
ContentConversionTracingEnabled : False
PipelineTracingPath : C:\Program Files\Microsoft\Exchange Server\TransportRoles\Logs\PipelineTracing
PipelineTracingSenderAddress : SERVER01-IS@contoso.com

Per individuare il motivo per cui la risposta di recupero informazioni ha esito negativo nel driver di archivio, impostare PipelineTracingSenderAddress affinché corrisponda all'indirizzo SMTP dell'archivio cartella pubblica da cui viene inviata la risposta di recupero informazioni. Impostare quindi ContentConversionTracingEnabled su $true e PipelineTracingEnabled su $true e riprodurre il problema. Successivamente, osservare la cartella specificata da PipelineTracingPath. Dovrebbe essere presente una sottocartella denominata ContentConversionTracing al cui interno è contenuta una cartella InboundFailures. Nella cartella InboundFailures sarà presente un file EML contenente il messaggio di replica e un file con estensione TXT contenente alcune informazioni sull'errore. All'inizio del file TXT si troveranno indizi utili relativi al motivo dell'errore.

Ad esempio, in alcuni casi l'output del file TXT sarà simile al seguente:

Microsoft.Exchange.Data.Storage.PropertyValidationException: Convalida della proprietà non riuscita. Proprietà = [{00020329-0000-0000-c000-000000000046}:'Keywords'] Categories
Errore = L'elemento 0 nella proprietà multivalore non è valido.

In questo caso il problema è relativo alla proprietà Categories e si verifica se la cartella pubblica in questione contiene elementi la cui proprietà Categories è impostata come vuota, ad esempio un solo spazio, anziché essere effettivamente vuota. Ciò è verificabile aprendo Outlook e scegliendo di visualizzare gli elementi per categoria. Saranno presenti due diversi set di elementi contenenti "Nessuna". Per correggere il problema, è sufficiente cancellare la categoria in tutti gli elementi contenenti "Nessuna" utilizzando Outlook. Può essere necessario impostarli su un'altra categoria e reimpostarli su Nessuna. Una volta cancellata effettivamente la proprietà Categories, sarà disponibile un solo set di elementi contenenti "Nessuna" e la replica avrà esito positivo.

Un altro esempio:

Microsoft.Exchange.Data.Storage.PropertyValidationException: Convalida della proprietà non riuscita. Proprietà = [{00062004-0000-0000-c000-000000000046}:0x8092] Email2AddrType
Errore = Email2AddrType è troppo lungo. Lunghezza massima consentita: 9, lunghezza effettiva: 35.

In questo caso il problema è dovuto alla proprietà Email2AddrType. Viene rilevato che tale proprietà è stata popolata con l'indirizzo di posta elettronica completo per alcuni contatti, anziché solo con il tipo di indirizzo come dovrebbe, ad esempio 'SMTP' o 'EX'. La correzione della proprietà consente di eseguire la replica degli elementi.

Talvolta si verifica un errore nel driver di archivio, ma non viene individuata una proprietà specifica come problema, come nell'output seguente:

Microsoft.Exchange.Data.Storage.ConversionFailedException: Contenuto del messaggio danneggiato. ---> Microsoft.Exchange.Data.Storage.ConversionFailedException: Impossibile eseguire la conversione. Contenuto TNEF danneggiato (stato di violazione: 0x00000800)

Questo è l'errore visualizzato quando si verifica il problema descritto in KB 936000. L'applicazione della correzione al server Exchange 2003 da cui viene generato il messaggio di replica consente di risolvere il problema.

È importante considerare che in Exchange 2007 viene eseguita la convalida delle proprietà per evitare che dati non validi vengano inseriti nell'archivio. Benché si tratti di una funzionalità utile, può impedire la replica dei dati della cartella pubblica dai server Exchange 2003 finché i problemi di contenuto non vengono corretti nel server 2003. Grazie a ContentConversionTracing è possibile individuare questi problemi e determinare la proprietà esatta che causa il problema.

Con ContentConversionTracing è possibile individuare un altro problema comune, che non è tuttavia causato da un problema relativo al contenuto. Il file TXT nella cartella InboundFailures sarà simile a quanto segue:

Microsoft.Exchange.Data.Storage.ConversionFailedException: Superato il limite della conversione del contenuto.
su Microsoft.Exchange.Data.Storage.InboundMimeConverter.ConvertToItem(MimePromotionFlags promotionFlags)
su Microsoft.Exchange.Data.Storage.ItemConversion.InternalConvertAnyMimeToItem(Item itemOut, EmailMessage messageIn, InboundConversionOptions options, MimePromotionFlags promotionFlags, Boolean isStreamToStream)
su Microsoft.Exchange.Data.Storage.ItemConversion.ConvertAnyMimeToItem(Item itemOut, EmailMessage messageIn, InboundConversionOptions options)

InboundConversionOptions:
- preferredCharset: iso-8859-1
- trustAsciiCharsets: True
- isSenderTrusted: False
- imceaResolveableDomain: contoso.com
- preserveReportBody: False
- clearCategories: True
- userADSession:
- recipientCache: Microsoft.Exchange.Data.Directory.Recipient.ADRecipientCache
- clientSubmittedSecurely: False
- serverSubmittedSecurely: False

ConversionLimits:
- maxMimeTextHeaderLength: 2000
- maxMimeSubjectLength: 255
- maxSize: 2147483647
- maxMimeRecipients: 12288
- maxRecipientPropertyLength: 1000
- maxBodyPartsTotal: 250
- maxEmbeddedMessageDepth: 30
- exemptPFReplicationMessages: True

Si noti che nella riga principale è indicato "Superato il limite della conversione del contenuto". Di solito un messaggio di replica di una cartella pubblica è esente dai limiti delle dimensioni e di altro tipo, pertanto occorre chiedersi per quale motivo si verifica questo errore. Si noti che "isSenderTrusted" è False. Ciò significa che il messaggio è stato inviato su una connessione SMTP non autenticata. L'autenticazione del server di invio ha avuto esito negativo o non è neppure stata tentata. Si tratta di una situazione analoga a quella descritta nella sezione dei problemi comuni della Parte 3, in cui un errore di autenticazione causerebbe l'errore del verbo XEXCH50 in Exchange 2003. Poiché il server di invio non ha effettuato l'autenticazione, i normali limiti delle dimensioni vengono applicati al messaggio dal server Exchange 2007. Se si tratta di un messaggio di replica di contenuto con più di 250 allegati (fatto non inconsueto per una risposta di recupero informazioni di contenuto), l'errore è dovuto al superamento del limite. Ciò accade spesso perché un amministratore ha creato un secondo connettore di ricezione che non consente l'autenticazione, ma lo ha configurato in modo che resti in attesa sull'IP interno anziché sull'IP esterno. Se non è questa la causa, può essere necessario utilizzare un'acquisizione Netmon per identificare il problema, come descritto nella Parte 3.

Conclusione

Questo argomento completa le informazioni necessarie per ridurre i problemi relativi alle repliche delle cartelle pubbliche in un ambiente con Exchange 2007. Tutti gli altri passaggi per la risoluzione dei problemi sono ancora applicabili, ma occorre considerare strumenti di amministrazione diversi e un altro set di problemi.

- Bill Long

Questo è un post di blog localizzato. L'articolo originale è disponibile in Public Folder Replication Troubleshooting – Part 4: Exchange Server 2007/2010 tips