Microsoft Teams Bot Proactive Notification - Bot Framework Connector 401 Unauthorized

gc 0 평판 포인트
2026-06-11T06:15:58.3333333+00:00

Microsoft Teams Bot Proactive Message Fails with Bot Framework Connector 401 Unauthorized

1. Case Summary

We are experiencing a consistent HTTP 401 Unauthorized error when sending Microsoft Teams proactive messages through the Bot Framework SDK.

The Microsoft Entra ID client credentials token request succeeds with HTTP 200. However, the subsequent Bot Framework Connector ReplyToActivity call using the issued token fails with HTTP 401 Unauthorized.

The same server, same runtime, same SDK version, same code path, and same credential-loading mechanism work successfully for older bots. However, multiple newly created bots fail 100% of the time.

The most visible difference is the bot creation date:

Bots created before 2026-04-23 work normally.

Bots created on or after 2026-05-18 fail with HTTP 401 Unauthorized.

Existing older bots continue to work even after client secret rotation.

Newly created bots fail even with newly issued credentials.

This suggests that the issue may be related to Azure Bot resource creation, Entra app registration, Teams bot registration, Bot Framework Connector trust mapping, app type enforcement, tenant policy, quota, or a backend rollout/change.

We are not assuming a single root cause. We need Microsoft to investigate the Connector-side backend rejection reason.

2. Business Impact

New Microsoft Teams bots cannot send proactive notifications.

Existing bots continue to work from the same server and same application.

This blocks new bot rollout, replacement, migration, and expansion of Teams notification-based automation.

The issue is reproduced 100% of the time for multiple newly created bots, so it does not appear to be a transient failure.

3. Environment

Runtime: .NET 8

Bot Framework SDK: 4.22.7

Adapter: CloudAdapter

Bot Framework authentication: ConfigurationBotFrameworkAuthentication

MicrosoftAppType: MultiTenant

MicrosoftAppTenantId: <redacted-tenant-id>

Channel: Microsoft Teams

Credential model: Bot-specific AppId + Client Secret

Creation path: dev.teams.cloud.microsoft → admin.teams.microsoft.com upload → Teams app policy deployment

Cloud: Public Azure tenant only

No GovCloud, GCC, or custom ChannelService

Example affected Bot AppId: <redacted-bot-app-id>

Example Teams Bot ID: 28:<redacted-bot-app-id>

Client secrets and raw access tokens are not included for security reasons. We can provide decoded JWT claims, working/failing Bot AppId pairs, ConversationReference, serviceUrl, and request metadata if needed.

4. API Call Sequence

Microsoft Entra ID token endpoint

Grant type: client_credentials

  client_id: `<redacted-bot-app-id>`

  
     scope: `https://api.botframework.com/.default`

     
        Result: HTTP 200, access token issued successfully

        
        Bot Framework Connector ReplyToActivity API

        
           Uses Teams serviceUrl

           
              Authorization: Bearer token from step 1

              
                 Includes conversationId and activity payload

                 
                    Result: HTTP 401 Unauthorized
```The key point is that Microsoft Entra ID successfully issues the access token, but Bot Framework Connector rejects the subsequent activity send request.

This 401 is not generated by our application. It is returned by Microsoft Bot Framework Connector to our outbound REST call.

## 5. Error Details

Failure time:

2026-06-01 19:03:45 KST

2026-06-01 10:03:45 UTC

Exception log:


```javascript
{
  "ExceptionType": "ErrorResponseException",
  "Message": "Operation returned an invalid status code 'Unauthorized'",
  "BotAppId": "<redacted-bot-app-id>",
  "BotId": "28:<redacted-bot-app-id>"
}

HTTP response metadata:

HTTP status: 401 Unauthorized
WWW-Authenticate header: null
Response body length: 61 bytes

Because token acquisition succeeds and the Connector response does not include a WWW-Authenticate header, we need Microsoft to confirm the exact Connector-side validation failure reason from backend logs.

6. Already Verified

The following have already been checked:

AppId and Client Secret are valid because the Entra ID token endpoint returns HTTP 200.

