User Profile
Nivedipa-MSFT
MicrosoftJoined Oct 12, 2021
User Widgets
Recent Discussions
Re: App Validation Issue - Bot must send a proactive welcome message in personal scope
Hello @ParamZ - Thanks for bringing this issue to our attention. 1.Graph API queries may generate unexpected conversationUpdate events. Recommended Solution: Use event deduplication based on activity ID and conversation ID to avoid sending duplicate welcome messages. 2.Reading Chat History – Suggested Method: Best Practice: Save conversation references when the bot is installed, rather than polling the Graph API. Alternative: Opt for webhooks or change notifications instead of using /me/chats queries. 3.App Validation – Proper Procedure: Primary Method: Utilize on_installation_update for sending welcome messages to meet validation requirements. Fallback: Apply on_members_added_activity with deduplication as needed for special cases. References: Design and control conversation flow - Bot Service | Microsoft Learn Teams Store Validation Guidelines - Teams | Microsoft Learn Please let us know if you have any further query here.Re: ❓ Can't remove member from Microsoft Teams Group Chat using Graph API with Application Permission
Hello Haekal_Arif_Rozikin, The error in your screenshot—"403 Forbidden" with "InsufficientPrivileges" and "AclCheckFailed-The initiator 28:app ... is not a member of the roster in the generic thread"—means the app (28:app...) isn’t recognized as a chat member and lacks permission to remove members, even with ChatMember.ReadWrite.All application permissions. Root cause: The app isn’t listed as a participant in the chat roster, so it doesn’t have the necessary rights to manage members. Why this happens: App installation is required: For ChatMember.ReadWrite.WhereInstalled to work, the app must be added to the chat as a participant. Application permissions alone aren’t enough; roster membership is also needed. Application permissions might be limited: ChatMember.ReadWrite.All might not support removing members in every chat scenario. The Graph API may require the app to be installed or restrict member removal actions without user context. RSC (Resource-Specific Consent) permissions: RSC permissions only apply if the app is installed in the chat. If the app isn’t in the roster, RSC permissions won’t grant access. How to resolve: Install the app in the chat (recommended) When creating a chat, add the app in the installedApps section so it becomes a roster member: POST https://graph.microsoft.com/v1.0/chats Content-Type: application/json { "chatType": "group", "members": [ { "@odata.type": "#microsoft.graph.aadUserConversationMember", "roles": ["owner"], "user@odata.bind": "https://graph.microsoft.com/v1.0/users('user-id-1')" }, { "@odata.type": "#microsoft.graph.aadUserConversationMember", "roles": ["owner"], "user@odata.bind": "https://graph.microsoft.com/v1.0/users('user-id-2')" } ], "installedApps": [ { "teamsApp@odata.bind": "https://graph.microsoft.com/v1.0/appCatalogs/teamsApps/YOUR-APP-ID" } ] } Try delegated permissions If application permissions don’t work, use delegated permissions with a service account that’s a chat member. Check app permissions in the manifest Verify your Teams app manifest includes the necessary RSC permissions for chat member management: "authorization": { "permissions": { "resourceSpecific": [ { "name": "ChatMember.ReadWrite.Chat", "type": "Application" } ] } } References: Create chat - Microsoft Graph v1.0 | Microsoft Learn Remove member from chat - Microsoft Graph v1.0 | Microsoft Learn Resource-specific Consent for Apps - Teams | Microsoft Learn Please let us know if you face any further issue here.Re: Issue with Teams Notification Only Chatbot(Android)
@achebrol - Thanks for bringing this issue to our attention. We’ve tested this on Android version 15 with Microsoft Teams version 2025.34.01.9, and it’s working as expected on our side. However, we are seeing a message that says, “Conversation with this bot is not supported.” Could you please share your deployed app manifest so we can test it on our end?Re: Overview where a SBC is used
@JFM_12 - Thanks for bringing this issue to our attention. Yes, you can use Microsoft Teams PowerShell to find where a Session Border Controller (SBC) is used in Voice Routing and other Direct Routing configurations. Here are some useful PowerShell commands: List all SBCs registered in Teams: Get-CsOnlinePSTNGateway Find Voice Routes using a specific SBC: Replace <SBCFqdn> with your SBC’s FQDN. Get-CsOnlineVoiceRoute | Where-Object { $_.PstnGatewayList -contains "<SBCFqdn>" } List all Voice Routes and their associated SBCs: Get-CsOnlineVoiceRoute | Select-Object Name, PstnGatewayList Find Voice Routing Policies using a specific Voice Route: Replace <VoiceRouteName> with the route name found above. Get-CsOnlineVoiceRoutingPolicy | Where-Object { $_.OnlineVoiceRoutes -contains "<VoiceRouteName>" } List all PSTN Usages and their associated Voice Routes: Get-CsOnlinePstnUsage References: 1. Get-CsOnlinePSTNGateway (MicrosoftTeams) | Microsoft Learn 2. Configure call routing for Direct Routing - Microsoft Teams | Microsoft LearnRe: Change Greeting Message in AA
@JFM_12 - Thanks for bringing this issue to our attention. Yes, you can update only the greeting message of a Microsoft Teams Auto Attendant using PowerShell, without modifying the menu options. How to do it: Use the Teams PowerShell module (MicrosoftTeams). Retrieve the Auto Attendant object. Update the GreetingPrompt property only. Example PowerShell: # Connect to Teams Connect-MicrosoftTeams # Get the Auto Attendant $aa = Get-CsAutoAttendant -Identity "<AutoAttendantId>" # Update the greeting message (Text-to-Speech example) Set-CsAutoAttendant -Identity $aa.Identity -GreetingPrompt @{ "PromptType" = "TextToSpeech"; "TextToSpeechPrompt" = "Your new greeting message." } Replace <AutoAttendantId> with your Auto Attendant's GUID or name. This command only changes the greeting; menu options remain unchanged. If you use a recorded audio file, set PromptType to "AudioFile" and provide the file.Re: Azure Bot not joining meeting - Server Internal Error. DiagCode: 500#1203002.@
@guoxl - You have correctly updated ServiceFqdn to "signaling.bottest.com" and verified your Nginx, certificate, AWS security group, and Windows Server configurations. The persistent error 500#1203002 still points to a Teams media platform connectivity or TLS/certificate issue. Key troubleshooting steps: Ensure your certificate's Subject Alternative Name (SAN) includes both signaling.bottest.com and media.bottest.com, not just *.bottest.com, as Teams media platform may require explicit SAN entries. Confirm that Nginx stream block for port 14217 supports both TCP and UDP (Teams media may use DTLS/UDP for media negotiation). Double-check that your certificate chain is complete and trusted by Microsoft Teams. Make sure your bot's public IP (InstancePublicIPAddress) matches the DNS record for signaling.bottest.com and is accessible from the Teams cloud. Review Application Insights and bot logs for any additional error details or handshake failures. For further troubleshooting, see: Troubleshoot HTTP 500 Internal Service Errors Bot Framework Media Platform connectivity requirements If all configuration steps are correct and the error persists, try regenerating the certificate with explicit SANs for all required hostnames and ensure UDP 14217 is open and routed correctly.
