Éviter les méthodes d'intégration non pris en charge pour Exchange

IMPORTANT : Cet article est issu d'une traduction automatique réalisée par un logiciel Microsoft et non par un traducteur professionnel. Cette traduction automatique a pu aussi être révisée par la communauté Microsoft grâce à la technologie Community Translation Framework (CTF). Pour en savoir plus sur cette technologie, veuillez consulter la page http://support.microsoft.com/gp/machine-translation-corrections/fr. Microsoft vous propose en effet des articles traduits par des professionnels, des articles issus de traductions automatiques et des articles issus de traductions automatiques révisées par la communauté Microsoft, de manière à ce que vous ayez accès à tous les articles de notre Base de connaissances dans votre langue. Il est important de noter que les articles issus de la traduction automatique, y compris ceux révisés par la communauté Microsoft, peuvent contenir des erreurs de vocabulaire, de syntaxe ou de grammaire. Microsoft ne pourra être tenu responsable des imprécisions, erreurs, ainsi que de tout dommage résultant d’une traduction incorrecte du contenu ou de son utilisation par les clients.

La version anglaise de cet article est la suivante: 3086992
Introduction
Cet article décrit comment Microsoft Services de Support technique peuvent aider les développeurs à générer des solutions personnalisées qui implémentent également les divers standards ouverts et qui integratewith de Microsoft Exchange Server.
Plus d'informations
Lorsque vous écrivez du code pour Exchange Server, il est important que vous utilisiez prise en charge API et les méthodologies. Parfois, les développeurs essaie d'améliorer le comportement d'Exchange ou autrement intégrer des applications avec Exchange à l'aide d'une méthodologie non pris en charge. Cela peut entraîner de Exchange devenir instable et se comportent de façon inattendue.

Les pratiques suivantes ne sont pas pris en charge par Microsoft :

  • À l'aide de l'emprunt d'identité de thread sur Exchange à l'aide des API qui n'acceptent pas spécifiquement l'emprunt d'identité de thread
  • Modification de la OWA, EWS, EAS ou flux similaires sur le serveur d'accès Client
  • Exécution d'un module ou une extension ISAPI dans un pool d'applications Exchange
  • Modification du compte sous lequel s'exécute un pool d'applications Exchange
  • Injection de DLL dans le processus Exchange de manière non pris en charge
Exchange utilise des interfaces spécifiques et pratiques pour lesquelles il est conçu et testé. Étant donné que ces pratiques présentant les fonctionnalités à l'aide d'une méthodologie non pris en charge, Microsoft considère que ce type de développement à être pris en charge.

Lorsque le Support Microsoft rencontre des applications tierces qui semblent utiliser l'une des méthodes répertoriées, ils demandera probablement que vous supprimez l'application pour vérifier si le problème de reproduit. Si le problème ne se pose pas après la suppression de l'application tierce, vous devrez contacter les ingénieurs du support technique de ce produit pour résoudre le problème.

Exchange possède des vérifications visant à empêcher le code à partir d'emprunt d'identité du thread. Par exemple, Exchange peut arrêter son processus très soudainement (FastFail). Dans ce cas, événement 4999 est consigné dans le journal des événements Exchange et contient suivant le texte :

M.E.D.D.ConnectionPoolManager.BlockImpersonatedCallers

Les API telles que EWS qui permettent l'emprunt d'identité par d'autres applications ont themechanisms pour emprunter l'identité de comptes. Logiciel de sécurité et le logiciel d'ouverture de session unique sont des exemples courants d'applications qui utilisent l'emprunt d'identité du thread pour modifier les informations d'identification pour les appels qui sont envoyés à Exchange.

Code de tiers qui s'exécute dans une application dans le processus de pool d'anotherapplicationcan problèmes, sauf si les applications sont effectuées pour travailler avec une autres. Exchange ne permet pas d'autres applications s'exécutent sous son processus de travail. Les processus de pool d'applications Exchange appartiennent exclusivement à Exchange, et ne pas utiliser de code tiers sous les. Cette opération peut entraîner des conflits avec Exchange et peut provoquer l'échec des processus.

Certains développeurs modifier le compte sous lequel les parties de Microsoft Exchange fonctionnent pour bénéficier de certaines fonctionnalités qu'ils n'auraient pas sinon. Cette causeserver peut bloque, corruption de données, unexpectedproblems d'etautres. Ces problèmes peuvent se produire à tout moment dans le processus.

Il existe des méthodes prises en charge pour intégrer DLLswith Exchange personnalisées, telles que les agents de transport personnalisés. Nous ne recommandons pas l'utilisation d'une méthode qui n'est pas pris en charge par le développement d'Exchange. Par exemple, une injection forcée d'une DLL est une méthode non prise en charge pour charger une DLL personnalisée dans Exchange.

Il est très important que vous évitez des méthodes qui ne sont pas pris en charge lorsque vous envisagez d'intégrer des applications tierces avec Exchange. Ce type de pratique peut avoir de graves conséquences par la suite, tels que la perte de fonctionnalités ou de la nécessité de réécrire une application. En fin de compte, vous pouvez rencontrer un bloc de route et ne qu'aucun chemin d'accès dans lequel vous souhaitez déplacer vers l'avant.
Événement 4999 fastfail emprunt d'identité du thread de M.E.D.D.ConnectionPoolManager.BlockImpersonatedCallers pris en charge le filtre isapi de développement meilleur pratiques

Avertissement : Cet article a été traduit automatiquement.

Propriétés

ID d'article : 3086992 - Dernière mise à jour : 09/11/2015 21:01:00 - Révision : 1.0

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

  • kbsurveynew kbmt KB3086992 KbMtfr
Commentaires