Yesterday, a peer brought an interesting problem to me:
His customer had been storing data in the on-premises msExchExtensionCustomAttribute properties for users and wanted to be able to use that data in Exchange Online for filtering and dynamic group membership.
You do know what blog you’re reading?
[Update 2020-05-17: I replaced the AAD Connect Transform to account for an empty string and not flow any value].
[using logic] This is something that should be doable.
I mean, if you look at AAD Connect’s synchronization rule configuration, we clearly are importing that data from AD and exporting it to Azure AD:
In from AD – User Exchange
In this rule (default precedence, 108), we’re creating a mapping from the on premises msExchExtensionCustomAttribute# value to a correspondingly-named value in the AAD Connect metaverse:
Out to AAD – User ExchangeOnline
In this rule (default precedence, 123), we’re creating a mapping from the metaverse to Azure AD for the same attributes. to a correspondingly-named value in the AAD Connect metaverse:
If you check a mailbox’s attributes, you can clearly see that ExtensionCustomAttribute1-5 are listed:
And, if you create a new Dynamic Distribution Group in Exchange and specify that attribute, Exchange Online allows you do to so (without error):
It would stand to reason that it could be used.
But then, you’d be very wrong.
While the value is:
- Imported from AD into the AAD Connect metaverse
- Exported to Azure AD
- Available as an attribute on a mailbox
- Available as a filterable attribute for creating a group
The plumbing to get it synchronized from Azure AD into Exchange Online is not there. Ugh.
So what can you do?
The workaround is to just use another attribute, silly.
Fortunately, you can create a new synchronization rule to copy the value of your msExchExtensionCustomAttribute into an unused attribute that is available in Exchange Online.
And here’s how.
- Identify the msExchExtensionCustomAttribute containing data that you need to map, such as msExchExtenstionCustomAttribute5.
- Identify a target attribute (such as ExtensionAttribute1-15) that can safely be used in your environment.
- Launch the AAD Connect Synchronization Rules Editor.
- Under Direction, select Outbound and then click Add new rule.
- Fill out name and description.
– Connected System, select your Office 365 / Azure AD Tenant (the .onmicrosoft.com name in the list).
– Connected System Object Type, select the type (usually, a user)
– Metaverse Object Type, select the object type (if you select user as the CSOT, then you’ll select person here).
– Link Type, select Join.
– Precedence, enter a value lower than any of the default rules (usually somewhere in the 90s or 80s is good, depending on how many custom rules you have)
- Click Next.
- Add any scoping rules (we’re not going to add any for this, rule) and click Next.
- Add any Join rules (we’re not going to add any of these, either) and click Next.
- On the Transformations page, click Add transformation.
- Fill out the rule accordingly, substituting your own target attribute and source attributes.
– FlowType, Expression
– Target Attribute, select the destination attribute. We’re going to use extensionAttribute14 in this example.
– Source, copy and paste the following exactly, only substituting the numeral in the source attribute. Note: msExchExtensionCustomAttribute(#) are multivalued attributes. You cannot use AAD Connect to directly copy it, since they’re different types. If you have just a single value stored in this attribute, we’ll just select the first (and only) one and move along. If you need to use the second value, update the ,1 to ,2. In this example, I’m going to use the Item function to return the first value in msExchExtensionCustomAttribute1 and use it as the source:
– Apply Once, leave unchecked
– Merge Type, leave as Update
Note: Make sure you’re using the exact capitalization specified above. You’ll get a sync error in AAD Connect if any of the capitalization is not what AAD Connect is expecting.
- Click Add.
- Acknowledge the window that says the next synchronization cycle will be a Full cycle.
At this point, the first value from msExchExtensionCustomAttribute1 will be written into extensionAttribute14 in Azure AD. As Emeril would say,