Using an Auto-Claim Policy for Automatic Assignment of Licenses to Teams Users

Unannounced Feature

On 17 March, Microsoft posted message center notification MC244882 to announce the immediate general availability of auto-claim policies in the Microsoft 365 admin center. Strangely, no roadmap item was cited, meaning that this feature never appeared on the Microsoft 365 roadmap. Thankfully, some documentation is available and the feature is disabled by default.

Apparently, the idea was around early last summer, but I never picked it up.

Auto-Claim Basics

The basic idea is that tenants can create policies to allow applications to claim from a pool of available licenses when a user needs a license to use the app. Auto-claim policies sounds like a good idea if you have:

• Users who are unlicensed.
• No other way of assigning licenses to users either manually during the account creation process, or automatically using your own scripts or with Azure AD group-based licensing.

Mature organizations usually have their own methods for license management and not many new accounts are created without the attachment of licenses.

Teams is the only app which supports auto-claim policies today but given that the policies are now integrated in the Microsoft 365 admin center, it’s likely that auto-claim policies will cover other apps in future. On the surface, it seems odd that Microsoft is now introducing another method. However, Azure AD group-based licensing requires Azure AD Premium P1 licenses and Office 365 E3 or E5, while apps like Teams have a much wider target audience.

Enabling Auto-Claim

Before you can define an auto-claim policy, you need to enable the feature. Go to the Billing section of the Microsoft 365 admin center, then Licenses, and select the Auto-claim policy tab. Finally, hit the big Turn on setting button (Figure 1).

You can also enable the setting through Org settings in the Microsoft 365 admin center. Go to User owned apps and services and check the option to let users auto-claim licenses the first time they sign in (Figure 2).

You can disable the auto-claim policy in Org settings. This doesn’t remove the policy if one is defined. Instead, the policy goes into abeyance until it is reactivated by switching the setting on again.

Creating a Policy

An auto-claim policy applies tenant-wide. There is no way to scope the policy to process only a selected group of accounts. Only one auto-claim policy exists for the tenant. This might change in time as additional apps support license auto-claim or Microsoft introduces policy scoping.

Creating a new auto-claim policy is straightforward. After giving the policy a name (always a test of creativity), the important part is when you link an app (Teams) with assignable licenses. In Figure 3, I define that if an unlicensed user accesses Teams, the auto-claim policy will step in to assign an Office 365 license to the user account. If no Office 365 licenses are available, the policy will attempt to assign an Office 365 E5 license (aka, the backup product).

Licenses like Office 365 E3 span many apps. Some tenants like to disable apps covered by licenses because they don’t want people using them. For instance, you might decide that Microsoft Bookings is not needed by users and so disable that app in the license. When creating an auto-claim policy, it was noticeable that the policy removed Exchange Online Plan 2. I turned it back on to receive an odd warning (Figure 4) that enabling Exchange might disrupt email delivery. Given that Microsoft strongly advocates a position that Teams is best when coupled with Exchange, this is an interesting stance.

After checking all the apps available in the licenses to be assigned, save the policy. It becomes effective immediately.

Testing License Assignment

To test that the auto-claim policy worked, I created a new account in the Azure AD portal. I then added the new account to a team and logged into Teams as the user. After going through the normal routine for a new user (setting a new password, etc.), Teams started up as normal. No indication appeared that a license assignment happened. From a user experience perspective, this is how things should happen. People responsible for the delivery of training before people use apps might need to reconsider how they approach training if license auto-claim becomes the norm.

The auto-claim policy does not assign a license for Teams if a licensed account with the Teams app turned off attempts to use the app.

According to the documentation, an auto-claim policy report is available in the Microsoft 365 admin center to show all licenses assigned by policy over the last 90 days. No trace of a report is visible in my tenant, but this is probably due to the normal two-day delay before usage reports are available in the admin center. It’s easy to check if a license is assigned to an account by looking at its properties (Figure 5), where we find that the policy did indeed work and a license is present.

You can also track license assignment in the audit events logged for the account in the Azure AD portal. Figure 6 shows details of an audit event captured after a license is assigned when a user logs into Teams for the first time.

Audit records also appear in the Office 365 audit log. Search for “Update user” operations and look for license updates in the ModifiedProperties property of the Auditdata payload in the audit events. You’ll see a bunch of license assignments recorded there similar to those shown in Figure 6 (unsurprising, because it’s the same data).

Update: After 7 days, no auto-claim report has shown up in the admin center.

A Good Idea but Maybe Not for All

Auto-claim policies seem like a good idea. It’s hard to be definitive now because these policies need to be tested in the wild and assessed by organizations which already have their own methods for license assignment, including granular management of licenses at departmental or country level. Given that solutions already exist in this area (after ten years of Office 365, it would be hard if tools weren’t available), people will need to be convinced to move from what they do now. I could see this approach being popular in sectors with heavy account turnover, like schools, but perhaps less so in large enterprises where license management is often a well-defined art.