Everyone that has been using Microsoft’s cloud offerings is well aware of the fact that quality has drastically degraded over the past few years. The examples of features that don’t work as advertised or are just broken are numerous, and it often makes you wonder just how much time is spent on testing and QA. Anyway, without further ado, here’s the latest annoyance I’ve run into.
The issue is evident when you create a new mail flow rule, or edit an existing one. All you need to do is include any condition, exception or action that involves some kind of recipient to be designated. It seems that some changes were made recently to the UI, which now passes the Display Name attribute to the underlying PowerShell engine. And since for every tenant with more than a handful of users it’s expected to have at least few objects with matching Display Names, selecting one such object results in the following error message:
Using the “Show cmdlet logging” dialog reveals that the cmdlet being passed to the PowerShell engine references a custom object, something like the below:
Command: Set-TransportRule -ModerateMessageByUser @([Microsoft.Exchange.Management.ControlPanel.PeopleIdentity])
While the full object cannot be retrieved and investigated, it doesn’t seem like it resolves down to an uniquely-valued entry, but passes something like the DisplayName value instead. Which in turn results in PowerShell complaining about the ambiguity of the input, as it should. So the issue basically boils down to how the selected object/parameters are being passed down from the UI to the backend. Pretty much every action that takes an user object as input from the picker dialog (invoked via https://outlook.office.com/ecp/Pickers/MemberPicker.aspx) can trigger the issue, which is in reality the majority of cases for which you would be creating Transport rules.
If you want to reproduce the issue yourself, all you need to do is create or edit a transport rule and within its settings, point to any recipient that has a matching Display Name value with another object in your tenant. If you need help locating such objects, you can use the following PowerShell cmdlet:
Get-Recipient | select Alias,DisplayName | Group DisplayName | ? {$_.Count -gt 1}
Count Name Group
----- ---- -----
2 First group {@{Alias=firstgroup; DisplayName=First group}, @{Alias=Firstgroup1; DisplayName=First group}}
2 Vasil Michev {@{Alias=vasil; DisplayName=Vasil Michev}, @{Alias=vasil.michev_quadrotech-it.com#EXT#; DisplayName=Vasil Michev}}
As seen from the above output, in my tenant there are two instances of duplicate Display Names, which is perfectly normal and acceptable, even expected in any reasonably-sized tenant. What’s also expected is for the Exchange UI to be well aware of this fact, and for it to use an uniquely-valued attribute to identify the objects instead, but alas.
Anyway, once you have identified a matching object, all you need to do is use it within a transport rule. The example below shows such a rule being created with the “Includes any of these recipients in the To or CC box” condition, and with one of the “duplicate” objects selected:
The rest of the settings don’t matter, you can select anything for the action. The moment you press the Save button on the Rule dialog however, you will be presented with the error shown on the first screenshot above. The good news is that Microsoft is aware of the issue, and it should be fixed soon, hopefully.
In the meantime, if you run into this issue you can simply resort to using PowerShell as the workaround. If you insist on using the UI, you can instead type in the object’s primary SMTP address in the “Check names” control.