Share via

Azure Bot communication with MS teams

Stephan Grotz 0 Reputation points
2026-05-19T09:23:13.2+00:00

We have been set up a new azure bot endpoint in Azure and we got it working with our internal messaging endpoints. When we use "Test in Webchat" functionality, everything works fine and we can communicate with our internal bot.

Then we linked it with Teams, created a manifest for a new app and deployed that. We can type in whatever we want, it never reaches our internal bot. In app insights, there are no entries - as if the teams app just doesnt send the messages at all.

Symptom timeline:

  1. Initially: Bot Service acknowledged msteams messages (Activity event in Application Insights with StatusCode 202) but never made an outbound dependency call to the bot endpoint. Inbound pod logs confirmed no Bot Service traffic reached the endpoint.
  2. Granted "Managed Identity Operator" on the UAMI to principal 27a762be-XXX-4f92-899c-151877d6d497 (Bot Service SP per az ad sp show).
  3. Re-applied bot endpoint config (no-op write to nudge Bot Service to reload).
  4. Re-toggled the Microsoft Teams channel (az bot msteams delete + az bot msteams create).
  5. Current state: zero msteams customEvents and zero dependencies in App Insights for >30 min while user has sent test messages. Teams Service shows channel green (isEnabled: true, provisioningState: Succeeded).

Verified on our side:

  • Pod authenticates outbound to AAD via Workload Identity Federation; ClientAssertionCredential returns valid Bot Connector tokens (~1656 bytes).
  • Direct Line / Test in Web Chat round-trips correctly with the same endpoint + UAMI.
  • Manifest published in Teams Admin Center (v0.1.8) with botId matching the UAMI client ID.
  • Reproduced with three previous bot resources in same tenant (two SingleTenant, now UAMI) — all show the same Teams→Bot Service dropout.

Can you please help us with any hints, tips or tricks to get that to work?

Microsoft Teams | Development
Microsoft Teams | Development

Building, integrating, or customizing apps and workflows within Microsoft Teams using developer tools and APIs

0 comments

Answer recommended by moderator

Stephan Grotz 0 Reputation points
2026-05-22T12:12:50.8933333+00:00

Wohoo,

I take it back - I removed the old azure robot, went back to a SingleTenant Bot and recreated the app-registration. But thanks to Thore for pointing out the TLS issue - all of our loadbalancers reject 1.2 - so I removed that rule and now that is working fine. I can finally chat with my bot.

Thanks a lot Thore and Vergil!!! Much appreciated

Was this answer helpful?

3 additional answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Heinroth, Thore 0 Reputation points
    2026-05-22T10:20:31.06+00:00

    We’ve been observing the same issue for about 14 days.

    Our setup is a bit different: We use an app registration and have our own subscription, including a resource group and an Azure Bot resource. The Azure Bot is linked to the app registration. The Teams channel has been added and is active. Direct Line and Web Chat are also active.

    In the Azure Bot, a message endpoint pointing to an n8n webhook URL is configured. For use in Teams, we also created an app manifest. The bot ID, WebApplicationInfo, and the app registration are identical.

    After making changes to the app manifest, I uninstalled the old Teams app in the client, deleted it in the Teams Admin Center, waited, and then uploaded it again. I then installed it in Teams. No changes were reflected. What confused me a bit in this context was that I could still see the old chat history.

    Until the end of April, communication with this setup worked flawlessly—until it suddenly stopped and cannot be restored.

    Now I have a completely new subscription, a new resource group, a new Azure Bot, and a new app manifest. The result is the same: I can’t send or receive messages via Teams. Web Chat works.

    Creating a bot via the Teams App Developer Portal leads to the same result.

    There are no anomalies in the sign-in logs of the app registration. There are no Conditional Access policies active that would block the sign-in.

    I came across a note saying that the Azure Bot Framework does not support TLS 1.3 encryption. Is that true?

    I would appreciate any help or pointers. Best regards, Thore

    Was this answer helpful?

    1 person found this answer helpful.
  2. Sayali-MSFT 6,021 Reputation points Microsoft External Staff Moderator
    2026-05-20T08:47:57.9233333+00:00

    Hello Stephan Grotz,
    Your symptoms strongly indicate Teams messages are not being routed to Bot Service at all anymore. The most probable cause is a mismatch between the Teams manifest botId and the Bot’s msaAppId, especially due to confusion with UAMI client IDs. Secondary causes include channel provisioning issues or Teams app caching.
    Fix typically involves correcting the botId, recreating the Teams channel, and reinstalling the Teams app.

    Was this answer helpful?

  3. Vergil-V 14,780 Reputation points Microsoft External Staff Moderator
    2026-05-19T10:40:57.6866667+00:00

    Hi @Stephan Grotz   

    Thank you for sharing the details you have gathered so far. It really helps me better understand the situation and narrow down where I should look next. 

    Based on my research, here are some additional areas you may consider checking: 

    1/ Check Entra ID sign in logs for the Bot Framework service principal 

    Azure Bot Service uses its own first party service principal to authenticate when forwarding messages from the Teams channel. If a Conditional Access policy in your tenant is blocking this principal, the forwarding may not go through as expected. 

    • Go to Microsoft Entra ID > Enterprise Applications 
    • Search for App Idd, for example: f3723d34-6ff5-4ceb-a148-d99dcd2511fc (Bot Framework Dev Portal) 
    • Open Sign-in logs and filter to the last 24 hours 
    • Look for any failed or interrupted sign-in attempts 

    If you find any failures, please check which Conditional Access policy is involved and consider adding an exclusion for this service principal. 

    2/ Verify the bot resource app type 

    For UAMI based bots, the bot resource needs to explicitly declare UserAssignedMSI as its app type. If this value is missing or set differently, the Bot Service may not use the expected authentication flow for message forwarding. 

    Could you please confirm whether the appType is returning UserAssignedMSI? 

    3/ Reinstall the Teams app after recreating the channel 

    I understand that you have already deleted and recreated the Teams channel. However, I did not see any mention of reinstalling the Teams app afterward. 

    The Teams client may still cache the previous channel registration. Without reinstalling, messages could still be routed to the old configuration. 

    4/ Run an echo bot isolation test 

    You could deploy a simple echo bot using a basic client secret setup, without UAMI or Managed Identity. 

    Then add the Teams channel and test it within the same tenant and user context. This can help determine whether the behavior is related to the current bot configuration. 

    I hope these suggestions help provide some direction. If you have any updates after trying these steps, please feel free to share.

    Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.