Artigo original publicado na segunda-feira, 05 de dezembro de 2011

Eu mencionei anteriormente que o Exchange 2010 Service Pack 2 seria lançado neste ano – e aqui está ele! Tenho o prazer de anunciar a disponibilidade do Exchange Server 2010 Service Pack 2, que está pronto para baixar.

Temos o prazer de adicionar valor continuadamente para o Exchange como parte do nosso ritmo de lançamento contínuo e as melhorias deste Service Pack são devidos em grande parte ao seus comentários. O SP2 inclui recursos antecipados, como o Assistente de Configuração Híbrida, Políticas de Catálogo de Endereços, Aplicativo do Outlook Web Mini e Redirecionamento Silencioso Entre Sites para o Outlook Web App, assim como as correções solicitadas pelo cliente e atualizações cumulativas lançadas antes do Service Pack 2.

Como fizemos com o SP1, o Service Pack 2 é uma versão totalmente integrada do Exchange com 13 idiomas de servidores e 66 idiomas de cliente (incluindo inglês) disponíveis em um único pacote. Não há um download separado para os idiomas do cliente e do servidor. Você precisará apenas baixar e instalar os pacotes de idiomas separados se tiver a Unificação de Mensagens.

Verifique os recursos em mais detalhes ou baixe o SP2 e teste-os sozinho.

Eu também anunciei que iríamos suportar as configurações no local do Exchange em um ambiente multilocatário. Para receber o suporte, iremos publicar um blog de acompanhamento em breve que irá destacar alguns cenários e apontar para as nossas recomendações detalhadas. Fique ligado.

Obrigado novamente aos nossos participantes TAP e a você, nossos clientes pelos ótimos conselhos que nos forneceu!

Kevin Allison
Gerente Geral
Experiência do Usuário do Exchange

Atualizações

• 12:23 PM: O conteúdo da TechNet está disponível agora.
• Esquema do Active Directory: Conforme mencionado no Anúncio do Exchange 2010 SP2, uma atualização do esquema do Active Directory é exigido para instalar o SP2. Para obter mais detalhes, consulte Preparar o Active Directory e domínios e Mudanças do Exchange Server para o Esquema do Active Directory, que documenta as mudanças do esquema para o Exchange 2003 através do Exchange 2010 SP2.
• Pacotes de Idioma da Unificação de Mensagens do Exchange 2010 SP2: Você pode baixar os Pacotes de Idiomas UM SP2 aqui.
• Para uma lista de problemas corrigidos no Exchange 2010 SP2, consulte Problemas que são corrigidos no Exchange 2010 SP2. O SP2 inclui os Pacotes Cumulativos de Atualizações 1-6 do Exchange 2010 SP1.

Esta é uma publicação de blog localizada. Encontre o artigo original em Lançamento: Exchange Server 2010 SP2

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!

- Bill Long

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

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!

- Bill Long

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

Artigo original publicado na segunda-feira, 28 de novembro de 2011

Publicação original no blog dos Estados Unidos: 20 de janeiro de 2006

Esta é a segunda publicação do blog sobre 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. Esta postagem de blog cobre a Resolução de problemas de replicação de dados existentes e a última publicação nesta série irá cobrir a Resolução de problemas de exclusão de réplicas e problemas comuns. Para ter uma visão total, leia todo o material de referência!

Resolução de problemas de replicação de dados existentes

Quando novas mudanças replicam, mas o material antigo e não alterado não, há um problema de aterramento. A situação mais comum em que o aterramento ocorre é quando um novo armazenamento público é criado. O cenário mais comum de aterramento de conteúdo é quando um armazenamento público é adicionado à lista de réplica de uma pasta.

