In Skype for Business, any and all telephone numbers published in AD (i.e. main / primary "telephoneNumber", "mobile", "homePhone", "otherTelephone" etc.) would appear in a drop-down menu (along with the default "Skype for Business call") any time there was a call button, either from the buddy list or from the contact card.

In Teams, this is quite broken:

1 Phone numbers visible in the contact card in Teams are not diallable / hyperlinked.

2 The Call button from the contact card presents a different user experience to the Call button in the chat screen. In the chat screen, it provides "Teams call" and the "mobile" phone number field (if populated in AD) in the drop-down menu as options. In the contact card, it just defaults to "Teams call" without giving you any option to dial alternate published numbers for the user.

3 The drop-down menu behind the Call button should display any and all telephone number fields published in AD, not just the "mobile" phone number field. Understand the need to push a "Teams call" as a preferred option, but there are legitimate customer scenarios where a Teams call is not possible, and click-to-dial to other published telephone numbers for the contact is required.

Currently when a channel has been removed and has remained deleted for 30+ days, the "Restore" button continues to show up in "Channels" tab of "manage team" settings despite it no longer being available for restore.

This misleads users who will click it without realising that restore is not available. There is also no feedback to the user to suggest the restore is not occuring.

My suggestion is for the channel settings UI to display if a restore is available or not (such as making the "Restore" option dissapear)
In an ideal scenario, the UI would also show the date that restores will no longer be possible (or perhaps days remaining until permanent deletion)

Whenever you call someone in Microsoft Teams and they do not get your call, you can leave them a voice message in the app.

Teams will then send an email message to the recipient's mailbox with the voice message information, the transcription and an attached audio file. Teams will also send it from the caller's email address (e.g. From: John.Doe@example.com).

These email messages are sent in such a way that an Exchange Transport Rule like the one attached in the PNG file will flag them unexpectedly, because they seem to be sent from IP address(es) not included in the default SPF record for Office 365 customers:
v=spf1 include:spf.protection.outlook.com -all

If you analyze the headers of the affected email messages, you will probably find lines like the one below:

Authentication-Results: spf=fail (sender IP is 52.114.76.82)

Received-SPF: Fail (protection.outlook.com: domain of example.com does not
designate 52.114.76.82 as permitted sender) receiver=protection.outlook.com;
client-ip=52.114.76.82; helo=EUR03B.map.protection.outlook.com;

This is a well known issue of Teams as documented in their github repo:
https://github.com/MicrosoftDocs/OfficeDocs-SkypeForBusiness/blob/live/Teams/Known-issues.md

Please, resolve this security problem at your earliest convenience.

This error message appeared after a user has logged back into the computer. It looks like Teams is trying to update itself but has failed to.

Temporary workarounds we have done is to remove Teams and download the latest update through the Teams website. But when Teams pushes another update, the same error message will appear.

Another workaround we did is go to C:\ProgramData\User\Microsoft\Teams and set the security permission of that folder so the user has full control.And then do a restart on the machine.

I wanted to ask if anyone has encountered this error and if there's hopefully a permanent solution to this.

Using Microsoft Teams & CloudPBX with AA and Call Queues.

If a user that is part of a call queue is actively making an outbound PSTN call (call not connected yet), and a call comes into the call queue, the outbound call is put on hold, and the inbound call is automatically answered, without the user actually clicking the answer button. The outbound caller hears nothing (because they are on hold.) We thought the fix would be to set the toggle on the call queue for "Agents can opt out of taking calls" but that didn't work. I have an existing case with Microsoft for this, with no resolution after a month.