Expired or incorrect secret is unlikely because token acquisition succeeds.

ConversationReference exists and the request reaches Bot Framework Connector ReplyToActivity.

serviceUrl and conversationId are present, and the Connector response is received.

Same code path works successfully for older bots.

Same IIS / Windows Server / .NET 8 application is used.

Same Bot Framework SDK version is used.

Public Azure tenant only. No GovCloud, GCC, or custom ChannelService.

Multiple newly created bots reproduce the issue 100% of the time.

Existing older bots still send proactive messages successfully.

Therefore, this does not appear to be a simple wrong secret, wrong AppId, or missing ConversationReference issue.

7. Critical Timeline Pattern

Working bots:

Created before approximately 2026-04-23

Same server, same code, same SDK

Continue to work even after endpoint or secret replacement

Proactive message succeeds

Failing bots:

Created on or after 2026-05-18

Same server, same code, same SDK

Newly issued credentials

Token acquisition succeeds

Connector ReplyToActivity fails with HTTP 401 Unauthorized

The failure boundary appears to be between 2026-04-23 and 2026-05-18.

This indicates that Microsoft should compare older and newer bots at the following layers:

Azure Bot resource configuration

Entra app registration

Teams app registration

Teams channel registration

Bot Framework channel registration

BotId / AppId mapping

Connector trust relationship

serviceUrl trust

tenant policy

quota or hidden limits

backend rollout, feature flag, or enforcement policy

8. Questions for Microsoft Support

Q1. Please confirm the Connector backend rejection reason

Please investigate the Bot Framework Connector backend logs for the failed request below and provide the exact reason for HTTP 401.

Tenant ID: <redacted-tenant-id>

Affected Bot AppId: <redacted-bot-app-id>

Teams Bot ID: 28:<redacted-bot-app-id>

Failure time: 2026-06-01 19:03:45 KST / 2026-06-01 10:03:45 UTC

API: Bot Framework Connector ReplyToActivity

Result: HTTP 401 Unauthorized

Please confirm which validation failed, for example:

token audience validation

token issuer validation

token tenant validation

token appid / azp validation

bot AppId validation

Azure Bot resource App Type validation

Entra app registration signInAudience validation

Bot Framework channel registration validation

Teams channel registration validation

Teams app registration validation

BotId / AppId mapping validation

serviceUrl trust validation

Connector-side trust relationship validation

tenant-level policy validation

quota / limit validation

backend rollout, feature flag, or enforcement policy

If possible, please provide the backend reason code or internal validation failure reason for the 401 response.

Q2. Were there any service-side changes around 2026-05-18?

Bots created before 2026-04-23 work, while bots created on or after 2026-05-18 fail 100% under the same conditions.

Please confirm whether there were any changes around this period in:

Azure Bot Service bot resource creation behavior

Bot Framework Connector authentication behavior

Teams Developer Portal bot or app registration behavior

Microsoft Entra app registration default values

Teams channel registration behavior

Bot Framework Connector trust mapping behavior

MultiTenant / SingleTenant / User Assigned Managed Identity policy

tenant-level rollout, enforcement, feature flag, or backend migration

proactive messaging Connector authorization policy

Teams app policy deployment behavior

Please confirm whether any MultiTenant bot creation deprecation enforcement or rollout reached our tenant around mid-May 2026.

Observed behavior:

Existing MultiTenant bots continue to work.

Newly created bots acquire tokens successfully but fail on Connector calls with HTTP 401.

The result differs strongly by bot creation date.

Server, code, SDK, tenant, and credential-loading logic remain the same.

Please confirm:

Whether there was any Azure Bot Service, Bot Framework Connector, or Teams Developer Portal authentication policy change around 2026-05-18.

Whether Connector authentication is now blocked or restricted for newly created MultiTenant bots.

Whether existing bots are grandfathered while newly created bots are subject to new enforcement.

If this is unrelated to MultiTenant bot deprecation, whether there was another backend change that could explain the creation-date-based failure pattern.

Q4. What is the officially supported configuration for newly created Teams proactive bots?

