Teams Clamps Down on MOERA-Only Tenants
The latest restriction on tenants using MOERA (service domain) addresses in production is that Teams will restrict external collaboration from September 2026. At this point, there is zero sense in any organization using a MOERA-only tenant for production purposes. Restrictions in Exchange Online and Teams should drive that point home, and the likelihood is that further clampdowns will follow in the future. https://office365itpros.com/2026/09/02/moera-only-tenants-external-collab/What if Teams isn’t too complicated — but simply being compared to the wrong product?
Many users first experience Microsoft Teams through meetings, chat, and file sharing. So it feels natural to compare Teams with messaging apps. But I’ve started to wonder whether that comparison itself shapes how people experience Teams. In markets such as Taiwan, Japan, and Thailand, LINE is deeply embedded in everyday communication. For those unfamiliar with it, LINE is a widely used consumer messaging app in these markets. When users bring that same mental model into Teams, a familiar question appears: “Why does Teams have to be so complicated?” But what if that isn’t quite the right question? I explored the idea in this short interactive page: Maybe We've Been Thinking About Teams the Wrong Way https://teams-vs-line-vinci.vinciwang.chatgpt.site/en/teams-vs-line One analogy sits at the center of it: LINE is like a speedboat. Teams is more like an aircraft carrier. I’m particularly interested in whether people here agree — or think this analogy actually proves the opposite. Is the problem mainly Teams itself, or the mental model we use to judge it?
Build governed asynchronous APIs with Azure API Management and Azure Service Bus
Many applications use Azure Service Bus to decouple services, handle traffic spikes, and process workloads asynchronously. However, securely exposing messaging capabilities to applications, partners, and internal teams can require custom middleware or messaging-specific client implementations. Today, we’re announcing the general availability of native Azure Service Bus integration in Azure API Management. With the send-service-bus-message policy, developers can publish messages directly from an Azure API Management gateway to an Azure Service Bus queue or topic. This provides a secure and governed HTTP interface for Service Bus workloads—without requiring teams to build and operate a separate adapter service. Connect APIs directly to Azure Service Bus Azure API Management can act as the governed entry point for applications that submit work to Azure Service Bus. A client sends a standard HTTP request to API Management. The gateway can authenticate and authorize the caller, validate or transform the request, and apply policies such as rate limits and quotas before publishing the message to a Service Bus queue or topic. Once the message is accepted, API Management can immediately respond to the caller while downstream services process the message asynchronously. Alternatively, message publication can be added to an existing API flow while the request continues to its primary backend. This integration brings together API governance in Azure API Management and reliable asynchronous messaging in Azure Service Bus—without adding another intermediary service. Greater control over Service Bus messages As part of general availability, we’re introducing additional controls for building production messaging workflows. 1. Control how messages are processed Developers can configure the following Service Bus message properties directly in the policy: Message IDs to correlate messages and support duplicate-detection or idempotent processing patterns. Session IDs to group related messages for ordered or stateful processing. Time-to-live to prevent messages from being processed after they are no longer relevant. These values can be generated dynamically using API Management policy expressions, allowing them to reflect request IDs, customer identifiers, transactions, or other application context. 2. Capture the send result The response-variable-name attribute captures information about the Service Bus send operation in an API Management context variable. Subsequent policies can use the result to add correlation information to an API response, emit telemetry, record an operational event, or apply conditional logic when a message cannot be sent. 3. Choose how failures affect the API Different messaging scenarios require different failure behavior. When publishing the message is the primary purpose of an API, a send failure can stop policy execution and invoke the API Management error-handling path. When publishing is secondary—such as sending an audit event or initiating optional downstream processing—the ignore-error option can allow the primary API request to continue. Information about the send operation remains available through the response variable for logging or subsequent policy logic. 4. Secure access with managed identity API Management authenticates to Azure Service Bus using a Microsoft Entra managed identity. Customers can use the system-assigned identity of the API Management service or specify a user-assigned managed identity. The selected identity is granted the Azure Service Bus Data Sender role for the appropriate namespace, queue, or topic. This removes the need to store Service Bus connection strings or shared access keys in API policies and makes it easier to apply least-privilege access using Azure role-based access control. Send a message with an API Management policy The following example sends the incoming request body to an orders queue. It assigns a message ID and expiration time, captures the result of the send operation, and treats successful publication as a required part of the API request. <send-service-bus-message queue-name="orders" namespace="contoso-messaging.servicebus.windows.net" message-id="@(context.RequestId.ToString())" time-to-live="00:10:00" response-variable-name="serviceBusResult" ignore-error="false"> <payload> @(context.Request.Body.As<string>(preserveContent: true)) </payload> </send-service-bus-message> A session ID can also be added when related messages need to be grouped for ordered or stateful processing. For a fully asynchronous API, the policy can be followed by return-response so that API Management acknowledges the request immediately after sending the message. For an existing API, the request can continue to its configured backend after the message is published. Common integration scenarios Create asynchronous APIs: Accept an order, document, or processing request through an HTTP API, publish it to a queue, and return immediately while downstream services complete the work. Govern partner integrations: Provide partners with a managed API contract instead of exposing the underlying Service Bus namespace. API Management can authenticate callers, validate requests, and apply quotas before publishing messages. Publish business events: Publish events to a Service Bus topic so multiple subscriptions and downstream services can process them independently. Handle bursts of incoming traffic: Use Service Bus to buffer messages when incoming API traffic temporarily exceeds the rate at which downstream services can process requests. Add events to existing API operations: Publish audit, notification, analytics, or workflow events while allowing the primary API request to continue to its configured backend. Preserve workflow affinity: Use Service Bus sessions to group related messages for ordered or stateful processing based on a customer, transaction, order, or workflow identifier. Get started To send messages from Azure API Management to Azure Service Bus: Create or select an Azure Service Bus queue or topic. Enable a system-assigned or user-assigned managed identity on the API Management service. Assign the identity the Azure Service Bus Data Sender role. Add the send-service-bus-message policy to an API operation. Configure the message payload, processing properties, output variable, and failure behavior. With native Azure Service Bus integration, Azure API Management provides a secure and governed way to connect HTTP APIs with asynchronous messaging workloads—without requiring additional middleware. Learn more Send Service Bus message policy reference Send messages to Azure Service Bus from Azure API Management Azure API Management June 2026 release notes Azure Service Bus documentation
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 PowerShell Embraces Web Account Manager and Imposes Control Over Federated Chat
Teams released a new version of their PowerShell module on July 19. The new module contains WAM support and cmdlets to limit federated chat for specific users and tenants. The new controls are welcome, but it’s a sad state of affairs that to configure the settings you must install a new version of a module that doesn’t work so well alongside other Microsoft 365 modules. https://office365itpros.com/2026/07/24/federated-chat-controls/Automatic initials are taking my business
Hello everyone, I'm a software developer, mostly based in Germany. I have a M365 Business Account and am using Teams as part of it. Since automatic initials, instead of generic profile pictures, became a thing, I'm constantly in a hurry to change my profile picture as soon as possible. This is because my initials are SS, which in the German culture is the abbreviation of the company responsible for the death camps during Nazi Germany. People are so upset about it that I even had customers not do business with me. They saw the SS initials in calls and thought I was using this on purpose to make a political stand, i.e. being in favour of the industrial scale mass murder of several million people. I'm not. So here is where my frustration is with Teams, which I'm paying for, and which is taking my business away with its stupid initials: I cant change the initials without changing my name I cant populate my picture to outside orgs preventing the initials from being shown This leads me to the incredibly uncomfortable situation that every time I connect to a new client, I need to discuss my distancing of the genocide 80 years ago before actually being able to commence a meeting. Not a very happy topic and as mentioned before I have lost business because of it. Is there please, any solution to this, that doesn't involve having to change my name? Kind Regards SebastianThe Misleading Teams Remove External Chat from User View API
The Graph removeAllAccessForUser API is supposed to remove external chat messages from the view of a tenant user when the chat contains some objectionable material. Unless the documentation is erroneous, the API doesn’t work as advertised and the results are disappointing. All of which means that blocking content for external chats isn’t really possible. If someone gets to start an external chat, they can pump some horrible stuff into your tenant. https://office365itpros.com/2026/07/02/external-chat-api/
Anyone Else Having Issues?
Hello! My company uses Teams as our main communication channel. For the past two or three weeks we have had significantly more issues than usual with Teams. Messages will sit and not send for sometimes over an hour. We have tried the standard troubleshooting methods and are still facing this problem. Is it just us or is this a bug? If so, is Microsoft working on a solution? Thank you!
Don't expire attached chat files | Show a warning.
Teams allows users to upload files to share with others in a chat. These files inherit the organization's sharing policy. So whether you use Share or Copy Link in SharePoint or OneDrive or you use Attach File in Teams, the same default policy is applied. The issue, what makes the Teams experience different from SharePoint / OneDrive, is that the message with the attached file persists in the chat. A file that was attached to a conversation two months ago appears to still be in the chat. However, the default policy blocks access to the file that appears present. Moreover, there is no method for the sender to alter the sharing policy using the Attach function. When this an issue, this is a HUGE issue. Suggestions: Actually attach the attached file and store in the recipient's Attachments folder. Don't use a paperclip icon that says "Attach file" for files that aren't actually attachments. Warn the sender that the attached file inherits the organization's 'Share with anyone' policy and may expire. Prompt the sender to alter the sharing link before sending. Put a timer on the attachment showing the countdown to expiration. After the expiration date, the file should be labeled "Your organization's sharing policy has expired access to this file". Add a button for the recipient to request access to the file again.
