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 of 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 | |
Private channel messages and files | Supported | Not supported | |
Channel announcement | Supported | Supported | |
Replies | Supported | Supported | |
Reactions | Supported | Supported Reactions that are added after the query returned the message, will not be archived. because there is a known bug in the Export API confirmed by Microsoft. | |
Emoticons | Supported | Supported | |
Animated GIFs, Stickers, Praises, and other rich content | Supported | Supported | |
Send email to channel | Supported | Supported | |
Loop components | Not supported | Not supported | |
OneNote | Not supported | Not supported | |
Participant join/leave events | Supported Initially, the membership information is determined based on periodic membership queries and/or 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). From the time a conversation is being recorded, accurate participant information can be determined from join/leave system events. | Supported Initially, the membership information is determined based on periodic membership queries and/or 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).Microsoft has a feature on the roadmap to include , which provide the list of members at the time of the query. From the time a conversation is being recorded, accurate participant information can be determined by combining the initial membership information received from the periodic membership queries and from join/leave system events in the exported messages which can resolve this issue in the future. Participant join and leave times are stored as follows: . Join/leave system events provide historical information and are used to verify changes in participant membership since the last membership information update. Note: Until the data from the initial membership query is received, only partial participant information is available, determined from the system events and user activity. The receipt of accurate participation information can also be delayed due to the delay in the ingestion of Teams chat and channel messages, and any throttling limits that exist for the API. | |
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 receiving join/leave system events and periodically querying Graph API endpoints and caching the data on the Media Recorders. | 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. However, due to the periodic query nature, the membership information might not be accurately reflected in the database for the chat and channel conversations. See Participant Join/Leave Events for more information. | |
Chat/channel name and description updates | Supported Available through regular polling and system events. | Supported Available through regular polling. | |
Disclamier notification | Not supported | Not supported | |
Architecture | Integration with Microsoft Graph APIs | The Webhook/DLP API is a set of Microsoft Graph APIs which that allow subscribing to change notification events for both chat and channel messages in a Teams tenant. The Webhook API based integration provides a real-time capture of messages and attachments. For more information, see https://docs.microsoft.com/en-us/graph/teams-changenotifications-chatmessage The system utilizes other Graph APIs to collect additional information such as attachments, user information, group membership, etc. | The Export API is a set of Microsoft Graph APIs which allow querying both chat and channel messages for specific users and teams in a Teams tenant. The Export API based integration provides a non real-time capture of messages and attachments. For more information, see https://docs.microsoft.com/en-us/microsoftteams/export-teams-content The system utilizes other Graph APIs to collect additional information such as attachments, user information, group membership, etc. |
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 only |
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:
For more information, see https://docsFor licensing information, please refer to the following Microsoft knowledge base article, "Graph APIs for Teams Data Loss Prevention (DLP) and for Teams Export" section: 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. | |
Limitations | Limitations | - | The following limitations should be considered when deploying the Export API based solution:
|
Deploying Microsoft Teams chat and channel archiving
...
For the detailed sizing guidelines of the different Recording Server components, see the paragraphs below:
Recording Director
In the case of the Webhook/DLP API, the Recording Director component has to be sized based on the real-time incoming load. The minimum CPU requirement is 4 CPU cores. It can process 1500 messages every second with a single CPU core, and 6000 messages every second with 4 cores.
...
Media Recorder and SQL Server
The Media Recorder component does not have to be sized for real-time processing, since the recorded data is stored already in the file queue storage. Instead, the Media Recorder can be sized based on the overall message count a day. If there are more incoming messages than the real-time processing capacity of the Media Recorder(s), then the messages will be inserted into the database later, so they will be also available for search and replay through the web interface later. However, sufficient processing capacity should be provided so it can process the daily message load at least within 16 hours.
...
Highly available setup with separated server roles:
Preparation
Make sure that all the required prerequisites are installed on each server prior to the installation.
...
For chat and channel archiving, see Microsoft Teams chat and channel archiving.