Microsoft Roadmap, messagecenter and blogs updates from 09-05-2026

Updated May 8, 2026: We have updated the timeline. Thank you for your patience. 

To help you manage agent adoption for Microsoft 365 Copilot Chat, we are introducing a new usage report in the Microsoft 365 admin center. The report provides visibility into how users in your organization are actively using agents in Microsoft 365 Copilot Chat and includes metrics such as: 

• Total number of active agent users and active agents 
• Usage breakdown per user, per agent, and per user-agent pair 
• Segmentation by license state (licensed vs. unlicensed Microsoft 365 Copilot users) 
• Segmentation by agent creator type (i.e. agents built by your organization, Microsoft, or Microsoft partners) 

The new report is rolling out in preview and will be available under Reporting > Usage > Microsoft 365 Copilot > Agent. During the preview stage, the report will display a maximum of 30 days of history. In addition, usage information from prior to August 19 2025 will not be available in the report. This report only includes declarative agents. Usage data for SharePoint agents and Custom engine agents will be available in a future update.

This message is associated with Microsoft 365 Roadmap ID 497999

[When this will happen:]

Public Preview (Worldwide): Available now.

General Availability (Worldwide): We will begin rolling out end of July 2026 (previously early May) and expect to complete end of July 2026 (previously mid-May).

[How this will affect your organization:]

[What you need to do to prepare:]

Updated May 8, 2026: We are not releasing this feature at this time. We apologize for any inconvenience this may cause.

[Introduction]

Teams users in tenants with open collaboration policies have long been able to start a chat with anyone who has an email address. However, recipients without a Teams account were previously asked to sign up for one before being able to collaborate. We’re introducing a new capability in Microsoft Teams for certain tenants (see ‘Who is affected’ below) that allows these recipients to join the chat as a guest— no account needed, and as long as it is allowed by the tenant’s existing policy configuration.

This feature will be available across Windows, Mac, Web, iOS, and Android platforms.

This message is associated with Microsoft 365 Roadmap ID 513271.

[When this will happen:]

• Targeted Release: Rollout for users with the aforementioned licenses begun in early November 2025 and was completed in mid-November 2025
• General Availability (Worldwide): We are not releasing this feature at this time. 

[How this affects your organization:]

Who is affected:

This capability is currently available only to small and medium business customers enrolled in public preview with a Teams Essentials, Business Basic, Business Standard, or Business Premium license. It also only affects organizations with guest chat enabled and that do not limit guest collaboration to specific domains. Organizations without users enrolled in public preview or without users with these licenses may still see this post even if they are not affected.

What will happen for those who are affected:

• After Teams users start a chat with someone who is not on Teams, the recipient will receive an email inviting them to join the chat as a guest. Only Teams users in your organization can start the chat, as users without Teams accounts cannot initiate chats.
• Chats will remain within your organization’s boundary.
• This feature is enabled by default but will be governed by your organization’s Entra B2B Guest policies and Teams Admin Center Guest Access policies. It will not override any existing policy configurations.

[What you can do to prepare:]

• Update internal documentation to reflect this new capability.
• Inform helpdesk and support teams about the change.
• Review the documentation here: Chat with anyone not using Teams – Microsoft Teams | Microsoft Learn
• To disable the feature, set the UseB2BInvitesToAddExternalUsers attribute of TeamsMessagingPolicy to false. Set-CsTeamsMessagingPolicy documentation here.

[Compliance considerations:]

No compliance considerations identified, review as appropriate for your organization.

Updated May 8, 2026: We have updated the content. Thank you for your patience. 

[Introduction]

We are introducing Microsoft Purview Data Lifecycle Management (DLM) retention support for Microsoft Teams call logs. Microsoft Teams stores call logs in several persistent locations, such as Call Detail Record (CDR) logs, which are currently retained indefinitely. However, regulatory requirements in various countries specify maximum retention periods for calling-related logs, creating a potential compliance gap. This update enables organizations to manage retention or deletion of Teams call logs to meet regulatory obligations, while still supporting evolving product features and business needs.

This message is associated with Microsoft 365 Roadmap ID 559261.

[When this will happen:]

General Availability (Worldwide): Rollout will begin in late April 2026 and is expected to complete by late April 2026.

[How this affects your organization:]

Who is affected:

• Microsoft 365 compliance administrators
• Organizations using Microsoft Teams calling

What will happen:

• Compliance admins can apply Microsoft Purview DLM retention and deletion policies to Teams call logs.
• Teams call logs stored with Teams compliance data in Exchange Online mailboxes are no longer retained indefinitely if new policies scoping teams call logs are setup.
• Existing Purview retention capabilities and workflows are respected.
• There is no direct impact to user calling experiences.

[What you can do to prepare:]

• Review your regulatory and business requirements for retaining Teams call logs.
• Create or update Microsoft Purview retention policies to retain or delete Teams call logs as required once the feature is available.
• Update internal compliance documentation and guidance for your compliance and legal teams.

[Compliance considerations:]

[Introduction]

We are introducing a new “Filmstrip” layout for the SharePoint News web part and expanding support for aggregating news from multiple SharePoint sites. This update provides an additional layout option for displaying news and extends cross-site news aggregation capabilities.

[When this will happen:]

• Targeted Release (Worldwide): We will begin rolling out in early May 2026 and expect to complete by mid-May 2026.
• General Availability (Worldwide, GCC, GCC High, DoD): We will begin rolling out in mid-May 2026 and expect to complete by late June 2026.

[How this affects your organization:]

Who is affected:

