New Feature in Microsoft Teams: Forwarding Messages to and from Channels

on
An upcoming Microsoft Teams feature will allow users to forward posts and reply messages to and from channels, enhancing collaboration by reducing limitations on the type of content that can be forwarded.  Change for users: Currently, users cannot forward messages to and from channels. With this new feature, users can select the three-dot More actions menu on any channel post or reply message and choose Forward. In the Forward this message dialog box, users can select any destination chat or channel, with channels now included in the people picker. Admin Impact: This feature will be enabled by default. Admins can control message forwarding for individual teams or at the tenant level using sensitivity labels control data important to the organization. If a sensitivity label is applied, message forwarding will be disabled, blocking users from sharing content outside the channel. The feature will according to the Roadmap ID 469508 be rolling out in January or February 2025.

Forcing the Lync client to use MAPI

on
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: