...
A Personal O365 Email Alias has a MAILBOX of “netid@connect.yale.edu”. This does not include people with a Primary Eliapps Alias who also are the owners of an Alias to an Exchange account belonging to a group or dependent Netid (although such Aliases should be owned by the Dependent Netid). As an additional check, their Exchange Online status will be “UserMailbox” if they really have an O365 mail account, but if not then the alias “points” to an non-existant O365 mailbox.
When a Secondary Alias has a MAILBOX that appears to be O365 (“netid@connect.yale.edu”) but there is no actual O365 mail account (so the Exchange status is MailUser instead of UserMailbox), then Exchange is not confused by the “connect.yale.edu” mail domain. We administrators use this domain exclusively for O365 mail, and Exchange knows that it is a mail domain that it handles, but it still delivers mail based on the type of Recipient and not the domain name. Since this Recipient is a MailUser with an ExternalEmailAddress ending in “@bulldogs.yale.edu”, Exchange will correctly forward this mail to the Eliapps account even through the MAILBOX is “connect” instead of “bulldogs”. While it would be better to fix the MAILBOX, we should not Delete the Alias thinking that it “points to a non-existant O365 account”. While it looks that way to people, the algorithm delivers mail to the Alias just as if it were a proper Eliapps alias.
Under Yale Policy, an O365 Mail account should always be primary, but that policy is not enforced. Because of this configuration and the Mail Relays, mail sent to “morrow.long@yale.edu” from any O365 user goes to his O365 inbox, while mail from outside Yale or from Eliapps goes through the Relays to his Eliapps mailbox. When the Mail Relays are replaced by Exchange Online, all mail will be delivered to O365. Morrow, jsi3, sbt3, fa292, and jm3353 should be notified of the change in behavior By a “personal” account, I am not including Secondary Aliases owned by a person that point to Email accounts owned by a Dependent Netid (typically used for shared mailboxes for groups or departments).
IAM code that only has access to databases, like the ACS1 tables, has to regard the MAILBOX in the alias as authoritative. A more direct check, but one available only to Powershell, is to call the ExchangeOnlineManagement Get-Recipient command to determine if a User object is a “UserMailbox” type of recipient. This directly determines if Exchange Online has an O365 mail account associated with the object. Without this check, there can be Aliases for a mail account that doesn’t exist, and mail accounts that in violation of Yale Policy have no Alias associated with them. These are errors that should be found and fixed manually. These errors arise from mismanagement of accounts by admins and not by normal changes to Identity status. The IAM functions in IIQ cannot be expected to fix them.
However, this type of error does not result in misdelivered Email because in neither case should anyone have an expectation that mail will be delivered to either a non-existent account or to an account with no Alias. There is some small chance of errors when someone who left Yale years ago and currently has such errors in their configuration were to try to return to the university and get a new mail account.
However, a small number of people violate Yale Policy by having a Primary Email Alias that points to Eliapps while also having an O365 mail account. This creates an ambiguity. Currently the Mail Relays deliver incoming mail to Eliapps, while mail sent from Exchange Online to the same address goes to the O365 mailbox.
However, the real problem is that this will try to generate duplicate ProxyAddresses. The Primary Email Alias (no matter what MAILBOX value it has) sets the UPN and MailNickName, and Exchange Online will always insert the UPN into the list of ProxyAddresses even if it is not in the Local AD list. Meanwhile, a secondary Eliapps account belonging to someone who owns an O365 mail account will generate a Contact object, and the ProxyAddresses list in the Contact will include the Aliases pointing to that account, and the first (primary) email address in that list will be the Primary Alias address.
Exchange Online will refuse to add the ProxyAddress to the second object it processes, which will generally be the Contact. The following list of Primary Aliases seem to have this problem, but only 5 of them represent current users. If nothing is done, then they will cease to get mail in their Eliapps account through the Primary Alias. All of them need to be rechecked before the Mail Relays are retired.
...