Evitar métodos de integração sem suporte para o Exchange

IMPORTANTE: Este artigo foi traduzido pelo software de tradução automática da Microsoft e eventualmente pode ter sido editado pela Microsoft Community através da tecnologia Community Translation Framework (CTF) ou por um tradutor profissional. A Microsoft oferece artigos traduzidos automaticamente por software, por tradutores profissionais e editados pela comunidade para que você tenha acesso a todos os artigos de nossa Base de Conhecimento em diversos idiomas. No entanto, um artigo traduzido pode conter erros de vocabulário, sintaxe e/ou gramática. A Microsoft não é responsável por qualquer inexatidão, erro ou dano causado por qualquer tradução imprecisa do conteúdo ou por seu uso pelos nossos clientes.

Clique aqui para ver a versão em Inglês deste artigo: 3086992
Introdução
Este artigo descreve como suporte e atendimento ao cliente Microsoft podem ajudar os desenvolvedores a produzir soluções personalizadas que implementam vários padrões abertos e que também degerenciamento integradosà Microsoft Exchange Server.
Mais Informações
Quando você escreve código para Exchange Server, é importante que você use suporte para APIs e metodologias. Às vezes, os desenvolvedores tentam aumentar o comportamento do Exchange ou caso contrário integrar aplicativos com o Exchange usando alguma metodologia sem suporte. Isso pode fazer com que o Exchange tornar-se instável e se comportem de maneira inesperada.

As práticas a seguir não são suportadas pela Microsoft:

  • Usando a representação do thread no Exchange usando APIs que não suportam especificamente representação do thread
  • Alterando o OWA, EWS, EAS ou fluxos semelhantes no servidor acesso para cliente
  • Executando uma extensão ISAPI ou um módulo em um pool de aplicativos do Exchange
  • Alterar a conta sob a qual é executado um pool de aplicativos do Exchange
  • Injetando DLLs em processos do Exchange de uma maneira sem suporte
O Exchange usa interfaces específicas e práticas recomendadas para a qual ela é criada e testada. Porque essas práticas apresentam recursos usando uma metodologia de suporte, a Microsoft considera esse tipo de desenvolvimento não são compatíveis.

Quando o Microsoft Support encontra aplicativos de terceiros que parecem usar uma das metodologias listadas, eles provavelmente solicitar que você remova o aplicativo para verificar se reproduz o problema. Se o problema não reproduzir após a remoção do aplicativo de terceiros, você teria que entrar em contato com os engenheiros de suporte do produto para resolver o problema.

O Exchange possui verificações para impedir que o código faça representação do thread. Por exemplo, Exchange pode desligar seu processo muito repentinamente (FastFail). Nessa situação, 4999 de evento é registrada no log de eventos do Exchange e contémos texto a seguir:

M.E.D.D.ConnectionPoolManager.BlockImpersonatedCallers

APIs como EWS que permitem a representação por outros aplicativos têm themechanisms representar contas próprias. Software de segurança e o software de logon único são exemplos comuns de aplicativos que usam a representação do thread para alterar as credenciais de chamadas são enviadas ao Exchange.

Código de terceiros que é executado em um aplicativo sob o processo de trabalho do pool de anotherapplicationcan causar problemas a menos que os aplicativos são feitos para trabalhar com um outros. Exchange não permite que outros aplicativos sejam executados em seus processos de trabalho. Os processos de pool de aplicativos do Exchange pertencem exclusivamente ao Exchange e você não deve executar o terceiro código abaixo delas. Isso pode causar conflitos com o Exchange e pode causar falha dos processos.

Alguns desenvolvedores alterar a conta sob a qual partes do Exchange funcionam para obter algumas funcionalidades que não teria caso contrário. Este causeserver pode falha, corrupção de dados e de outros unexpectedproblems. Esses problemas podem ocorrer em qualquer ponto no processo.

Existem maneiras com suporte para integrar a troca de DLLswith personalizado, como agentes de transporte personalizado. Não recomendamos o uso de um método não é suportado pelo desenvolvimento do Exchange. Por exemplo, uma inclusão forçada de uma DLL é um método não suportado para carregar uma DLL personalizada no Exchange.

É muito importante que você evite métodos que não são suportados quando você considerar a opção de integrar aplicativos de terceiros com o Exchange. Esse tipo de prática pode ter conseqüências graves mais tarde, como perda de funcionalidade ou a necessidade de reescrever um aplicativo. No final da contas, você pode encontrar um bloco de estrada e não ter nenhum caminho mover para frente.
Evento 4999 fastfail representação de segmento M.E.D.D.ConnectionPoolManager.BlockImpersonatedCallers suporte para filtro de isapi de desenvolvimento de práticas recomendado

Aviso: este artigo foi traduzido automaticamente

Propriedades

ID do Artigo: 3086992 - Última Revisão: 09/11/2015 21:03:00 - Revisão: 1.0

Microsoft Exchange Server 2013 Enterprise, Microsoft Exchange Server 2010 Enterprise, Microsoft Exchange Server 2007 Enterprise Edition

  • kbsurveynew kbmt KB3086992 KbMtpt
Comentários