Microsoft rolled out read receipts in Teams. It shows you if your messages were read or not. By default it’s enabled. You get a popup that read receipts is available and how it looks like. In this post I provide an overview.
In the Teams client settings you can disable or enable it depending on what’s configured in your Office 365 tenant.
Teams Admin Center
If required, a Teams administrator can configure read receipts by modifying Teams messaging policies in the Teams Admin Center as depicted below.
- By default, read receipts are on and the message policy configuration is set to“User Preference” which means that users can disable it within their Teams Client settings.
- Turned on for everyone: It’s enabled for all users and a user cannot turn it off.
- Turned off for everyone: It’s disabled for all users and a user cannot turn it on.
Limitations [January 2020]
The “Manage messaging policies in Teams” documentation says
- it is for 1:1 chat or chats with up to 20 people
- it is not caputered in eDiscovery reports
Conclusion, opinion and summary
It’s another neat feature to easily recognize if your chat message was read or not. Thus you can decide how to react, e.g. send a priority notification or make a call.
In this post I give you an architectural overview on how you can connect analog devices, e.g. fax machines, analog phones, door bells, intercoms etc. to Microsoft Teams.
First of all, I’d recommend to please get rid of your analog devices. Let me guess you are probably reading this because you have some of these poor and legacy analogs which you cannot get rid of for some reasons?
- If this is the case:
Well, ok, let’s go ahead to keep your existing investments in analog devices and get it to work.
- If not, i.e. you can get rid of them:
Skip this post and read something more interesting. 😉
The goal is to add analog devices to a Microsoft Teams voice/telephony deployment.
Use Cases – Analog Telephony with Teams user and PSTN
The uses cases are defined as follows:
- call from an analog device to a Teams user
- call from a Teams user to an analog device
- call from an analog device to a PSTN (external) phone (number) [e.g. mobile phone]
- call from a PSTN (external) phone to an analog device
In this architectural sketch you can see a high level Microsoft Teams Direct Routing deployment including an analog device which is connected via an anlog [device] gateway.
- [left] PSTN sip trunk [from your PSTN provider of choice],
- [center] a (certified) session border controller (SBC),
- [center] a analog [device] gateway
- sip trunk between analog gateway and SBC
- analog link (FXS, RJ11) between analog gateway and analog device
- [center-right] analog device [connect to analog gateway]
- [right] a Microsoft Phone System sip trunk
- [right] a Microsoft Teams User
What are the requirements for this? To keep it short, you need:
- Teams Direct Routing (TDR) [for details, please see Plan Direct Routing]
- Analog [Device] Gateway
Note: In case you have Microsoft Teams and utilize calling plans for telephony already but need these analog devices added you can add Teams Direct Routing to what you’ve got already.
Conclusion, opinion and summary
To sum this up, to connect analog devices to your Microsoft Teams deployment you need Teams Direct Routing (TDR). Then you can attach an analog device to an analog (device) gateway which is linked to a certified SBC for Direct Routing which handles the voice routing (from/to PSTN/Microsoft Phone System/analog gateway).
Microsoft plans to release federation between Teams and Skype (for consumer) in January 2020. This federation is in great demand. On Teams User Voice more than 3000 people voted for this. Except the description on the road map no further details are on docs.microsoft.com as far as I could see. However, I’m sure that there will be more details available as soon as the feature hits preview or general availability.
Teams <-> Skype (for consumer) Federation
What is the upcoming release of the federation between Teams and Skype (for consumer) probably like? As far as we can read in the road map it says that it supports chat and voip calls. I’d assume that this will be similar to what we’ve seen and experienced in the federation between Teams and Skype for Business at the beginning, e.g.
- peer-to-peer (p2p) chat
- peer-to-peer (p2p) voice calls
Conclusion, opinion and summary
In my opinion this is a good start for federation between Teams and Skype. I’m looking forward to it. In the past, for many Skype for Business (Server/Online) implementations the option to communicate with Skype (for consumer) was an important argument for globally distributed organizations with the need to communicate with freelancers, small agencies etc. In my view this federation option is another step to increase adoption and communication.
- Microsoft Teams – Teams/Skype Consumer chat and calling interop [Microsoft 365 Roadmap Featured ID: 53935]
- Skype integration (Consumer Federation) [Microsoft Teams User Voice]
- Microsoft Teams Federated Chat Experience Update 06-2019
- My Microsoft Teams Federation Notes
In this post I highlight the updated Microsoft whitepaper regarding the administration and governance of Microsoft Power Apps and Power Automate. It very extensiv with its 117 pages and covers topics from platform architecture to security and even user adoption (alias “Educate and Support”).
In my opinion, Microsoft’s Business Application Platform has become a very rich and incredibly valuable toolbox to empower people to do what they need in a more efficient and digital way as before. And all within the Microsoft 365 stack but extensible via interfaces/connectors/gateways to integrated with other external elements as needed.
- Power BI to visualize data
- Power Apps to build apps with no or low code
- Power Automate to create rich digital workflows
- Power Virtual Agents to build chat bots for customer dialog and interaction
Due to the fact that the Business Application Platform has grown and provides so many features it needs to be administrated, managed and governed as other services, too.
The whitepaper goes guides you through the following topics:
- Platform Overview
- Platform Architecture
- Platform Security
- Platform Monitoring
- Platform Alerts and Actions
- Platform Deployment
- Eduation and Support (Adoption)
Microsoft keeps on updating the document from time to time and of course the features. That’s why you should stay tuned and follow the Business Application Platform blogs.
Microsoft announced that there will be some enhancements to manage Microsoft Teams Phone System. So what are these enhancements?
Based on the lastest roadmap details the administration of Microsoft Teams Phone System will be improved in the following areas:
- Calling Plans administration
- search phone numbers
- acquire phone numbers
- assign phone number/s to users
- create emergency addressess
- assign emergency addresses to users
- Dial plan/s
- create custom dial plans
- test custom dial plans
- manage custom dial plans
- Dynamic Emergency Calling
- configure dynamic emergency calling
- Auto Attendants / Call Queues
- improved administration
- Microsoft Teams – Phone System Administration Enhancements [M365 Roadmap Featured ID 56786]
In this post I like to notify you about the release of the Microsoft Teams Client for Linux (DEB/RPM package) and it’s minimum hardware requirements. To run Teams on Linux you need to check that the minimum requirements are meet.
Microsoft Teams Linux Client (minimum) Requirements
- OS: Ubuntu 16.04 LTS (with certain prereqs, see docs.microsoft.com), 18.04 LTS, Fedora 30 Workstation, RHEL 8 Workstation, CentOS 8
- CPU: > 1.6 GHz (32/64-bit)
- RAM: > 2.0 GB RAM
- Disk: > 3.0 GB available
- Screen resolution: > 1024×768 and > 128 MB GFX RAM
- Peripherie: camera, microphone, speakers (compatible endpoint equipment)
In this post I point you to a very helpful admin resource hub which offers you an entry point in case your are facing issues with Microsoft Office 365. There you’ll find information on troubleshooting for …
- Office 365,
- Teams and
- Skype for Business.
Conclusion, opinion and summary
In my experience the most common issues are related to things like
- Connectivity from/to Office 365 services,
e.g. a client cannot connect to certain IPs/URLs to use a certain service successfully and completely (!) etc.
- Not all prerequisites are satisfied, e.g. UPNs are not ok, e.g. email@example.com or else.
- Misconfiguration/s of clients, e.g. GPOs to redirect an Outlook client always to an onpremise Exchange, not updated proxy pac files etc.
Before you start investigating you should always start to to ask some common questions, for example:
- How many users are affected?
E.g. does it affect a single user or all users at a certain branch site …
- Where are you (and the affected users) located?
E.g. Home Office, corporate premises …
- What’s the issue, could you please describe the issue in more detail?
E.g. my Outlook client asks several times a day for credentials …
- Did you try to connect from another network?
E.g. does the issue also occur if you use a network cable instead of WiFi? Or did you experience the issue only if you are working remotely from home?
- Did you try this from another computer?
In case you check all this you can then dig deeper into the related client or service to figure out what the (root) cause is and how to resolve it. For that, you might go to the related “Office troubleshooting for admins and IT professionals” page on Microsoft docs to proceed troubleshooting and issue resolution.
Below, I also added two helping tools, the well-known Remote Connectivity Analyzer and the Network Testing Companion. The first one is an online troubleshooting analyzer and the second is a PowerShell-based tool which enables you to check client connectivity towards Office 365, either directly within PowerShell or you can open the Network Testing Companion GUI (by executing Invoke-NetworkTestingClient in PowerShell).