Forum Discussion
ACS Teams interop meeting chat suddenly returns 403 Forbidden on all sends since late Aug 2026
Since approximately Aug 24, 2026, every Azure Communication Services (anonymous interop) user joining Microsoft Teams meetings in our tenant gets 403 Forbidden on ALL meeting chat operations, while calling, roster, and screen-share work normally. This broke suddenly with no changes on our side.
The error on both ChatThreadClient.sendMessage and sendTypingNotification is "CommunicationError" Code "Forbidden", Message "The initiator doesn't have the permission to perform the requested operation." ACS users also receive no thread messages (Teams-native participants chat with each other fine in the same meeting), and the communication-react composite shows "You are no longer in this chat thread" immediately on join - so the ACS user appears to never be attached to the meeting chat thread, even though the call roster add works.
What we have verified and ruled out -
- Reproduces with the minimal azure/communication-react (1.32.0) CallWithChatComposite quickstart and a freshly minted ACS identity (voip+chat scopes) - not our application.
- - Reproduces on BOTH Graph-app-created online meetings AND a meeting created by a human organizer in the Teams desktop app with default options.
- - Fails on chat api-versions 2024-06-05-preview and 2025-03-15.
- - All CsTeamsMeetingPolicy instances have MeetingChatEnabledType = Enabled (verified via Teams PowerShell as Global Admin).
- - ACS federation is configured. EnableAcsUsers = True and our ACS resource's immutable ID is in AllowedAcsResources. External access policies have EnableAcsFederationAccess = True. EnableExternalAccessRestrictionsForChatParticipants and EnableMutualFederationForChatParticipants are both False.
- - Per-meeting allowMeetingChat = enabled. Anonymous join allowed. BlockedAnonymousJoinClientTypes empty.
- - User is fully admitted and call state is Connected when sends fail (not the known join-timing issue), and the failure persists for the entire meeting.
Sample failing request - POST to (resource).canada.communication.azure.com /chat/threads/19%3Ameeting_...%40thread.v2/messages?api-version=2025-03-15 returns 403, Ms-Cv IGMF4wkAI0+MIaxuFQ0kJw.0, 2026-08-31 16:04:38 UTC (Canada region resource).
Was there a recent service-side change or rollout to how ACS interop users are added to Teams meeting chat threads, or a new tenant/meeting setting that now gates this? Is anyone else seeing this since late August 2026? We can share tenant ID, resource ID, and additional Ms-Cv values privately with Microsoft engineers. An Azure support case is also being opened in parallel.
Also posted on Microsoft Q&A - https://learn.microsoft.com/en-us/answers/questions/5990218/acs-teams-interop-meeting-chat-suddenly-returns-40
1 Reply
- khalid-hasanCopper Contributor
UPDATE (Aug 31): new finding that isolates this to the ACS interop path. In the SAME meeting where every ACS SDK user gets 403 on chat sends, an anonymous participant joining through the Teams WEB CLIENT (display name only, unverified - no email OTP) can send meeting chat messages normally. So the tenant, meeting options, and organizer policy demonstrably permit unverified anonymous meeting chat - the failure exists only for the ACS client type. BlockedAnonymousJoinClientTypes is empty and all other anonymous-related controls are permissive (verified as Global Admin). Also tested - a brand-new meeting created after assigning a test policy with AnonymousUserAuthenticationMethod=None still fails with 403. Severity-A Azure support case is open.