Restore a Conditional Access Policy Only Possible via Graph Requests For Now

Documented but not announced, the beta endpoint for the Microsoft Graph conditionalAccessPolicy resource now supports an API to restore soft-deleted conditional access policies. The restore API is used alongside the API to list soft-deleted objects used with conditional access policies. The APIs are relatively new and have not yet shown up in the Entra admin center, which currently issues a solemn warning if an administrator deletes a conditional access policy (Figure 1).

Finding Soft-deleted Conditional Access Policies

The code to discover if a tenant has any soft-deleted conditional access policies is straightforward. Because the API is relatively new, a cmdlet is not yet available in the Microsoft Graph PowerShell SDK (V2.31). No doubt a cmdlet will appear in a future version.

To discover if any soft-deleted conditional access policies exist, we execute the Invoke-MgGraphRequest cmdlet to run a HTTP request against the API and examine the details of what the API returns. The Policy.Read.ConditionalAccess permission must be available to the interactive session and the signed-in user must hold a suitable Entra role such as Conditional Access administrator or Security administrator.

$Uri = 'https://graph.microsoft.com/beta/identity/conditionalAccess/deletedItems/policies'
$Data = Invoke-MgGraphRequest -Uri $Uri -Method Get -OutputType PSObject | Select-Object -ExpandProperty Value

If ($Data) {
  Write-Host ""
  Write-Host ("{0} soft-deleted conditional access policies found" -f $Data.count)
  Write-Host ""
  $Data | Format-Table Id, displayName, createdDateTime, deletedDateTime
} Else {
  Write-Host "No soft-deleted conditional access policies found to restore"
}

1 soft-deleted conditional access policies found

id                                   displayName                   createdDateTime     deletedDateTime
--                                   -----------                   ---------------     ---------------
14786eef-facd-41ac-83e6-19b317d3e054 Strong MFA for Hard Deletions 05/02/2025 14:05:07 02/10/2025 17:01:05

The output shows that the API found a soft-deleted conditional access policy. Like other Entra ID soft-deleted objects, conditional access policies remain in the soft-deleted state after deletion. When the retention period expires, Entra removes the policy object permanently and it is no longer recoverable.

Restore a Soft-Deleted Conditional Access Policy

Restoring a soft-deleted conditional access policy requires the Policy.ReadWrite.ConditionalAccess permission. The signed-in user must also hold a suitable RBAC role as described above. This example selects the first item in an array of soft-deleted policies returned using the first example, creates the URL to restore the policy, and executes the request to restore the soft-deleted conditional access policy. A successful restore populates the variable used to accept the output of the Invoke-MgGraphRequest cmdlet, so the code checks the variable to make sure that the restore worked:

$PolicyId = $Data[0].Id
$RestoredPolicy = $null
$Uri = ("https://graph.microsoft.com/beta/identity/conditionalAccess/deletedItems/policies/{0}/restore" -f $PolicyId)
Try {
  $RestoredPolicy = Invoke-MgGraphRequest -Uri $Uri -Method Post -ErrorAction Stop
} Catch {
  Write-Host ("Error restoring conditional access policy {0}" -f $PolicyId)
}
If ($RestoredPolicy) {
  Write-Host ("Successfully restored soft-deleted {0} conditional access policy" -f $RestoredPolicy.displayName)
}

Another way to check that the restore worked is to run the Get-MgIdentityConditionalAccessPolicy cmdlet:

$Check = Get-MgIdentityConditionalAccessPolicy -ConditionalAccessPolicyId $RestoredPolicy.id
If ($Check) {Write-Host "Restore worked!"}

The newly restored policy will be visible in the Entra admin center the next time the Conditional Access Policies page refreshes.

Permanently Remove a Soft-Deleted Conditional Access Policy

If necessary, soft-deleted policies can be removed before the 30-day retention period expires with the delete policyDeleteItem API. Once again, the example uses the first item in an array of soft-deleted policies.

$PolicyId = $Data[0].Id
$Uri = ("https://graph.microsoft.com/beta/identity/conditionalAccess/deletedItems/policies/{0}" -f $PolicyId)
Try {
  Invoke-MgGraphRequest -Uri $Uri -Method Delete -ErrorAction Stop
} Catch {
  Write-Host ("Failed to remove soft-deleted policy {0}" -f $PolicyId)
}

Recovery Options are Always Good

It’s always good to have a get out of jail card that allows the recovery of items deleted in error and the new restore capabilities are a good addition to the PowerShell cmdlets for managing conditional access policies.

I’m not sure how many administrators delete conditional access policies instead of first disabling unwanted policies for a period of a week or so before proceeding to deletion. That’s still the best way of removing conditional access policies from a tenant because everything can be done through the Entra admin center. However, Microsoft has some AI-powered Entra administrative agents in preview. The current set of agents includes the conditional access optimization agent, which is designed to analyze and optimize the conditional access policies found in a tenant, including:

The agent also evaluates all existing enabled policies to propose potential consolidation of similar policies. When the agent identifies a suggestion, you can have the agent update the associated policy with one click-remediation.

