How Michelin Modernized Its Microsoft Licensing

A license is missing… and no other license can be assigned.

Michelin found itself in this situation with Microsoft software. Behind the scenes, a new license assignment process based on Active Directory groups was being rolled out.

Originally, a direct-assignment system

When the company adopted Office 365 about ten years ago, assignments were direct, via the admin center or via PowerShell scripts. It relied on license bundles mapped to worker profiles.

To store these profiles, it was decided to leverage Active Directory extension attributes — typically used, among other things, for syncing on-prem Exchange mailboxes. These attributes were synchronized to Azure Active Directory.
The main script, run on-site on a periodic basis, detected new users, read the associated attributes, and assigned the corresponding licenses.

For recruitment, the attributes were defined by HR systems in AD (initially indirectly, via the internal directory). In other cases (freelancers, internal mobility, dedicated accounts…), they were defined via an internal provisioning portal.

This system had its limitations. Among them, the main script gradually grew more complex (adding/modifying profiles, altering the underlying business logic). Moreover, since it was scheduled and not event-driven, there was always a lag relative to upstream tools, amplified by the 30-minute Azure AD Connect synchronization interval.

This approach did not, in general, prevent admins from assigning any license to a user beyond what they were supposed to receive.

The group-based approach, implemented in two stages

In this context, Michelin began migrating to a group-based approach, at the tenant scale (today around 120,000 seats). It was already using it for a few services such as Copilot.

The initial idea was to create a dynamic group in AAD for each profile. The “Knowledge Worker” group, for example, would be defined by the formula (user.extensionAttribute13 – eq “Knowledge Worker”). Each group would then be assigned the licenses corresponding to the profile. The whole system could gradually replace direct license assignments.

A few days after going live, it was observed that the absence of one license type was enough to block the assignment of others within a group. An issue not identified during testing… and not documented, to Michelin’s knowledge.

The “one group per profile” approach was therefore abandoned in favor of a more modular system linking a group to each combination “profile(s) + license type.”
Each group thus includes a license and the set of profiles expected to benefit from it. For example, GP-AAD-USR-LICENSE-E1_SDFA, which links the profiles “Standard” (SD) and “Functional Account” (FA) to the Office 365 E1 license.

Ten profiles have been defined:

The system has been in production for several months. Some problematic cases remain to be addressed, such as cloud-only accounts.