Resolução de problemas de replicação de pasta pública - Parte 4: Dicas do Exchange Server 2007/2010
Artigo original publicado na segunda-feira, 28 de novembro de 2011
Publicação original no blog dos Estados Unidos: 11 de janeiro de 2008
Dois anos atrás, eu publiquei uma série de três partes sobre a resolução de problemas de replicação de pasta pública. A Parte 1 discutiu a replicação de novos dados, a Parte 2 discutiu a replicação de dados existentes e a Parte 3 discutiu o processo de exclusão de réplica e alguns problemas comuns que vemos com o Exchange 2003. Com esta publicação, desejo atualizar a série para o Exchange 2007.
No Exchange 2007, a replicação de pasta pública funciona basicamente da mesma forma de sempre. As etapas de resolução de problemas nas primeiras três partes da série ainda se aplicam. No entanto, as ferramentas de administração mudaram, e os problemas comuns que vemos com o Exchange 2007 são um pouco diferentes, e é isto que desejo cobrir aqui.
Mudanças nas ferramentas administrativas
O log de evento ainda é a melhor ferramenta para diminuir um problema de replicação para um determinado ponto de falha. Na Parte 1, eu sugeri ativar o registro de log da Replicação de entrada e Replicação de saída ao Máximo. Isso ainda se aplica, exceto que, com o Exchange 2007, você estará usando o cmdlet Set-EventLogLevel para definir o "MSExchangeIS\9001 Public\Replication Incoming Messages" e o "MSExchangeIS\9001 Public\Replication Outgoing Messages" para o nível Expert.
Na Parte 2, eu descrevi como usar as opções Sincronizar hierarquia e Sincronizar conteúdo no ESM para forçar uma mensagem de status e para o tempo limite de todas as entradas de aterramento pendentes. Você ainda pode fazer isso no Exchange 2007 através dos cmdlets Update-PublicFolderHierarchy e Update-PublicFolder. Eles também estão disponíveis na ferramenta de gerenciamento de pasta pública do Sp1, exibidos como Atualizar hierarquia, quando a raiz das pastas públicas é selecionada, e como Atualizar conteúdo, quando uma determinada pasta pública é selecionada. Como você pode usá-los na linha de comando, eles são muito mais flexíveis do que as opções do Exchange 2003. Por exemplo, agora é muito simples definir o tempo limite das entradas de aterramento para cada pasta que possua uma réplica no seu servidor do Exchange 2007 com um simples comando "Get-PublicFolderStatistics | Update-PublicFolder". Isso não era possível no Exchange 2003 sem muitos cliques.
Na Parte 3, eu descrevi como usar a exibição de Pasta pública para ver se a exclusão de uma réplica tinha sido concluída. No Exchange 2007, você usa o comando Get-PublicFolderStatistics para ver a mesma informação.
Problemas comuns no Exchange 2007
O sintoma mais comum que eu vi até agora é uma falha na unidade de armazenamento. Por exemplo, uma resposta de aterramento será enviada para um servidor Exchange 2007, mas se você olhar o log de aplicativo no lado do 2007, você nunca verá o evento de replicação de entrada. O rastreamento de mensagem mostra que a mensagem de replicação chegou ao servidor de transporte do hub e falhou na unidade de armazenamento.
Isso pode ocorrer por vários motivos e, felizmente, não é difícil de resolver. Sua melhor abordagem de resolução de problemas nesse caso é usar o Rastreamento de pipeline e o Rastreamento de conversão de conteúdo disponíveis no servidor de transporte de hub. Se você executar o "Get-TransportServer | fl", você verá algumas configurações relacionadas a isso:
PipelineTracingEnabled : False
ContentConversionTracingEnabled : False
PipelineTracingPath : C:\Program Files\Microsoft\Exchange Server\TransportRoles\Logs\PipelineTracing
PipelineTracingSenderAddress : SERVER01-IS@contoso.com
Para descobrir porque sua resposta de aterramento está falhando na unidade de armazenamento, defina o PipelineTracingSenderAddress para corresponder ao endereço SMTP do armazenamento de pasta pública que está enviando a resposta de aterramento. Defina o ContentConversionTracingEnabled para $true e o PipelineTracingEnabled para $true e reproduza o problema. Depois disso, dê uma olhada na pasta especificada pelo PipelineTracingPath. Você deve encontrar uma subpasta chamada ContentConversionTracing e a pasta InboundFailures dentro dela. Na pasta InboundFailures, haverá um arquivo EML contendo a própria mensagem de replicação e um arquivo TXT contendo algumas informações sobre a falha. O início do arquivo TXT frequentemente fornecerá uma dica útil sobre o motivo da falha.
Por exemplo, em alguns casos nós vemos este resultado no arquivo TXT:
Microsoft.Exchange.Data.Storage.PropertyValidationException: Property validation failed. Property = [{00020329-0000-0000-c000-000000000046}:'Keywords'] Categories
Error = Element 0 in the multivalue property is invalid..
Nesse caso, está reclamando sobre a propriedade Categorias. Isso ocorrerá se a pasta pública em questão contiver itens nos quais a propriedade Categoria estiver definida para vazio - como com um espaço único - em vez de realmente estar vazio. Você pode ver isso entrando no Outlook e escolhendo exibir os itens por Categoria. Você deve descobrir que há dois conjuntos diferentes de itens com "Nenhum". Para corrigir o problema, simplesmente limpe a Categoria em todos os itens "Nenhum" usando o Outlook. Você pode precisar defini-los como alguma outra categoria e defini-los novamente para Nenhum. Quando a propriedade Categorias estiver realmente limpa, você precisará apenas definir os itens que exibem "Nenhum", e então os itens irão replicar com êxito.
Outro exemplo:
Microsoft.Exchange.Data.Storage.PropertyValidationException: Property validation failed. Property = [{00062004-0000-0000-c000-000000000046}:0x8092] Email2AddrType
Error = Email2AddrType is too long: maximum length is 9, actual length is 35..
Nesse caso, a propriedade Email2AddrType está sinalizada como um problema. Nós descobrimos que ela foi preenchida, de alguma forma, com o endereço de email completo em determinados contatos, em vez de conter apenas o tipo de endereço que deveria, como 'SMTP' ou 'EX'. Corrigir essa propriedade permite que os itens sejam replicados.
Algumas vezes, a unidade de armazenamento falhará de uma forma que não identifica uma propriedade específica com problema, como neste produto:
Microsoft.Exchange.Data.Storage.ConversionFailedException: Message content has become corrupted. ---> Microsoft.Exchange.Data.Storage.ConversionFailedException: Content conversion failed due to corrupt TNEF (violation status: 0x00000800)
A falha parece assim quando você atinge o problema descrito no KB 936000. Aplicar a correção no servidor do Exchange 2003 que está gerando a mensagem de replicação irá corrigir esse problema.
O mais importante a se tirar disso é que o Exchange 2007 realiza muitas validações de propriedade para evitar que os dados ruins cheguem ao armazenamento. Embora isso seja uma coisa boa, pode evitar que os dados da pasta pública sejam replicados nos seus servidores do Exchange 2003 até que os problemas com o conteúdo sejam corrigidos no servidor 2003. O ContentConversionTracing pode ajudar a identificar esses problemas e frequentemente apontará para a propriedade exata que está causando o problema.
Há um outro problema comum que você pode identificar com o ContentConversionTracing, mas não é causado por um problema real com o conteúdo. O arquivo TXT na pasta InboundFailures irá se parecer com isso:
Microsoft.Exchange.Data.Storage.ConversionFailedException: The content conversion limit has been exceeded.
at Microsoft.Exchange.Data.Storage.InboundMimeConverter.ConvertToItem(MimePromotionFlags promotionFlags)
at Microsoft.Exchange.Data.Storage.ItemConversion.InternalConvertAnyMimeToItem(Item itemOut, EmailMessage messageIn, InboundConversionOptions options, MimePromotionFlags promotionFlags, Boolean isStreamToStream)
at 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
Primeiro, observe o que a linha superior diz, "O limite de conversão de conteúdo foi excedido". Geralmente, uma mensagem de replicação de pasta pública é isenta de limites de tamanho e similares, portanto, por que essa mensagem falharia dessa forma? Observe que o "isSenderTrusted" é Falso. Isso significa que a mensagem veio de uma conexão SMTP que não foi autenticada. O servidor de envio falhou na autenticação ou nunca tentou autenticar. Isso é muito parecido com o que descrevi na seção Problemas comuns da Parte 3, em que uma falha de autenticação pode fazer com que o verbo XEXCH50 falhe no Exchange 2003. Como o servidor de envio não autenticou, o servidor do Exchange 2007 aplica os limites de tamanho normais na mensagem. Se esta é uma mensagem de replicação de conteúdo com mais de 250 anexos (não incomum para uma resposta de aterramento de conteúdo), então ela falhará porque excede o limite. Isso ocorre frequentemente porque um administrador criou um segundo Conector de recebimento que não permite autenticação, mas foi configurado para que ouça o IP interno ao invés do IP externo. Se essa não for a causa, você pode precisar usar uma captura Netmon para identificar o problema, conforme eu descrevi na Parte 3.
Conclusão
Isso deve cobrir tudo que você precisa saber para diminuir os problemas de replicação de pasta pública em um ambiente com o Exchange 2007. Todas as etapas de resolução de problemas antigas ainda se aplicam, apenas temos ferramentas administrativas e um conjunto de problemas diferentes. Espero que isso ajude!
Esta é uma publicação de blog traduzida. Você pode encontrar o artigo original em Public Folder Replication Troubleshooting - Part 4: Exchange Server 2007/2010 tips0