Artigo original publicado na quarta-feira, 9 de novembro de 2011.
No outro dia, eu estava conversando com um de nossos Gerentes do Programa de Suporte, Nino Bilic, e ele mencionou algo que era bastante preocupante: o principal motivo pelo qual nossos clientes Premier abrem o Exchange 2010 em situações críticas é porque os bancos de dados da Caixa de Correio se desmontam devido à falta de espaço em disco no LUN do log de transações.
Vamos amadurecer essa ideia em um momento. Naturalmente estou chocado...Para ser totalmente honesto, pensei que com a Calculadora de Requisitos de Caixa de Correio e nossas orientações no TechNet, já teríamos eliminado esse problema. Depois de compartilhar essas informações comigo, Nino decidiu que eu, não ele, deveria escrever um artigo no blog sobre o assunto do planejamento de capacidade do log de transações (obrigado, Nino!).
Para dimensionar adequadamente um LUN do log de transações, precisamos entender alguns aspectos sobre o ambiente:
Para os fins dessa discussão, vamos supor que cada banco de dados abrigará 250 caixas de correio. Cada caixa de correio envia/recebe 150 mensagens por dia, com mensagens com um tamanho médio de 100KB. Com base na tabela em Noções básicas sobre o banco de dados Caixa de Correio e fatores de capacidade de log, sabemos que um perfil de 150 mensagens com um tamanho médio de mensagens de 75KB gera 30 logs de transações por dia (período de 24 horas). Como nosso tamanho de mensagem é maior que 75KB, precisamos considerar isso na geração de logs de transações por caixa de correio. A orientação estipula que:
Se o tamanho médio das mensagens dobrar para 150KB, os logs gerados por caixa de correio aumentarão em um fator de 1,9. Esse número representa o percentual do banco de dados que contém os anexos e as tabelas de mensagens (corpos de mensagens e anexos).
Portanto, podemos determinar o impacto do nosso tamanho médio de mensagens de 100KB com esta fórmula:
150 / 1,9 = [tamanho médio de mensagens do perfil] / x
x = (100 * 1,9) / 150
x = 1,266666666666667 ~ 1,27
Se você tiver um tamanho de mensagem que é 25KB maior do que a linha de base, o número de logs de transações gerados por dia e por caixa de correio aumentará em um fator de 1,27. Portanto, 30 logs de transações * 1,27 = 39 logs de transações / dia / caixa de correio. Isso significa que, para um banco de dados de 250 caixas de correio, cada banco de dados gerará 39 * 250 = 9.750 logs de transações gerados por caixa de correio / dia / banco de dados.
As movimentações de caixa de correio também geram logs de transações. Cada caixa de correio movida para o banco de dados de destino gera logs suficientes (no destino, não na origem) que se igualam ao tamanho da caixa de correio (incluindo o conteúdo nas pastas de Itens Recuperáveis). Por exemplo, mover 1% das caixas de correio por dia significará que 2,5 caixas de correio são movidas para um banco de dados todos os dias. Se cada caixa de correio tiver 5,4GB de tamanho médio (incluindo a retenção de item excluído por 14 dias com a Recuperação de Item Único habilitada), então 2,5 * 5,4GB / 1024 = 13.888 logs de transações de movimentações de caixa de correio / dia / banco de dados.
A partir de uma perspectiva de backup/restauração, é preciso levar em consideração o tipo de arquitetura de backup que estamos aproveitando. Com cada cenário de backup, há um número recomendado de dias adicionais de provisão de uma perspectiva de capacidade para os logs de transações gerados por caixa de correio. Ao fornecer espaço extra, você pode sobreviver a múltiplas falhas sem sofrer uma interrupção de evento. Para obter mais informações sobre o truncamento do log de transações, consulte Compreendendo o backup, a restauração e a recuperação de desastres.
É claro, existem outros cenários que talvez você precise considerar. Por exemplo, se você estiver implantando um Grupo de Disponibilidade de Banco de Dados (DAG) esticado em dois datacenters, o truncamento de log só ocorrerá se o vínculo de rede entre os dois datacenters estiver operacional e se as cópias do banco de dados estiverem íntegras. Se você souber que uma interrupção do vínculo WAN poderá levar cinco dias para ser consertada, deverá ajustar a sua proteção contra falha de backup para levar isso em consideração.
Para o nosso cenário, vamos supor que só precisamos garantir que possamos sobreviver três dias de eventos de falha de truncamento. Isso significa que precisamos 9.750 / 1024 * 3 = 28,5GB de espaço em disco para nossos logs de transações gerados por caixa de correio.
Além disso, precisamos considerar a quantidade de espaço em disco necessária para os eventos de movimentação de caixas de correio para uma semana inteira: 13.888 / 1014 * 7 dias = 94,9GB de espaço em disco para as operações de movimentação de caixas de correios.
Assim, isso significa que cada banco de dados precisa de 123GB de espaço em disco para os logs de transações. Devemos incluir também um fator de sobrecarga de dados para considerar qualquer fenômeno inexplicável que possa ocorrer: 123GB * 1,2 = 148GB de espaço em disco para os logs de transações.
Se estivermos implantando um LUN dedicado para os logs de transações, não forneceríamos um LUN de 150GB porque isso significaria que poderíamos consumir todo o espaço em disco se tivéssemos tendo falhas de backup e movimentações excessivas de caixa de correio. Geralmente, você quer garantir que cada LUN seja provisionado de tal forma que somente 80% da capacidade do disco seja utilizada. A fórmula é:
Espaço do LUN = [utilização projetada do espaço em disco] / (1 – [percentual de espaço em disco desejado])
Espaço do LUN = 148GB / (1 – 0,2) = 148GB / 0,8 = 185GB de espaço do LUN para o volume dedicado do log de transações
Se você estiver implantando os logs de transações no mesmo LUN do banco de dados, poderia simplesmente combinar os requisitos de espaço em disco do log de transações com os requisitos de espaço em disco do banco de dados para o valor de [utilização projetada de espaço em disco].
Em primeiro lugar, você precisa obter uma linha de base de seu ambiente para determinar a taxa de geração de log típica por dia. Além disso, você deve configurar o monitoramento e agir em todos os alertas que são gerados. O monitoramento deve ser feito nos seguintes cenários:
Meu amigo, Mike Lagase, escreveu um ótimo artigo sobre como solucionar os problemas desse cenário - http://blogs.technet.com/b/mikelag/archive/2009/07/12/troubleshooting-store-log-database-growth-issues.aspx (observe que o artigo foi escrito com o Exchange 2007 em mente, assim, várias ferramentas e/ou recomendações podem não ser aplicáveis ao Exchange 2010). Além das etapas mencionadas por Mike, você pode usar o seguinte no Exchange 2010 para ajudar a determinar o crescimento inexplicado do log de transações (obrigado a Todd Luttinen por criar esta lista):
[PS] C:\>$stats = Get-StoreUsageStatistics –Database <Database Name> [PS] C:\>$stats | ? {$_.DigestCategory -eq 'LogBytes'} | group MailboxGuid |sort count -Descending | Select -first 1 -ExpandProperty Group | sort SampleTime | ft -a MailboxGuid,Sample*,Log*
Iniciando em <date/time>, o serviço <name> executou esta atividade no servidor: Operações RPC: 24168. Páginas do Banco de Dados Lidas: 1329 (das quais 629 páginas pré-lidas). Páginas do Banco de Dados Atualizadas: 12418 (das quais 11555 páginas reatualizadas). Registros do Log do Banco de Dados Gerados: 13906. Bytes de Registros do Log do Banco de Dados Gerados: 660331. Tempo no Servidor: 19142 ms. Tempo no Modo do Usuário: 6100 ms. Tempo no Modo Kernel: 63 ms.
Acho que todos nós compreendemos como é importante garantir que haja capacidade suficiente para que a disponibilidade de banco de dados não seja afetada. Esperamos que essas informações ajudem no planejamento da capacidade do log de transações.
Ross Smith IV Gerente de programa principal Experiência do cliente do Exchange
Esta é uma postagem de blog traduzida. O artigo original encontra-se em Capacity Planning – Yes Transaction Log Space is Critical to Keeping your Databases Healthy and Mounted
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 em 23 de setembro de 2010, quinta-feira
Aqui está um webcast interessantes para esta semana... Neste mês de outubro, a Rússia não irá "retroceder" e permanecerá essencialmente no horário de verão. Essa mudança tem implicações generalizadas em todos os sistemas de informação conectados. Nesse webcast dirigido aos profissionais de TI, teremos uma visão geral dos impactos e das soluções para Windows e Outlook Exchange.
Também oferecemos uma série de novos webcasts para ajudar os clientes e as organizações a se prepararem para o horário de verão, particularmente as novas mudanças na Rússia este ano. Isso é parte do nosso programa "passo a passo" para fazer a transição de DST. Você descobrirá uma lista dos próximos webcasts no nosso site DST & TZ em http://www.microsoft.com/time. Também incluímos alguns webcasts arquivados e sob demanda disponíveis aqui: http://support.microsoft.com/gp/dst_webcasts.
Noções básicas e preparação para a mudança do horário de verão da Rússia em 2011 (VIR66CAL)
15 de setembro de 2011, 10:00 am para 11:30 am - Horário de Verão do Pacífico (Clique aqui para calcular seu fuso horário local)
Apresentado por: M3 Sweatt, Gerente líder de programa, Microsoft Matthew Brown, Gerente de programa sênior, Microsoft Mike DeGooyer, Gerente de programa sênior, Microsoft Bala Sivakumar, Gerente de programa, Microsoft Ron Ragsdale, Gerente de programa, Microsoft Jenny Liu, Gerente de programa, Microsoft
Visão geral da sessão: em 2011, o governo da Rússia adotou uma lei para cancelar o horário de verão (DST). Como resultado, a Rússia não "retrocederá" para o horário de inverno. Esse webcast discutirá as implicações dessa decisão e o que a Microsoft está fazendo para atenuar essas implicações para nossos clientes e parceiros.
Nível: 200
Informações para o cliente Microsoft
Inscrição para a conferência: https://www.eventbuilder.com/event_desc.asp?p_event=u48c3q60
Suporte técnico: problemas com a conferência no dia da sessão? Clique aqui para suporte do Live Meeting ou ligue para: 866-493-2825
Antes do webcast: certifique-se de ter baixado a versão mais recente do Microsoft Office Live Meeting 2007. Para obter uma visão geral da plataforma e dos recursos do Microsoft Office Live Meeting 2007, visualize o guia de introdução aqui.
Esta é uma postagem localizada do blog. encontre o artigo original em Announcement: Upcoming Microsoft webcast on daylight saving time changes in Russia
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
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
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
ID de Evento: 3079
Fonte: MSExchangeIS Público
Tipo: Erro
Categoria: Erros de replicaçã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
ID de Evento: 9528
Categoria: Geral
Fonte: MSExchangeIS
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
Artigo original publicado na quinta-feira, 17 de novembro de 2011
Há alguns meses, Bruce Langworthy redigiu um excelente artigo relacionado a algumas novas recomendações para definir o valor de Tempo Limite de Disco do Windows - http://blogs.msdn.com/b/san/archive/2011/08/15/the-windows-disk-timeout-value-understanding-why-this-should-be-set-to-a-small-value.aspx.
Essa postagem me fez pensar sobre o Exchange e como nós lidamos com problemas de I/O. Se você ainda não leu o artigo de Bruce, ele explica que o tempo limite de disco padrão de 60 segundos significa que o Windows não irá relatar o travamento de I/O por 60 segundos e não irá tentar executar o I/O novamente por 8 minutos. Oito minutos é muito tempo para aguardar antes de tentar executar um I/O travado novamente, portanto, a Microsoft está lançando novas orientações, recomendando a alteração da definição do Tempo Limite de Disco do Windows para um valor que esteja alinhado com sua arquitetura de armazenamento.
A dúvida em minha cabeça sobre o Exchange era simples, como este comportamento de tempo limite do disco afeta as implantações do DAG do Exchange; mais especificamente eu devo reduzir o Tempo Limite de Disco do Windows nos meus servidores Exchange de acordo com as novas recomendações ou deixar como está??
Para responder essa pergunta, eu abordei alguns de nossos desenvolvedores ESE para saber o que eles pensam... isso é o resultado da discussão…
Eu decidi que antes de podermos determinar o que fazer com nossas definições de tempo limite de disco, devemos entender o que a inteligência do Exchange Server 2010 SP1 introduziu e como pode interagir com tempos limites de disco.
O Exchange Server 2010 SP1 trouxe algumas excelentes melhorias sobre como lidar com o travamento de I/O. Essas melhorias são discutidas em detalhes no seguinte artigo TechNet http://technet.microsoft.com/en-us/library/ff625233.aspx:
“O Exchange 2010 SP1 inclui uma nova lógica de recuperação que aproveita o comportamento de verificação de bug integrado do Windows quando ocorrem determinadas condições, especificamente quando ocorre o travamento de IO. No SP1, o Mecanismo de Armazenamento Extensível (ESE) foi atualizado para detectar travamentos de IO e para realizar ações corretivas para recuperar o servidor automaticamente. O ESE mantém um thread watchdog do IO, que detecta quando um IO está pendente por um período determinado de tempo. Por padrão, se um IO de um banco de dados está pendente por mais de um minuto, o ESE irá registrar um evento. Se um banco de dados possui um IO pendente por mais de 4 minutos, irá registrar um evento de falha específico, se for possível fazê-lo. O evento ESE 507, 508, 509 ou 510 pode ou não ser registrado, dependendo da natureza do travamento de IO. Se a natureza do problema é que o volume do SO é afetado ou a capacidade de gravar no log de evento é afetada, os eventos não serão registrados. Se os eventos são registrados, o serviço de Replicação do Microsoft Exchange (MSExchangeRepl.exe) irá detectar esta condição e causar uma verificação de bug intencional do Windows encerrando o processo wininit.exe.”
Então, o que isso significa? Bem, após algumas discussões (e algumas pesquisas do código ESE), a seguinte tabela foi criada para tornar o comportamento mais fácil de compreender (eu incluí versões anteriores do Exchange para referência).
Observação: eu realmente desejo agradecer muito ao Alexandre Costa e a Brett Shirley, dois desenvolvedores de ESE na equipe do Exchange e sem os quais este informe não teria sido possível – obrigado, pessoal!
Versão do Exchange
Tipo de I/O
Tempo de I/O
Comportamento
Exchange Server 2003
Concluído
>60 segundos
Exchange Server 2007
Exchange Server 2010 RTM
Exchange Server 2010 SP1
Em andamento
>4 minutos
>30 segundos
Observação: o I/O em andamento descreve uma operação de I/O lenta que não foi concluída com êxito. O I/O concluído representa um I/O lento que foi concluído, mas levou mais de 30 segundos. É importante observar aqui que, antes do Exchange Server 2010, não havia conceito para detectar I/O lentos em andamento, nós reportamos apenas uma vez que o I/O foi concluído.
Como a maioria das coisas, eu gostaria de aconselhar contra a mudança do novo comportamento a não ser que você tenha uma razão muito clara e convincente para fazer isso… No entanto, se você realmente precisa modificar um novo comportamento da Recuperação do mecanismo de armazenamento extensível no travamento de IO, existem algumas chaves de registro/atributos do Active Directory que permitem que você faça a mudança, o que está documentado aqui.
Se voltarmos para o motivo que me levou a redigir este artigo, era para avaliar se podíamos reduzir o Valor do Tempo Limite de Disco do Windows nos nós do servidor do DAG do Exchange, conforme recomendado aqui.
Após conversar com Matt Gossage da equipe do Exchange (Matt conhece tudo sobre o Exchange e o I/O), ele explicou que uma das coisas que o tempo limite de disco faz é proteger o host de tempestades de redefinição de barramento. Um dos efeitos colaterais interessantes quando um I/O atinge o Valor de Tempo Limite de Disco do Windows é que a unidade disk.sys irá emitir uma redefinição de barramento. Essa redefinição afeta todos os LUNs no servidor, não apenas o LUN que está falhando ao responder.
O cenário mais comum em que esse comportamento foi observado é com o Exchange 2010 e o armazenamento JBOD. Onde uma solução RAID é implantada, o controlador de disco pode lidar com leituras de blocos ruins lendo os dados de outro disco ou recalculando os dados de paridade. Isso atrasa o I/O, mas não significantemente. Com o JBOD, existe apenas uma única cópia do bloco de dados e, portanto, há a possibilidade de blocos ruins causarem um travamento de I/O enquanto aguardamos que o disco tente e leia os dados – resumindo, com uma implementação JBOD não queremos reduzir o Valor de Tempo Limite de disco e, de fato, podemos desejar até aumentá-lo para reduzir os efeitos de uma tempestade de redefinição de barramento se um dos eixos do disco JBOD começar a falhar.
A tabela a seguir destaca as recomendações para a definição do HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Disk\TimeOutValue para servidores que realizam o papel de caixa de correio do Exchange Server 2010.
Neil Johnson Consultor Sênior, MCS Reino Unido
Esta é uma postagem do blog traduzida. Encontre o artigo original em Windows Disk Timeouts and Exchange Server 2010
Artigo original publicado no domingo, dia 20 de novembro de 2011
No início de agosto deste ano, a equipe do Windows SE liberou o artigo da Base de Dados de Conhecimento (KB) a seguir e o hotfix do software que acompanha sobre um problema nos clusters de failover do Windows Server 2008 R2:
KB2550886 - Uma falha de comunicação transitória faz com que um cluster de failover do Windows Server 2008 R2 pare de funcionar
Esse hotfix é altamente recomendado para todos os grupos de bancos de dados de disponibilidade que são alongados em múltiplos datacenters. Para DAGs que não são alongados em múltiplos datacenters, também é recomendável ter esse hotfix. O artigo descreve um problema de deadlock da condição de corrida e do banco de dados de cluster que pode ocorrer quando um cluster de failover do Windows encontra uma falha de comunicação transitória. Há uma condição de corrida na lógica de reconexão de nós de cluster que se manifesta quando o cluster tem falhas de comunicação. Quando isso ocorre, ele faz com que o banco de dados de cluster trave, resultando em perda de quórum do cluster de failover.
Conforme descrito no TechNet, um grupo de disponibilidade de banco de dados (DAG) depende da funcionalidade de cluster específica, incluindo o banco de dados de cluster. Para que um DAG seja capaz de funcionar e fornecer alta disponibilidade, o cluster e o banco de dados de cluster também devem estar funcionando corretamente.
A Microsoft encontrou cenários nos quais uma falha de rede transiente ocorre (uma falha de comunicações de rede durante 60 segundos) e, como resultado, todo o cluster está com deadlock e todos os bancos de dados no DAG são desmontados. Como não é muito fácil determinar qual nó do cluster está realmente com deadlock, se um cluster de failover tiver deadlock como um resultado da reconexão da corrida lógica, o único curso de ação disponível será reiniciar todos os membros de todo o cluster para resolver a condição de deadlock.
O problema geralmente se manifesta na forma de perda de quórum de cluster devido a uma falha de comunicação assimétrica (quando dois nós não podem se comunicar entre si, mas ainda podem se comunicar com outros nós). Se houver atrasos entre outros nós no recebimento de mensagens de reagrupamento de cluster a partir do Gerenciador de Atualização Global (GUM) do cluster, as mensagens de reagrupamento poderão acabar sendo recebidas em ordem inesperada. Quando isso acontece, o cluster perde quórum em vez de executar o comportamento esperado, que é retirar um dos nós que sofreram a falha de comunicação inicial do cluster.
Geralmente, esse bug se manifesta quando há latência assimétrica (por exemplo, onde metade dos membros do DAG tem latência de 1 ms, enquanto a outra metade dos membros do DAG tem latência de 30 ms) nos dois nós do cluster que descobrem uma conexão interrompida entre si. Se o primeiro nó detectar uma perda de conexão bem antes do segundo nó, uma condição de corrida poderá ocorrer:
Se esse problema ocorrer, as consequências serão muito ruins para os DAGs. Como resultado, recomendamos que você implante este hotfix em todos os servidores da sua Caixa de Correio que são membros de um DAG, especialmente se o DAG estiver esticado em datacenters. Esse hotifx também poderá beneficiar os ambientes que executam Clusters de Cópia Única e Replicação Contínua em Cluster do Exchange 2007.
Além de corrigir o problema descrito acima, o KB2550886 também inclui outros hotfixes importantes do Windows Server 2008 R2 que também são recomendados para DAGs:
Esta é uma postagem de blog localizada. O artigo original encontra-se em Recommended Windows Hotfix for Database Availability Groups running Windows Server 2008 R2
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 AllisonGerente GeralExperiência do Usuário do Exchange
Esta é uma publicação de blog localizada. Encontre o artigo original em Lançamento: Exchange Server 2010 SP2
Artigo original publicado na sexta-feira, 23 de setembro de 2011.
Se você perdeu o Geeking out with Perry, ele está de volta em sua melhor forma com um novo blog e um episódio com edição especial do Geek Out with Perry. Nesse episódio, Perry fala sobre muitos assuntos referentes às pergutas registradas em junho, quando eu estava em Atlanta conversando com as pessoas que estavam participando da Tech·Ed North America. Matt Gossage, que é o Administrador Principal do Programa na equipe, estava do escritório de Perry quando eu cheguei para a gravação e Matt ajudou a fornecer informações adicionais sobre os tópicos de alta disponibilidade do Exchange 2010.
Além disso, também queríamos compartilhar algumas notícias interessantes sobre Perry que, sem dúvida, irá embaraçá-lo (Perry não gosta de se gabar) e fará com que ele reduza o tamanho limite da nossa caixa de correio como penitência para o que estamos prestes a dizer em seguida. Vamos enfrentá-lo, somos fãs de Perry Clarke, então, não podemos manter isso em segredo (como se você precisasse de um prêmio extra para ter um motivo para ler o blog do Perry e conferir os vídeos da série Geek Out with Perry.. ).
Sem mais delongas…
Perry Clarke torna-se um Distinguished Engineer Perry passou a maior parte dos seus 15 anos na Microsoft dentro do Grupo de Produtos do Exchange. Durante o desenvolvimento do Exchange 2007 e do Exchange 2010, ele liderou a Equipe de Engenharia do Servidor da Caixa de Correio. Atualmente, Perry gerencia toda a equipe de desenvolvimento do Exchange (o Grupo de Produtos do Exchange, assim como outros grupos de produtos, é dividido em quatro divisões:, gerenciamento de programa, desenvolvimento, teste e experiência do usuário). Hoje temos a satisfação de anunciar que Perry foi promovido para a função de Distinguished Engineer; existem menos de 60 pessoas com esse título na Microsoft. O título Distinguished Engineer é uma designação de líder técnico na Microsoft e as pessoas com esse título são reconhecidas por suas contribuições extraordinárias. Esses funcionários têm uma reputação de longa data de conhecimento técnico profundo construído sobre um corpo de trabalho sustentado e são as “principais pessoas cuja visão técnica, experiência e liderança de categoria internacional têm sido o instrumento no desenvolvimento e no manuseio de produtos e normas para a empresa e as indústrias.” Algumas contribuições extraordinárias de Perry foram: Ajudando a redefinir radicalmente o sistema de armazenamento nas duas últimas versões do Exchange para habilitá-lo a executar em servidores pequenos e escalonados com mercadoria de unidades SATA, com IOPSsignificativamente mais baixo. Perry, pessoalmente, tem defendido essa busca, apesar de algum ceticismo da indústria, com uma percepção profunda e fazendo acontecer. A liderança na condução da resiliência da caixa de correio também tem ajudado para que ele desempenhe um papel importante em ajudar a escalonar o Exchange para nuvem com o Office 365. Perry foi um membro essencial da equipe que ajudou a orientar a funcionalidade de arquivamento de e-mail corporativo e conformidade no Exchange 2010.
Perry passou a maior parte dos seus 15 anos na Microsoft dentro do Grupo de Produtos do Exchange. Durante o desenvolvimento do Exchange 2007 e do Exchange 2010, ele liderou a Equipe de Engenharia do Servidor da Caixa de Correio. Atualmente, Perry gerencia toda a equipe de desenvolvimento do Exchange (o Grupo de Produtos do Exchange, assim como outros grupos de produtos, é dividido em quatro divisões:, gerenciamento de programa, desenvolvimento, teste e experiência do usuário).
Hoje temos a satisfação de anunciar que Perry foi promovido para a função de Distinguished Engineer; existem menos de 60 pessoas com esse título na Microsoft.
O título Distinguished Engineer é uma designação de líder técnico na Microsoft e as pessoas com esse título são reconhecidas por suas contribuições extraordinárias. Esses funcionários têm uma reputação de longa data de conhecimento técnico profundo construído sobre um corpo de trabalho sustentado e são as “principais pessoas cuja visão técnica, experiência e liderança de categoria internacional têm sido o instrumento no desenvolvimento e no manuseio de produtos e normas para a empresa e as indústrias.”
Algumas contribuições extraordinárias de Perry foram:
Todos nós no Grupo de Produtos do Exchange, parabenizamos Perry pela sua merecida promoção.
Ann Vu
Esta é uma postagem localizada do blog. Encontre o artigo original em A Special Edition Geek out with Perry – Distinguished Engineer
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..
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
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.
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".
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
Artigo original publicado na segunda-feira, 31 de outubro de 2011
Na equipe do Exchange, é sempre importante para nós obtermos feedback de nossos clientes sobre o que estamos fazendo bem e o que poderíamos estar fazendo para tornar a experiência melhor para você. No Exchange 2007, em resposta a uma das maiores solicitações de recurso do Exchange 2003 OWA, apresentamos a Exibição de Documento WebReady. Isso permite que os usuários do OWA exibam os documentos do Microsoft Office e PDFs anexados em um navegador da Web sem ter que salvá-los em disco nem abri-los em um aplicativo instalado no local. Continuamos a oferecer essa funcionalidade no Exchange 2010, mas recebemos muitos comentários que o texto e a formatação dos documentos do Office nem sempre eram iguais ao documento original quando exibido nos aplicativos de cliente do Office de área de trabalho.
Estamos animados para anunciar uma atualização para o OWA no Exchange Online, que agora integra o Office Web Apps à experiência de visualização de anexos do Word, Excel e PowerPoint. Juntamente com o suporte a PDF, isso significa que os usuários do Exchange Online obtêm visualizações de alta fidelidade de documentos do Office na Web, exatamente no mesmo formato em que foram criados. A Exibição de Documento WebReady é perfeita para visualizações rápidas de documentos e, se você precisar editar um documento, poderá facilmente abrir o arquivo no seu cliente do Office de área de trabalho a partir do Office Web App com um único clique.
Clique no link "Abrir no navegador" ao lado de anexos de documentos do Office para começar a usar esse recurso no Exchange Online hoje.
David Alexander, Kartik Murthy
Esta é uma postagem de blog traduzida. O artigo original encontra-se em Introducing Office Web App Integration with Outlook Web App in Exchange Online
Artigo original publicado na segunda-feira, 14 de novembro de 2011
Ao longo dos anos, houve muito debate em relação aos recursos do Windows que são geralmente denominados Microsoft Scalable Networking Pack (recursos individuais são conhecidos como Receive Side Scaling (RSS) e Chimney/TCP Connection Offload/TOE), e ao efeito de tê-los ativados ou desativados em nossos servidores.
Aproveitando o assunto para falar da memória, embora seja verdade que, quando os recursos foram liberados no Windows 2003 SP2, havia alguns problemas a serem corrigidos (nos códigos da Microsoft e de terceiros, como drivers de rede), a situação melhorou dramaticamente ao longo dos anos, ao ponto em que desativá-los pode ter impacto significativo no desempenho dos servidores.
Veja um exemplo:
A captura de tela abaixo mostra uma das CPUs com carga em excesso, enquanto as outras não estão compartilhando a carga. Isso é bem típico em um servidor com conexão de rede ocupada e o recurso RSS desligado:
A figura a seguir mostra um pouco melhor o que acontece quando o RSS está de fato habilitado no servidor. O ponto da habilitação está ilustrado pelo círculo vermelho. Observe como um único processador estava muito ocupado com o tráfego de rede, enquanto o resto não estava tão ocupado, e observe o que acontece depois de o RSS ser habilitado:
Agora que tenho sua atenção, gostaria de recomendar um artigo que um dos meus colegas de equipe do Windows, Tod Edwards, escreveu recentemente: descreve detalhadamente o que são esses recursos, por que você deve habilitá-los, como fazê-lo e também como certificar-se de que esteja em um bom lugar quando o fizer. Para lê-lo, acesse:
Outro ponto de vista do Microsoft Scalable Networking Pack
http://www.windowsitpro.com/article/networking/give-microsofts-scalable-networking-pack-140350
Eu não deveria precisar lembrar: verifique se os drivers da placa de rede estão atualizados.
Aproveite!
Nino Bilic
Esta é uma postagem de blog traduzida. O artigo original encontra-se em Time to revisit recommendations around Windows networking enhancements usually called Microsoft Scalable Networking Pack