Quando você tem um problema de aterramento como esse, já pode ter lhe ocorrido que há uma solução fácil – é preciso apenas fazer uma mudança em todos os itens. Ao fazer isso, você contorna o processo de aterramento quebrado e replica tudo como novas mudanças. Apesar do fato de que eu criei ambas as ferramentas que normalmente são usadas para isso (PFDAVAdmin e ModifyItems), geralmente é melhor resolver o problema do processo de aterramento e corrigir a causa raiz. Se você apenas mudar tudo para fazer replicar, você pode terminar com o mesmo problema de aterramento no futuro, quando as réplicas saírem de sincronia novamente. Isso posto, vamos discutir sobre o aterramento. Para compreender o processo de aterramento, primeiro é necessário compreender como as mudanças são rastreadas.

Para cada pasta e mensagem no armazenamento é atribuído um Número de Alterações (CN) quando ela criada e toda vez que for modificada. Quando a replicação ocorre, os CNs em cada objeto são usados para determinar se esse objeto precisa ser replicado. Um grupo de CNs é chamado CNSet. O CNSet para uma determinada pasta em um servidor é chamado informação de status. Essa informação de status está incluída em cada mensagem de replicação. Cada mensagem tipo 0x2 contém o status de hierarquia para o servidor de envio. Da mesma forma, cada tipo de mensagem 0x4 contém a informação de status para aquela determinada pasta para o servidor de envio. Todos os outros tipos de mensagem de replicação contêm informações de status de suas respectivas pastas.

Quando um novo armazenamento público é montado pela primeira vez, ele envia uma solicitação de status (tipo 0x20) da hierarquia de todos os armazenamentos públicos existentes. Da mesma forma, quando um novo armazenamento é adicionado à lista de réplica de uma pasta, esse armazenamento irá enviar um 0x20 para todas as outras réplicas daquela pasta. Como toda mensagem de replicação, uma solicitação de status contém um CNSet de todos os CNs da pasta em questão (ou hierarquia) que o armazenamento de origem possui e solicita que os outros armazenamentos respondam se possuem CNs que o originador não possui. Observe que antes do Exchange 2003 Sp2, não foi pedido a nenhuma réplica que respondesse à solicitação de status, portanto, alguns armazenamentos irão ignorar as solicitações de status mesmo se sofreram mudanças que o armazenamento de origem não sofreu. Um servidor 2003 Sp2 solicitará respostas de todas as réplicas e responderá mesmo quando o servidor de origem não solicitar especificamente isso, enquanto possuir mudanças que o servidor de origem não possui. Isso pode melhorar muito as decisões feitas durante o processo de aterramento. A única questão sobre uma solicitação de status é que ela não contém qualquer dado para replicar - possui apenas uma lista de números de alteração. O outro armazenamento responde com mensagens de status (0x10), que listam seus próprios CNSets para a mesma pasta (ou hierarquia). Quando o servidor de origem recebe as mensagens 0x10, compara o CNSet contido dentro de seu próprio CNSet. Se o 0x10 contém mudanças que o armazenamento ainda não possui, o progresso de aterramento começa.

A primeira etapa no processo de aterramento é adicionar entradas da matriz de aterramento para a pasta em questão. Essas entradas possuem um CNSet que descreve as mudanças faltantes e um valor de tempo limite descrevendo quando o armazenamento solicitará os dados faltantes. O tempo limite do aterramento irá variar dependendo da situação. No caso de um novo armazenamento público ser posto online ou de uma nova réplica de uma pasta ser adicionada, o tempo limite inicial é de 15 minutos.

As entradas de aterramento podem ser adicionadas a matriz de aterramento durante o curso normal de operação. Considere uma situação onde um determinado armazenamento público tenha transmitido duas mudanças em duas mensagens 0x2 separadas. Vamos dizer que o administrador exclua a primeira mensagem 0x2 da fila, mas a segunda passa. Quando os outros servidores receberem esta 0x2, eles irão descobrir que o CNSet na informação de status contém CNs que eles não possuem. Como resultado, eles irão criar entradas de aterramento para este dado. As entradas de aterramento para dados faltantes que foram descobertas durante o curso normal de replicação iniciarão com um tempo limite de 6 horas se o dado estiver disponível no mesmo Grupo de Roteamento (RG) ou 12 horas se estiver disponível em um RG diferente. Cada vez que uma solicitação de aterramento é emitida, o próximo tempo limite será de 12 e depois 24 horas para solicitações entre RGs ou 24 e 48 horas para solicitações dentro do RG.

