Overview
Microsoft provides 2 set of Graph APIs to archive chat and channel messages for Microsoft Teams. The Verba system supports both integrations. The following table provides a comparison for the 2 integration options.
| Feature | Webhook/DLP API | Export API | |
|---|---|---|---|
| Capture | Internal chat (peer-to-peer and group) messages and files | Supported | Supported |
| External chat (peer-to-peer and group) messages and files | Supported Files can only be archived if the chat is started by an internal party | Supported Files can only be archived if the chat is started by an internal party | |
| Internal channel messages and files | Supported | Supported | |
| Internal meeting messages and files | Supported | Supported | |
| External meeting messages and files | Supported Files cannot be archived unless the meeting is hosted by an internal party | Supported Files cannot be archived unless the meeting is hosted by an internal party | |
| Replies | Supported | Supported | |
| Reactions | Supported | Supported | |
| Emoticons | Supported | Supported | |
| Animated GIFs, Stickers, Praises, and other rich content | Supported | Supported | |
| Send email to channel | Supported | Supported | |
| Participant Join/Leave Events | Supported based on periodic membership queries and message sender information (there is a chance that this is not 100% accurate all the time. VFC data is only as accurate as the information returned in the periodic query). | Supported based on periodic membership queries and message sender information (there is a chance that this is not 100% accurate all the time. VFC data is only as accurate as the information returned in the periodic query). | |
| Selective Capture | Supported for both chats and channels with limitations, participant information is not 100% accurate all the time (see below) | Chat: supported Channel: supported, but the API only offers team based queries (user based queries are not available, teams have to be configured as recorded extensions) | |
| Participant information | Chat and channel membership information is collected by periodically querying Graph API endpoints and caching the data on the Media Recorders. When selective capture is configured, the system could over-record or lose data if the system did not recognize on time if the configured user has left a group/channel or joined it. Join and leave times stored by the user are not 100% accurate for the same reason. | Chat and channel membership information is collected at the point when the Export API is queried. The accuracy of the chat and channel membership information has no effect on the selective capture, there will be no data loss (unlike with the webhook/DLP based capture). However, due to the periodic query nature, the membership information might not be accurately reflected in the database for the chat and channel conversations. Microsoft has a feature on the roadmap to include join/leave system events in the exported messages which can resolve this issue in the future. | |
| Disclamier notification | Not supported | Not supported | |
| Architecture | Data segregation, access to regulated users' data only | Not supported, the webhook sends data for every user in the tenant which is filtered on the Media Records only, the files in the file queue are encrypted automatically | Supported |
| Load balancing for Recording Director | Supported via load balancers | Supported by automatic allocation of archived users and teams to file queues Note: Recording Director and Media Recorder roles are always co-located for Export API based deployments | |
| Load Balancing for Media Recorder | Supported via file queues | ||
| Failover for Recording Director | Supported via load balancers | Supported by deploying standby servers Note: Recording Director and Media Recorder roles are always co-located for Export API based deployments | |
| Failover for Media Recorder | Supported by deploying standby servers | ||
| Scalability for Recording Director | Scales by adding more servers behind a load balancer | Scales by adding more servers Note: Recording Director and Media Recorder roles are always co-located for Export API based deployments | |
| Scalability for Media Recorders | Scales by adding more servers | ||
| Possible data loss scenarios |
| No data loss since the queries can be executed at any time. Microsoft stores messages for the defined retention period (see https://docs.microsoft.com/en-us/microsoftteams/retention-policies). Deleted messages are kept for 21 days only. | |
| Multi-tenancy | Supported | Supported | |
| Data duplication | No duplication, messages and files are stored only once even where there are multiple archived users in the same chat or channel | Chat: data duplication, messages and files are multiplicated based on the number of archived users in the chat Channel: no duplication, messages and files are stored only once even where there are multiple archived users in the same channel | |
| Export | Export | SMTP based export only User/participant based or conversation/chat based export | SMTP based export only User/participant based or conversation/chat based export |
| Licensing | Microsoft Licensing | Instant message, and attachment archiving requires one of the following user licenses for bot Webhook/DLP and Export API deployments for all archived users:
In addition to the user license requirements above, the owner of the application registration must define the licensing model for the deployment. Model A is required for Security and Compliance (S+C) and general usage scenarios. The licensing model is configurable in the VFC system. For more information about seeded capacity and consumption fees, see https://docs.microsoft.com/en-us/graph/teams-licenses. | |
Deploying Microsoft Teams chat and channel archiving
...
The following table shows the expected incoming message rates at different user numbers:
1K Users | 10K Users | 100K Users | |
|---|---|---|---|
| Average during the day* | 1.6 msg/s | 16.6 msg/s | 166.6 msg/s |
| Low message rate** | 2.7 msg/s | 27.7 msg/s | 277.7 msg/s |
| Medium message rate** | 4.1 msg/s | 41.6 msg/s | 416.6 msg/s |
| High message rate** | 6.9 msg/s | 69.4 msg/s | 694.4 msg/s |
*Based on Slack usage statistics
...
Large deployments may require multiple VMs and other Azure components. In the case of the Webhook/DLP API, a load-balancer has to be placed in front of the Recording Servers (Recording Directors).
If the Recording Director and Media Recorder roles are separated, multiple Media Recorders can be deployed behind the Recording Director(s).
In the case of the Webhook/DLP API, only one of the Recording Director components is writing into the file queues at once, depending on which one receives the events from the Application Gateway. The other Recording Director(s) will be on standby.
In the case of the Export API however, the active Recording Director components divide the user list amongst each other equally, and only query the chats of their own portion of the user list. The standby Recording Director(s) will become active only if an active one goes down. In that case, it takes over the user list portion of the server that went down.
The Media Recorder component works the same way regardless of the API being used. File queues are distributed between the active Media Recorders equally. Standby Media Recorders will become active only if an active Media Recorder goes down. In that case, it rakes over the file queues of the server that went down.
Highly available setup with separated server roles:
Preparation
The Microsoft Teams integration requires additional prerequisites and configuration on Azure and O365, see Configuring Microsoft Teams Recording for more information.
...