Avoid unsupported integration methods for Exchange

Applies to: Exchange Server 2013 EnterpriseExchange Server 2010 EnterpriseExchange Server 2016 Enterprise Edition


This article describes how Microsoft Customer Service and Support can help developers produce custom solutions that use various open standards and that also integrate with Microsoft Exchange Server.

More Information

It's important to use supported APIs and methodologies when you write code for Exchange Server. Sometimes, developers try to augment the behavior of Exchange or otherwise integrate applications with Exchange Server by using some unsupported methodology. This can cause Exchange to become unstable and behave in an unexpected manner.

The following practices are not supported by Microsoft:
  • Using thread impersonation against Exchange by using APIs that do not specifically support thread impersonation
  • Changing the OWA, EWS, EAS, or similar streams on the Client Access server (CAS)
  • Running an ISAPI extension or module in an Exchange application pool
  • Changing the account under which an Exchange application pool runs
  • Injecting DLLs into Exchange processes in an unsupported manner
Exchange Server uses specific interfaces and practices for which it is designed and tested. Because these particular practices introduce features by using an unsupported methodology, Microsoft considers this type of development to be unsupported. 

When Microsoft Support agents encounter third-party applications that seem to use one of the listed methodologies, they will most likely ask you to remove the application to check whether the issue reproduces. If the issue does not reproduce after the third-party application is removed, you would have to contact the support engineers for that product to resolve the problem.

Exchange has checks to prevent code from doing thread impersonation. For example, Exchange can shut down its process very suddenly (FastFail). In this situation, Event 4999 is logged in the Exchange event log. It contains the following text:
APIs such as EWS that allow impersonation by other applications have the mechanisms to impersonate accounts themselves. Security software and single sign-on software are common examples of applications that use thread impersonation to change credentials on calls that are sent to Exchange.

Third-party code that is run in one application under the worker pool process of another application can cause issues unless the applications are made to work with one other. Exchange does not allow other applications to run under its worker processes. The Exchange application pool processes belong exclusively to Exchange, and you should not run third-party code under them. Doing this may cause conflicts with Exchange and could cause processes to fail.

Some developers change the account under which parts of Exchange work in order to gain some functionality that they would not have otherwise. This can cause server crashes, data corruption, and other unexpected problems. These problems might occur at any point in the process.

There are supported ways to integrate custom DLLs with Exchange, such as custom transport agents. We do not recommend using a method that is not supported by Exchange development. For example, a forced injection of a DLL is an unsupported method to load a custom DLL into Exchange.

It’s very important that you avoid methods that are not supported when you consider the option to integrate third-party applications with Exchange. This kind of practice can have severe consequences later, such as lost functionality or the need to rewrite an application. In the end, you might encounter a road block and have no path in which to move forward.