This post has been republished via RSS; it originally appeared at: New blog articles in Microsoft Tech Community.
Last year, during Ignite 2018, I also did a blog about the Microsoft Teams Architecture session. This year, I was really looking forward to the “update” session. I am getting asked a lot of questions about Teams Architecture from customers and in the community. A knowledge update is always good then.
The session this year was presented by Bill Bliss. Bill is the Platform Architect for Microsoft Teams and one of the founding members of the Microsoft Teams team within Microsoft. A long time ago, Bill was also one of the founding members of the Outlook team, so ironically Bill is disrupting himself :)
The session started with an update about the client architecture. The architecture focuses on client agility and was designed with auto-update in mind. As you can see in the diagram below, the web and desktop clients share a lot of code. The desktop clients also use some native code for calling & meeting.
Next topic was Teams Services, the middle tier of Teams. This consists of many micro services that handle the communication where Teams is depending on other services in Office 365. The diagram below shows these services. For example, synchronizing user information with Azure Active Directory, or enforcing data retention policies.
The next diagram shows the Intelligent Communications Cloud, basically the next-generation Skype services.
This is, for example, where PSTN calling integration is located. The Personal Expression service is used for emojis and stickers. The Experimentation config service is used to enable or disable certain features in the various deployment rings that exist for Teams. Think of rings for development, one for testing, one for preview, one for generally available (there are more rings, but those are the most important ones). The Experimentation service is also used for A/B testing of new features to discover which design is most effective.
Teams is not aiming to reinvent the wheel. Instead it leverages many existing Office 365 services and features. The following diagram shows the various services that Teams uses:
For example, Exchange is used to store messages for information protection purposes. Modern Groups (Office 365 Groups) are used for membership and owner definition. SharePoint and OneDrive for Business are used to store files. Stream is where all meeting recordings are stored. And for Information Protection, Teams uses the existing capabilities of eDiscovery, audit logging and retention policies. PowerBI is used for analytics, but that's for internal Microsoft use only. All data that is collected is stripped of any customer identifiable information.
Finally, Teams is using many Azure services. Not everything, but a lot. For example, not Quantum Computing, yet :).
Teams uses in-region or in-country data residency for Teams chats, conversations, images, voicemail, contacts and for all SharePoint Online and OneDrive for Business files. If a tenant is provisioned in Australia, Canada, the European Union, India, Japan, the United Kingdom, or the United States, then all the abovementioned Teams data is stored in that same region or country.
Below you’ll find a high level architecture overview of Teams, one level deeper than we just discussed:
The Teams client communicates with underlying services directly, there is no middle tier, beside the Team Services we talked about before.
Here’s an overview of the messaging service:
Real-time notifications use long poll over TCP/IP. A Roster is where the members of a chat are stored. The Aggregation service fetches messages in bulk when you have not connected to a chat or channel for a while.
When it comes to storage of Teams related data, the following diagram is very useful:
As you can see, messages and images are stored both in Azure services and in Exchange. Like I mentioned before in this article, the ingestion in Exchange is for compliance reasons. The diagram shows that message storage is moving to CosmosDB. In fact, for 1-on-1 chats and group chats, that is already the case. Channel messages will follow later.
Next in this session, we switched gears a bit and we moved to meetings, calendar and presence. Interestingly, what Bill told us, Teams uses a Calendar middle tier in the calendar architecture to communicate with Exchange, because this middle tier layer provides support for Exchange on-premises as well.
When it comes to meetings, it’s very interesting to know that when a user starts a recording in a meeting, a recorder bot is added to the meeting which starts the recorder and will post a message with the link to the recording in the chat after the recording has been published to Stream. The flow looks as follows:
The calling architecture is explained in the following diagram:
In the client calling stack, the Call Controller handles transfers, pick-ups and hang-ups, and renegotiates when you hang up in the web and switch to PSTN for example. The policy store is used to check what policies apply to a user. "Is a user allowed to call to external phone numbers?" for example.
The next topic of this session was about Teams on Virtual Desktop Infrastructure environments. Teams now supports VMware and Citrix environments. More platforms might follow later. What Microsoft has done together with their partners, is quite ingenious. Microsoft has created a number of WebRTC functions that override the client functions in order to create connections in the Thin Client instead of on the VM. This enables A/V to stream directly between the remote client and the thin client. Also, some intelligent element occlusion takes place. When a people card or a Teams notification popup is shown, the VDI partner needs to cut the overlay out of their window in order to see the popup window. Also, the partner software needs to keep track of the order of windows, to show the correct one on top. Interesting how this works and how this is solved!
The VDI version of Teams is a separate MSI package. If Teams is already installed in the VM environment, you have to uninstall Teams first before you install the VDI version. Also, for now, updates are a manual process (uninstall and then reinstall), but Microsoft is working on automating that. You have to install the client using the per-machine mode.
You can find the VDI versions here:
X86 version: https://teams.microsoft.com/downloads/desktopurl?env=production&plat=windows&download=true&managedInstaller=true&arch=x86
Install with: msiexec /i Teams_windows.msi /l*v msi_install.log ALLUSER=1
Uninstall with: msiexec /passive /x Teams_windows.msi /l*v msi_uninstall.log
X64 version: https://teams.microsoft.com/downloads/desktopurl?env=production&plat=windows&download=true&managedInstaller=true&arch=x64
Install with: msiexec /i Teams_windows_x64.msi /l*v msi_install_x64.log ALLUSER=1
Uninstall with: msiexec /passive /x Teams_windows_x64.msi /l*v msi_uninstall_x64.log
After this, we came to the last topic of this session, the compliance boundaries of Microsoft Teams. The following diagram shows a very useful overview of how Teams communicates with the outside world:
That’s it! Thank you very much Bill Bliss! This was a great session, with a lot of great content.