Share via

Microsoft Lync 2010 MAPI COM Server Authentication Prompt Explained

  • Article

One of my customers informed me that some users received the Microsoft Lync MAPI COM server authentication prompt and it was confusing them.

We could narrow the behavior down to the following:

  • it only appeared when Outlook was closed
  • it most of the time happened only for remote users.
  • Outlook Anywhere on Exchange was set for Basic Authentication.
  • EWS integration with Lync was working fine (EWS Status OK).

Since I could reproduce the behavior on our own production system and some of my Pro-Lync peers indicated that they saw the exact same behavior on their systems too, I decided to get to the bottom and spread the word. To be sure I involved Microsoft Support Services to confirm my findings.

How it looks like

I bet that you already know how it looks like since you’re reading this post, but for reference this is how it looks like:

http://www.pro-exchange.be/resized-image.ashx/__size/550x0/__key/CommunityServer.Blogs.Components.WeblogFiles/ocs_5F00_wave_5F00_14/LyncMAPI2010COMServer.png

What is it?

Plain and simple: Lync 2010 tries to connect to Exchange server using MAPI, notices that it requires credentials and asks them to the user.

It has good technical reasons for that (keep on reading), but it still is annoying and confusing for your users.

Where does it come from?

Some background...

To explain what the “Lync MAPI COM Server” authentication prompt is and where it comes from, we’ll have to dig into how Lync 2010 interacts with Exchange.

Lync 2010 needs to talk to Exchange for various reasons:

  • Access conversation history and voice mail
  • Play back voice mail messages
  • Display free/busy information and working hours
  • Display meeting subject, time, and location
  • Display Out of Office status and note
  • Exchange contact sync
  • Search Outlook personal contacts

Lync 2010 has 2 ways to communicate with Exchange, which are explained on the technet Lync 2010 Integration page.

Exchange Web Services
Lync 2010 client will connect and talk with Exchange server using a set of methods available through web services, available via Internet Information Server (IIS) on the Exchange server. This is the recommended way of contacting Exchange server but only available for Exchange 2010 & Exchange 2007, since previous versions of Exchange do not have the EWS feature.

EWS integration is built into the Lync 2010 client and is the primary/recommended integration method for Exchange Server.

Messaging Application Programming Interface (MAPI)
MAPI stands for “Messaging API” and is an API made available for developers to easily integrate messaging/email features in client applications on windows.  As an application programmer you can make some calls to MAPI, and MAPI will handle the communication to the backend server. This is much easier than building your own messaging stack.

There are two versions available, a simple and an extended one, where the simple version was made available in Windows through Outlook Express and the extended version was implemented in Outlook.

In case of Exchange Server, clients can interact with the server using MAPI calls over an RPC connection directly to the server. To facilitate connections from external users, this MAPI over RPC traffic can be tunneled through HTTP(S) using an RPC-Over-HTTP component installed on the IIS Server.  Since Outlook 2007 this is called "Outlook Anywhere".

If we look at Lync 2010, MAPI integration is implemented through the ucmapi.exe (32-Bit) or ucmapi64.exe (64-bit) process. This executable can be found in the Lync installation folder and is a background process when Lync is active:
http://www.pro-exchange.be/resized-image.ashx/__size/550x0/__key/CommunityServer.Blogs.Components.WeblogFiles/ocs_5F00_wave_5F00_14/ucmapi.exe.jpg

Where does the Lync 2010 MAPI COM Server authentication prompt come from?

To confirm which Exchange connection method was causing this Lync MAPI COM Server authentication prompt, I took a network trace of the Lync startup process with Netmon. The advantage of Netmon is that the connections are sorted by process executable, so it is very easy to see which process communicates with which peer and when.

The Lync client I was capturing was at a remote location and showed the following behavior:

1/ Connect to Lync Edge and register
The first 10 seconds of the captured log, Lync client connects to the Lync Access Edge Server and registers.

2/ Connect to autodiscover and EWS
After +/- 30 seconds, Lync started connecting to Exchange autodiscover and Exchange Web Services to enable Exchange integration. This succeeded and took about 5 seconds until the 35 second mark.
After these connections are made, the Configuration Information Window showed “EWS Status OK”. This means that the connection to EWS was successfully made.
MAPI Integration still gave the "MAPI Unavailable" status with message "Lync is in the process of connecting to the Exchange server. This process may take a few minutes .... ":
http://www.pro-exchange.be/resized-image.ashx/__size/550x0/__key/CommunityServer.Blogs.Components.WeblogFiles/ocs_5F00_wave_5F00_14/mapi.jpg

3/ UCMapi.exe starts and requests for authentication
After +/- 60 seconds, the ucmapi.exe process was launched by Lync. At this exact same time, the Lync 2010 MAPI COM Server authentication fired up. 
The MAPI Integration status in the Configuration Information window remained the same.
No network traffic from the ucmapi.exe process was captured until credentials were provided! Only after credentials are provided, network traffic is captured by Netmon and the ucmapi.exe process appears in the list. This means that Lync requires the credentials before it even attempts to make a connection to Exchange server.

