Resolução de problemas de pasta pública – Parte 3: Resolução de problemas de exclusão de réplica e problemas comuns
Artigo original publicado na segunda-feira, 28 de novembro de 2011
Publicação original no blog dos Estados Unidos: 24 de janeiro de 2006
Esta é uma terceira publicação do blog sobre a resolução de problemas de replicação de pasta pública. Na primeira publicação nós cobrimos a Resolução de problemas de replicação de novas mudanças. A segunda publicação do blog cobriu a Resolução de problemas de replicação de dados existentes. Esta publicação irá cobrir a Resolução de problemas de exclusão de réplica e problemas comuns. Para ter uma visão geral, consulte todo o material de referência!
Resolução de problemas de exclusão de réplica
Você removeu um servidor antigo da lista de réplica em todas as suas pastas. No entanto, quando você for para Instâncias de pasta pública do armazenamento antigo no ESM, você verá muitas pastas. Isso ocorre devido a um problema com o processo de exclusão de réplica. Na versão do Exchange 2003 Sp2 do ESM, se você tentar excluir um armazenamento público neste estado, o ESM apresenta um diálogo declarando:
“Não é possível excluir este armazenamento de pasta pública, pois ele contém réplicas de pastas. Para evitar perda de dados, clique com o botão direito no armazenamento de pasta pública e use Mover réplicas para mover as réplicas para um servidor diferente. Pode levar várias horas até que o conteúdo seja replicado para o novo servidor, e as réplicas locais sejam removidas.”
Quando você remove um armazenamento da lista de réplica em uma pasta, esse armazenamento não exclui imediatamente os dados. Ao invés disso, envia uma solicitação de status 0x20 especial para todas as outras réplicas. Isso é chamado de Solicitação de Status Pendente de Exclusão da Réplica (RDPSR) e não pode ser distinguido de uma solicitação de status normal no log de aplicativo. Um RDPSR contém um sinalizador indicando que a réplica está pendente para exclusão. Quando os outros armazenamentos recebem essa 0x20, eles respondem com uma 0x10 especial chamada de Confirmação de Pendência de Exclusão da Réplica (RDPA). A RDPA indica que está tudo bem excluir esses dados – mas os outros armazenamentos só enviam essa 0x10 se já possuem todos os CNs que a réplica de exclusão pendente possui. A réplica será excluída somente quando o armazenamento receber uma 0x10 indicando que mais alguém possui os dados.
Isso significa que se você excluir o armazenamento antes de a Instância de pasta pública estar vazia, você provavelmente perderá dados. Somente o 2003 Sp2 ESM irá impedir que você faça isso – em versões mais antigas, você deve verificar manualmente a Instância de pasta pública para ver se pode excluir o armazenamento. Você deve sempre verificar a Instância de pasta pública antes de excluir um armazenamento público e, quando o 2003 Sp2 ESM fornecer esse aviso, você não deve tentar ignorá-lo ou deixá-lo de lado – em vez disso, você deve resolver o problema no processo de exclusão de réplica.
Observe que antes do Exchange 2003 Sp2, o servidor que foi removido da lista de réplica envia o RDPSR apenas uma vez. Se ninguém responder, você verá que a pasta apenas permanece na Instância de pasta pública indefinidamente, a não ser que você adicione o armazenamento de volta na lista de réplica e remova-o novamente, fazendo com que um novo RDPSR seja enviado. O 2003 Sp2 mudou esse comportamento para que o armazenamento seja tentado novamente a cada hora até obter um RDPA de alguém.
Resolução de problemas
Isso é quase o mesmo que a resolução de problemas do processo de aterramento.
1. A réplica de exclusão pendente envia uma 0x20?
A não ser que você já tenha ativado o registro em log quando removeu a réplica, não há como saber. Infelizmente, você pode apenas adicionar a réplica de volta e removê-la novamente. Verifique o log de aplicativo para a 0x20.
2. A 0x20 atingiu outras réplicas?
Você deve saber o caminho nesse ponto. Verifique os logs de aplicativo em outras réplicas para ver se elas receberam a 0x20.
3. Alguma outra réplica respondeu com uma 0x10?
Essa é a parte em que você provavelmente acabará se concentrando. Se uma réplica recebeu a 0x20 da réplica de exclusão pendente, mas não respondeu com uma 0x10, isso significa que a réplica de exclusão pendente possui dados que a outra réplica não possui. Como você sabe que ela acabou de receber um 0x20 daquela réplica, então você também sabe que ela já conhece qual dado está faltando. Portanto, você esperaria ver uma solicitação de aterramento para essa pasta a cada 24 a 48 horas. Verifique o log de aplicativo e resolva o problema exatamente como o processo de aterramento normal descrito anteriormente.
4. A réplica de exclusão pendente recebeu a 0x10?
Uma vez que qualquer outra réplica tem todos os dados, essa réplica deve responder com uma 0x10. Quando a réplica de exclusão pendente receber essa 0x10, ela finalmente terá vontade de excluir os dados. Isso não significa, porém, que isso ocorrerá imediatamente. Se há clientes usando essa réplica, não será excluída até mais tarde, durante a manutenção online. Se você desejar, pode acelerar o processo desmontando e montando o armazenamento para desconectar os clientes.
Problemas comuns
Você pode descobrir que um servidor enviou algum tipo de mensagem de replicação para outro servidor, mas o servidor de recebimento nunca registrou a mensagem em entrada no log de aplicativo. No entanto, o rastreamento de mensagem diz que foi entregue localmente para o armazenamento naquele servidor. Esse comportamento geralmente indica um problema com a tabela Estado da Replicação ou um problema de permissão no servidor virtual SMTP.
Vamos falar primeiro sobre o mais fácil. Um problema que faz com que uma mensagem de replicação seja ignorada pelo servidor de recebimento é um problema com a tabela Estado da Replicação ou ReplState. Observe que um problema com a tabela ReplState também pode fazer com que o servidor falhe ao emitir solicitações de aterramento (0x8) para algumas pastas, portanto, essa informação também se aplica a essa situação. Cada armazenamento público usa sua tabela ReplState para rastrear o estado da replicação de qualquer pasta replicada. A tabela contém várias linhas para cada pasta - uma linha por réplica. É possível que as linhas na tabela ReplState saiam de sincronia com a lista de réplica, por isso ela possui linhas extras ou faltantes. Algumas vezes, você pode fazer com que ela entre em sincronia novamente apenas fazendo uma mudança como remover um servidor da lista de réplica, aplicar a mudança e imediatamente adicionar de volta, mas nem sempre isso funciona. Felizmente, um teste ReplState foi adicionado ao isinteg. Consulte o KB889331 para o Exchange 2003 ou o KB892485 para o Exchange 2000. Enquanto você tiver o isinteg.exe e store.exe atualizados, você pode usar o isinteg para corrigir o problema com a tabela ReplState. Se você executar apenas o teste ReplState, ele é geralmente muito rápido - menos de um minutos, mesmo em um armazenamento público grande. Uma vez que o isinteg tenha sido executado, você ainda pode precisar voltar e fazer uma mudança na pasta para colocar a tabela ReplState em sincronia com a lista de réplica. Depois de estarem em sincronia, o servidor deve ser capaz de processar as mensagens de replicação de entrada ou deve começar a emitir solicitações de aterramento normalmente.
O outro problema comum que faz com que uma mensagem de replicação de entrada seja ignorada é um problema específico com o Exchange 2003. Um servidor do Exchange 2003 exige que o servidor de envio tenha o direito Enviar como no servidor virtual SMTP de recebimento. Isso é, se o ServerA é o Exchange 2003 e o ServerB está enviando uma mensagem de replicação PF para o ServerA, o ServerB deve ter o Enviar como no servidor virtual SMTP do ServerA. Caso contrário, o ServerA não processa a mensagem de replicação de entrada. Essa permissão geralmente é concedida através dos grupos dos Servidores de domínio do Exchange. Se o direito Enviar como é o problema, todas as mensagens de replicação de entrada de um determinado servidor falharão. Eu acho mais fácil identificar esse problema com um rastreamento de rede obtido enquanto uma mensagem de replicação está sendo transferida de um servidor para outro. A conversa deve ocorrer como a seguir:
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
A parte importante aqui é que o ServerA deve publicar as opções GSSAPI NTLM LOGIN. Se você não vir essas opções na resposta do ServerA ao EHLO, geralmente é porque a autenticação integrada do Windows foi desmarcada no servidor virtual SMTP. Isso é mencionado na etapa 1 do KB843106 e na etapa 3 do KB842273. Enquanto esses verbos de autenticação aparecerem, você deverá ver o ServerB tentando usá-los:
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 a autenticação não for realizada com êxito, você pode ter um problema de Kerberos ou um problema com a conta do computador do ServerB. Em seguida, os servidores irão transmitir a informação linkstate. Depois disso, eles finalmente começam a transferir email:
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
Essa última resposta ao verbo XEXCH50 é importante. Se a resposta é "354 Send binary data" está tudo bem, pelo menos em relação às permissões relacionadas ao servidor virtual SMTP. Se as opções de login GSSAPI NTLM não são publicadas ou se a tentativa de autenticação falhar, é esperado que o ServerA responda com "504 Need to authenticate". Se essas etapas forem bem sucedidas, mas o ServerA ainda disser "504 Need to authenticate" em vez de "354 Send binary data", o ServerB não possui o direito Enviar como no servidor virtual SMTP do ServerA. Existem várias formas em que isso pode ocorrer. Uma delas é quando você delega direitos como Administrador pleno do Exchange no ESM, esse usuário ou grupo herda uma negação do direito Enviar como. No entanto, usar o ESM para delegar direitos administrativos à conta do computador, o grupo Servidores de domínio do Exchange, ou qualquer outro grupo que contém os servidores do Exchange irá quebrar a replicação de pasta pública. Outra possibilidade é que a conta do computador não está no grupo Servidores de domínio do Exchange, que normalmente possui o direito Enviar como. Você precisará avaliar as permissões no servidor virtual SMTP e determinar por que a conta do computador para o servidor de envio não possui direitos de propriedade. Consulte KB843106 e KB842273 para obter mais detalhes sobre o problema "504 Need to authenticate".
Conclusão
Você pode ter observado, enquanto você lê este documento, que o Sp2 para Exchange 2003 contém várias melhorias importantes para evitar problemas de replicação e ajuda a resolver problemas. Os ambientes com vários armazenamentos públicos podem realmente ver um grande benefício do Sp2, especialmente quando se trata de mover réplicas entre servidores e adicionar e remover armazenamentos públicos.
Eu espero que isto tenha sido útil. Agradeço Dave Whitney por revisar tudo!
Esta é uma publicação de blog traduzida. Você encontra o artigo original em Public Folder Replication Troubleshooting – Part 3: Troubleshooting Replica Deletion and Common Problems