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.

Build Out of a Complete Person Platform within Microsoft 365

After publishing the article about customizing the Microsoft 365 profile card through the Microsoft 365 admin center, I started to think about the work Microsoft is doing on the “people platform,” an effort to unify the different strands of people-related data that exist inside Microsoft 365, such as Entra ID, mailbox properties, skills defined for SharePoint Online users (now the people skills solution), people settings like name pronunciation and personal pronouns, and so on. Drawing together disparate sources of information to create a unified view of a person (tenant user, guest, or contact) seems like a good idea, especially if AI tools like Copilot use people information to enhance responses to user prompts.

Exploiting the Graph to Discover More About the People Platform

I’ve often argued that acquiring a knowledge of how the Microsoft Graph works and how to interact with Graph APIs is a good way to gain an insight into how Microsoft 365 works. In this case, the profile resource type is very revealing. A lot of the work in this area is still in beta and is therefore prone to change, but you can see where Microsoft is heading in the description of the Microsoft 365 person experience (described for a multi-geo tenant, but still valid):

“The Microsoft 365 Person encompasses the complete set of properties, attributes and associated people contacts that are representative of a user in the Microsoft 365 tenant.”

The sources used to build the complete picture of a person include:

• Basic administrative information about people stored in Entra ID, including information synchronized from on-premises Active Directory. This information includes the display name, employee identification number, employee type, physical location, and so on. It also includes the person’s photo.
• Data to build out the one-dimensional picture of a user as found in Entra ID by populating information about the person’s jobs (work positions or roles), skills, languages, education (including certifications), and so on. This information can be added programmatically through the Graph APIs or imported from an external system using a Copilot connector for people data.

Adding a Work Position

To demonstrate what kind of information the people platform uses to build out a complete picture about a user, I spent a little time playing with the Microsoft Graph PowerShell SDK cmdlets that add work position information to the people platform. A work position is a job or role undertaken by a person within a business. The role might be in the past or current, so a complete work history within an organization can be constructed from the work position data. Like the rest of the platform, these cmdlets are based on beta code, so some stuff doesn’t work. Nevertheless, the information defined for a work position is a good example of what Microsoft is doing.

This code adds a new work position, marking the role as current (isCurrent is true). The allowedAudiences property is set to organization, meaning that the information is available within the organization (it could also be set to “me,” meaning that it’s personal to the user). After building the properties to describe the role, running the New-MgBetaUserProfilePosition cmdlet adds the work position record to the people platform. This is equivalent to posting a request to the https://graph.microsoft.com/beta/users/{userId}/profile/positions endpoint.

$AddDate = ([datetime]::UtcNow.ToString("s")) + "Z"

[string]$AddDate = '2025-09-04T22:18:03.8608268Z'
[string]$endDate = '2039-09-04T22:18:03.8608268Z'

$Parameters = @{}

$RoleDetail = @{}

$RoleDetail.Add("jobTitle", "Senior Technical Manager")
$RoleDetail.Add("role", "Technology Consulting")
$RoleDetail.Add("employeeId", "150847")
$RoleDetail.Add("employeeType", "Permanent")
$RoleDetail.Add("description", "Responsible for the management of a small team of technical consultants covering the NYC area")
$RoleDetail.Add("level", "MGR-02")
$RoleDetail.Add("startMonthYear",$AddDate)
$RoleDetail.Add("endMonthYear", $EndDate)

$Company = @{}

$Company.Add("displayName", "Office 365 for IT Pros")
$Company.Add("department", "Consulting")
$Company.Add("officeLocation", "New York City")
$Company.Add("costCenter", "100014")
$Company.Add("division", "Professional Services")
$Company.Add("webUrl", "https://office365itpros.com/")

$Address = @{}
$Address.add("type", "business")
$Address.add("street", "170 Avenue of the Americas")
$Address.add("city", "New York City, New York")
$Address.add("countryOrRegion", "United States")
$Address.add("postalCode", "10036")

$Company.Add("address", $address)

$RoleDetail.Add("company", $Company)
$Parameters.Add("detail", $RoleDetail)
$Parameters.Add("isCurrent", "true")
$Parameters.Add("allowedAudiences","organization")
$Parameters.Add("createdBy", "Tony Redmond")

New-MgBetaUserProfilePosition -UserId $User.Id -BodyParameter $Parameters

