Syncing Exchange attributes after upgrading from dirsync to AADConnect

​Another common issue I run into on the different O365 forums quite often – after upgrade from dirsync to the new AADConnect tool, people are complaining about different Exchange attributes, most often the msExchHideFromAddressLists one, not being synced anymore from on-prem to Azure AD. The solution for the issue is simple – make sure the object in question has the mailNickname attribute populated in AD.

So how do I know that? And how to troubleshoot similar issues? Well, remember that both dirsync and AADConnect are stripped down version of FIM. The process is still the same – the objects and their corresponding attributes are brought from the on-prem AD to the Metaverse via ADDS connector, and then synced to Azure AD via the WAAD one. There are several settings that control the attribute flow, and in this case the important one are the sync rules. Let’s use some basic examples to try and locate the exact issue.

We have two users for which we have set the msExchHideFromAddressLists attribute to True: Pesho and Gosho. The difference between them is that for the later one, Gosho, we have also set the mailNickname attribute as evident from the screenshot below:

 After forcing a sync the changes we have made to the attributes should be picked up by the sync engine and the relevant properties of the object in the Connector space should be updated. As seen from the below screenshot, in both cases the msExchHideFromAddressLists is updated:

So far so good. If we look at the corresponding objects in the WAAD Connector space however, the situation is a bit different:

Note how the msExchHideFromAddressLists attribute is missing from the properties of Pesho’s object? You can also confirm this if you take a look at the object in the Metaverse:

This method also allows us to quickly check for some additional information, which will prove very useful for troubleshooting the issue at hand. Not only we see the attributes and their values, but also which management agent was responsible for provisioning the attribute as well as the actual sync rule that was in effect. In this case, the rule in question is the “In from AD – User Exchange” one. Now, if we check the actual rule in the Synchronization Rules Editor tool, we will be able to determine the cause of the issue – the rule has a scoping filter configured to skip every object that does not have the mailNickname attribute populated. The same actually applies to all Exchange related rules (In from AD – User Common from Exchange, In from AD – InetOrgPerson Common from Exchange, In from AD – User Exchange, In from AD – InetOrgPerson Exchange). Something to have in mind!

Now, while we are on the subject of troubleshooting sync issues, lets see another way to check the object attributes in the Metaverse as well as the contributing sync rules. We can simply run a sync preview by pressing the corresponding button on the Connector Space Object Properties (see above screenshots). This will bring up the Preview dialog, with the options to generate a Full or Delta sync preview (as well as to commit the preview). Generating the preview in turn will generate a lot of data. First, we have the Source Object Details tab, which list the object properties in the Connector space we started the process with. Nothing interesting here, as we have already seen it previous steps. On the Import attribute flow tab, all the relevant attributes for the object that are present in the Metaverse, as well as their contributing sync rules will be displayed, along with the expressions that were used to calculate their final values. Below it, a detailed information on the Export flows per connector will be revealed, again with the rule, expression and final values. If we are generating the preview for the user Pesho, this is what we would see:

As discussed above, some of the sync rules will not be in effect due to the missing mailNickame attribute, thus not all attributes will get updated to the Metaverse and subsequently, in Azure AD. If we compare the previews for two similar object, one for which the sync is working as expected and one for each it is not, we would quickly be able to see where the issue lies by checking if the relevant attributes are present and which rules did not act on the object (a list of said rules is shown in the bottom box). If the object as a whole was filtered out due to some reason (say this was the default Admin account or sAMAccountName was not populated), the relevant Connector would not have been displayed under Connector Updates on the left hand side, giving us a quick indication that something is wrong.

Yet another way to quickly glance the rules that were in effect is to click on the Lineage tab on the Connector space object properties dialog.  If we do again a side-by-side comparison of our two users, we will quickly see that two rules didn’t fire:

Lastly, for the PowerShell lovers, we can also use some troubleshooting via the command line. For example, if we want to quickly list all rules that involve the msExchHideFromAddressLists attribute, we can use the following cmdlet:

PS C:\> Get-ADSyncRule | ? {$_.AttributeFlowMappings -like "*hide*"} |  ft Name,Identifier

Name                                                        Identifier
----                                                        ----------
Out to AAD - User ExchangeOnline                            86c1fc19-3e0b-41d0-bc5e-51987d821c90
Out to AAD - User LyncOnline                                a75b2ef5-5e0c-49a7-9e83-53ada736363a
Out to AAD - Contact ExchangeOnline                         c4a62ffd-fa58-48a8-8aef-b83859004e87
Out to AAD - Group ExchangeOnline                           a6b6155a-437c-4448-898a-269e807f579a
Out to AAD - Group SharePointOnline                         e1a8435a-744d-497c-91e8-fa4150d5b0f2
Out to AAD - Contact LyncOnline                             c0cda3b9-a923-4179-852c-8aa03941cfa6
Out to AAD - Group LyncOnline                               696c9dd7-012b-4b03-b8e8-b8530033432a
In from AD - Contact Join                                   da934cdc-6da7-4842-894b-5cca456bba03
In from AD - Contact Common                                 83143571-0ab7-4954-a4b9-282aec956265
In from AD - User Exchange                                  b0c347e6-9006-4a59-98a2-a4e8b28e2844
In from AD - InetOrgPerson Exchange                         fdbdfce8-aad3-43e8-9212-0796f3b33a47
In from AD - Group Exchange                                 f0f884f4-52d1-4237-9fe7-5417fa62de33

Or if we only want to check for rules that act on User objects (as User objects correspond to ‘person’ in the Metaverse, this will only list Inboud rules, exactly what we are looking for):

PS C:\> Get-ADSyncRule | ? {$_.AttributeFlowMappings -like "*hide*" -and $_.SourceObjectType -eq "user"} |  ft Name,Identifier

Name                                                        Identifier
----                                                        ----------
In from AD - User Exchange                                  b0c347e6-9006-4a59-98a2-a4e8b28e2844

Once we have identified the rule, we can quickly check for any scoping filters:

PS C:\> (Get-ADSyncRule b0c347e6-9006-4a59-98a2-a4e8b28e2844).ScopeFilter.ScopeConditionList

Attribute                               ComparisonValue                                              ComparisonOperator
---------                               ---------------                                              ------------------
mailNickname                                                                                                  ISNOTNULL

And voila – we now know that the mailNickname attribute is mandatory if we want to properly sync msExchHideFromAddressLists to Azure AD. And if we want to also check which other rules depend on the mailNickname attribute:

PS C:\> Get-ADSyncRule | ? {$_.ScopeFilter.ScopeConditionList.Attribute -eq "mailNickname"} |  ft Name,Identifier
Name                                                        Identifier
----                                                        ----------
In from AD - User Common from Exchange                      8c5a1599-08a1-4240-8032-6c6e5e16fb75
In from AD - InetOrgPerson Common from Exchange             3cc8676b-c896-49bb-9753-c2b77c772fa5
In from AD - User Exchange                                  b0c347e6-9006-4a59-98a2-a4e8b28e2844
In from AD - InetOrgPerson Exchange                         fdbdfce8-aad3-43e8-9212-0796f3b33a47

So that’s basic troubleshooting for attribute flow issues with AADConnect. Hope it helps!