Exchange and Outlook On The Same Machine

I was hoping to post something less controversial for my first blog entry, but this issue came up again recently and I felt I had to address it.

I'm frequently asked why I we don't support putting Outlook and Exchange on the same machine. One response I typically hear is “But I run both on my machine and never have a problem”. In this post, I'll attempt to clarify a few things and explain what kinds of problems you can expect when you put Outlook and Exchange on the same server.

A couple definitions - shorthand mainly:

Admin: The Exchange Administrator (5.5) or the Exchange System Manager (2000 and 2003).

MAPI: Used by iself, refers to Extended MAPI. I'll spell out Simple MAPI when I need to make a distinction.

The main thing to clear up is that the warning against putting the Outlook and Exchange on the same machine applies primarily to servers and other mission critical machines. Basically, if your server hosts an application which uses MAPI, you should never install Outlook on it.

So why do the articles make a point to say not combine the Admin and Outlook? The answer is because there are a large number of server applications out there which rely on MAPI for integration with Exchange. Examples include voicemail, PDA synchronization, workflow, archival, legal discovery and connectors (gateways) to third party mail/database systems. The recommended method for installing MAPI onto a server for one of these applications is to install the Admin.

Here's a (greatly simplified) synopsis of MAPI's architecture. The core file is mapi32.dll. After loading MAPI, applications then open message stores and address books. These are implemented by providers. The providers which allows MAPI to talk to Exchange and the directory are emsmdb32.dll and emsabp32.dll.

MAPI was designed so that anyone could implement the core component and providers. A few companies did choose to implement the Simple MAPI portion of the API in their own mapi32.dll, but AFAIK, the only currently available implementations of the Extended MAPI portion of the API are those shipped by Outlook and Exchange. A key flaw in the original MAPI design is that it did not allow for multiple implementations to coexist.

Life would be very simple if the mapi32, emsmdb32 and emsabp32 shipped by Outlook and Exchange were the same implementation, built out of the same code tree. If that were the case, the only concern would be keeping up with the latest builds.

However, life is not this simple. Outlook and Exchange have different needs from MAPI, and, as such, the code for their implementations has diverged a good deal. Exchange needs high stability and scalability out of MAPI, so a good portion of the design and testing is focused on eliminating potential deadlocks and memory leaks. Outlook needs a strong user experience, so the focus is on features like Cancel RPC, RPC over HTTP, Cached Mode, and server reconnect. Outlook also needed to solve the coexistence problem to allow for other mail clients, so enter the MAPI Stub.

The stub library works by acting as a central dispatcher for MAPI calls, proxying the calls out to the various implementations of MAPI which may be on the box. There's a performance penalty to the stub library's proxying mechanism though. This performance penalty was not acceptable in a server environment, so Exchange declined to support their implementation of MAPI with the stub. The effect of all this is that Exchange's providers expect to be loaded by Exchange's MAPI, and Outlook's providers expect to be loaded by Outlook's MAPI. We can't guarantee this will be the case if both are installed on the same box.

I began this post promising to list some concrete examples of the problems this can cause. These are real issues I've encountered as an Escalation Engineer:

  • Missing interfaces - Exchange has recently extended the IExchangeManageStore interface to allow the Admin to provide listings of over 65000 mailboxes and public folders. The new interfaces required for this are not in Outlook's Emsmdb32.
  • Memory leaks and deadlocks - Outlook's MAPI trails far behind Exchange's MAPI in shipping fixes for issues which can show in high stress multithreaded MAPI applications. This is not suprising considering the level of testing Exchange's implementation gets, not only internally but by third parties. Quite often, we get calls from our partners saying that “the latest fix didn't work” - that their customer is still seeing a leak/deadlock/transient hang that should have been fixed by a recent hotfix. On investigation, we'll find that some administrator at the customer's site had installed Outlook on the application server “just for testing“, essentially forcing the application to run in an environment where it was never previously tested.
  • Stub dependencies Lead to Crashes - Just found this one last week. The Outlook stub library works great with Simple MAPI, which has only 12 functions, each with a well defined DLL entry points. Proxying Extended MAPI calls is much more complex - more places to fail. In the scenario I debugged, Outlook's stub failed to locate the entry points for some functions in Exchange's Emsmdb, so the function pointers were left NULL, leading to a crash when we tried to invoke the functions. I believe the setup was Exchange 2000 with Outlook 2000.
  • Simple MAPI - I just mentioned the stub library works great with Simple MAPI, but it can't work at all if Simple MAPI isn't there. As of Exchange 2003, Exchange no longer implements Simple MAPI. The API was removed to reduce the potential attack surface.
  • Rpc_Binding_Order - Installing Outlook on an Exchange cluster will prevent mad.exe from logging on. The Exchange release notes only indicate Freebusy won't work, but that's just one effect of mad.exe failing. Any other MAPI based program could fail in this scenario as well.

