Office 365 – Assign Licensing “User Location” via Active Directory

The first time you assigned an Office 365 license to a user, you likely used the portal as opposed to PowerShell. There’s also a good chance you saw the error message below:

Organizations populate Active Directory user objects with varied amounts of data. In many organizations, especially global organizations, the “Country” field is populated in Active Directory. It would seem logical if I’m using DirSync / AADSync and I have “Country” populated on-premises, then Office 365 should know “Country” as well.
So why are we getting this error?

Background

Revolutionize Your Business With Generative AI

From product design and software development to virtual agents, content creation, and reporting, GenAI is transforming business. Our AI experts help you unlock GenAI’s full potential and drive growth.

Let’s Get Started

Office 365 actually does know the user’s country and you can verify this via PowerShell or in the Exchange Online Global Address List. If you look at a cloud user via PowerShell, you’ll also see there is a separate “UsageLocation” attribute; this attribute is the one used by licensing. Some features within Office 365 are not allowed in certain countries and it is “UsageLocation” that determines this.
For example, if you try to enable Unified Messaging for a user with a “UsageLocation” of “India”, you’ll receive the following message:

If the user for some reason had a mailing address in India but was a user located in the United States with “Country” set to “IN” and “UsageLocation” set to “US”, then Unified Messaging can be enabled.

Options

So now that we understand the reason behind this attribute, there are a couple ways to populate it; we’ll assume like in most cases, “Country” will match “UsageLocation”. What I commonly see done by organizations is they populate “UsageLocation” in the cloud at the time they are assigning licenses, usually via PowerShell. So that works but it’s one more field to track when licensing users.
If you look at the connectors in DirSync and AADSync, you’ll see that “UsageLocation” in the Azure Active Directory is mapped to “msExchUsageLocation” on-premises. What’s interesting about this is that you can populate the attribute either in the cloud or on-premises; most attributes are only writeable on one side or the other. Based on the flow rules, the on-premises value will take precedence here and overwrite existing data in the cloud.
Valid values for “msExchUsageLocation” appear to be the same as those for the “Country” field (attribute name = “c”); basically it’s the 2-letter ISO code for the country.
So you can streamline your licensing process a bit by taking the value of “Country” and writing it to “msExchUsageLocation” in your on-premises Active Directory; DirSync / AADSync will then populate “UsageLocation” in the cloud based on this data.
Alternatively, you could take a less supported approach and modify your connectors so that “c” is mapped to “UsageLocation” instead of “msExchUsageLocation”. The downside is you could never have a user with a different “UsageLocation” than their country (for scenarios where that applies like my India example above) and obviously you’re running in a somewhat unsupported configuration.

Summary

• The “UsageLocation” attribute is separate from “Country”
• Office 365 features may vary based on “UsageLocation”
• You can populate “UsageLocation” via the “msExchUsageLocation” attribute in Active Directory
• Values populated in the on-premises Active Directory will overwrite those populate in the cloud

 
Did you find this article helpful?
Leave a comment below or follow me on Twitter (@JoePalarchio) for additional posts and information on Office 365.