If the conditional access optimization agent recommends consolidation into a smaller set of policies, it probably will result in the removal of some policies that are no longer required. Administrators click to action the agent’s recommendations. It’s good to know that if the agent proposes the removal of some policies that should be kept, at least administrators can recover the deleted policies if they go ahead with “one-click remediation.”

Insight like this doesn’t come easily. You’ve got to know the technology and understand how to look behind the scenes. Benefit from the knowledge and experience of the Office 365 for IT Pros team by subscribing to the best eBook covering Office 365 and the wider Microsoft 365 ecosystem.

Monthly Update #124 for Office 365 for IT Pros Available for Download

The Office 365 for IT Pros team is delighted to announce the availability of the October 2025 update for Office 365 for IT Pros (2026 edition). This is monthly update #124. Current subscribers can download the updated EPUB and PDF files from their Gumroad.com account or by using the View content link in their receipt. See our FAQ for more information about how to download updates.

We’ve also updated the Automating Microsoft 365 with PowerShell eBook, which is now at version 16.4. The updated PowerShell EPUB and PDF files are available at the same location as the Office 365 for IT Pros book files. The paperback version of Automating Microsoft 365 with PowerShell has also been updated and is available on a print-on-demand basis from Amazon.

October Updates and the AI Effect

As usual, a bunch of changes are spread across the book chapters, details of which are in our change log. One thing that’s becoming increasingly notable is the growing percentage of Microsoft 365 message center notifications that relate to AI instead of updates to workloads like Exchange Online, SharePoint Online, and Teams.

It’s easy to understand why this is so. First, many of the Microsoft 365 workloads are very mature and already feature-rich, so less opportunity exists to add new functionality. Second, Microsoft’s development attention is obviously focused on adding as much AI-driven features to applications as possible to encourage customers to buy Microsoft 365 Copilot licenses.

The focus on AI gives us a challenge in deciding how much attention we should pay to Copilot features. We know that many Microsoft 365 tenants don’t use Copilot because the licenses are too expensive, they’ve chosen a different solution (like ChatGPT), or simply don’t see the value of AI in their environment at this point. While adding more Copilot content to the book might delight some tenants, it reduces the value of the book to other tenants.

Our current approach is to include Copilot content where it matters to tenant administration. An example is the configuration of the DLP policy to prevent Copilot Chat including content from sensitive documents in its responses. On the other hand, Copilot features that are user-centric in apps, like the facilitator agent in Teams, are usually not covered in the book. There are many of these features spread across Office and other apps. In addition, the features are in a period of rapid evolution, so documenting their use would occupy lots of time that could otherwise be used to cover topics of more general interest.

As AI becomes more embedded in administration (the initial skills available in Copilot for SharePoint Admin are a poor example of what will increasingly happen), we’ll probably change our guidelines, but that’s our current thinking.

Fixing the PDF Stamping Problem

As many of our subscribers know, Gumroad has struggled to fix a bug in the routine that stamps subscriber email addresses on our PDF files. The symptom is that the PDF is unavailable for download because it is “being prepared.” This doesn’t happen for all PDF downloads, but it happened enough to be a royal pain. Subscribers affected by the problem had to contact us, and the only workaround we had was to reissue the receipt. This action kicked off the PDF stamping routine and most of the time, it was enough to make the PDF available.

The good news is that we think Gumroad has fixed the problem by rewriting the PDF stamping routine. Every month in the recent past we have dealt with several subscribers who hit the problem. We’ll soon know if the Gumroad fix is effective. Fingers and toes are firmly crossed.

On to November 2025

