Skip to main content

Microsoft

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

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:
UsageLocation validation error: This feature is not available in the location indicated in this user's UsageLocation
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.

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

  1. “Alternatively, you could take a less supported approach and modify your connectors so that “c” is mapped to “UsageLocation” instead of “msExchUsageLocation”.”
    Where can I make this change? We do not run an Exchange server, so msExchUsageLocation is not an attribute I see available.

  2. Jake-
    You could install the Exchange schema and it would give you the attribute.
    Otherwise, the details on how you would setup the mapping will vary depending on if you’re using DirSync, AADSync or now AAD Connect. At a high level, with DirSync, you’re going to go to the properties of the on-premises AD connector, go to “Configure Attribute Flow” and then change the “Data Source Attribute” that flows into “usageLocation” from “msExchUsageLocation” to a source of “c”.

  3. Thank you for the fast reply! We are currently using AADSync. I looked for a Configure Attribute Flow, but I’m guessing that has changed between DirSync and AADSync.

  4. Jake-
    In AADSync, you would need to use the “Sync Rules Editor” and likely find it in the “Transformations” but without Exchange I’m not completely sure what rule the mapping would be under if it’s in there at all.

  5. For anyone else that has trouble finding it – in AAD Connect Sync – open syncronization rules editor and then look at the in from AD rules (since it is going into the metaverse from AD) then its under In from AD – User Exchange ->Transformations

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Joe Palarchio

More from this Author

Categories
Follow Us
TwitterLinkedinFacebookYoutubeInstagram