You might be experiencing something similar to this:
You have set the msExchHideFromAddressList to either TRUE or FALSE using the attributes on the User Object in your on-prem Active Directory. You have also waited up to half an hour for Azure AD Connect to synchronize the setting to Azure AD. But when you log on to the Office365 administration portal, or Exchange Online management portal the attribute remains unchanged, and obviously you cannot change the setting in either portal because the object is synchronized from your on-prem Active Directory.
While researching the issue I found quite a few posts on different forums from others experiencing this, and even more suggestions including uninstalling and reinstalling Azure AD Connect, doing af Full Sync, etc., but none of them were solving the issue.
There are actually two solutions to the problem, depending on whether you want to control this particular setting from you on-prem Active Directory or through either of the management portals.
In case you want to control the setting from you on-prem Active Directory, you need to make sure that the attribute mailNickname has a value. If not, you will need to add a value, typically the initials of the account in question.
Why is this, you might ask. Well, the issue occurres because the msExchHideFromAddressLists attribute is affected by a default Exchange synchronization rule definition in Azure AD Connect which includes a scoping filter setting in which the mailNickname has a value of IsNotNull. In other words, the condition specified in the rule says the mailNickname attribute must contain a value for the msExchHideFromAddressLists attribute setting to be applied to the user object.
If you want to manage the setting from within either of the portals, you can deselect the msExchHideFromAddressLists attribute withing Azure AD Syncronization Service (miisclient.exe). This disables the synchronization of the attribute and should allow you to change the setting as preferred in either the O365 Portal by selecting the user, or by editing the settings for the mailbox within the Exchange Online management portal.
I sure hope this helps and prevents headaches and frustrations.
Good info. This worked for me. Note that mailNickname (aka Alias) is an Exchange attribute which means that the on-prem AD must have the Exchange schema extensions. Adding a value to an on-prem AD account’s mailNickname updates the Alias value of the linked mailbox/account in O365. Note that it will not modify any existing e-mail addresses nor add a new one.
“Well, the issue occurs because the msExchHideFromAddressLists attribute is affected by a default Exchange synchronization rule definition in Azure AD Connect which includes a scoping filter setting in which the mailNickname has a value of IsNotNull.”
This absolutely solved the problem we were having which spanned roughly 6 months of on-and-off searching. I owe you a beer after a long and frustrating journey trying to figure out why that property wouldn’t sync!
I want to say a huge THANK YOU to whoever authored this fix. You saved me a world of frustration. Appreciate folks like you who take the time to write these. I personally will look for opportunities to help others doing the same. – Sincerely, David
Thank you – I am happy this helped you solve your problem.