If you cancel the authentication prompt, Lync Configuration Information provides the “MAPI Unavailable” status with the message "A separate sign in was required to connect to Outlook, but the sign-in dialog box was canceled or closed". Screenshot:

http://www.pro-exchange.be/controlpanel/resized-image.ashx/__size/550x0/__key/CommunityServer.Blogs.Components.WeblogFiles/ocs_5F00_wave_5F00_14/mapi2.jpg

No features appear to be broken and no error message is shown in the GUI, so why do we need this MAPI connection anyway?

EWS Status OK, why still MAPI?

If we have a look at the technet Lync 2010 Integration page and more specific the “Exchange Server Communication Interfaces”, we can see that there is one communication interface that requires a MAPI connection:  "Communicate with Exchange Delegates"

http://www.pro-exchange.be/resized-image.ashx/__size/550x0/__key/CommunityServer.Blogs.Components.WeblogFiles/ocs_5F00_wave_5F00_14/delegates.jpg

I could not find any other documentation on the subject, and even the Microsoft support engineer could not provide me with more information. Fact is that even with EWS working fine, Lync still needs to make a MAPI connection to Exchange.

How it works...

The Lync MAPI COM server authentication prompt we get is related to MAPI authentication. It is not related to EWS! This is very important to know and you should not start looking in EWS direction.
The MAPI stack is implemented in Outlook and for Lync, the UCMAPI.EXE process is used to interact with it.

The MAPI Stack refers to the user’s Outlook profile settings to determine how it can connect to Exchange using MAPI.  These connection specific settings in the Outlook profile are obtained and refreshed using Exchange autodiscover.   Outlook Anywhere supports the NTLM and Basic authentication methods, but Exchange autodiscover can only provide one method to the clients while IIS on the Exchange server can be set to use both. (reference)

You can review the current client settings using the "mail" control panel applet and advanced configuration settings of the Exchange profile:
http://www.pro-exchange.be/resized-image.ashx/__size/550x0/__key/CommunityServer.Blogs.Components.WeblogFiles/ocs_5F00_wave_5F00_14/profile.jpg

For internal users, Outlook/UCMAPI.EXE can directly connect to Exchange server using MAPI over RPC and use the associated authentication methods. Outlook Anywhere and it's specific authentication is not used.

For external users, or if Outlook Anywhere is forced for internal connections, MAPI over RPC is not an option and Outlook Anywhere will be used.  Outlook Anywhere can either use NTLM or Basic Authentication. In case Outlook Anywhere is set to Basic Authentication, the MAPI Stack requires credentials from the user to be able to authenticate to Exchange!

The first MAPI-aware application that will get launched and triggers the MAPI stack to make an Exchange connection, will need to provide the required credentials to the same MAPI stack. Once the connection between the MAPI Stack and Exchange is made, no credentials are required as long as the connection remains active.

  1. If Lync is set to automatically start with system logon, Lync will always start up first and thus Lync will fire the “Lync MAPI COM Server authentication” prompt to get the required Outlook Anywhere credentials.  After valid credentials are provided, the MAPI Stack will create the connection to Exchange server. If a user then launches Outlook, it won’t request for credentials since the MAPI connection is already active.
  2. If Outlook is started first, Outlook will request for credentials and the MAPI connection is made by the MAPI Stack. If Lync is started/restarted afterwards, it will not request for MAPI authentication since the connection is already active.

Solution

**1/ Switch from Basic Authentication to NTLM Authentication on Outlook Anywhere. **
Using NTLM Authentication for Outlook Anywhere is recommended by Microsoft, because basic authentication sends username/password through the (SSL secured) communication channel. NTLM Authentication never sends the password through the communication channel but uses hashes instead. (Reference)

Using NTLM authentication will allow to enable integrated windows authentication for domain-joined machines, which will use cached logon information on the computer to perform the authentication. The user will not need to provide any credentials in this scenario.

The disadvantage of NTLM authentication is that some packet-inspecting firewalls/proxies may not allow it through. (But then we have a Microsoft Forefront solution, right?)

2/ Cache the user credentials in Windows credential manager
In case switching to NTLM authentication is not possible, the only way to prevent the user from providing credentials is to cache the credentials in Windows credential manager. Javier Carmona blogged on beat a bit in detail how to configure this to make it work for Outlook and Lync on either 32-bit and 64-bit systems. Unfortunately this is not maintainable in large organizations and might not match with your security policies.

3/ Educate your users
Educate your users and tell them that Lync needs to connect to Outlook and requires them to provide the Outlook credentials in the Lync MAPI COM Server authentication window.

That’s about it, I hope this post helped!

NOTE: This article was first posted by myself on the Belgian UC-User group "Pro-Exchange", also known as Pro-Lync and Pro-Office365. Click to see the original article