After positions are added, the Get-MgBetaUserProfilePosition cmdlet can retrieve an array of all the work positions known for the user:

[array]$Positions = Get-MgBetaUserProfilePosition -UserId $User.Id

The information written by New-MgBetaUserProfilePosition is available in several composite properties, like Detail (Figure 1). It’s easy to see how this information might surface on a form of the current profile card.

You’ll always find a position registered for a user because the people platform synchronizes details from Entra ID to create a default position from information like a user’s job title held in the directory.

A Complex Undertaking

It’s obvious that building the people platform is a complex undertaking. Anything to do with personal information is sensitive. Personal privacy must be protected. I am sure that employee unions and worker councils will take a keen interest in how Microsoft 365 tenants decide to populate the Graph with people information and then, more importantly, how that data surfaces in places like the Microsoft 365 profile card.

It’s often said that we live in interesting times. Things might just get more interesting as the people platform develops. It’s certainly something that anyone involved in identities and user management should keep an eye on.

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.

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!

Hard to Find Logic for Copilot License Check in Exchange Connectivity Tool

Unless you’re a keen reader of the Microsoft blogs posted to the Microsoft Technical community, you might have missed the August 25 article about a new diagnostic tool for a “Copilot License Details Check.” According to the text, it’s “a powerful tool designed to streamline and validate your license readiness by confirming whether Copilot for Microsoft 365 licenses are properly assigned to users.” In reality, it’s some Graph API requests cobbled together to report details of a Microsoft 365 Copilot license assignment to a user account that’s been bolted onto the side of the Exchange Remote Connectivity Analyzer (ExRCA).

As I explain in another article, ExRCA started as a troubleshooting tool to help Exchange on-premises administrators debug connectivity problems with protocols like Autodiscover and ActiveSync (check out the YouTube video from that time). Later, Microsoft upgraded ExRCA to support Exchange Online and Teams. At this point, it’s fair to say that ExRCA is an invaluable tool for Microsoft 365 tenant administrators.

However, having a valuable support tool is no reason to bolt on a license checker. I’m sure Microsoft will point to the inclusion of the message header analyzer tool in ExRCA as evidence that ExRCA has become a toolbox, but that’s missing the point that the message header tool is at least associated with a messaging protocol (SMTP) whereas the Copilot license check is a barefaced attempt to help people use more Copilot features.

Running a Copilot License Check

Running a Copilot license check is very simple. Input the user principal name or primary SMTP address of a user account, sign in as an administrator with permissions to access user account details, and the code runs to verify that the account has a Microsoft 365 Copilot license with all its service plans intact (Figure 1).

A Simple Check

Stripping everything away, the license check is very simple and the results that it generates are equally simple (no expensive CPU cycles for AI analysis are burned here). Figure 2 shows that the user being checked is good to go. I’m sure that this is deemed to be a successful test.

But some issues exist. First, the test doesn’t distinguish between direct-assigned licenses and group-assigned licenses, which is valuable information for an administrator to know if they want to address a problem highlighted by the test. Second, the test only considers a “full” Microsoft 365 Copilot license to be valid. Trial licenses are not considered valid. Third, disabling some Copilot features is a perfectly reasonable thing to do. Not everyone needs to create new agents through Copilot Studio, for example.

PowerShell Code for the Copilot License Check

To show what the ExRCA Copilot check does, I recreated the check using the Microsoft Graph PowerShell SDK. The code is simple and took about an hour to write (including testing):

• Sign into the Graph with Connect-MgGraph using an administrator account.
• Prompt for a user account and validate that the account exists.
• Check that the account has a valid Microsoft 365 Copilot license (including trial licenses). License and service plan information is available online.
• Run the Get-MgUserLicenseDetail cmdlet to retrieve service plan information for the Copilot SKU.
• Check each of the service plans defined in the license to report if it is enabled or disabled.

Figure 3 shows some sample output.

You can download the script from the Office 365 for IT Pros GitHub repository.

No Reason to Use ExRCA to Check License Details

I don’t know how many Microsoft 365 tenant administrators will seek out ExRCA to answer questions like “I wonder if the Copilot license assigned to John Doe is good to go?” It seems like an unnatural reaction to consider ExRCA in that light when it’s straightforward to build your own tools to measure user readiness for Copilot or analyze and report licenses assigned to user accounts (including disabled service plans).

The idea might be a good one, but I fear it’s implemented in the wrong place and is too limited to deliver much value.

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.