Microsoft has a long history of trying to drive increase for its cloud services usage at the expense of admin control. One of the most blatant examples was the attempt to roll out self-service purchase capabilities for the Power platform. After some customer uproar, a decision was made to delay the feature until admin controls are introduced, with a “request a license” feature introduced later on.
Now, another similar feature has been introduced as part of MC244882, namely Auto-Claim Policies. Since nothing has changed in the effort put in naming those features, you’ll need to go over the description and additional information in order to make sense of what it is all about. In a nutshell, the feature offers an admin-configurable way to automatically assign licenses to users:
An auto-claim policy lets users automatically claim a license for a product the first time that they sign into an app. As an admin, you typically assign licenses to users either manually, or by using group-based licensing. By using auto-claim policies, you manage the products for which users can automatically claim licenses. You can also control which products those licenses come from.
In a rare example of showing that they can learn from past mistakes, Microsoft is releasing the feature in a default OFF state, meaning an admin will have to enable it first. To do so, you can login as a global admin and navigate to the M365 Admin Center > Settings > Org settings > Services > scroll down to User owned apps and services > toggle the value of Let users auto-claim licenses the first time they sign in. Alternatively, you can also enable the feature from it’s configuration page under M365 Admin Center > Billing > Licenses > Auto-claim policy. You cannot however toggle it off from said page.
Toggling the feature does nothing on its own, you will also need to configure one or more policies for the actual “claiming” or assignment of licenses. As Microsoft Teams is currently the only product that supports this feature, and policies are configured per product, currently you can only create a single policy. The creation process itself is fairly straightforward and driven by the familiar “wizard” interface.
Start by accessing the aforementioned configuration page by following the left nav menu or by directly opening this link, then press the Add a policy button. After giving the policy an appropriate Name, you will need to select which app or product the policy will apply to under the Policy details section. Again, currently the only choice is Microsoft Teams, so accordingly once you select the Microsoft Teams entry from the When a user signs in to this app dropbox, the list of SKUs containing a Teams service entry will be populated in the This policy will assign a license from this product dropbox.
You can also specify up to four additional “backup” SKUs, under the Backup products section. This is an optional configuration step and only SKUs containing the corresponding license/service will be listed. The intention here is to designate “alternate” or “fallback” SKUs to be used in case the number of available seats in the “primary” designated one reaches zero (“backup” is a rather inappropriate notation, but anyway). In my case, I’ve selected the Office 365 E5 license as the “primary” and I was offered a choice between the Office 365 E3 and/or the Office 365 E5 without Audio conferencing SKUs as backup ones.
Once you are done with configuring the Policy details, hit the Next button to advance to the Apps and services page, where you can granularly control the set of individual services corresponding to a given SKU. Interestingly, in my case each of the selected (“primary” and “backup”) SKUs had the Exchange Online Plan 2 service unchecked, so make sure to double- and triple-check things. That’s probably my fault, as the user I’ve chosen already had a mailbox, so it was more of a corner case scenario. Some caution is advertised though, after all, you do need an Exchange mailbox for best Teams experience.
Once you are done with the individual services configuration, press the Next button again to progress to the Finish section of the wizard. Apart from getting a summary of the policy settings, on this page you can change the order of the SKUs from which the license will be assigned, but selecting the entry and clicking the Move up/Move down button as appropriate. If everything is set as desired, press the Finish button to complete the auto-claim policy creation process.
Do note that nowhere in the process we were asked to provide a list of users (or groups) to which the newly configured auto-claim policy will apply. In other words, auto-claim policies are tenant-wide and apply to all existing and newly created users within the tenancy (not Guests though!). While the feature itself might remind you of the good old Group-based licensing capabilities in Azure AD, the lack of granularity in this aspect is one of the main differences between the two. Of course, the use of the Group-based licensing feature is tied in to E3/Azure AD Premium, whereas auto-claim policies are available for free. Another one is that Group-based licenses are generally processed immediately (well, almost), whereas a license assigned by an auto-claim policy will only be “consumed” after the user logs in to a given app/service for the first time. Which I suppose is the reasoning for the unfortunate feature name…
Once the policy has been created, you will be able to see some information about it or change some of it settings by clicking the policy entry in the list. An option to Turn this policy on or off will be presented in the right-hand pane. In addition, selecting the policy entry will also surface some additional action items, such as the Delete button, a Refresh button and the Report button. Clicking the latter will take you to a new page where you can get some details about the usage of this feature. Details include the Name of the user (I would prefer something more appropriate such as the UserPrincipalName), the datetime at which the license was assigned, the license name and the policy that “acted”. A Download report button is available should you want to export this information to a CSV file, which sadly does not contain any additional details.
Finally, a few words about the end user experience. Once an auto-claim policy has been created, any user within the tenant will automatically get a license assigned to them once they login to Microsoft Teams. The process itself is transparent to the end user, which is both good an bad. Not having the user to worry about licensing requirements is of course helpful, however given the number of services available within Office 365/Microsoft 365 nowadays, it’s more than likely that organizations will want to provide some sort of training or onboarding experience. In the case of auto-claim policies, the end user is “in control” of when the actual license assignment happens, and they might get a bit overwhelmed by the number of apps/services they get access to after their attempt to login to Teams.
In any case, the feature seems like a step in the right direction, at least when we compare it to previous Microsoft attempts in this space. Being released as disabled by default and doing nothing until an admin with the appropriate permissions configures it is commendable and almost unexpected. Sure, the Global admin requirements seem to be a bit steep, but going forward they might be relaxed to something more appropriate. And of course, it will need to expand to cover additional apps and services to become a viable alternative to the group-based licensing feature. Some minor improvements in naming might also be a good idea, as might be controls to limit the scope of the feature to specific users/groups of users or plugging in an approval workflow. Additional information can be found in the official documentation.