As usual, we have started work on next month’s update (#125). Given that the Ignite conference is in the second half of November, there might be fewer changes to process. Then again, there’s always change in Microsoft 365, so we expect to be busy.

Integrate External Information into Microsoft 365 Copilot Search Results

In July 2025, Microsoft released Microsoft 365 Copilot Search. On its own, Copilot Search is a great way to search SharePoint Online, OneDrive for Business, Teams, and Exchange for information available to the Graph. The more interesting aspect is the ability for tenants with Microsoft 365 Copilot licenses to integrate external sources of information into search. AS Microsoft said at the time:

“Copilot Search leverages Microsoft Graph and Microsoft 365 Copilot connectors to index content across Microsoft 365 and third-party apps. It interprets user context, natural language, behavioral signals, and organizational relationships to deliver highly personalized, context-aware answers to complex queries.”

A Gallery of Microsoft 365 Copilot Connectors

The Copilot section of the Microsoft 365 admin center includes a gallery of off-the-shelf Microsoft 365 Copilot Connectors (previously called Graph connectors). These connectors can be plugged into Copilot search by configuring them to external sources of the relevant type, like the Jira Cloud or ServiceNow (Figure 1). These are called prebuilt connectors (see the online documentation).

If a prebuilt connector isn’t available for your preferred source, you can develop a custom connector. For example, the People platform that Microsoft is building envisages information about people being ingested into the Graph through Microsoft 365 Copilot connectors.

Sometimes it’s hard to get your mind around whether a new feature will be valuable in your environment. If someone in your organization asked, “how can we exploit Microsoft 365 Connectors?”, my guess is that quite a few tenant administrators would struggle to come up with a cogent answer. I’d be in the same position, so decided to take a look at configuring a connector to see what happens.

Configuring the Enterprise Websites Connector

I chose to test the enterprise websites connector, which is designed to ingest material from company or public websites available on the internet. Configuring the enterprise website connector is simple. Essentially, all you need is the https URL for a website. When active, the connector crawls the target website to fetch and index content to include the material into Copilot searches. Given the superb information found in Office365itpros.com and Practical365.com, I decided to configure connectors for both sites. Figure 2 shows the configuration I used to fetch information from the Practical365.com website.

It takes some time for a connector to perform the initial crawl and bring information into Microsoft search. Eventually, the connector status will turn to Ready (Figure 3), and at that point you’ll know that the information retrieved from the website is available for searching.

Searching External Data with Microsoft 365 Copilot Search

Microsoft 365 Copilot Search responds to search requests with information from all the sources available to it. I searched for information about the Microsoft 365 licensing report script that I knew occurs in articles published on Office365itpros.com (here’s one) and was rewarded with an instant hit (Figure 4) with the source that Copilot Search retrieved the information from clearly indicated in the results. Even comments for posts are indexed and available.

Clicking the link brings the user directly to the source page on the website. It’s a very seamless experience.

Even better, if asked to summarize the results, Microsoft 365 Copilot integrates the information from the external websites along with the other Graph-based information available to it. In the summary shown in Figure 5, Copilot cites a source from the Practical365.com site and tags it as “ThirdParty,” meaning that the information comes from a non-standard Graph source.

Easy, Quick, Seamless

Being able to integrate external website content into Microsoft 365 Copilot Search is one of the best features I’ve seen Microsoft launch in the blizzard of AI-related functionality introduced since the Copilot launch in March 2023. Configuring the connector is quick and easy; crawling happens automatically (and a schedule for crawling can be set up); and the results are presented seamlessly alongside items from other Graph sources. It’s a great example of the power of bringing external data into the Graph and can certainly help answer the question of what to do with Microsoft 365 Graph connectors.

Best of all, this is an easy way to integrate information from trusted external web sites into Graph searches. Who wouldn’t want to integrate content from Office365ITPros.com and Practical365.com?

Insight like this doesn’t come easily. You’ve got to know the technology and understand how to look behind the scenes. Benefit from the knowledge and experience of the Office 365 for IT Pros team by subscribing to the best eBook covering Office 365 and the wider Microsoft 365 ecosystem.

Knowledge Agent to Sort Out SharePoint Metadata

With all the associated hype that’s now the norm for a Microsoft announcement associated with AI, the SharePoint development group launched the preview of the SharePoint Knowledge Agent on September 18, 2025. You think “so what” because SharePoint has supported agents for almost a year. However, those agents reason over the content of files found in a site while the big difference with the Knowledge Agent is that it deals with site metadata and its purpose is to make sites work better rather than to help users find information.

Given Microsoft’s promise that the new agent could help stream content management (aka, sort out the mess that’s in so many sites) to “SharePoint into a dynamic, intelligent knowledge hub that gives your organization a competitive edge,” it seemed like a good thing to test. That is, if you have a Microsoft 365 Copilot license.

Enabling a Microsoft 365 Tenant for the SharePoint Knowledge Agent

With the licensing issue out of the way, the next step is to enable the tenant to support the Knowledge Agent. This can be done for all or selected sites, as described in the documentation. Enabling Knowledge Agent can only be done through PowerShell at this point, and throwing caution to the breeze, I elected for all sites and ran this command after connecting to SharePoint Online:

Set-SPOTenant -KnowledgeAgentScope AllSites

Using the SharePoint Knowledge Agent

There’s no point in testing any software against just a few objects, so I started by testing the Knowledge Agent against a site containing roughly 4,000 files in 10.2 GB of storage. The Knowledge Agent has its own floating action menu, which appears on top of the regular document view (Figure 1).

Given my notorious lack of organization, the Organize this library option seemed like a good place to start. The options (Figure 2) include creating three columns to hold metadata that the agent will generate to make the library easier for Microsoft 365 Copilot to process, creating a rule to do something when an action happens in the library, extract key actions from files to populate an autofill column, and summarize files.

I asked the Knowledge Agent to create some suitable columns. The document library already has some custom columns that I use to organize and search articles that I’ve written. As such, you might think that the library is already well-organized. The agent thought for a bit and then suggested that the library could use columns for the document type, date received, and assigned staff. If you agree, the agent adds the new columns to the existing view or creates a new view that includes the columns.

The important thing is that these are autofill columns. SharePoint auto-fills the properties for new files when they are created, and to backfill the properties for older files, background processes use the Copilot LLMs to generate the necessary information (Figure 3). The backfill process doesn’t happen immediately, and full population of the columns for all items can take a few days. The categorization of articles into document type was the most interesting part of the exercise, but nothing was gained from the date received (date the item was uploaded to SharePoint) and assigned staff (always me) columns.

The extract key actions and summarize options also use autofill columns to hold their results. The summaries are like the automatic summaries created by Copilot for Word documents. There’s no indication of if or how often the agent checks files for new or changed text to update the metadata and the autofill status doesn’t provide too much insight into what’s happening. Mostly, the autofill status showed information about processing that occurred over eight hours ago even when it was obvious that the agent had processed files more recently. In Figure 4, the agent updated the summary (for this article) but the autofill activity page lagged way behind.

Obviously, if the agent can’t extract text to summarize, it cannot populate these columns, so expect good results from Office and PDF files and lesser joy elsewhere. The agent experienced some problems with Word documents translated into Japanese by the SharePoint translation service, but on the upside, the agent stripped text nicely out of JPEG files to report what it found there.

Creating a rule calls the standard SharePoint feature, so there’s not much to say about it except that the agent possibly makes it a little easier for people to create rules. However, if they want to make changes to the rule, they’ll still need to go to SharePoint’s Automate menu, select Rules, and then Manage rules.

No Audit Records for Agent Processing

Unlike when humans create SharePoint agents, there’s no trace of Knowledge Agent activity in the audit log. This is perhaps unsurprising because the creation of SharePoint agents is only auditable by checking FileUploaded audit events for .agent files. Other workloads, including Exchange Online, create audit records when background processes perform actions that affect users, so I don’t know why SharePoint Online lags in this respect.

No Real Magic

The Knowledge Agent is a preview and who knows what the final version will deliver. For now, I find little trace of any magic generated by AI in what the Knowledge Agent delivers. But it’s entirely possible that my testing did not cover the kind of scenarios that Microsoft envisages the agent delivering most value, like classifying legal documents, or to help HR organize the resumes for job applicants.

I would have liked to try the agent out on sites with different types of information, but even though the Knowledge Agent is enabled for all sites, its action menu is only available in the first site I chose for testing (the situation persists a week after enabling the Knowledge Agent). There’s got to be something simple that’s going wrong here, but I can’t find an answer to the case of the missing action menu.

Insight like this doesn’t come easily. You’ve got to know the technology and understand how to look behind the scenes. Benefit from the knowledge and experience of the Office 365 for IT Pros team by subscribing to the best eBook covering Office 365 and the wider Microsoft 365 ecosystem.

Change to Beta Graph API Requires Update to User Password and Authentication Report Script

Last year, I wrote about how to exploit the newly-added Graph API to report the per-user MFA state for Entra ID accounts. As with all additions to the Graph, the new API used the beta endpoint, which is where APIs function when Microsoft is happy to expose the API in public while still knowing that some work is needed before the API can advance to the production (V1.0) endpoint.

Recently, a reader posted a comment about the article and said that when they ran the script in their tenant, no data showed up in the “Default MFA method” column in the report. I write scripts to illustrate principals and explore what’s possible rather than attempting to create production-ready code. In addition, it’s impossible for me to see what’s happening in another tenant, unless the tenant administrator gives me the necessary account with permissions, and that shouldn’t happen. My default response is therefore to ask people who report issues to do some basic PowerShell debugging by selecting the code where the problem seems to lie and running the commands to see what happens. Besides, I was on vacation, so I didn’t want to spend any time looking into what the issue might be.

Searching for the Problem

To cut a long story short, the person who reported the problem responded with sufficient data to indicate that an issue was present. After returning from vacation, it was time to open Visual Studio Code (and GitHub Copilot) and try to figure out what was happening.

The code looked good, and nothing seemed out of the ordinary. The script used Graph requests rather than cmdlets from the Microsoft Graph PowerShell SDK, but that’s a normal state with newly-released beta APIs because the AutoRest tool that generates SDK cmdlets from the API metadata hasn’t yet included the cmdlets in an SDK release. To make the code easier to read, I replaced a couple of API requests with SDK cmdlets and then noticed that the output from the Get-MgBetaUserAuthenticationRequirement cmdlet no longer contained details of a user’s default MFA method. This was the cause of the problem.

The Downside of Beta Graph APIs

Using beta APIs (or beta cmdlets) is a double-edged sword. The positive is access to functionality sooner than waiting for Microsoft to upgrade an API to a production release. Some APIs stay in the beta endpoint for years, and you can’t predict when Microsoft might consider an API to be reliable, robust, and performant enough to justify promotion from beta to production.

The downside is that beta features are prone to change based on developer and customer feedback, the need to accommodate changes elsewhere in the underlying workload, or as the side effects of bug fixing or tuning for performance. I have no idea why Microsoft removed the default MFA method output from the data reported by the cmdlet. Maybe it was because the UserPreferredMethodForSecondaryAuthentication property contains similar information.

A New User Password and Authentication Report Script

In any case, my script can only report what’s available, so I updated the code to remove the obsolete column and renamed the UserPreferredMethodForSecondaryAuthentication column to be “Preferred MFA method” (Figure 1). The change seemed to make sense at the time. If you disagree, feel free to create a GitHub push request to update the script. I’m happy to review any and all suggestions.

Don’t Depend on Beta Graph APIs

All of this goes to show that developers who rely on beta Graph APIs need to keep a wary eye out for changes that might impact their code. The change can happen at any time and probably won’t be flagged by Microsoft because it is, after all, a change to a beta API that’s expressly not intended for production use. I should learn my lesson (some day). In the meantime, enjoy the updated user password and authentication report script and all the other examples in the Office365itpros GitHub repository. I’m sure there’s a few more bugs lurking there that I need to attend to.

Need some assistance to write and manage PowerShell scripts for Microsoft 365, including Azure Automation runbooks? Get a copy of the Automating Microsoft 365 with PowerShell eBook, available standalone or as part of the Office 365 for IT Pros eBook bundle.

A Logical Progression for Copilot in the Microsoft 365 Apps

The news in message center notification MC1096218 (last updated 17 September 2025) about the rollout of Copilot Chat confirms the worst fears of some that Microsoft is on a one-way path to stuffing Copilot into as many places as it can. Well, that feeling is backed by some truth, but in this case, I think the change is a natural progression of Copilot’s existing presence in apps like Word, where it’s been producing document summaries since last year.

Once Copilot appeared in the Office apps, there was only one way forward, and that wasn’t to see Copilot disappear from Office. Now Copilot Chat is available in Word, Excel, and PowerPoint, just like it has been available in Outlook (new and classic) for a while. Microsoft says that the rollout is expected to complete in the coming weeks, which basically means that it will turn up when the stars align in terms of desktop client Office build and server infrastructure.

Copilot Chat for All

Copilot Chat is available for any user of the Microsoft 365 apps, with or without a Microsoft 365 Copilot license. The difference is that those with Microsoft 365 Copilot licenses can access tenant resources like documents stored in SharePoint Online and OneDrive for Business while those without are restricted to web queries (via Bing search).

Working in Copilot and an Office App

The idea behind the side-by-side implementation is that users can work on a file in the main pane while being able to interact with Copilot in a side pane (Figure 1). It’s a useful feature that makes it easy to take questions from the main file, research them in Copilot, and take the results back into the file.

Apart from anything else, integrating Copilot so tightly into the Office apps makes it less likely that users will seek AI assistance elsewhere and potentially end up uploading documents from SharePoint and OneDrive to services like ChatGPT. It also encourages people to consider upgrading from the free Microsoft Copilot to the full-feature and more expensive Microsoft 365 Copilot.

Word Action Button for Microsoft 365 Copilot Chat

After Outlook, Word is easily the Office app where I spend most time. The announcement in message center notification MC1143298 (last updated 17 September 2025) that an Open in Word action button will soon be available to move text from Copilot to Word is therefore very interesting.

It’s possible to move content from Copilot to Word now using Copilot pages as an interim step. Copilot pages are built from Loop, so the intention is that the content is worked on in Loop after coming from Copilot rather than being exported to a new app. At this point, Word is a more sophisticated word processing tool than Loop is. Given the use cases for the two apps, this is the natural state of affairs. I seldom need to collaborate with others to write articles or book text. Being able to move content from Copilot to Word is an action I shall check out once it becomes available later this month.

Teams Move to the Unified Microsoft 365 Apps Domain

Before closing for the weekend, a little bird tells me that Teams might soon move from its teams.microsoft.com domain to teams.cloud.microsoft as part of the initiative launched by Microsoft to create a unified domain for Microsoft 365 apps.

In March 2024, Microsoft posted a note for developers to tell them that Teams apps needed to be able to use teams.cloud.microsoft. By this point, I’m sure that most ISVs will have updated their apps, but if your tenant has some custom home-grown Teams apps, it’s worthwhile checking with the developers that the apps are ready to accommodate the domain switch. Who wants to be surprised when the switch happens?

Support the work of the Office 365 for IT Pros team by subscribing to the Office 365 for IT Pros eBook. Your support pays for the time we need to track, analyze, and document the changing world of Microsoft 365 and Office 365. Only humans contribute to our work!

Should Microsoft 365 Tenants Disable Keep Me Signed In?

When I wrote about the Entra ID Keep Me Signed In (KMSI) feature in February 2022, I concluded that growing threats might have made the feature less valuable than it once was. Like anything to do with Microsoft 365, the passing of time requires re-evaluation of attitudes and opinions, and this is true for KMSI too. Here’s my best attempt at summarizing the current state of the art.

Recapping How the Keep Me Signed In Feature Works

As a recap, KMSI is the option presented to users after they authenticate to “stay signed in” to reduce the number of times Entra ID forces the user to sign in. If the user chooses to stay signed in by choosing the Yes option (Figure 1), Entra ID creates a persistent authentication cookie that can last for up to 90 days (as opposed to 24 hours, which is the lifetime of a non-persistent cookie). With a persistent autentication cookie available, the user can connect to applications without signing in for the lifetime of the cookie. Because the cookie is persistent, it doesn’t matter if the browser session is restarted.

The Don’t show this again checkbox has nothing to do with the creation of the persistent authentication cookie. The checkbox controls whether Entra displays the prompt on the device for future sign-ins.

Obviously, a persistent authentication cookie is a bad idea if workstations are shared, but when workstations are personal and only used by a single person, keep me signed in is a nice way to reduce the friction of signing in. In fact, the Entra ID sign-in flow contains some logic to detect if a sign-in originates from a shared device and won’t show the stay signed in screen in this case. The same is true if Entra ID considers a sign-on to be high risk.

Clearing browser cookies on a workstation will remove the persistent authentication cookie.

Conditional Policies and Sign-in Frequency

Conditional access policies can interfere with the operation of persistent authentication cookies. If a conditional access policy insists that users reauthenticate based on a certain frequency, the full authentication process is invoked, and users must provide credentials. Some tenants impose unreasonable demands on users (or just guest accounts) and insist on very frequent authentication, so it’s a matter of achieving balance between annoying users and maintaining the desired level of security.

Considering the Question of Enabling Keep Me Signed In

All of which brings me back to the question of whether Microsoft 365 tenants should enable or disable KMSI. Generally speaking, I don’t see anything wrong with KMSI when the following conditions are true:

• People use personal rather than shared workstations. Authentication processing for people who use shared workstations can be controlled by specific conditional access policies.
• Strong multi-factor authentication is in place to ensure that the initial authentication is secure and is unlikely to be compromised by external attackers. In other words, use the Microsoft authenticator app or passkeys.
• Conditional access policies are in place to impose a reasonable sign-in frequency. Monthly seems about right. After using a weekly frequency for the last few years (for one tenant that I access frequently as a guest), I think this interval creates too much friction.

As always, the first order of business is to prevent user accounts being compromised. If an account is not compromised, KMSI is unlikely to cause a problem. The widespread adoption of continuous access evaluation by Microsoft 365 workloads makes closing off compromised account access easier, but that’s no excuse to avoid deploying strong multifactor authentication everywhere to protect every Microsoft 365 account.

Configuring Keep Me Signed In

To configure KMSI for everyone in a tenant, use the checkbox in User settings in the Entra admin center (Figure 2). KMSI is either enabled or disabled. It can’t be enabled for a specific group of users and disabled for everyone else.

KMSI is Fine in the Right Conditions

Microsoft 365 users have enough on their plate to cope with the ongoing and constant change in the apps they use daily. Reducing friction from sign-ins through features like KMSI seems like a good idea, providing it can be done securely and doesn’t compromise the tenant. Deploying strong multifactor authentication and effective conditional access policies go a long way to establishing the right conditions for KMSI. But if your tenant is open to compromise because it still uses single factor authentication (passwords) or lets people use weak multifactor authentication methods, don’t blame KMSI when you are compromised. At that point, persistent authentication cookies are the least of your worries.

So much change, all the time. It’s a challenge to stay abreast of all the updates Microsoft makes across the Microsoft 365 ecosystem. Subscribe to the Office 365 for IT Pros eBook to receive insights updated monthly into what happens within Microsoft 365, why it happens, and what new features and capabilities mean for your tenant.

Default Changes to Copilot Enabled Without Transcription

First issued on August 22, 2025, and updated on September 5 to clarify the timeline, message center notification MC1139493 (Microsoft 365 roadmap item 478611) flags an important change in how Microsoft 365 Copilot functions in Teams meetings. Ever since the introduction of Copilot, the way things worked is that transcription is enabled when Copilot is used in meetings. After Microsoft rolls out the change starting in early November 2025, using Copilot in Teams meetings will no longer enable and save transcripts. This change might be disruptive if meeting organizers expect transcripts to be available after meetings conclude, but as always, the devil is in the detail and this change might not affect your tenant.

The change isn’t surprising given that Copilot can answer meeting participant queries without a transcript (this wasn’t originally the case) and that Microsoft has gradually tightened access control to the meeting transcript over time.

Why Change the Generation of Meeting Transcripts

Microsoft isn’t saying why Copilot-enabled Teams meetings will no longer generate a transcript, but it’s probably to safeguard against the possibility that Copilot will regurgitate meeting discussions in its response to user prompts.

Meeting transcripts are stored in the meeting organizer’s OneDrive for Business account and are indexed by Microsoft Search. Because their content is indexed, transcripts are available for Copilot to process just like any other document that isn’t blocked by the DLP policy for Microsoft 365 Copilot. Meeting organizers with Teams Premium licenses can apply a sensitivity label to files shared during a meeting, but the sensitivity label doesn’t apply to the transcript.

Will The Change Affect My Tenant

The simple answer is yes, if your tenant uses the default Teams meeting policy. That’s because Microsoft manages the settings of default Teams policies and can adjust policy settings as needed.

In this instance, Microsoft will change the value of the Copilot setting in the Teams meeting policy from EnabledWithTranscript to Enabled. The first value is in place today and it’s what instructs Teams to generate the transcript with Copilot. The second value allows Copilot to be used in Teams meetings without the generation of a transcript. If you check the documentation for the Set-CsTeamsMeetingPolicy cmdlet, you’ll see that Microsoft refers to a “persisted” and “non-persisted” transcript. A persisted transcript is one that’s saved to OneDrive for Business; a non-persisted transcript is one that Teams generates internally to allow Copilot to reference what people have said during the meeting before deleting all trace of the transcript when the meeting finishes.

New Microsoft 365 tenants will automatically pick up the Teams meeting policy default settings. Existing Microsoft 365 tenants will use the default settings for new meetings.

An exception exists where custom meeting policies are in use. It’s relatively common to customize Teams policies and the meeting policy is often changed to meet organizational needs. When a tenant customizes a default policy, Teams copies the default policy to create a custom copy for the tenant. The tenant controls the settings of custom policies and Microsoft therefore cannot change the default setting for Copilot. In other words, everything happens as before and enabling Copilot for a meeting will generate and save a transcript.

If Microsoft updates meeting policies for a tenant, it’s easy to revert the change to ensure that transcription occurs with Copilot. The change must be made with PowerShell by running the Connect-MicrosoftTeams cmdlet to connect to Teams PowerShell. Then, run this code to find which meeting policies have Copilot enabled without a transcript:

Get-CsTeamsMeetingPolicy | Where-Object {$_.Copilot -eq "Enabled"} | Format-Table Identity 

To update a policy and restore Copilot with transcription, note the policy name and update it like this:

Set-CsTeamsMeetingPolicy -Identity "RestrictedFunctionality"-Copilot "EnabledWithTranscript" -AllowTranscription $true

Copilot Transcription for Individual Meetings

Even if Microsoft updates the default Teams meeting policy, meeting organizers can opt for transcription through meeting options either when scheduling (Figure 1) or during the meeting.

Persistent Conversations in Meetings

In MC1139493, Microsoft also make the point that conversation history has been made persistent within meetings. In other words, participants can switch between different elements of a meeting like chat or viewing the participant list without losing access to Copilot insights, even without a transcript being taken. The point is that when transcription is not enabled, persistence is possible using the internal transcript, which is how it should be.

So much change, all the time. It’s a challenge to stay abreast of all the updates Microsoft makes across the Microsoft 365 ecosystem. Subscribe to the Office 365 for IT Pros eBook to receive insights updated monthly into what happens within Microsoft 365, why it happens, and what new features and capabilities mean for your tenant.

Use the SharePoint Site Content Report to Highlight Issues – If You Can Find Any

As quickly as they can and in as many ways as possible, Microsoft is attempting to address the problem of digital rot in SharePoint Online. Having old, obsolete, inaccurate, and just plain wrong information in SharePoint Online and OneDrive for Business doesn’t matter so much until the eagle eye of AI tools are deployed. At that point, all manner of misleading responses can appear because the AI is grounded on misleading or incorrect information.

To some extent, customers cannot be blamed for the digital debris that they accrue in SharePoint Online. For years, Microsoft has encouraged cloud storage (the latest tactic is a policy setting to block users from saving to non-cloud locations), so it’s natural that some rot accumulates along with valuable material. As I’ve said before, many of the problems customers have encountered with Microsoft 365 Copilot deployments are the legacy of previous Microsoft collaboration strategies. Not everyone goes through the process of auditing the files stored in SharePoint Online to remove dross (here’s how to create a report of files in a document library, and here’s how to do the same for a OneDrive for Business account).

The Site Content and Policy Comparison Report

All of which brings me to the “SharePoint AI-powered site content and policy comparison report” announced in MC1143287 (27 August 2025). The report is available to tenants with Microsoft 365 Copilot or SharePoint Advanced Management (SAM) licenses. It’s one of the SAM features made available to Copilot customers without the need for SAM licenses. The site content and policy comparison report is rolling out in general availability now with completion worldwide due in late December 2025.

According to Microsoft, the idea is that a tenant selects a reference site that they regard as a good example of a site with “up-to-date and relevant policies” to use as a benchmark to compare up to 10,000 other sites against (Figure 1). In addition to policies that apply to the site (like data lifecycle policies), the reference site should contain more than 10 files of the same kind of material that’s found in the target sites. This is because the comparison uses the 10 most recently used files from each site.

The report uses AI to examine the target sites. The target sites can be chosen by uploading a CSV containing their URLs or selected using several site properties, ranging from the simplest (examine everything as shown in Figure 2) to identifying sites based on the container management sensitivity label assigned to sites, the site type, creation date (for example, sites created within the last 30 days), sites with no owners, and sites where external sharing is disabled.

Nothing in My Reports

Behind the scenes, AI compares the target sites against the reference site to highlight inconsistent application of policies based on the similarity between the reference site and target sites (here’s the documentation). After pondering on any anomalies that it finds (a process that Microsoft warns could take up to 48 hours), the AI generates a report for administrators to consider and potentially act upon.

And that’s where my story ends because despite multiple attempts to select a good reference site to compare against the other sites in my tenant, the AI always came up with an empty report. I even purposely populated a site with content that I knew is similar to other sites and edited ten of the files added to the site to make sure that fresh material was available for the comparison. The site had the same sensitivity label and settings as the reference site, but the report still ignored it.

Maybe my SharePoint Deployment Has No Problems

I could take a positive view and conclude that the AI discovered no irregularities. For instance, all my team sites have container management labels and have assigned retention policies. It could also be the case that the selected reference sites are very dissimilar to the other sites in the organization, so much so that none of the other sites came close enough to be of interest.

However, I suspect that the AI comparison just doesn’t work well for tenants where many similar sites exist but only a few of those sites are actively used. I also wonder why Microsoft insists on comparing the last ten most recently used files because if the intention is to help organizations prepare for Copilot, then perhaps sites that hold many files without having sufficient recently modified files should be highlighted? After all, in the eyes of AI tools, a file is a file, and the information contained in a file that hasn’t been modified in years could end up being cited in a Copilot response. Using old material often leads to poor responses.

Don’t assume that just because it didn’t work for me, the site content and policy comparison report is rubbish. It might work well in your tenant and highlight many areas that you should investigate to improve the tenant readiness for AI.

Learn about managing SharePoint Online and the rest of Microsoft 365 by subscribing to the Office 365 for IT Pros eBook. Use our experience to understand what’s important and how best to protect your tenant.

New Policy Setting to Force Office to Save to Cloud Locations

Announced in Microsoft 365 message notification MC1137593 on 18 August 2025, Microsoft is introducing a new policy setting to force the creation (saving) of Office files in cloud locations. The setting only applies to Word, Excel, and PowerPoint files saved using the Microsoft 365 enterprise apps (subscription version of Office). No other Office version is affected.

Cloud locations means SharePoint Online, OneDrive for Business, and third-party cloud storage services like Dropbox or ShareFile (if the feature is enabled for the Microsoft 365 tenant).

The new policy enablecloudonlysaveasmode setting can be deployed to clients using Group policies or registry updates. The setting is available in the Administrative Template files for Microsoft Office (version 5516.1000 or newer) and applies to the Windows versions of the Microsoft 365 enterprise apps version 2506 (build 19029.2000) or later. I checked the feature using version 2508 (build 19127.20192) (Current Channel Preview).

MC1137593 says that public preview started to roll out in late August 2025 and is scheduled to complete by mid-September 2025. General availability for all clouds will start in mid-September 2025 and should be available everywhere by the end of September 2025. If you don’t take steps to apply the policy setting, nothing changes.

Higher Cloud Usage

Microsoft says that the new policy is “part of a new set of tools for IT Administrators to move their organizations towards higher Cloud usage and Increase security and compliance.” Increasing cloud usage adds stickiness to the Microsoft cloud because the more data that users store in SharePoint Online and OneDrive for Business, the harder it is to move to any other platform.

The point about increasing security and compliance is justified by the fact that SharePoint Online and OneDrive for Business are subject to the tenant’s security and compliance policies. It’s true that cloud files are more resilient than files stored on a local drive and it is very convenient to be able to move from PC to PC while keeping files available. However, everything depends on the network and if the network’s not available or you don’t want to use a potentially insecure network like free wi-fi, losing the ability to save files to the local drive can be a real pain. I often save copies of Offices files as PDFs to share with other people, and I don’t really want those PDFs cluttering up OneDrive.

Microsoft sometimes goes overboard in its enthusiasm to save files in OneDrive, like PowerShell modules. Some might consider this step to be in that category.

What Users See

The default situation is shown in Figure 1. No policy is configured, and the user can save to SharePoint Online, OneDrive for Business, the local hard drive, and other cloud services (configured through Add a Place).

With the policy setting enabled, Office applications are limited to cloud locations to save new files or save existing files as a new file (Figure 2). Note that the “This PC” and “Browse” (for folder) options are missing.

Updating Office with the Microsoft 365 Apps Policy

Microsoft 365 tenants can apply the setting to restrict saving to the cloud via a cloud policy configured in the Microsoft 365 Apps center. Search for the Restrict saving on non-cloud locations setting and change the value from not configured to enabled (Figure 3).

After saving the policy, its settings are applied by the click to run service and the new setting should be active within a day.

Like most Office settings, the change can be made manually by updating the system registry on a PC. In this case, it seems like the setting is controlled by two settings. The first enables the cloud only save mode by creating a new DWORD value called EnableCloudOnlySaveAsMode at HKEY_CURRENT_USERSOFTWAREMicrosoftOffice16.0CommonFileIO. The second apparently removes the UI options for non-cloud locations through another DWORD value called PreferCloudSaveLocations at HKEY_CURRENT_USERSoftwareMicrosoftOffice16.0CommonGeneral. Both values are set to 1 to enable or 0 to disable. When I tested, the settings worked on one PC and not on another. It took too long to figure out that the PC where things worked ran Current Channel (Preview) while the one where the feature didn’t work ran Current Channel.

A Change That Might Annoy Some

Some will hate this change and ask what’s the point of having a local drive if it’s inaccessible. Others might not notice that all files are stored in the cloud because they do that as the norm. And some will only notice the change when they go to save a file locally. I save most of what I do with Word, Excel, and PowerPoint in the cloud, so I guess that I’m in the last category.

If I was forced to live with storing all Office files in the cloud, I could adapt my workflow without much difficulty. Until a network outage occurs…

Support the work of the Office 365 for IT Pros team by subscribing to the Office 365 for IT Pros eBook. Your support pays for the time we need to track, analyze, and document the changing world of Microsoft 365 and Office 365. Only humans contribute to our work!