Of course, most of these problems could be solved (any problem can be solved, right?), and the stub library is a good first step, but committing to support of this configuration would greatly expand the test matrices of both Exchange and Outlook, not to mention the increased test burden for third party server applications using MAPI. Unfortunately, we've not been able to justify the cost this would entail.

So, can you put Outlook and the Exchange Admin on the same box? If you're just talking about an administrator's desktop, one which can be rebooted on a whim or even rebuilt if needed, where downtime isn't a big issue, sure - it still won't be supported, but you might get away with it. If you're talking about your Exchange server or a server hosting an application integrated with Exchange, you do so at your own peril.

[Comments on this post have been closed]

Comments (23)

  1. Venkat Ramisetty says:

    This article clarified quiet a few doubts i used have and thanks a lot Steve.

  2. andy says:

    I don’t see how re-joining the models increases third party test matrices. From a third party perspective, we get every bit as much pressure to run /on/ the exchange server as we do to run /not on/ the exchange server. That means we have to test with both versions of MAPI exhaustively – double the load, not less.

  3. I’m not sure what sort of product you develop, so you may be right for your case. However, most server side MAPI applications that put a big stress on MAPI run on Exchange based systems, not Outlook based systems. So companies developing those applications don’t test with Outlook and don’t have many customers who run their applications with Outlook. And the bulk of the issues we see with MAPI under stress are discovered in the wild, not in test labs. This leads to more reports coming in for Exchange’s MAPI, leading in turn to a more stable implementation. It’s kinda like evolution.

    Also, I think you missed my point about putting Outlook and Exchange on the same server increasing the test matrix – it’s not double – it’s exponential. The reason is you don’t have a good guarantee which version of each file you’re gonna load – you might get Exchange’s emsmdb32 with Outlook’s emsabp32 with Exchange’s emsui32x with Outlook’s mapi32, etc. And then multiply that by all the versions of Outlook someone could have installed on all the versions of Exchange.

  4. This post was inspired by a case I worked recently. In this case, the customer was using the 5.5 Event…

  5. I’m working on a followup to my memory management article and a writeup on a MAPI deleted profile bug…

  6. GThompson says:

    How do you correct the situation if you have Outlook installed on an Exchange 2003 server?  I assume uninstalling Outlook would remove the MAPI dll and break Exchange!?

  7. My recommendation is always to rebuild the server from scratch. I would never trust an Exchange server that has had Outlook installed on it.

    If you do try to go the uninstall route you’ll need to at least rerun the exchange installation and reapply service packs.

  8. You can now download the MAPI subsystem and CDO 1.21 from Microsoft and install them separate from Exchange…

  9. This is from an email I send out this morning after a discussion about CDO 1.21 and the Exchange store

  10. This has long been a challenge for many and I have yet to see a complete solution to the problem of getting…

  11. There has been some questions on the newsgroups with regards to installing Outlook 2007 on an Exchange

  12. A couple notes from the field as we enter the window of time that is DST 2007… Due to the security

  13. SYMPTOMS: ======================== I recently assisted with a CDO 1.21 DST related issue where custom

  14. You can now download the MAPI subsystem and CDO 1.21 from Microsoft and install them separate from Exchange

  15. This post was inspired by a case I worked recently. In this case, the customer was using the 5.5 Event

  16. We recently released a downloadable Exchange System Manager (ESM) for Exchange 2003 which can be installed

Skip to main content