Async MAPI Notifications in Exchange are a problem for MAPI clients that impersonate

I had a case six months ago where the customer was using Exchange’s MAPI against Exchange 2013 and was seeing a number of MAPI_E_NETWORK_ERRORs in his application. After discussing the issue with him it was determined that the application was running in the security context of Local System but would impersonate a user who has access to the target mailbox on the thread doing the work.

Impersonation support in MAPI has always been suspect. Outlook’s MAPI does not support it. In Exchange’s MAPI it seems to work, but that is most likely because it doesn't do anything to conflict with its use. At least until Exchange’s MAPI started supporting Asynchronous MAPI Notifications for Exchange 2010. Async MAPI Notifications use Asynchronous RPC to receive notifications from the Exchange Server. This allows MAPI to park a request with the Exchange Server and not have to wait for the next remote operation to get notifications. The problem comes in when a MAPI client is impersonating on one thread and the identity of that thread does not flow to the threads responsible for servicing the Async RPC. The result is that the threads responsible for the Async RPC do not use the impersonated security context and instead use the security context of the process itself.

In Exchange 2013's Outlook Anywhere, the RPC Association and the security context are used to identify the client connection. Exchange 2013 caches this data to use in subsequent requests. This is called a "registration". When the security contexts don’t match between requests, but the RPC Associations do, you get the error “Registration of the Association GUID failed”. Since Exchange doesn’t know how to proceed with the request it fails it and you start receiving MAPI_E_NETWORK_ERROR on the client side. It also removes the registration from its cache. This means that the thread responsible for Async notification causes impersonated threads to fail because they no longer have a registration on the server.

The fix is to not use impersonation in your application. Instead, run your process in the security context of a user who has permissions to access the target mailbox[es]. If you can’t do that, set the flag CONNECT_NO_NOTIFICATIONS (0x20) on the profile property PR_PROFILE_CONNECT_FLAGS. This will instruct the MAPI download to not use notifications at all. The caveat to this is that if your application utilizes notifications you will not be able to use this flag.