Please confirm the currently supported authentication configuration for newly created Microsoft Teams proactive bots.

Current configuration:

Azure Bot resource App Type: MultiTenant

Entra app signInAudience: AzureADMultipleOrgs

SDK MicrosoftAppType: MultiTenant

SDK MicrosoftAppTenantId: configured with our tenant ID

Adapter: CloudAdapter

Auth class: ConfigurationBotFrameworkAuthentication

Token scope: https://api.botframework.com/.default

Channel: Microsoft Teams

Please confirm whether this configuration is still supported for newly created bots, or whether we should use SingleTenant or User Assigned Managed Identity.

Please also confirm whether the following combinations are officially supported for Teams proactive messaging:

Azure Bot App Type: MultiTenant Entra signInAudience: AzureADMultipleOrgs SDK MicrosoftAppType: MultiTenant SDK MicrosoftAppTenantId: configured

Azure Bot App Type: SingleTenant Entra signInAudience: AzureADMyOrg SDK MicrosoftAppType: SingleTenant SDK MicrosoftAppTenantId: required

Azure Bot App Type: User Assigned Managed Identity SDK MicrosoftAppType: UserAssignedMSI Tenant / identity configuration as required

Q5. Please verify the Teams Developer Portal / Admin Center creation path

We create and deploy bots and Teams apps through this path:

dev.teams.cloud.microsoft → admin.teams.microsoft.com upload → Teams app policy deployment

Please confirm whether bots created after 2026-05-18 through this path may have different generated values or mappings compared to older bots, including:

Azure Bot resource App Type

Entra app registration signInAudience

Bot Framework channel registration

Teams channel registration

Teams app manifest bot registration

BotId / AppId mapping

messaging endpoint registration

serviceUrl trust registration

Teams tenant policy behavior

Teams app permission behavior

admin.teams.microsoft.com upload / policy deployment behavior

dev.teams.cloud.microsoft default creation behavior

Please especially verify whether the mapping between Bot, Entra app, Teams app manifest, and Teams bot registration differs between older working bots and newly created failing bots.

Q6. Please check tenant-level limits, quota, or policy restrictions

Please confirm whether there are any tenant-level limits, policies, backend quotas, or hidden limits for:

Azure Bot resources

Entra app registrations

Teams apps

Teams bot registrations

Bot Framework channel registrations

number of bots allowed to send proactive messages in a tenant

number of MultiTenant bots that can be newly created in the same tenant

custom app / bot count deployed through Teams app policy

number of bot identities trusted by Bot Framework Connector in one tenant

Please also confirm whether reaching any such limit or policy could cause newly created bots to receive HTTP 401 Unauthorized from Bot Framework Connector.

We are not assuming this is a quota issue. We are asking Microsoft to include tenant-level limit and policy validation as part of the broader investigation.

Q7. What comparison data should we provide?

If Microsoft needs a side-by-side comparison between working and failing bots, please advise which fields should be compared.

We can provide the following privately:

Working and failing Bot AppId pairs

Bot creation dates, including createdDateTime

Azure Bot resource configuration comparison

Entra app registration configuration comparison

Teams app manifest comparison

Teams Admin Center app registration / policy comparison

decoded JWT claims comparison

ConversationReference comparison

serviceUrl comparison

SDK stack trace

HTTP request / response metadata

logs by failure timestamp

We will not provide client secrets or raw access tokens.

9. Primary Ask

Please investigate the failed request from the Bot Framework Connector backend perspective and confirm the exact reason why the Connector returns HTTP 401 Unauthorized even though Microsoft Entra ID successfully issues the access token.

The most important point is that older bots work under the same server, code, SDK, and credential-loading structure, while newly created bots fail consistently based on creation date.

Microsoft 팀 | 비즈니스용 Microsoft Teams | 기타
댓글 0개

답변 1개