A cada cinco minutos, o armazenamento verificará se todas as entradas de aterramento atingiram seu tempo limite. Se atingiram, uma solicitação de aterramento (tipo 0x8) é emitida para os CNs faltantes, e o tempo limite é definido para o próximo intervalo. Uma solicitação de aterramento não é uma transmissão, ela é direcionada a cada servidor único - um dos servidores que indicaram anteriormente que possuíam CNs faltantes na informação de status enviada para o servidor de solicitação. Quando esse servidor recebe o 0x8 de entrada, ele imediatamente processa a solicitação e responde com uma ou mais respostas de aterramento (0x80000002 para hierarquia ou 0x80000004 para conteúdo), que contêm os dados atuais para os números de mudança solicitados. Assim como as solicitações de aterramento, as respostas de aterramento não são transmitidas - elas são enviadas apenas para o servidor solicitante.

Se o servidor solicitante processa com êxito a resposta de entrada de aterramento, os CNs contidos são limpos da matriz de aterramento naquele armazenamento. Na realidade, qualquer mensagem de entrada que contenha CNs pendentes na matriz de aterramento fará com que esses CNs sejam limpos da matriz.

Resolução de problemas

Como se pode ver, existem muitas perguntas para responder na resolução de problemas do processo de aterramento.

1. O armazenamento sabe que estão faltando dados?

Primeiro você deve determinar se o servidor percebe que outros armazenamentos possuem mudanças que ele precisa solicitar. Infelizmente, não há uma ferramenta ou uma utilidade suportada que irá permitir a você visualizar a matriz de aterramento diretamente para ver se há algo nela. No entanto, existem outras formas mais indiretas de descobrir isso.

Uma forma é aguardar. Se o servidor sabe que estão faltando dados, ele solicitará esses dados pelo menos uma vez a cada 24 ou 48 horas. Isso significa que você pode apenas ativar o logon e aguardar para ver se uma mensagem 0x8 é emitida. Se você não vir uma 0x8 para a pasta em questão, mas está vendo 0x8 em outras pastas, você pode ter atingido o limite de aterramento pendente, o qual iremos discutir brevemente.

Outra opção é certificar-se de que o servidor receba a informação de status mais atual. Lembre-se, o servidor apenas envia uma solicitação de status que você já adicionou à nova réplica. Depois disso, a única informação de status que ele receber será através do curso normal de replicação. Portanto, se sua tentativa inicial de obter status foi perdida porque a 0x20 ou a 0x10 em resposta foi perdida ou excluída, ele pode ficar lá indefinidamente e não perceber que está faltando algo. Existem várias formas de garantir que o servidor tenha recebido a informação de status para uma pasta.

- Vá para um servidor que possua todos os dados e faça uma mudança na pasta adicionando, excluindo ou modificando uma mensagem. Em caso de uma hierarquia, crie, exclua ou altere as propriedades de uma pasta. A 0x4 ou 0x2 resultante conterá a informação de status para aquela pasta ou hierarquia, respectivamente. Quando o servidor em que estão faltando os dados processar com êxito a mensagem de replicação de entrada, você saberá que ele processou todas as entradas adequadas na matriz de aterramento.

