Why is “M365 License Manager” assigning Power Apps premium licenses to my users?

This one stumped me for the better half of today.

We use groups to assign licenses in our firm. Including everything Power Platform related. Self-service purchasing is disabled for all products (well, most products, coz Microsoft loves to keep adding new products with self-service enabled by default; see this article on how to see what’s enabled for self-service currently and how to disable). The following snippet can disable it for all currently enabled products:

Get-MSCommerceProductPolicies -PolicyId AllowSelfServicePurchase | Where-Object { $_.PolicyValue -eq "Enabled" } | %{ Update-MSCommerceProductPolicy -PolicyId AllowSelfServicePurchase -ProductId $_.ProductId -Value "Disabled" }

1	Get-MSCommerceProductPolicies -PolicyId AllowSelfServicePurchase \| Where-Object { $_.PolicyValue -eq "Enabled" } \| %{ Update-MSCommerceProductPolicy -PolicyId AllowSelfServicePurchase -ProductId $_.ProductId -Value "Disabled" }

It’s possible to do this via Graph API too, though I haven’t done it yet.

In the past I also remember doing to disable self-service subscriptions:

Set-MsolCompanySettings -AllowAdHocSubscriptions $false

1	Set-MsolCompanySettings -AllowAdHocSubscriptions $false

While that works now, that’s all going away in March 2025.

Anyhoo. As far as we are concerned, there’s no way a user should be able to get a directly assigned license as we have disabled everything that needs disabling. And yet, we found a bunch of users who have the Power App Premium license (previously known as Power Apps per User license) assigned. They have it both via the group they are supposed to get, and also a direct assignment. Odd. 🤔

I used this bit of KQL to see what admin or service principal is doing any license changes to them.

AuditLogs
| where TimeGenerated > ago (30d)
| where OperationName == 'Change user license'
| extend UPN = TargetResources[0].userPrincipalName
| where UPN in ("abc@def.com", "123@def.com", "456@def.com")
| extend AdminUPN = tostring(parse_json(tostring(InitiatedBy.user)).userPrincipalName)
| extend ServicePrincipal = tostring(parse_json(tostring(InitiatedBy.app)).displayName)
| extend Actor = iff(isempty(AdminUPN), ServicePrincipal, AdminUPN)
| summarize ActionedBy=make_set(Actor) by tostring(UPN)

AuditLogs

| where TimeGenerated > ago (30d)

| where OperationName == 'Change user license'

| extend UPN = TargetResources[0].userPrincipalName

| where UPN in ("abc@def.com", "123@def.com", "456@def.com")

| extend AdminUPN = tostring(parse_json(tostring(InitiatedBy.user)).userPrincipalName)

| extend ServicePrincipal = tostring(parse_json(tostring(InitiatedBy.app)).displayName)

| extend Actor = iff(isempty(AdminUPN), ServicePrincipal, AdminUPN)

| summarize ActionedBy=make_set(Actor) by tostring(UPN)

NO admin users are making changes. Everything’s either via group based licensing or… M365 Licensing Manager. Whatever the heck is that?!

Google didn’t help much. This seems to be used by the licensing API, and that’s it.

It’s possible to see what users have signed up for via self-service in the admin portal. Nothing there, so these licenses can’t have been via self-service purchasing.

I logged in to make.powerapps.com with a test account that doesn’t have the Power Apps license assigned, and it let me sign up for a trial (yeah, weird). I ended up with two licenses, neither of which is Power Apps premium and neither of which appears in the licensing pane under this account. So these are not being allocated from our tenant, and I can ignore them.

At this point I was stumped and thought I should take a look at Power Platform itself. These users were all part of an environment to which they were recently added to access an app, so maybe it is something in the environment? I dug around and didn’t find anything but then I remembered this was a managed environment. As far as I know that doens’t do anything regarding licenses, but who knows… time to do a quick Google! And that’s how I found this post. Turns out:

As part of our ongoing commitment to simplifying license management for administrators, we’re automating the creation of auto-claim policies for tenants with managed environments.

Starting December 2023, an auto-claim license policy for Power Apps per-user licenses, named ‘Auto-Created Policy for PowerApps,’ will be created in the Microsoft 365 admin center for tenants currently using managed environments. Under this policy, if a user without a Power Apps per-user license launches an app in a managed environment, they will automatically be assigned a Power Apps per-user license if one is available in your tenant.

Microsoft is so helpful! We’ll just give users a license if the tenant has one… coz why not!

Sure enough, our tenant had this enabled and that’s why the user was getting a license. What’s probably happening was that the users were visiting the app before they were added to the group granting the Power Apps Premium license (or at least before Entra ID recognized this and assigned the license to the user), and since the environment is managed Microsoft assigns a license from our tenant. That sticks, even when the user is assigned a license via the group later. Hah! 😬

Only Global admins have the right to change this.

Admins maintain authority over the default Auto-claim Policy. Global admins have the right to manage the policy in Microsoft 365 admin center and view a report of which users have been assigned licenses via the policy. Similarly in the Power Platform admin center admins can decide whether the policy should apply to managed environments only or to all environments.

All a Power Platform admin can do is decide whether this auto assignment should be only to managed environments, or to all environments.

So there you go, mystery solved! Looks like the auto-policy applies to Power Automate too.