Join Teams work meetings from Microsoft Teams (free) and vice versa

Microsoft Teams (Free) users can currently join Teams for work (or school) meetings only as guests, which requires them to use a browser and results in a sub-optimal experience. The new feature rolling out will allow these users to join Teams for work (or school) meetings in one click, without being redirected to the browser or asked to fill in their name/surname. They will also be able to continue collaborating with the meeting organizer and other participants via meeting chat after the meeting.  The feature will work in the opposite way as well, so Teams for work (or school) will just as easily be able to join meetings hosted by a Teams Free user with one click. This is associated with Roadmap ID: 167326

Forcing the Lync client to use MAPI

There are certain scenarios where I would like to provide Lync for users who belong to a different forest than the Lync installation is in. If you can set up a trust and federation between the two forests, then all is well. “All” you have to do, is to follow the following for the users in the separate forest: http://technet.microsoft.com/en-us/library/gg670909.aspx. Or if you also host Exchange services (in the same forest) for the customer, you should not run into any issues.

But, if for some reason you cannot set up the Lync forest as a resource forest for the customer/user, and you do not host the customers Exchange as described, you might run into some challenges with the Exchange integration. I have personally run into these scenarios a couple of times, and have been faced the following client side challenges:

  1. If the customer has not deployed EWS, the Lync client will not find any EWS and default to MAPI. Except for some missing features (I will get back to), “all” is well.
  2. If the customer has deployed EWS but the EWS is unreachable, the client defaults to MAPI
  3. 3. If the customer has deployed EWS and it is reachable by the Lync client, the authentication fails and MAPI is not used. 
The two first scenarios are not too common, but would give most of the functionality for the user (The user might be prompted once for logon with MAPI credentials.

The 3rd scenario is (in my experience) the most common scenario, and renders the Lync client without any integration at all. As it turns out, when the Lync client tries to access EWS it uses the same credentials it has stored for the Lync client logon. It will not prompt you for correct credentials if EWS authentication fails. And it will not fall back to MAPI, as it sees the EWS as up and running. (While if EWS is not available, and MAPI is chosen you will get prompted for credentials if logon fails).

I’ve been looking far and wide for a way to force the client to use MAPI instead EWS in these scenarios. And after a lot of research and quite a few emails with Microsoft support, I have finally been able to “trick” the Lync client to use MAPI.

Functionality 
Well aware of the loss of functionality when forcing MAPI, I have found this a lot better than no functionality at all. The features you will not get when forcing MAPI, include:

  • Read working hours information 
  • Handle Exchange contact sync
  • Read or delete Conversation History items
  • Read or delete voice mail items 
But the clients will still be able to do the following:

  • Read free/busy times 
  • Read Out ofCreate the Conversation History folder 
  • Handle voice mail notifications 
  • Handle missed Conversation notifications 
  • Read Contacts folder 
  • Find related conversations 
  • Open contact card 
  • Create a personal Outlook contact 
  • Open voice mail 
  • Write contacts (on demand) (EWS and Exchange Server 2010 SP1 only) 
  • Write Conversation History items (on demand) Office message 
  • Communicate with Exchange delegates 
  • Send email message 
  • Schedule a meeting 
  • Open voice mail folder 
  • Open the Conversation History folder 
All of this is taken from the following guide: http://technet.microsoft.com/en-us/library/gg398806.aspx (You should read it before thinking of doing what is later described in this post, as the article will be updated as the product might change).

Warning!
If you read the the rest of the blog, and try to implement this in your own system, you do so on your own risk. This solution is no way supported by Microsoft in any way, nor by me. But I have tried this setup in three systems that all work as expected.

Not all of the settings I discuss are necessary, but I have added them to help you make the integration as smooth as possible. These setting should be done before enabling users for Lync (Or you will have to go back and possibly edit users later)

Client tweaking:
First of all, by default, Lync expects the email address of the user to match the user sip URI. To avoid this to be an issue, I disable the email comparison check. Also, the MAPI poll interval is 30 minutes, and this can be a bit long. I wouldn’t set it too low, but 10-15 minutes should be fine. Both of these settings can be done with the set-csclientpolicy command, like this: 

Set-CsClientPolicy -DisableEmailComparisonCheck $true -MAPIPollInterval 00:15:00

Read more about the set-csclientpolicy and its options here: http://technet.microsoft.com/en-us/library/gg398300.aspx

How does Lync know what to look for:
The key to trick the Lync client to use MAPI is to understand how the Lync client tries to access the Exchange EWS. The lync client uses the Active Directory user object’s mail attribute to find the email server. It will use the mail attribute to start the auto-discover process to find the exchange services. If the attribute is empty, it will simply not try to connect to Outlook or Exchange. At least that is what I have experienced.


The easiest part in tricking the Lync client is putting a fake email address/domain in the mail attribute. Something like absolute@nonsence.foo (important: domain must not exist, now or ever). Once this is done, the Lync client will try to autodiscover the “nonsence.foo” domain and fail. It will state: EWS not deployed, and fail over to MAPI.

New problem
But by resolving one problem, we create ourselves another problem; The generated address book will show the fake address, and client interaction (such as sending email) will not work at all.



Next move:
To solve this problem, you need to alter from which field the addressbook service populates its data. It turned out this was just as simple as the previous task.
I downloaded, and used the address book configurator from DrRez: http://blogs.technet.com/b/drrez/archive/2011/01/31/microsoft-lync-server-2010-resource-kit-tool-absconfig.aspx.

First I chose a different user property to populate with the correct email address (I often use the “info” field).


Then, I launch the absconfig and change the email value.

!Warning #2! The absconfig was written for OCS, not for Lync. It works for changing fields, but under no circumstance should you try “restore to default” (or try any of the other features in the tool, it will possibly mess up your system. Read more about it here: http://waveformation.com/2011/02/11/restore-lync-abs-default-configuration/ if you should have done so before reading my warning. I did, and I used this post to repair my system).



After editing your address book behavior, you might want to follow Jeff’s way to update your addressbook: http://blog.schertz.name/2010/09/updating-the-lync-2010-address-book/ Then the user should look alright:



You should also remember not to enable Lync users with the email address as their sip address after doing this, as it will pick the wrong attribute to create a user from:


Comments

Anonymous said…
Very nice post, really! This single article revealed a lot more about the tight relationship between Lync the EWS and the MAPI, than the whole Lync Resource kit book written by those so-called Microsoft "experts"

"The lync client uses the Active Directory user object’s mail attribute to find the email server"

The ABSENCE of this sentence in the whole Lync product documention (including the ITPRO.chm and the whole Resource Kit 20 chapters) caused me wasting 3-4 weeks at a customer to find the reason why some of their users were unable to acquire EWS connectivity to retrieve their voicemail list.
Anonymous said…
Great article, exactly what I neeԁed.
My web site - Mid Heel Shoes
Anonymous said…
Great Post.
Very good technical stuff.
Fixx said…
Fantastic article and is exactly what a client of ours is looking for.

Can I assume that the ABSConfig change only needs to be applied once and when new users are enabled for Lync, the email address field within the Lync client will sort itself over time (providing the AD attributes have been modified)?

Alternatively, will Update-CSUserDatabase and Update-CSAddressbook commands have to be run each time?

Thanks in advance,
When you use the ABSConfig file, you alter the Database (and yes, it's permanent).
The ABS service will use these settings on all new users. (The only reason I wrote about the commandlets, is for you to see an immediate result)