Lync and Exchange/Outlook integration can cause a fair bit of frustration, in particular when the Lync and Exchange servers are in different AD forests. For example one company might leverage another companies Lync infrastructure, while maintaining there own Exchange infrastructure. This article details my experiences, and is by no means definitive, or even true for all circumstances. I welcome your feedback and own experiences.
There are 3 options available to Lync to provide Exchange/Outlook integration – Exchange Web Services (EWS), MAPI or a combination of both. If EWS can be resolved the Lync client will attempt to authenticate using the same credentials it has stored for the Lync client logon, or NTLM authentication for the logged on user. If it fails it will not give you the chance to enter different credentials, and as a result EWS authentication will fail. If EWS cannot be resolved or authentication fails, Lync will still attempt to connect to Outlook using MAPI. You may be prompted for credentials, however generally if Outlook is already open, then MAPI authentication has already occurred.
Access via MAPI is carried out locally by Lync client integration with Outlook. The requests are made to Outlook, and then Outlook forwards the request to the mailbox server. EWS is direct from the Lync client to the Exchange Server. The Lync client queries Outlook for the connection address for EWS. If Outlook is not installed, Lync attempts an Exchange autodiscover look-up for the email domain in the AD users “Email” attribute, in the following order:
- autodiscover.emaildomain.com
- _autodiscover._tcp.emaildomain.com
This behavior creates 3 scenarios:
- If EWS is resolved to the Exchange infrastructure where Lync also resides, then the Lync client will authenticate to EWS using the saved Lync credentials successfully, and will also connect to the MAPI account locally.
- If EWS is resolved to an Exchange infrastructure outside where Lync resides, then the Lync client will fail to authenticate using the Lync logon credentials, however should succeed if it is able to pass though the NTLM credentials of the logged on user. As above MAPI should also succeed.
- If EWS is not resolved, then the Lync client will only use MAPI integration.
Summary of MAPI and EWS features
Enabling the scenarios and their pro’s and con’s
1. Use EWS provided by the Exchange infrastructure where Lync also resides
In this case we populate the Lync users AD “Email” address field with an email address which has a domain name matching that of the Exchange autodiscover service in the Lync environment. The email address doesn’t necessarily need to be valid.
**When you enable the Lync user account for Exchange and Unified Messaging, this step is not required since the “Email” field will automatically be populated with the default SMTP address.
Advantages
- Provides a mixture of EWS and MAPI from both Exchange environments
- Lync client visual voicemail will work
- Lync client conversation history will work
Disadvantages
- New Lync Meeting creation from Outlook will not work, and you will receive the following error message “You cannot schedule the Lync Meeting because you are not UC enabled or there may be issues with your Communications Server account. Make sure you are signed in to the same account you use for Microsoft Outlook. If the problem continues, please contact your support team”**If you temporarily apply option 2 below, create an Outlook Lync Online Meeting then revert back to option 1, it appears this will keep working. There is also a registry key that could be created manually, but I have not tested this (HKEY_CURRENT_USERSoftwareMicrosoftOffice15.0LyncConfAddin).
- Occasionally Exchange integration is slow to establish, or will not establish at all. This situation can normally be resolved be signing out and back in again.
- MAPI relies on Outlook being installed and setup with the account you want to integrate with on the computer where you are running Lync.
2. Use EWS provided by an Exchange infrastructure outside where Lync resides
In this case we populate the Lync users AD “Email” address field with an email address which has a domain name matching that of the Exchange autodiscover service in your local Exchange environment. This would normally be the users actual primary SMTP address.
Advantages
- EWS and MAPI are connected to your companies Exchange environment
- New Lync Meeting creation from Outlook will work
Disadvantages
- Lync visual voicemail will not work. This does not stop voicemail working, and voicemail messages can still be delivered to your inbox (by way of forward), however to configure voicemail options requires login via OWA.
- Lync client conversation history will not work, however it will still be stored in Outlook “conversation History” folder.
- Users may be prompted to verify the certificate used by the autodiscover service
- The “Email” address field is displayed on the Lync contact card (see workaround here)
3. Don’t use EWS
In this case we populate the Lync users Active Directory “Email” address field with an email address which has a domain name not associated to an Exchange autodiscover service. This ensures that EWS is not resolved and only MAPI will be used. This would normally be an invalid email address which does not resolve now or in the future e.g. [email protected].
Advantages
- Over the above 2 options are are no benefits
Disadvantages
- EWS will not work at all
- Not all features are available over MAPI
Clearly option 1 is the best bet in terms of functionality. It has certainly worked for me in the past, but I am sure there will be cases where it just wont work.
Disable Email Comparison Check
Regardless of which option you select you will need to change the Lync client policy to allow the users SMTP address to be different to their SIP address. This can be done with the following command:
|
1 |
Set-CsClientPolicy -DisableEmailComparisonCheck $true |
More Information
More information on Lync and Exchange/Outlook integration see the following TechNet articles:
Lync 2013 Compatibility – http://technet.microsoft.com/en-us/library/gg412817.aspx
Lync 2010 Integration (no comparable article for 2013) – http://technet.microsoft.com/en-us/library/gg398806.aspx
You can always set up a trust between the two forests. Use "disabled" accounts in the resource forest (Where Lync is installed).
This way, The Lync is accessed with the credentials exchange recognizes.
Cheers!
Hey Lasse, could you please elaborate a little as I haven't got any experience with creating a forest trust for Lync. So the disabled accounts are the ones that are Lync enabled in the resource forest? You cant use accounts in the Exchange forest and enable them for Lync after the trust is created?
HI Andrew. Our primary smtp address was abc.co.nz. We used the same address to login to SFB. Our sip address was also .Co. nz address. We are federated with our global partner on abc.com. Recently we changed our primary smtp address and cannot sign into skype. Meaning we are now abc.com but sip address still .Co.nz. We applied the power shell command but still no luck. I even changed back my primary smtp address for me only but again no luck. Any advice would be appreciated.
Hey Phillip,
You cant sign in to the SfB client at all? Changing the primary SMTP address shouldn’t effect this at all.
I found your very interesting post when looking for the reverse problem: how to disable MAPI and leave only EWS (MAPI is causing inconsistent and erratic behaviour when synchronizing). The information you provide help a lot to understand the whole mechanism, thanks.
Thanks! Not sure it’s possible, not something I have done. I had a quick look around to see what I could find but nothing much came up.