- Use a opção Sincronizar conteúdo no ESM do Exchange 2003. Essa é uma opção bem escondida, mas muito útil. Para localizá-la, vá para a árvore Pastas Públicas e para a pasta em questão. Destaque a pasta no painel esquerdo. No painel direito, clique na guia Status. Clique com o botão direito do mouse no servidor que possui todos os dados e escolha Sincronizar conteúdo. Isso faz duas coisas - faz com que o servidor emita uma solicitação de status 0x20 para a pasta e faz com que encerre o tempo limite imediatamente de qualquer entrada de aterramento. Observe que eu disse que você deve sincronizar o conteúdo do servidor que possui os dados. Você pode se perguntar o porquê de fazer isso, já que é o outro servidor que possui as entradas de aterramento que precisam ser encerradas. Lembre-se de que nesse ponto estamos apenas tentando garantir que o servidor sem os dados SAIBA que possui algo para aterrar. Para isso, podemos usar Sincronizar conteúdo do servidor que possui os dados para enviar um 0x20 para o servidor que não possui. Nesse caso, não estamos realmente interessados em ver uma resposta de status 0x10 para o 0x20. Apenas queremos que o armazenamento com conteúdo faltando receba uma mensagem de replicação para a pasta de um armazenamento com conteúdo, para que possa adicionar as entradas adequadas na matriz de aterramento. A 0x20 do servidor com os dados tem esse objetivo. Observe que no Exchange 2003 Sp2, Sincronizar conteúdo está agora disponível para a hierarquia clicando com o botão direito no próprio nó Pastas Públicas.

- Use o valor de registro Sinalizadores de replicação (KB813629). Se você colocar este valor em vigor, junto com o valor Habilitar mensagens de replicação na inicialização do KB321082, pode ser que o armazenamento envie uma solicitação de status 0x20 para cada pasta na inicialização. Novamente, você desejaria usar isso em um servidor que possui o conteúdo - o objetivo dessa etapa é fazer com que o servidor que possui conteúdo envie suas informações de status para o servidor que está com conteúdo faltante.

- Use o ESM 2003 para enviar uma resposta de aterramento. No Sp1 2003, você pode usar a opção Enviar hierarquia para enviar uma resposta de aterramento de hierarquia e a opção Enviar conteúdo para enviar uma resposta de aterramento de conteúdo da pasta. No Sp2 2003, ambas as opções se tornam Reenviar alterações. Isso envia uma resposta de aterramento para o intervalo de dados que você especificar, mas provavelmente você não especificará o intervalo completo de dados, uma vez que isso poderia satisfazer todas as entradas de aterramento pendentes e terminar voltando para o problema original. Em vez disso, especifique um intervalo de somente um dia ou dois. Isso faz com que um 0x80000002 ou um 0x80000004 vá para o servidor de destino, que novamente serve para o objetivo de fornecer informações de status para o armazenamento que possui os dados.

Uma vez que você usou uma dessas opções para forçar informações de status e verificou que o armazenamento com dados faltantes recebeu a mensagem de entrada verificando o log do aplicativo, você sabe que ele sabe que estão faltando dados.

2. O armazenamento solicita os dados faltantes?

Depois de você ter verificado que o armazenamento sabe que precisa aterrar alguns dados, ele emite uma solicitação de aterramento? Lembre-se disso depois de o armazenamento ter tentando aterrar os dados algumas vezes. Talvez você precise aguardar 24 ou 48 horas para a próxima solicitação de aterramento, pois esse será o intervalo de tempo limite mais longo para aterramentos dentro do site e entre sites, respectivamente. Existe apenas uma forma de acelerar isso, que é usar novamente o Sincronizar conteúdo, mas dessa vez a partir do servidor em que estão faltando os dados. Isso limitará o tempo imediatamente das entradas de aterramento para aquela pasta. No entanto, você ainda pode descobrir que o armazenamento não emite uma solicitação de aterramento para a pasta em que você está concentrado. Se for esse o caso, verifique o log de aplicativo pelas próximas 24 a 48 horas. Se o armazenamento está enviando solicitações de aterramento para outras pastas, mas não para a pasta que você deseja, ele pode ter atingido o limite de aterramento pendente.

