You are viewing an earlier version of the admin guide. For the latest version, please visit EmpowerID Admin Guide v7.211.0.0.

Skip to end of banner
Go to start of banner

About Azure Licensing Manager

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 11 Next »

Azure License Manager (ALM) is as licensable module in the EmpowerID Suite that is designed to help organizations inventory their Azure licenses and expenses across multiple Azure tenants for cost reporting and allocation of license expenses to the different business areas of the organization. To understand how Azure Licensing Manager can help your organization with the costs associated with Azure licenses, it is helpful to review how Azure provides licensing.

For each Azure tenant, there exists one Azure Active Directory and in that Active Directory an organization can enable various Microsoft products to license them. Each product includes one or more Service Plans, which are the components or the services that are offered in that product like Office 365 Enterprise E3, Visio and Project. If your organization chooses to subscribe to Office Enterprise E3, that product becomes a subscription with a specified number of licensed users with a per user per month cost.

Azure Licensing Challenges

There are multiple challenges with managing license distribution and license reporting for organizations using Microsoft Office 365 and Azure. One key challenge is that when a company subscribes to licenses with Azure and Office 365, it can only subscribe once. For large organizations with multiple departments or business units using these licenses, there’s no real way to determine how many licenses are being consumed by which units or to grant responsibility to groups within the organization manage who gets licenses, who can approve license assignments and to report how much of the organization’s license budget is being consumed by the various business units.

The below example provides a simple illustration of the challenges associated with determining how much of the total licensing costs spent by an organization can be allocated to individual business units from the information available in Azure. As can be seen, there exists a company consisting of a headquarters department with two business units, one located in Germany and another located in the United States. The company has one Azure subscription for Office 365 Enterprise E3 and one subscription for Visio Online Plan 1. In the case of Office 365 Enterprise E3, there are 10,000 users at a list price of $20 per month, which is an annual expense of $2,400,000. Some of these licenses are consumed by users in Germany, some are consumed by users in the United States, and some are consumed by users in the headquarters location. The question becomes, How many licenses are being consumed by each unit and how are those licenses being managed? With native Office 365 features, there’s no real way to gather data that is intelligent enough to portion off those licenses to each business unit to allow those units to see how much they are spending or to allow them to manage their own license assignments. Azure Licensing Manager allows organizations to gather the intelligence they view not just the total of their licensing costs, but to see who is driving costs and grant those entities the responsibility for managing license assignments.

How Does Azure Licensing Manager Help?

EmpowerID provides a very flexible cost and responsibility allocation mechanism within Azure License Manager called "license pools and bundles." License pools and bundles allow an organization to break up their subscriptions to match their logical organization structure.

License Pools and Bundles

Keeping with our previous example of a fictitious company consisting of a headquarters department and business units in both Germany and the United States, the above illustration demonstrates how license pools and bundles give organizations visibility and control over licensing. In the example, the company has a total of 10,000 Office 365 Enterprise E3 licenses, one license pool and license pool owner for each business unit, as well as several license bundles with an allocated license count per bundle. So for example, the business unit in Germany has been allocated 6,000 Office 365 Enterprise E3 licenses distributed to two license bundles, the “DE Standard Employees” and the “DE Interns” license bundles. The bundles themselves can have owners who can manage user and group assignments to the license bundles. All bundle owners determine who can have a license in the bundle and become the default approvers for license access requests to a license in their respective license bundles. By using license pools and bundles, the organization can set license cost controls, and bundle up the cost for a total expenditure allowed per license pool.

The below image provides an end-to-end flow of how Azure License Manager helps organizations visualize and control licensing costs. Azure (shown on the left), has a number of subscriptions the organization purchased, which in this case includes 10,000 Office 365 Enterprise E3 licenses and 800 Visio Plan 1 licenses. In the middle of the image, these licenses are logically divided into two license pools for cost allocations and expenditure—one pool for the business unit in Germany and another for the unit in the United States. Each license pool has assignable bundles, each with a specified number of user licenses mapped to a single Office or Azure product or a single subscription. 

On the right side of the image, in the Azure tenant, each license bundle is mapped to a single Azure Active Directory group for fulfillment. That group has been configured for group-based licensing and is mapped to that same subscription with service plans enabled or disabled. So, in the Germany example, users in the DE Standard Employees license bundle are fulfilled by a licensed Office 365 Enterprise E-3 full group, which grants all service plans as enabled, whereas the license bundle for the DE Interns is mapped to a licensed Office 365 E-3 Limited group, which has two of those service plans disabled. The bundles deliver the same subscription, but have been configured and mapped to provide different features to their assignees.

License Bundles - Key Points

  • License bundles are the assignable policy object you create in EmpowerID in order to grant to users a subscription in Azure

  • Each license bundle creates a single Azure subscription and pushes the resultant assignees of the bundle into a single Azure AD group

  • License bundles are mapped to a specific group in Azure that fulfills it

  • License bundles are assignable policy objects that can be assigned to any EmpowerID actor type, including users, groups, Management Roles, Business Roles, and Query-based Collections.

  • License bundles can have exclusion rules to prevent license assignments to certain people, as well as to enforce regulatory restrictions. Exclusion rules can be applied to any EmpowerID actor type.

  • License bundles can be requested by self-service users in the IT Shop

