ACS Teams interop meeting chat suddenly returns 403 Forbidden on all chat sends (calls work) - started ~Aug 24, 2026

Question

ACS Teams interop meeting chat suddenly returns 403 Forbidden on all chat sends (calls work) - started ~Aug 24, 2026

Khalid Hasan 0

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/screen-share work normally. This broke suddenly with no changes on our side.

Error (both ChatThreadClient.sendMessage and sendTypingNotification):

ChatError: ChatThreadClient.sendMessage: {
  "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've verified / 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 https://<resource>.canada.communication.azure.com/chat/threads/19%3Ameeting_...%40thread.v2/messages?api-version=2025-03-15 -> 403, Ms-Cv: IGMF4wkAI0+MIaxuFQ0kJw.0, 2026-08-31 16:04:38 UTC (Canada region resource).

Was there a recent service-side change/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.

Khalid Hasan 0 Reputation points

2026-08-31T18:34:14.4366667+00:00

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; happy to share tenant/resource IDs and additional Ms-Cv values with Microsoft engineers.

1 answer

Your answer

Khalid Hasan 0 Reputation points

2026-08-31T18:34:14.4366667+00:00

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; happy to share tenant/resource IDs and additional Ms-Cv values with Microsoft engineers.

Answer 1

Based on the troubleshooting you've already completed, this does not appear to be a client-side, SDK, API-version, or standard Teams meeting policy configuration issue.

The key indicator is that the ACS participant appears to be joining the meeting successfully for calling scenarios, but is never becoming a valid member of the associated Teams meeting chat thread.

According to Microsoft documentation, Azure Communication Services users joining Teams meetings should be able to participate in meeting chat, including sending and receiving messages and typing notifications. The behaviour you're seeing differs from the commonly documented transient timing scenario where chat operations briefly fail until chat-thread membership is established.

Several details support this conclusion:

The issue persists for the entire meeting rather than resolving after join.
Both sendMessage and sendTypingNotification return 403 Forbidden.
No meeting chat messages are received by the ACS participant.
The Communication React UI immediately reports "You are no longer in this chat thread".
The issue reproduces with the Microsoft quickstart sample and freshly created ACS identities.
The behaviour is consistent across both Graph-created and Teams-created meetings.
Calling, roster and screen-sharing functionality continue to work normally.

Taken together, this suggests the failure may be occurring in the ACS-to-Teams meeting chat membership provisioning path, rather than in message authorisation itself.

You have already ruled out many of the common causes:

MeetingChatEnabledType is enabled.
ACS federation appears correctly configured.
Anonymous join is allowed.
The ACS participant is fully admitted and connected before chat operations are attempted.
Multiple chat API versions show the same behaviour.

Given the evidence provided, I would focus further investigation on whether the ACS participant is successfully being provisioned as a member of the Teams meeting chat thread at join time.

For troubleshooting and platform investigation, it would be useful to collect:

First known-good and first known-bad timestamps.
UTC timestamps for several failed chat requests.
Corresponding Ms-Cv correlation IDs.
ACS resource region and immutable resource ID.
Tenant ID.
Meeting ID and chat thread ID.
Confirmation that Teams-native participants can exchange messages normally in the same meeting.
A minimal reproducible sample (which you already appear to have).

Based on the information shared, the evidence currently points toward a problem with meeting chat thread membership establishment for ACS-interoperability participants, rather than a missing ACS chat permission, SDK defect, or meeting policy configuration issue.

your investigation has already eliminated most documented configuration causes. The persistent 403 responses, combined with the ACS participant never attaching to the meeting chat thread and reproducing in the official sample, suggest the issue is likely occurring within the ACS-Teams meeting chat integration path rather than within your application code.

Help make this community better for everyone: if this answer resolved your issue, please accept it or leave an upvote. If not, share more details in a comment so we can continue the discussion and find the right solution.

Khalid Hasan 0 Reputation points

2026-09-14T11:39:10.29+00:00

Thanks Vinodh - agreed, and we've now confirmed it from the service side. The resource's own ACSChatIncomingOperations logs show, for the SAME caller and token: ListChatMessages returns 200 on native ACS threads (19:acsV2_) but 403 only on Teams meeting threads (19:meeting_). Every meeting-thread op 403s (GetChatThread / ListChatMessages / SendChatMessage / SendTypingIndicator), while the non-thread-scoped GetRealTimeNotificationConfiguration returns 200 - so the token and chat scope are valid; only meeting-thread membership is denied. That is exactly your "membership provisioning path" read. Server-side ResultDescription: "The initiator doesn't have the permission...". Sample CorrelationId WAn58DuYbEKzj+cuTUGggA (2026-09-04 15:31:10 UTC); region Canada; tenant/resource IDs available privately. Still reproducing after ~2 weeks with no response on the Sev-A case or on Azure/communication-ui-library#6074 / Azure/Communication#600. If you can flag this to the ACS/Teams-interop product team, that would help.