Quando você passa por uma situação em que você adicionou réplicas de várias pastas em um novo armazenamento, e a replicação parece bem no início, mas vai diminuindo até parar nos dois dias seguintes, você provavelmente atingiu o limite de aterramento pendente. O limite de aterramento pendente é um mecanismo destinado para a aceleração da replicação. Por padrão, o armazenamento irá permitir apenas 50 solicitações de aterramento pendentes por vez. Quando tiver 50 pendentes, ele solicitará novamente essas 50 solicitações indefinidamente até que sejam realizadas. Uma vez que todas as entradas pendentes tenham sido realizadas, isso abre uma fenda no OBL para um novo conjunto de dados a ser solicitado. Isso significa que se 50 solicitações estão tendo problemas para serem realizadas por qualquer motivo, a replicação não pode continuar.

Se você estiver vendo esse comportamento, deve verificar o log de aplicativo para ver o que o armazenamento está solicitando. Você estará vendo mensagens 0x8 periódicas para as 50 solicitações de aterramento pendentes atuais e você descobrirá que nenhuma resposta de aterramento é recebida, que é o motivo pelo qual ainda estão pendentes. Nesse ponto, você deve alterar seu foco para resolver problemas de uma das pastas que o armazenamento está tentando aterrar atualmente, pois resolver o problema permitirá seguir para outras pastas.

Existe uma outra opção, que é aumentar o limite de aterramento pendente (OBL). Você pode fazer isso criando um valor de registro chamado Limite de aterramento pendente da replicação na chave de registro para aquele armazenamento. O valor máximo é de 5.000 decimal. No entanto, uma vez que você fizer isso, a comporta da replicação abrirá e será difícil determinar quais 50 pastas causaram a obstrução. Você precisará adiar a resolução de problemas até que as coisas se estabilizarem novamente. Geralmente, eu recomendo deixar o limite em 50 e corrigir o problema, em vez de trabalhar para aumentar o limite.

Se o OBL não parece ser o problema, e se você ainda não está vendo as mensagens 0x8 de saída para a pasta em questão, consulte "Problemas Comuns" na última publicação desta série.

3. O outro armazenamento responde à solicitação?

Quando você tiver uma solicitação de aterramento para se concentrar em, você precisa determinar se o aterramento de destino já obteve a solicitação. Verifique o log de aplicativo no servidor para a 0x8 de entrada. Você também pode pesquisar o log de aplicativo pela ID da mensagem mencionada no evento de saída do lado de envio. Se você não conseguir encontrar um sinal dele no log de aplicativo, use o rastreamento de mensagem para ver até que distância ele percorreu. Se ele recebeu a 0x8, deve responder quase imediatamente com uma ou mais mensagens 0x80000002 ou 0x80000004 (você frequentemente verá várias respostas de aterramento a uma única solicitação de aterramento, pois as mudanças não são enviadas em uma única mensagem). Claro, o tempo que leva para gerar as mensagens de resposta de aterramento irá variar com base nos dados da pasta e no limite de tamanho da mensagem de replicação. Por exemplo, se você definir o tamanho máximo da mensagem de replicação como 1 GB, o servidor de resposta poderia tentar empacotar toda a hierarquia em uma única resposta de aterramento, o que pode levar uma hora ou mais apenas para embalar!

4. O servidor solicitante obtém a resposta?

Agora é o momento de verificar o log de aplicativo no servidor de solicitação para ver se ele recebeu a resposta de aterramento. Caso contrário, rastreie a mensagem e veja quão longe ela foi. Se o servidor recebeu a resposta de aterramento e registrou no log do aplicativo, essa solicitação de aterramento foi realizada e deve poder continuar.

Como mencionado anteriormente, se você descobrir que o rastreamento de mensagem mostra que uma dessas mensagens foi entregue para o armazenamento, ainda que o log de aplicativo não mostre a mensagem de replicação em entrada, consulte "Problemas Comuns" na última publicação desta série.

Na próxima publicação do blog: Troubleshooting Replica Deletion and Common Problems..

- Bill Long

Esta é uma publicação de blog traduzida. Você encontra o artigo original em Public Folder Replication Troubleshooting – Part 2: Troubleshooting the Replication of Existing Data

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.

- Bill Long

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