• SharePoint page editors and site owners with permissions to edit pages
• Organizations using SharePoint Online across Worldwide, GCC, GCC High, and DoD clouds

What will happen:

• A new “Filmstrip” layout will be available in the News web part.



• The Filmstrip layout displays news posts in a large, visually prominent format to improve discoverability.
• Editors can select multiple SharePoint sites as news sources, allowing the News web part to aggregate and display posts from those sites in a single view. Users will only see content they have permission to access.
  • This capability is now available in GCC, GCC High, and DoD environments; it was previously available in Worldwide environments.
• Both the Filmstrip layout and multi-site news capabilities are available by default and are optional to use.
• Existing news configurations, permissions, and publishing workflows remain unchanged.

[What you can do to prepare:]

No required action.

Recommended actions:

• Inform SharePoint site owners and page editors about the new layout option.
• Update internal documentation or training materials to include the Filmstrip layout.
• Review intranet pages where enhanced visual storytelling may improve engagement.
• If applicable, guide users on leveraging multi-site news aggregation.

Learn more: Use the News web part on a SharePoint page | Microsoft Support

[Compliance considerations:]

The multi-site news capability enables the News web part to aggregate and display content from multiple SharePoint sites. This expands how existing content is accessed and presented across site collections while continuing to respect existing permissions.

[Introduction]

To balance organizational branding with user flexibility, administrators will be able to control whether users can change the default compose font in Outlook for iOS and Android. When a default font name or size is set using Microsoft Intune app configuration policies, new configuration keys will allow administrators to decide if users can modify those defaults.

[When this will happen]

General Availability (Worldwide): We will begin rolling out in early June 2026 and expect to complete by late June 2026.

[How this affects your organization]

Who is affected

• Administrators managing Outlook for iOS and Android using Microsoft Intune
• Users only if administrators enable user changes

What will happen

• Today, when a default compose font name or size is configured through Intune app configuration, users cannot change it.
• With this update, administrators will be able to optionally allow users to change:
  • The default font name
  • The default font size
  • Both
• Two new Intune app configuration keys will be available:
  • com.microsoft.outlook.Settings.defaultFontName.UserChangeAllowed
  • com.microsoft.outlook.Settings.defaultFontSize.UserChangeAllowed
• By default:
  • Both keys will be set to false, preserving existing behavior.
  • No changes will occur unless an administrator enables them.
• The keys will apply only when the corresponding default font setting is already configured.
• If a user changes the font:
  • The administrator-configured default will no longer apply for that user.
  • Future administrator updates will not override the user’s selection.
  • There is no automatic reset to the administrator-defined value.
• This feature will be off by default and requires explicit administrator configuration.

[What you can do to prepare]

No action is required to maintain the current locked-font behavior.

Optional (recommended):

• Review your Intune app configuration policies for Outlook for iOS and Android.
• To allow user changes:
  • Set com.microsoft.outlook.Settings.defaultFontName.UserChangeAllowed to true to allow font name changes.
  • Set com.microsoft.outlook.Settings.defaultFontSize.UserChangeAllowed to true to allow font size changes.
• Update internal documentation or helpdesk guidance as appropriate.

[Compliance considerations]

[Introduction]

To strengthen security for federated authentication, Microsoft Entra will update the default behavior of federatedTokenValidationPolicy. This policy governs how Microsoft Entra validates federated authentication tokens and determines whether sign-ins are allowed when the internalDomainFederation does not match the user’s UPN domain. Previously, enforcing this behavior required explicit tenant configuration, but it will now be applied by default to reduce the risk of unintended cross-domain sign-ins caused by misconfigured or overly permissive federation trust relationships.

[When this will happen]

General Availability (Worldwide, GCC, GCCH, and DoD): We will begin rolling out in mid-August 2026 and expect to complete by mid-August 2026.

[How this affects your organization]

Who is affected

• Microsoft 365 tenants using federated authentication in Microsoft Entra
• Admins managing federated domains that were configured before December 2025
• Applies only to federated domains that have an internalDomainFederation object

What will happen

• By default, federated sign-ins will be blocked when the internalDomainFederation does not match the user’s UPN domain.
• The internalDomainFederation object is typically created automatically during federation setup with Active Directory Federation Services (AD FS) or other identity providers (IdPs).
• This stricter default behavior of the federatedTokenValidationPolicy is already enforced for federated domains added since December 2025.
• After this change, the same behavior will apply to all existing federated domains with an internalDomainFederation object.
• Impacted sign-ins will fail with the error:

AADSTS5000820: Sign-in blocked by Federated Token Validation policy. Contact your administrator for details.

• There is no change to the user experience unless cross-domain federated sign-ins are currently occurring.

[What you can do to prepare]

• No action is required for most organizations.
• Cross-domain federated sign-ins will be blocked automatically as part of this security improvement.
• Organizations that rely on cross-domain federated sign-ins should review their existing federation configurations before rollout.
• (Strongly discouraged) If required for business continuity, Security Administrators, Hybrid Identity Administrators, or External Identity Provider Administrators can use Microsoft Graph to create a custom federatedTokenValidationPolicy with rootDomains = none to allow cross-domain sign-ins.
• Communicate this change to identity and helpdesk teams to reduce support escalations.

Learn more:

• Get federatedTokenValidationPolicy | Microsoft Graph | Microsoft Learn
• Get internalDomainFederation | Microsoft Graph | Microsoft Learn
• Use Graph Explorer to try Microsoft Graph APIs | Microsoft Graph | Microsoft Learn
• validatingDomains resource type | Microsoft Graph | Microsoft Learn

[Compliance considerations]