I had a case recently where the customer was had written a service application using Extended MAPI. The customer found that in his test environment the call to
MAPILogonEx() was hanging and not returning. After debugging it, we realized that the hang was caused by an unseen SSL security prompt. The target Exchange server hosting Autodiscover was using a self-signed certificate. Because the transport being used was RPC over HTTP (ROH) and the certificate was untrusted by the client, Outlook was prompting the “user” to accept the use of the certificate. Since this was a service application and there was no one to accept the prompt, MAPILogonEx() would hang. Ultimately, this is a by-design issue with ROH. ROH doesn’t allow you to “trust” certain types of security prompts, although you really wouldn’t want to anyhow. Since Outlook can’t proceed without someone trusting the certificate, it needs to prompt. To workaround this, the developer has two options:
- Use only trusted certificates for your Exchange Server. Even in the scenario of a self-signed certificate, you can manually trust the certificate or possibly create a GPO for all machines in the organization to trust it.
- Use the registry value outlined in this article:
Outlook 2016 displays a prompt that lets you connect to an Exchange server if a certificate issue occurs https://support.microsoft.com/en-us/kb/3114926
If you use the latter, understand that the request will fail and that should cause
MAPILogonEx() to fail. However, the failure not may be immediately obvious. You may not see the result of the failure until a subsequent call to MAPI (e.g.