정렬 기준: 가장 유용함
가장 유용함 최신순 등록순
  1. Michelle-N 20,735 평판 포인트 Microsoft 외부 직원 중재자
    2026-06-11T09:06:10.0166667+00:00

    I would like to first clarify that this is a user-to-user support forum, and we are not Microsoft support. Moderators here do not have backend access and cannot directly intervene in Microsoft products or perform escalations. We can only provide technical guidance and best-practice recommendations based on reported issues.

    Please note that this is the Korean (ko-kr) forum. I kindly recommend posting your question in Korean so that more community members can assist you effectively. If you prefer using English, you are welcome to post in the English forum instead. I sincerely appreciate your understanding and cooperation.

    Hi @gc

    Based on the information you shared, I understand that you are facing a critical blocker where multiple newly created Microsoft Teams bots (created on or after May 18, 2026) are failing 100% of the time with an HTTP 401 Unauthorized error during outbound ReplyToActivity calls for proactive messaging. This happens even though the initial Microsoft Entra ID token acquisition succeeds with an HTTP 200, and your legacy bots (created before April 23, 2026) continue to function perfectly using the exact same server, .NET 8 runtime, and SDK codebase.

    While a successful Entra ID token indicates your credentials (AppID and Secret) are valid, a valid token alone does not guarantee a successful API call to the Bot Framework Connector. When sending proactive messages, the Connector enforces additional, strict server-side validation layers, including Token Audience, Issuer, and ServiceUrl Trust.

    When a bot is created exclusively via the Teams Developer Portal, it registers the bot ID within the Teams app manifest allowing inbound message processing. However, if it hasn't been completely and officially registered within the global Bot Framework Connector registry or linked to an Azure Bot Service resource, outbound/proactive requests are often rejected with a 401 Unauthorized error due to a lack of backend serviceUrl trust mapping. Additionally, Multi-Tenant authentication models with explicit tenant IDs can introduce subtle trust mismatches during proactive token validation on newly provisioned service architectures.

    To bypass this provisioning discrepancy, I highly recommend explicitly registering and linking an Azure Bot resource using a Single-Tenant configuration for your new bots. Please try the following steps for one of your failing bots to see if it resolves the trust mapping issue:

    Step 1: Create and Link an Azure Bot Resource

    1. Sign in to the Azure Portal
    2. Navigate to Create a resource > Search for and select Azure Bot
    3. Choose the "Use existing app registration" option and input the existing App ID that matches your Teams app manifest.
    4. Configure the Bot setting fields explicitly as follows:
      -App Type: SingleTenant

    -Microsoft App ID: [Your Bot AppId]

    -Tenant ID: [Your Specific Tenant ID]

    -Client Secret: Generate a fresh secret if necessary.

    1. Set your Messaging Endpoint to your actual public URL: https://<your-domain>/api/messages
    2. Under the Channels blade of the newly created Azure Bot, make sure to explicitly Enable Microsoft Teams.

    Step 2: Update Your Bot Application Configuration

    Modify your app configuration (e.g., appsettings.json) to reflect the Single-Tenant authentication model so that the Bot Framework SDK can automatically scope the authentication process to the correct tenant authority:

    {   
"MicrosoftAppId": "<your-bot-app-id>",   
"MicrosoftAppPassword": "<your-client-secret>",   
"MicrosoftAppType": "SingleTenant",   
"MicrosoftAppTenantId": "<your-redacted-tenant-id>" 
}
 

    Because this issue exhibits a highly distinct failure boundary based on the creation date, it strongly points toward a service-side policy enforcement, an updated default infrastructure rollout, or a backend trust mapping change for newly provisioned app registrations within the Bot Framework ecosystem. Therefore, I strongly recommend raising a high-priority technical support ticket directly through the Azure Portal. The specialized Azure Bot Service engineering team will have the exact deep-dive capabilities to audit your timestamp against the internal Connector logs, cross-reference the backend changes deployed around mid-May 2026, and provide the definitive root cause.

    I hope this information helps.

    If the answer is helpful, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".

    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.

    이 대답이 도움이 되었나요?

답변

질문 작성자는 답변을 '승인됨'으로 표시하고, 중재자는 답변을 '추천됨'으로 표시할 수 있습니다. 이를 통해 사용자는 해당 답변이 작성자의 문제를 해결했다는 것을 알 수 있습니다.