Somewhat recently, Microsoft released the Azure AD Premium Group-Based-Licensing (aka GBL) feature in Public Preview, and I’ve had a TON of my customers transition to using this new feature.
https://docs.microsoft.com/en-us/azure/active-directory/active-directory-licensing-group-advanced
So far everyone has been thrilled with GBL, however there’s a caveat… UsageLocation
If you previously used GraphAPI or PowerShell to assign licenses, there’s a likelihood that you probably set the UsageLocation value as part of that same process. When you switch to GBL and toss your script, you now need to rely on something else to set it for you, otherwise it’ll be set to the default location of your directory in Azure AD.
The great news is that you can do it with AAD Connect, the not-so-great news is that by default, it is synced from the msExchUsageLocation attribute, which most customers don’t seem to have populated.
So, what do you do if you’re a global company, and don’t have msExchUsageLocation set for your users, but need UsageLocation set to a specific country code? Well, you could populate that the msExchUsageLocation value, but odds are, the attribute ‘c’ in your Active Directory may have the correct value for your users as well…
https://msdn.microsoft.com/en-us/library/ms675432(v=vs.85).aspx
Sadly, I’ve encountered quite a large number of customers who have the ‘c’ attribute incorrectly populated with a 3 character value, instead of the expected 2 character ISO-3166 code.
That list can be found here: https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2
Ok, so that’s great, but I am sure you’re asking why this blog post is about AAD Connect.
Well, since I’m a huge advocate of AAD Connect, I thought it’d be fun to create a sync rule that leverages RegEx to verify that ‘c’ is properly formatted, and if not, default to a standard value (eg. US) or even throw an error in the sync engine.
Now, the right answer here, is to fix the source data, but we all know that mid-migration there’s likely some urgency to using the sync engine to help out, since a single rule can fix this, whereas updating hundreds of thousands of objects in AD might take a bit more change control Kung-Fu.
So, let’s do it with AAD Connect:
Create a new inbound Sync Rule, targeted at the on-premises AD forest and for user objects:
Make sure the Connected System is your on-premises AD, the Connected System Object Type is User and the Metaverse Object Type is Person. Set the precedence value high (ie. a low number) – dealer’s choice…
Scoping Filters and Join rules aren’t really necessary.
Create a single transformation with a Flow Type of Expression, the Target Attribute should \ could be UsageLocation (and ‘c’ if you want to fix both).
For the source, your expression will be something like :
IIF(IsPresent([c]),IIF(RegexIsMatch([c], “^[a-zA-Z]{2}$”, “IgnoreCase”),[c],”US”),”US”)
Translation?
This expression uses the Regex ^[a-zA-Z]{2}$ to ensure that the value of ‘c’ is alpha-only, [a-zA-Z] and limited to 2 characters {2}
The rest of the expression wrapped around this nifty RegEx feature checks to make sure that ‘c’ is populated in AD (hence the need to avoid a scoping filter) – if not, it defaults to US, then flows the value as-is if it matches, or flows US if it doesn’t.
If you wanted, you could use the Error() method instead of defaulting to US and throw an error in the Sync Service Manager – something like Error(“AD Attribute c value is not present.”)
In our example above, if ‘c is missing, or invalid, we just set it to US.
Hope this helps someone, either with GBL, or just the use of RegEx in AAD Connect sync rules…