Resolução de problemas de replicação da pasta pública – Parte 1: Resolução de problemas de replicação de novas mudanças
Artigo original publicado na segunda-feira, 28 de novembro de 2011
Publicação original no blog dos Estados Unidos: 17 de janeiro de 2006
Observação: esta publicação do blog é a primeira de uma série de Resolução de problemas de pasta pública. Verifique também a parte 2, a parte 3 e a parte 4 da série.
Introdução
O objetivo desta publicação do blog é servir como um guia para resolver problemas de replicação da pasta pública. O artigo não dirá exatamente como corrigir cada problema de replicação possível. No entanto, irá mostrar como isolar cada possível problema de replicação para que você concentre a resolução do problema no ponto de falha. Colocando de outra forma, esta publicação é destinada a levar você a uma descrição de problema como "O conteúdo no meu antigo servidor não está replicando em meu novo servidor" para uma descrição de problema muito mais específica como "Meu servidor antigo não está respondendo às solicitações de status do meu novo servidor, portanto, o novo servidor não sabe que está perdendo dados e não está tentando aterrar. Isso significa que o problema é realmente com o servidor antigo." Esta publicação também descreverá como identificar alguns dos problemas de replicação mais comuns. Antes de entrar nos detalhes da resolução de problemas, quero fornecer uma visão geral da minha abordagem a esses problemas.
A melhor ferramenta de resolução de problemas para replicação de pasta pública é o log de aplicativo. Para isolar um problema de replicação, você deve seguir os eventos de replicação no log para ver exatamente onde o processo está quebrado. Geralmente, você deve aumentar ao máximo o Log de diagnósticos em replicação em entrada e replicação em saída como um ponto inicial para resolver o problema. Cada vez que um armazenamento envia ou recebe uma mensagem de replicação, ele irá registrar um evento para esse efeito (assumindo que o registro em log esteja ligado). Os vários tipos de mensagens de replicação podem ser diferenciados por "Tipo" exibido na descrição do evento. Eu prefiro me concentrar no Tipo em vez da ID do evento por vários motivos:
- As IDs de evento mudam entre as versões do Exchange. Por exemplo, no Exchange 5.5, a ID de uma solicitação de aterramento em saída era 3014. No Exchange 2000 e 2003, é 3016.
- As IDs de evento de entrada e de saída são diferentes para cada tipo. Uma mensagem de hierarquia de saída é 3018, enquanto uma mensagem de hierarquia de entrada é 3028.
- As solicitações de status e mensagens de status usam a mesma ID de evento, mesmo se forem dois tipos de mensagens diferentes. Dessa forma, você não pode distinguir entre elas apenas pela ID de evento.
Concentrar-se no Tipo é um pouco mais fácil. É possível correlacionar facilmente com as IDs de Evento examinando seu log de aplicativo. Existem apenas sete tipos, e você pode ver se a mensagem está em entrada ou em saída verificando a Categoria do evento. Se você se concentrar nos tipos em vez das IDs do evento, tudo que precisará lembrar é:
Hierarquia - 0x2
Conteúdo - 0x4
Solicitação de aterramento - 0x8
Resposta do aterramento - 0x80000002 (para hierarquia) ou 0x80000004 (para conteúdo)
Status - 0x10
Solicitação de status - 0x20
Observe também que o registro em log dos Erros de Replicação é raramente útil. Mesmo quando uma replicação está funcionando normalmente, a maioria dos servidores irá gerar muitos eventos de erro de replicação, como o evento ID 3093 indicando que houve um erro ao ler uma propriedade. Na maioria dos casos, a propriedade não tem efeito na replicação e o erro pode ser ignorado. Eu recomendo deixar o registro de log de Erros de Replicação em Nenhum, a não ser que você esteja procurando por algo específico, como o problema descrito na publicação de blog anterior.
Resolução de problemas de replicação de novas mudanças
Para resolver problemas de replicação da pasta pública, você deve estar familiarizado com o fluxo de mensagem normal que é esperando quando uma replicação está funcionando. Baseado nesse conhecimento, você pode identificar o ponto de falha quando um problema surge. Antes de discutir como resolver problemas de replicação de novas mudanças, vamos descrever qual é o comportamento esperado.
Replicação de hierarquia
A replicação de uma nova mudança de hierarquia ocorre sempre que uma pasta é criada ou excluída ou quando uma mudança é realizada nas propriedades de uma pasta pública, como a lista de replicação, permissões de cliente, descrição, observação administrativa ou limites de armazenamento. Observe que isso não inclui os endereços de email em uma pasta habilitada para correio. Os endereços de email são armazenados no objeto de diretório no Active Directory, portanto, mudá-los não resulta em replicação da hierarquia. Apenas mudar as propriedades armazenadas no próprio armazenamento público irá causar uma replicação de hierarquia.
A cada 15 minutos (por padrão), o armazenamento transmite qualquer mudança realizada nas propriedades da pasta em uma ou mais mensagens de replicação de hierarquia. Com o registro em log no Máximo de saída de replicação, você verá um evento como este no servidor em que a hierarquia foi modificada:
Tipo de evento: Informação
Fonte de evento: Armazenamento público do MSExchangeIS
Categoria de evento: Mensagens em saída de replicação
ID do evento: 3018
Descrição:
Uma mensagem de replicação em saída foi emitida.
Tipo: 0x2
ID da mensagem: <91ACCD0758385549A56A10971798985572D5@bilongexch1.bilong.test>
Banco de dados "First Storage Group\Public Folder Store (BILONGEXCH1)"
CN mín: 1-72CF, CN máx: 1-72D3
RFIs: 1
1) FID: 1-6994, PFID: 1-1, Compensação: 28
IPM_SUBTREE\NewFolder
Observe o "Tipo: 0x2" no início da descrição, identificando isto como uma mensagem de replicação de hierarquia.
Uma mensagem de replicação de hierarquia é enviada do servidor de origem diretamente para todos os armazenamentos públicos. Não há conceito de topologia para a replicação de novas mudanças. Todas as mudanças da hierarquia são enviadas diretamente do servidor no qual as mudanças foram feitas para todos os outros servidores que possuem um armazenamento público associado com a mesma hierarquia. Cada servidor deve registrar um evento de entrada exibindo um tipo 0x2 quando eles processam com êxito a mensagem de replicação de entrada.
Replicação de conteúdo
A replicação de conteúdo ocorre sempre que uma mensagem é criada ou excluída ou que as propriedades da mensagem são alteradas. As vezes em que o armazenamento transmite mudanças de conteúdo de uma pasta podem ser modificadas alterando a programação de replicação naquela pasta, mas, por padrão, as alterações serão transmitidas a cada 15 minutos, assim como a hierarquia. Uma mensagem de replicação de conteúdo é identificada pelo tipo 0x4 na descrição de evento. Novamente, não há conceito de topologia para a transmissão de novas mudanças. Quando o conteúdo de uma pasta é modificado em uma determinada réplica, esta réplica irá enviar uma mensagem 0x4 diretamente para todas as outras réplicas na pasta. E novamente, cada servidor recebedor deve registrar um evento 0x4 de entrada quando eles processam com êxito a mensagem de entrada.
Etapas de resolução de problemas
Esses são os dois cenários mais básicos para replicação. Quando novas mudanças de hierarquia ou de conteúdo não são realizadas de um servidor para o outro, a resolução de problema é muito direta.
1. O servidor gerou uma mensagem de replicação em saída?
Você realizou uma mudança para uma pasta ou adicionou conteúdo em uma pasta de um determinado servidor, e esse conteúdo não chegou a alguns dos outros servidores. A primeira pergunta a responder é se a transmissão do servidor de destino mudou. Ao resolver problemas, é importante manter um registro de com qual servidor você está trabalhando ao realizar mudanças. Existem várias formas de fazer isso. No ESM, você pode clicar com o botão direito no nó Pastas Públicas e escolher "Conectar em" para apontar um determinado armazenamento. Para a maior parte, o ESM realizará mudanças em um armazenamento específico, mas esteja ciente de uma exceção - as Permissões de Cliente. Antes do Exchange 2003 Sp2, quando você mudava as Permissões de Cliente através do ESM, o ESM tentaria realizar a mudança em um armazenamento que aloja uma réplica da pasta, mesmo quando não é necessário por as permissões serem armazenadas como uma propriedade da pasta na hierarquia. Com a versão 2003 Sp2 do ESM, isso foi alterado para que agora seja feita a alteração na hierarquia que você indicou. Quando você está testando a replicação de hierarquia fazendo mudanças pelo ESM, você deve evitar usar as permissões para teste, pois pode ser difícil prever em qual armazenamento a mudança será feita, a não ser que você esteja executando o ESM 2003 Sp2. Se você está usando o Outlook e deseja verificar qual réplica de pasta você está acionando, você pode usar o MFCMAPI ou uma ferramenta similar para exibir a propriedade PR_REPLICA_SERVER da pasta. Isso exibirá o nome do servidor que o Outlook está usando para acessar o conteúdo daquela pasta.
Se a programação de replicação é Sempre para a pasta em questão (o que é sempre verdadeiro para a hierarquia), e você não vir um 0x2 ou 0x4 em saída dentro de 15 minutos, você saberá que algo está errado no servidor de origem. Se o servidor não está gerando qualquer hierarquia em saída ou transmissões de conteúdo, o agente de replicação pode ter falhado ao iniciar. Um dos cenários mais comuns está descrito no KB272999. O importante a se observar aqui é o evento 3079:
ID de Evento: 3079
Fonte: MSExchangeIS Público
Tipo: Erro
Categoria: Erros de replicação
Descrição:
Erro inesperado do thread de replicação 0x3f0.
EcGetReplMsg
EcReplStartup
FReplAgent
Isso será registrado mesmo sem nenhum registro em log adicional ligado quando você montar o armazenamento público. Se o 3079 inclui a função "EcReplStartup", isso significa que o agente de replicação falhou ao iniciar, e nenhuma nova mudança será transmitida até que o problema seja corrigido, e o armazenamento seja montado novamente.
A replicação de hierarquia também é vulnerável a determinados problemas de permissão quando os armazenamentos públicos do Exchange 5.5 estão presentes na organização. Quando um servidor do Exchange 2000 ou 2003 envia uma mensagem de replicação de hierarquia para um servidor do Exchange 5.5, ele deve produzir uma propriedade ptagACLData (as permissões estilo 5.5 baseadas no legacyExchangeDN) a partir da propriedade ptagNTSD (as permissões de estilo 2000 baseadas no SID). Isso significa que cada SID deve ser convertido para um legacyExchangeDN. Essa conversão de SID para legacyExchangeDN pode falhar por vários motivos. Por exemplo, se um SID soluciona para mais de um usuário, um evento como este pode ser gerado:
ID de Evento: 9528
Categoria: Geral
Fonte: MSExchangeIS
Tipo: Erro
Descrição:
O SID S-1-5-21-408248388-469072634-37170099-1391 não foi encontrado em 2 usuários no DS, portanto, o armazenamento não pode mapear esse SID para um único usuário.
Os usuários envolvidos são:
/DC=com/DC=company/CN=Users/CN=User1
/DC=com/DC=company/CN=Users/CN=User2
Como o SID não pode ser convertido para um legacyExchangeDN, o armazenamento falhará ao gerar uma mensagem de transmissão de hierarquia em saída.
2. A mensagem foi endereçada para o servidor que não recebeu a mudança?
Se o servidor de origem gerou a mensagem de saída, a próxima etapa é certificar-se de que foi endereçado para o servidor que não recebeu os dados. A forma mais fácil de verificar isso é rastreando a mensagem. No rastreamento de mensagem, você pode apenas rastrear a ID da mensagem que foi relatada no evento de replicação de saída. Na janela Histórico de Mensagens, a linha Para: estará visível. Se o local de armazenamento que não recebeu as mudanças não está listado aqui, novamente o foco deve ser no servidor de origem. Ele lista aquele servidor na organização? O servidor possui endereços de email no seu objeto de armazenamento público? O servidor de origem lista esse armazenamento na lista de réplica da pasta em questão?
3. A mensagem chegou ao servidor de destino?
Quando você verificou que a mensagem foi endereçada ao servidor de destino, a próxima pergunta a responder é - a mensagem chegou lá? Você pode determinar isso pelo rastreamento de mensagem. Se o rastreamento de mensagem diz que a mensagem foi entregue ao armazenamento, mas você não vê qualquer evento de replicação de entrada reconhecendo a mensagem, consulte a seção "Problemas Comuns" na última publicação desta série.
Na próxima publicação do blog: Troubleshooting the Replication of Existing Data.
Esta é uma publicação de blog traduzida. Você pode encontrar o artigo original em Public Folder Replication Troubleshooting – Part 1: Troubleshooting the Replication of New Changes