Planner task comments no longer send email notifications – critical regression
This change removed a previously existing core functionality without providing an adequate replacement. With the new Planner experience, task comments no longer trigger automatic email notifications to assigned users. This breaks a critical communication mechanism that many teams relied on for reliable task coordination. As a result, assigned users are no longer consistently informed about updates, introducing a high risk of missed information and operational issues in day-to-day work. There is currently no supported or enforceable alternative to ensure users are notified. Previous behavior: Task comments triggered automatic email notifications Assigned users were reliably informed Communication was traceable and consistent Current behavior: No automatic email notifications No configuration to restore this @mentions required (manual, error-prone, not enforceable) Microsoft Support has confirmed that this is by design and cannot be reverted. From an enterprise perspective, this is not just a design change, but a regression of critical functionality without an equivalent replacement. Request: Please restore automatic email notifications for task discussions or provide a reliable, enforceable alternative for notifying assigned users. Question to the community: How are you handling this change in real-world scenarios? Switching tools? Enforcing @mentions? Moving communication out of Planner? Would appreciate hearing how others are dealing with this.
Shared Channels: @Channel mentions fail to trigger activity notifications for team-shared members
Hello everyone, I am facing a persistent issue regarding notification behavior in Microsoft Teams Shared Channels that I hope someone can clarify or help with. Scenario: We have a Shared Channel that is shared with multiple teams (e.g., 17 teams in total). Note: I know that this way of communicating is not the recommended way, but we are not allowed to use any Viva products etc. Users accessing the channel are members of those shared-in teams, but they are not listed as direct individual members in the Shared Channel's own member list. Users have their channel notification settings correctly configured to receive notifications (e.g., "All new posts" or standard banner/activity settings). The Problem: When someone uses a channel mention (e.g., @ChannelName) in this shared channel, the users who have access via the team-sharing mechanism do not receive any activity feed notifications. The workaround/oddity: They only receive the activity notification if we explicitly add each user as a direct individual member to the Shared Channel. The dilemma: Since the channel is shared with 17 teams, adding hundreds of users manually or via scripts as direct members creates massive redundancy and clutters the UI (users see the team and the channel redundantly). Inconsistency: We noticed that in older shared channels created some time ago, channel mentions worked across team shares without needing direct individual memberships. It seems newer shared channels behave differently and strictly require direct membership to trigger activity feed notifications for @Channel mentions. Questions: Is this a known design limitation or a recent backend change in Microsoft Teams for newer Shared Channels regarding how @Channel mentions resolve indirect team members? How are organizations supposed to utilize @Channel mentions effectively in large-scale collaborations involving multiple shared teams without bloating the direct membership list? Any insights or workarounds would be greatly appreciated. Thank you!
Teams calls reporting as potentially scams incorrectly
Hey Teams Community, In the past 5 days I am seeing callers from external tenants that are trusted and in mto showing as suspected scam callers when they call me. They see.me as a suspected scam also when I call. These tenants are all trusted and most of them are.members of the same MTO. This only started happening in the last 7 days. What is causing this? Does anybody else see this happening recently with a similar setup?Teams Enables Easier File Sharing in Federated Chat
A change to Teams makes it easier for users to share files in federated chat. Sounds good, but Microsoft planned to overwrite existing tenant controls to make the feature work, and that’s wasn't so good. That issue is now resolved, but the real question is whether Microsoft 365 tenants want users to share files through federated chat. I’m not so sure and would control this facility tightly. Apart from anything else, you might need some more MDO licenses to protect against possible infection. https://office365itpros.com/2026/10/02/easier-federated-chat/
Is there any rate limiting on inbound messages through bot framework?
I found this documentation regarding rate limits for app using bot framework - https://learn.microsoft.com/en-us/microsoftteams/platform/bots/how-to/rate-limit. However, it seems to be applicable to outbound messages from our service backend to MS Teams. Is there any similar rate limiting for messages being pushed to our backend from Teams conversations?How to receive app mentions only from a channel, while having the consent to read user messages?
We're building a Teams bot (Azure Bot + Entra app) that a customer adds into a standard Teams channel. Members @mention the bot and it replies in the same thread. To make replies useful, when the bot is mentioned we want to read recent messages in that thread for context, including messages where the bot was not mentioned. We have two requirements that appear to be in tension, and we'd like your guidance on the best-supported way to satisfy both: a. Delivery: we want Teams to send our bot only the activities where it is @mentioned (not every channel message), to avoid unnecessary inbound load and Bot Framework rate-limit pressure in busy channels. b. Context read: on those mention turns, we want to read recent thread messages via Microsoft Graph (/teams/{team}/channels/{channel}/messages/{id}/replies). We've identified two approaches, each with their drawbacks: a. RSC (ChannelMessage.Read.Group) - all channel messages; team-scoped & consented by team owner at install (low friction) Concern: RSC forces delivery of every channel message; heavy backend filtering + bot framework rate-limit risk b. App permission (ChannelMessage.Read.All) - @mention-only; tenant-wide consent; tenant-admin consent Concerns: setup friction (admin consent URL, per app per tenant); read grant spans all standard channels, including ones the app isn't a member of Our core question: Option 1 gives the delivery we don't want but the scoping we like; Option 2 gives the delivery we want but a tenant-wide read grant we'd prefer to avoid. Specifically: Is there any supported way to keep @mention-only delivery and a channel-scoped (RSC-style) read grant, i.e. decouple RSC's message delivery from its read authorization? Can the tenant-wide read in Option 2 be narrowed to specific teams/channels (e.g., via a Teams application access policy or any resource-scoping mechanism), so the app can only read where it's intended to operate? Given our two requirements, which approach does Microsoft recommend, and is there any option we've missed? TIA!How to Validate That Your BizTalk SB-Messaging Adapter Is Really Using AMQP
On September 30, 2026, Azure Service Bus stops accepting the Service Bus Messaging Protocol (SBMP) — the protocol the BizTalk SB-Messaging adapter has always used. The failure mode is not a warning in a log file; it is a refused connection. To keep those integrations running, a BizTalk Server 2020 hotfix adds a new Azure.Messaging.ServiceBus AMQP implementation to the adapter in place of the legacy SBMP path. This post walks through how to validate the hotfix was successfully deployed and is using AMQP and not SBMP. Required baseline: BizTalk Server 2020 with Cumulative Update 6 or Cumulative Update 7 installed, plus the SB-Messaging AMQP hotfix — KB5091379, obtained by opening a Microsoft support case. The hotfix is not offered through Windows Update or the regular CU download, and it will not install on a CU5 or earlier baseline. Every node in the BizTalk group needs it. A multi-server group will happily run the affected host instance on an unpatched node, and your test may land on the one server where the fix is not active. Patch and restart host instances everywhere, then record the edition, CU level, hotfix number, and component build per server. Hotfix location: https://1drv.ms/f/c/cac4b5f5988b8228/IgCrzn_KTaZ8T5tuKmcdPgXxARuOLcGHDhxVLgeysj44GWE?e=w5AcpM Once the baseline is confirmed, test in a non-production environment that reproduces production topology, authentication, and the full network path — proxy, firewall, private endpoint, and DNS. And list every materially different configuration you intend to validate: each send port and receive location, queue, topic, and subscription usage, 32-bit versus 64-bit hosts, and features such as sessions, ordered delivery, or transactions. A green result on one port does not validate the others. Method 1: Verify the active connection on port 5671 (recommended) The adapter selects AMQP over TCP, and Azure Service Bus uses TCP port 5671 for AMQP over TLS. Correlating an established 5671 connection with the correct BTSNTSvc or BTSNTSvc64 process demonstrates that the BizTalk host is using the AMQP transport. Run elevated PowerShell while the receive location is enabled and actively polling: $hostProcesses = Get-Process BTSNTSvc, BTSNTSvc64 -ErrorAction SilentlyContinue Get-NetTCPConnection -State Established -RemotePort 5671 | Where-Object OwningProcess -in $hostProcesses.Id | ForEach-Object { $process = Get-Process -Id $_.OwningProcess [pscustomobject]@{ Process = $process.ProcessName ProcessId = $_.OwningProcess LocalAddress = $_.LocalAddress LocalPort = $_.LocalPort RemoteAddress = $_.RemoteAddress RemotePort = $_.RemotePort State = $_.State } } Expected result: Process is BTSNTSvc or BTSNTSvc64. Remote port is 5671. State is Established. The remote address resolves to or corresponds to the Service Bus namespace. What an empty result means: not much, on its own. An empty result is inconclusive, not a failure. Confirm the port or receive location is enabled, the host instance is running, traffic is actually flowing during the check, and that DNS, firewall, or private endpoint rules permit the connection — then repeat. One important exception: if your environment routes AMQP over WebSockets on TCP 443, you should not expect a 5671 connection at all. In that case skip to Method 2. Method 2: Capture adapter traces When the connection view is unavailable or ambiguous, the trace is the more definitive answer, because it shows which code path executed rather than which socket happened to be open. BizTalk adapter tracing uses ETW through BT.Trace.Tracer, and entries containing [SBMessaging-AMQP] confirm that the new AMQP-specific implementation executed. Start BizTalk adapter tracing immediately before the test — not hours earlier. Send or receive a single, uniquely identifiable test message through the target port or receive location. Stop tracing as soon as the message completes. Search the captured output for [SBMessaging-AMQP] entries inside the test window, and match them to the host instance and configuration you were exercising. Method 3: Block the legacy SBMP ports Methods 3 and 4 are corroborating tests, not proof, and belong in an isolated environment. Legacy SBMP commonly uses TCP ports 9350 through 9354. If the isolated AMQP workload continues to operate while those ports are blocked and TCP 5671 remains available, the result corroborates that the workload does not depend on SBMP. Record the original firewall rules before you start and restore them immediately afterwards — this test has a real blast radius if it escapes the test subnet. Method 4: Large message functional test In Basic and Standard tiers, the maximum message size is 256 KB, regardless of SDK or protocol, so this test does not apply there. In Premium, the legacy SBMP path supports messages only up to 1 MB, whereas AMQP supports larger messages up to the entity’s configured maximum of 100 MB. Successfully processing a Premium message larger than 1 MB therefore provides supplementary evidence that the adapter is using AMQP. Read a failure carefully: entity limits, timeouts, and pipeline constraints all produce the same symptom, so a failed large-message test is not by itself evidence that the hotfix did not take. Verify payload integrity and the event log, then remove the test message and restore any temporary entity settings. Do not stop at the protocol Confirming that AMQP is in use answers the transport question. It does not answer whether your solution still behaves the same way. AMQP and SBMP differ in a handful of behavioural details, so before you call the validation complete, run the scenarios your integrations depend on and compare against a pre-change baseline: Send and receive across each representative queue, topic, and subscription path, checking message body and application-property fidelity. Peek-lock completion, abandon, defer, dead-letter, and retry behaviour, plus sessions, ordering, transactions, and duplicate detection where you use them. Authentication renewal, and recovery after a host instance restart or a brief network interruption. Throughput and latency within your accepted baseline, with no new event log errors, suspended instances, duplicates, or lost messages.Teams Gets Messaging Reminders
The Teams Remind Me feature is a new action available to allow users to create future reminders for chat and channel messages. When the set time comes around, Teams notifies the user about the marked messages, with the intention that users can pick up a topic discussed in a chat or channel conversation. It’s a good idea that’s similar to the way that email reminders work. The only wonder is why reminders have not appeared in Teams before now. https://office365itpros.com/2026/09/16/remind-me-teams/
