lol, got some guidance on a 'workaround' from MS support on this, and it's about as ridiculous as I'd expect. As follows:
Hope you are doing well.
I have reproduced the issue in the lab and confirmed with the internal team that this issue is by design with the AD sync environment. However, as a workaround, synced user can be converted to an In-Cloud user that will allow to run Set-Mailbox -Identity -Name command that will show the correct name instead of the Object ID. Later on, if you wish user(s) can be converted back to the synced user.
So you can perform below steps for the test user to check this.
- Move mailto:email address removed for privacy reasons user to "Lost and Found" OU and run the initial sync. Command is Start-ADSyncSyncCycle -PolicyType Initial
- It will move email address removed for privacy reasons to Deleted users in office 365. Please restore the user and connect PowerShell to Exchange Online to run Set-Mailbox -Identity email address removed for privacy reasons -Name "users name"
- Now we are all set. Remove User from the dynamic list > Save the changes and readd it.
- Now you would see the correct name.
- If you want, email address removed for privacy reasons can be moved back to original OU to sync it with AD.
So basically, break the users connection, and change the name manually, then sync back up.
In order to prevent it going forward, I'm assuming we'd need to manually create the user both in AAD/EXO and AD, set the properties, and then sync them up, rather than just creating them in AD, syncing them, and going forward as usual.
It's just astounding this is considered intentional and usable behavior.