M365 Copilot and the case of the broken license

Did you know that assigning your user a M365 Copilot license doesn’t actually mean they have a M365 Copilot license?

It doesn’t make sense to me either, but apparently that is “by design”.

Let’s take a look at this flawed approach. This blog post is more of a public service announcement, as I recently discovered this flawed approach when working with an organisation that was implementing my M365 Copilot Usage Report.

License vs. Service Plan

Within the M365 Copilot license are several service plans:

• Copilot Studio in Copilot for M365
• Graph Connectors in M365 Copilot
• Intelligent Search
• Microsoft 365 Copilot for SharePoint
• Microsoft 365 Copilot in Microsoft Teams
• Microsoft 365 Copilot in Productivity Apps
• Microsoft Copilot with Graph-grounded chat
• Microsoft Viva Insights
• Microsoft Viva Insights Backend
• Power Platform Connectors in Microsoft 365 Copilot

NOTE: The above naming and ordering is as shown in the M365 Admin Center. One would hope for consistent naming and the usage of “for” or “in”, as well as alphabetically sorted, but this is what we’ve been given.

Apart from Microsoft Viva Insights Backend, all of the service plans can be enabled or disabled on a per user level.

The Challenge

In some organisations they may not be ready for all the features yet or have a reason why some shouldn’t be enabled.

In this scenario, it would be reasonable to simply de-select the service plan from the assigned license for specific users or groups.

The organisation I was recently working with needed to do some additional changes to their tenant around data safety, but they still wanted to push forward with rolling out the licensed version of M365 Copilot.

To achieve this, I had suggested that they disable some of the features (aka “service plans”) within the M365 Copilot license while they worked through the configurations to their tenant.

What we found was that the users with restricted licenses were not showing any usage in my M365 Copilot Usage Report. In fact, queries to the aiInteractionHistory\getAllEnterpriseInteractions API endpoint failing results with an error message stating that user was not licensed.

(For clarity, the full query would be something like: https://graph.microsoft.com/v1.0/user/<User ID>/interactionHistory/getAllEnterpriseInteractions)

This was quite a head scratcher, because the user was licensed – so why would it say they weren’t?

Others who had all the service plans enabled had no issues, so the logical conclusion was that the issue was due to one of the service plans not being enabled on the problem users.

I performed some troubleshooting and found the following results:

I was able to replicate this in two other tenants to validate that it wasn’t specific to the client’s tenant.

We raised a case with Microsoft, and after a few hoops got through to someone who said that this functionality was by design.

While I’m known to have strong opinions, I also believe myself to be reasonable and objective. However, this was illogical. The user has a license, therefore it shouldn’t say that they don’t have a license.

Additionally, if that one specific service plan is not enabled – it means that no usage data can be returned for that user, despite them having a license assigned and usage.

I called this out and was again told that it was by design.

I pushed back and said that the documentation does not refer to this in any way. In fact, here is a screenshot of the license statement last week:

The Solution

Unfortunately, the solution was not what I expected.

What I had hoped for would be something along the lines of “oh, good point. We’ll raise that with engineering and fix the logic with how that endpoint responds”, what I actually got was: “the documentation is wrong and we’ll change it”.

In probably the fastest turnaround I’ve seen on Microsoft documentation (and trust me, I’ve had to correct Microsoft documentation previously because it simply wasn’t done), the page now has this text instead:

Instead of fixing the problem – they’ve simply documented around it.

Conclusion

Now, the case for disabling “Microsoft Copilot with Graph-grounded chat” from user assignments of M365 Copilot is not something that I would expect to happen often, but it still may need to happen for some organisations or users.

And while none of this is catastrophic, it reinforces a familiar (and growing) frustration: logical expectation from customers doesn’t always translate into logical behaviour from Microsoft’s own products.

---

Also published on Medium.