License Bundle Assignees

At the most basic level, license bundle assignees are the people who have been assigned to a license bundle and who should receive the license granted by the bundle. As mentioned in the key points above, license bundles can be assigned to any EmpowerID actor type. This gives you the power to make assignments to license bundles using any criteria that makes sense for your organization. License bundle assignees can be diverse as any or all of the following:

  • You can assign user accounts directly to a license bundle.

  • You can assign a group in another system, such as those in an on-premise Active Directory, those in Amazon AWS, Salesforce, or ServiceNow, among others.

  • You can assign Business Role and Locations to a license bundle, giving all people with that Business Role and Location a license.

  • You can assign Management Roles to a license bundle, giving all people with that role a license.

  • You can assign Query-based Collections (QBC) that return all users with a specific attribute value to a license bundle so that every user in each QBC gets a license.

Beyond defining who should get the license bundle, you can apply exclusion rules to the bundle to define who should not receive a license. As with assignments, you can use the same actor types in your exclusion rules. Once a license bundle is defined with assignees and exclusion rules, the EmpowerID engine calculates the resultant license bundle assignees, which is everyone who should have the license, minus everyone who shouldn't have it. All resultant people will receive the license bundle. EmpowerID adds each of these assignees to the License Fulfillment Queue and pushes them into the the mapped license bundle group in Azure AD, which gives the license.

License Bundle Eligibility

Beyond defining who should receive a license bundle, EmpowerID makes it possible for you to define who should be eligible to receive a license bundle. Returning to the example of the fictitious company mentioned earlier, consider how the structure of the company can benefit by defining license bundle eligibility. As you may remember, the company has the following structure:

  • The with business units in Germany and license pools and bundles in Germany and the United States, exampleNow you can also configure who should be eligible to receive a license bundle, so you might have many license bundles again broken down to match your organizational structure. So we have our license bundles in our pool in Germany. We have a license bundles and a pool in the United States. We've even maybe further broken those down the standard employee license bundle in Germany versus the intern license bundle. So we want control that if users are shopping for licenses, we don't want them to see license bundles that aren't really meant for them. So if I'm an intern in Germany, I should only see the Internet bundle if it wasn't automatically assigned to me or if maybe we have project or optional Microsoft products, we don't want those advertised to everyone, only to those individuals who could request them. So license bundle eligibility uses the same idea as the assignees where you can map out who should be eligible to receive a license, who should be excluded from that list and not be eligible. And then the engine calculates the result in eligibility. So eligibility is really a way to advertise specific licenses to the right people so that end users are not overwhelmed. They don't see too many licenses of the same type. And they they're not presented with options that they are not allowed to request. So you're advertising to these audiences which license bundles are relevant and requestable by them.

Putting It All Together —  License Fulfillment Flow

License fulfillment is the process of taking the policies in EmpowerID that specify who should have which license bundles, making those changes in the Azure tenant and adding the resulting Azure AD users to the license groups matched to those bundles.

  1. Based on how the license bundle is configured, EmpowerID determines everyone who should be in the bundle and compares that to everyone who already has the license that the bundle grants. who should beNow there's a job in EmpowerID we discussed called the "License Pool Compiler" and it is what looks at the resultant assignees for each license bundle. It also looks at the inventory data about who already has a license via a license group - so who's already in these license groups. It looks at this in the "GroupAccountLicensePoolServiceBundle" table. That's really what says which groups contain, which user accounts because of which license bundles. And it looks at that. It says, OK. The resultant assignees should be this. But these are the users that have this group membership already. 

  2. So, we can calculate the delta. And it adds those delta entries about which users need to be added and which users should be removed because they're not allowed to have that license bundle anymore. It adds, as is entries to the License Fulfillment Queue, which is stored in a table known as the "AZLicensePoolServiceBundlePersonChangeInbox." So, you might hear referred to as the license inbox. It's an inbox where items are added into the inbox for processing, additions of users to license groups and removals for users from license groups. 

  3. Now another job is monitoring this queue and grabbing them in batches for high volume processing. And it's called the "LicensePoolChangeInboxProcessor." So, it processes these inbox entries by grabbing them, calling out to the EmpowerID Azure AD SCIM App service in your tenant and making the call to add or remove users to and from the appropriate license groups. So, this is really the end-to-end of how that license fulfillment flow works.

Inventoried Data

The below image presents a high-level overview of how EmpowerID stores and gathers the inventory data it retrieves when connected to Azure.

On the right side of the image, we see our Azure tenant and on the left we see our EmpowerID instance—whether it's on premise or a SaaS instance. EmpowerID is running as Web and Application Server containers hosting inventory jobs that pull the data from Azure and stores it in the appropriate tables of the Identity Warehouse. Users from Azure Active Directory are stored in the Accounts table, groups in the Group table, and the products to which the tenant has subscribed in the AZLocalServiceBundle table. Additionally, detailed information about which users or groups are assigned to which of these subscriptions, as well as which of product features of the service plans are enabled or disabled on each of these assignments is stored in the AZAssigneeLocalServiceBundleService table. While the image shows just a few of the tables, it allows you to see the overall flow of how EmpowerID could securely communicate to an Azure App service running in your tenant, using a managed identity to talk to the Graph API to retrieve this information and to store it in the identity warehouse.

  • No labels