A partir de 20 de junho de 2013, a Microsoft não publicará mais novos conteúdos neste blog (mas o arquivo com postagens existentes permanecerá ativo). No futuro, visite http://blogs.technet.com/b/exchange para encontrar as informações mais recentes para Profissionais de TI sobre o Microsoft Exchange Server.
Artigo original publicado na sexta-feira, 29 de março de 2013
Sou engenheiro de suporte em CSS. Estava trabalhando com um cliente que reportou um erro de loop de e-mail para um domínio específico como contoso.com. Esse erro foi observado apenas em e-mails grandes. Sim, é realmente um mistério até você descobrir que isso é causado por uma restrição de tamanho no conector Enviar. Achei que isso fosse curioso o suficiente para compartilhar.
Inicialmente, pensei que talvez fosse o resultado da configuração do servidor de Borda para o uso de um servidor DNS externo (um servidor DNS que resolve hospedagens externas). Normalmente, quando o servidor Transporte de Borda é configurado para usar um DNS externo, ele resolve o nome de domínio para os endereços IP públicos (geralmente apontando para si próprio, para o firewall externo ou provedor de serviço) em vez de um servidor Transporte de Hub no site do Active Diectory, causando um loop de e-mail.
Ao reproduzir o problema, descobri que o servidor Transporte de Borda não foi configurado para usar um servidor DNS externo. O ambiente que configurei para reproduzir o problema parecia com o diagrama abaixo:
Veja o que aconteceu nesse cenário: quando o servidor Transporte de Borda recebe um e-mail de 20 MB de um remetente na Internet, ele o aceita. O servidor Transporte de Borda tem dois conectores que correspondem ao espaço do endereço - um para o espaço de endereço contoso.com para o site do Active Directory e outro para o espaço de endereço *. Ao tomar a decisão de encaminhamento com base em todos os conectores disponíveis, aquele da Borda para o Hub não é considerado, devido à restrição de tamanho (há um limite de tamanho de 10 MB). A melhor correspondência é o conector * da Borda para a Internet (Revise o algoritmo de seleção de conector documentado em Noções Básicas Sobre Roteamento de Mensagens) que tem um limite de tamanho de mensagem de 30 MB.
Resultado final: a mensagem é encaminhada de volta para a Internet causando o loop da mensagem entre a Internet e o servidor de Borda.
Com base no conector Enviar para a Internet configurado para usar DNS ou um Host inteligente para entregar o e-mail de saída, receberemos os seguintes NDRs:
Se estiver usando DNS:
#554 5.4.4 SMTPSEND.DNS.MxLoopback; DNS records for this domain are configured in a loop ##
Se estiver usando um Host inteligente:
5.4.6 smtp;554 5.4.6 Hop count exceeded - possible mail loop> #SMTP#
Esse comportamento ocorre por padrão e pode ser facilmente corrigido por meio da modificação do limite de tamanho da mensagem no conector. Com base em seu requisito, é possível escolher uma das seguintes opções:
Mistério solucionado! Agradeço a Arindam Thokder e Scott Landry, que me ajudaram a preparar este material para o blog!
Esta é uma postagem de blog localizada. Encontre o artigo original em Mysterious mail loop on Edge Transport server: Check your size limits!
Artigo original publicado na terça-feira, 12 de março de 2013
Em novembro de 2012, anunciamos nosso cliente Beta do MCA. Estivemos bastante ocupados trabalhando para aprimorar as opções de teste disponíveis a partir do cliente MCA. Veja o que construímos para a versão 1.0:
Estamos empolgados em anunciar a versão 1.0 do Microsoft Connectivity Analyzer. Essa ferramenta é um complemento para o site Microsoft Remote Connectivity Analyzer. A ferramenta MCA fornece aos administradores e usuários finais a habilidade de executar diagnósticos para cinco sintomas de conectividade comuns diretamente se seus computadores locais. Os usuários podem testar sua própria conectividade e salvar os resultados em um formato HTML que os administradores reconhecerão a partir dos resultados no site do RCA.
Instale a ferramenta MCA 1.0 aqui: https://testconnectivity.microsoft.com/?tabid=client
Assista ao vídeo de introdução:
Microsoft Lync Connectivity Analyzer Tool: Você também perceberá a Lync Connectivity Analyzer Tool na página cliente. Estamos trabalhando para combinar o MCA com MLCA no futuro próximo, mas queríamos disponibilizar essas duas ótimas ferramentas para os clientes a fim de aprimorar nossas opções de diagnóstico do cliente. Para saber mais sobre a MLCA – clique AQUI
Feedback: envie todo feedback para o alias MCA Feedback. Diga-nos o que pensa da ferramenta e se ela será útil na solução de problemas de cenário de conectividade. Além disso, sinta-se a vontade para fornecer feedback sobre testes adicionais que você deseja adicionar futuramente.
Estamos empolgados em anunciar a versão 2.1 do site do Microsoft Remote Connectivity Analyzer. A ferramenta fornece aos administradores e aos usuários finais a habilidade de executar diagnósticos de conectividade para nossos servidores a fim de testar problemas comuns com o Exchange, Lync e Office 365. Adicionamos os novos testes de Servidor de nome de domínio do Office 365, aprimoramos os testes existentes e aprimoramos a experiência geral do site.
Confira as atualizações do site aqui: https://testconnectivity.microsoft.com
Versão 2.1 (março de 2013)
Aproveite!
Obrigado.
em nome de toda a equipe do MCA/RCA.
Siga a equipe no Twitter - @ExRCA
Esta é uma postagem de blog localizada. Encontre o artigo original em Announcing Microsoft Connectivity Analyzer (MCA) 1.0 and Microsoft Remote Connectivity Analyzer (RCA) 2.1
Artigo original publicado na quinta-feira, 21 de fevereiro de 2013
Temos o prazer de anunciar o documento frequentemente solicitado Orientação a hospedagem e multi-locatário para Exchange Server 2013. Ele está disponível para download aqui.
Como leitor perspicaz observará, ele é bastante parecido com a orientação para Exchange Server 2010. Não porque localizamos, copiamos e substituímos, mas porque a estratégia que decidimos para o Exchange 2010 se mantém para o Exchange 2013. Ou seja, você deve usar apenas as ferramentas integradas, cmdlets e interfaces para configurar sua solução e você não deve, sob nenhuma circunstância, manipular diretamente objetos no AD para à atender sua configuração desejada.
O que também ficou é a noção de que nem todos os recursos funcionarão como você deseja em uma configuração parecida com multi-locatário. Por exemplo, MailTips funcionará exatamente da mesma maneira que em uma implantação do tipo local padrão – e isso normalmente pode resultar na exposição de dados indesejados entre locatários. O documento realça recursos que talvez não funcionem conforme o esperado quando você configura o Exchange para multi-locatários e faz recomendações para configuração ou desativação onde for necessário.
Fundamental para o elemento importante de segmentação de diretório de sua solução é o recurso Política de Catálogo de Endereços. Com o anúncio recente de um agente de transporte, criado para aproveitar a vantagem das Políticas de Catálogo de Endereços, esperamos que você considere sua solução de 2013 ainda mais fácil de construir e manter.
Observe que há algumas mudanças importantes para 2013 e, portanto, o incentivamos a ler a orientação completamente antes de planejar e construir sua solução e consulte-a novamente quando necessário, se você enfrentar algum problema.
Assim como ocorre com o Exchange 2010, temos soluções de parceiros construídas seguindo as diretrizes no documento, e as soluções que validamos no momento também estão listadas no site. Essa lista crescerá, portanto consulte-a novamente caso a solução que você deseja usar não estiver atualmente na lista ou entre em contato com o fornecedor e pergunte sobre os planos para validação.
Planejamos lançar uma Orientação de escala para Exchange 2013 atualizada, configurada para multi-locatário ou hospedagem, e atualizaremos o site de soluções quando esse documento estiver disponível.
Esperamos que você considere o documento útil e esperamos seu feedback.
Líder gerente de programa principal
Exchange Customer Experience
Esta é uma postagem de blog localizada. Encontre o artigo original em Hosting and Multi-Tenancy Guidance for Exchange Server 2013 Now Available
Artigo original publicado na terça-feira, 13 de novembro de 2012
Recentemente, lançamos um GWT (guia passo a passo interativo) para solucionar problemas de replicação de pastas públicas no Microsoft Exchange 2003. Há alguns modos de acessar a solução de problemas. Você pode usar este link para acessá-lo diretamente. Além disso, ele estará inserido em vários artigos relacionados à replicação de pastas públicas, como este: http://support.microsoft.com/KB/842273.
Sei que você está se perguntando por que lançamos uma solução de problemas para o Exchange 2003, já que ele não faz mais parte do suporte base. Tomamos essa decisão por diversos motivos. Em primeiro lugar, há muitos clientes do Exchange que ainda utilizam o Exchange 2003, e queremos ajudá-los na medida do possível para que eles possam mudar para as versões do produto com suporte. Esse é o melhor modo de orientar esses clientes, já que não temos mais à disposição uma opção de suporte telefônico para eles. Em segundo lugar, de modo geral, todos os problemas com pastas públicas do Exchange Server 2003 já foram identificados. Por isso, pudemos criar uma solução de problemas que aborde esse material e que não passe por mudanças drásticas. Por fim, como o mecanismo de replicação de pastas públicas não passou por alterações significativas por algum tempo (até o Exchange 2013), fez sentido iniciar com Exchange 2003, pois ele nos proporcionou a estrutura para que possamos fazer atualizações relacionadas às versões posteriores com relativa facilidade.
A organização de suporte dedicará esforços na expansão dessa solução de problemas, de modo que, futuramente, inclua as versões 2007/2010.
Na verdade, esse guia passo a passo é um guia para a solução de problemas de replicação, conforme explicado em uma série de posts de Bill Long, aqui, aqui e aqui. O objetivo dele não é substituir todas as informações que ajudam na compreensão do processo de replicação de pastas públicas, mas sim fornecer rapidamente as etapas necessárias para que você localize o problema (caso haja problemas de replicação).
Gostaria de agradecer às pessoas que ajudaram a transformar tudo isso em realidade. Aqui estão as partes envolvidas (até onde eu sei):
Suporte do Exchange:
Equipes de criação de conteúdo/documentação:
Atenciosamente,
Engenheira de conhecimento de sistemas de mensagens
Esta é uma postagem de blog traduzida. Consulte o artigo original em Public Folder replication troubleshooter