"Enhancing Exchange" via unsupported methods.

Every so often we run into cases where customers try to augment the behavior of Exchange or otherwise integrate with it using some unsupported methodology.  When this is done Exchange may become unstable and behave in unexpected ways.  It’s extremely important to stick to what is supported.  If you venture into the land of the unsupported then you may find yourself having to do a major rewrite or at a dead-end and scrambling to find a path forward.

Prior in my blog I pointed out that doing things like changing the flow of traffic in an ISAPI filter, etc for OWA or EWS is not supported.  Overall it is an inappropriate way to "tweak" Exchange in order to introduce features using an unsupported methodology.  Below are some additional things we see developers doing which Microsoft does not support doing.   When we see such things being  done by a third party application we will most likely ask that the application be removed to see if the issue reproduces and if it only reproduces with the third party application then you would need to talk to that products support for assistance.

• Doing any thread impersonation when talking to Exchange.
• Modifying the OWA, EWS, EAS, etc. streams on the CAS.
• Running an ISAPI Extension/module under an Exchange application pool .
• Modifying the account an Exchange application pool runs under.

Exchange does have some checks in place to prevent things such as doing thread impersonation – this will cause Exchange to shut-down its process very abruptly (FastFail).  In such a case you should find an Event 4999 in Exchange’s Application Event log with "M.E.D.D.ConnectionPoolManager.BlockImpersonatedCallers"noted in its text.  Our APIs have which allow impersonation such as EWS have their own facility to support impersonation.  The types of applications which I usually see thread impersonation being done to change credentials on calls being sent to Exchange are security software and single sign-on software.

Running third party code under another applications worker pool process is generally a really bad idea. Exchange’s application pool process belong to Exchange and no third party code should be running under them.  Doing so may cause issues with Exchange and could take down the process.

I’ve seen some customers wanting to change the account that parts of Exchange work under in order to gain some functionality they could not otherwise have.  Doing something like this could cause problems that would manifest at any point and in in unknown ways.  It possibly could cause crashes and data corruption.

So, its highly important that when considering options for integrating with Exchange that you don’t go down the unsupported path.  If you till choose to do so then you would need to live with the consequences – which could include the rewrite of an application, loss of functionality or even hitting a road block with no path to move forward.

Comments

• Anonymous
  February 25, 2015
  Another area of development which is not supported for messaging development is injecting a DLL or otherwise modifying an Exchange process. Further, this method of development would require some reverse engineering of Exchange code in order to tie into a running process - please refere to your Exchange EULA on this topic.  The reason for this type of development is often to tie into running code which has no supported interface and the methods and events which would be tied into are usually not documented.

• Anonymous
  September 11, 2015
  Please refer to the following KB:    Avoid unsupported integration methods for Exchange    support.microsoft.com/.../3086992