Content Comparison

...

To make this work, we require that Exchange Online be configured to do two things:

...

three things:

• While Exchange has always been configured with Primary Email Aliases for O365 accounts, it has not been configured with all the “@yale.edu” email names (all the Alias Names in the Alias Table) that it does not already know about.

• Exchange automatically knows what to do with mail associated with a MAILBOX that ends in “@connect.yale.edu”. It must be configured with MAILBOX values for Eliapps (case 2 above) and the DNS name of email processing service machines (case 3 above).

Exchange does not need to distinguish Eliapps from “Case 3” addresses, but we choose to configure Eliapps accounts for students differently from the way we handle Case 3 addresses for other Yale business reasons.

Exchange requires that an O365 mail account be configured in a single User object. Every personal O365 mail account is attached to the AD User object for that Netid, so all the aliases pointing to that account have to be added to the ProxyAddresses list of that User Object. The Primary Email Alias is there already. We have to make sure that all secondary aliases that have the same MAILBOX value are also in the list, realizing that it is possible at Yale for an alias to one personal Email account to be “owned” by someone other than the person who owns the account the alias points to.

We have decided to configure student personal Eliapps mail accounts in the User object of the student. Again, all the secondary aliases that point to the account have to go in the ProxyAddresses list of the student who owns the mail, but since this is an external account we also have to store the MAILBOX value in the TargetAddress field of the User object.

Everything else goes into a MailContact we create in AD and AzureAD to point all the remaining Yale Mail Aliases to their corresponding MAILBOX values.

Exchange Online Configuration

...

• secondary aliases. Sometimes Exchange depended on the Mail Relays to translate Aliases it did not know into specific accounts. We must add all Aliases to the Exchange configuration.

• Exchange was originally configured with only O365 accounts. A year ago we added the Primary Email Aliases of students with an Eliapps account. We need to add in the secondary aliases.

• Every other Email Alias not configured in the previous two steps has to be configured to Exchange Online as a Contact object in AD. The Alias Name is a ProxyAddress and the MAILBOX is a Target Address.

To be sure everything is configured correctly, the following things must be true:

1. Every Email Alias of a personal O365 mail account must be in the ProxyAddresses list of the AD object associated with that account.

2. Every Email Alias of an Eliapps or other non-O365 mail account must be in the ProxyAddresses list of some AD object (User or Contact) whose TargetAddress is equal to the MAILBOX value of the Alias.

3. A given Alias must be unique in the AD (it must be in only one ProxyAddresses list of one object).

4. Every AD object (User or Contact) involved in Mail Routing must have a unique Mail Box value, which is the Primary Alias Name of User objects and the first ProxyAddress of Contacts.

We can run through the Email Alias table and make sure that every row is associated with some object and that the fields match up. However, fixing errors that exist in the Alias Table or existing AD objects is an ongoing function. Most of these errors are not related to the Mail Relay function and need not be fixed in order to retire the Mail Relays.

Exchange Online Configuration

The only way to know for sure if a user has an Exchange mail account or if an email address is known to it is to ask Exchange Online directly. The easiest way to do this is with Powershell.

Exchange has what it calls MailRecipients. There are three primary types of Recipients: O365 personal mail accounts (called a UserMailbox), external mail accounts (mostly Eliapps) that Exchange knows about, and “resources” like SharedMailboxes and Distribution Lists.

It turns out that anyone with a Netid can download code and ask Exchange to provide information on all Recpients:

$recipients=get-exorecipient -ResultSize unlimited -Properties ExternalEmailAddress(

If you don’t specify -ResultSize unlimitedare patient, you get the first 1000 objects. If you don’t specify -Properties ExternalEmailAddress then you don’t get the TargetAddress for Eliapps and other non-O365 mail accounts).Now go do something else for a few minutes and when you come back $recipients will be a variable with about 106126 objects. These objects consist of MailUser, UserMailbox, MailContacts, and a list of special objects manually configured to Exchange (that we don’t have to worry about):will get back something around 106126 objects. There is an UserMailbox object for every Netid who has a personal O365 mail account. There are a set of more specific object types for the native Exchange objects created by Exchange administrators that receive mail but are not people:

MailUniversalSecurityGroup
SharedMailbox
GroupMailbox
GuestMailUser
RoomMailbox
MailUniversalDistributionGroup
EquipmentMailbox
SchedulingMailbox
DynamicDistributionGroup
DiscoveryMailbox
PublicFolder
TeamMailbox

The reason why we don’t worry about these things is that they are manually created in response to a user request by the Help Desk or Email Management groups, are created in Exchange so Exchange knows how to deliver mail to them, and are not within the scope of identities managed by IAM. Currently they may have Email Aliases so that the Mail Relays know to forward mail to these destinations through Exchange Online, but if the mail went directly to Exchange Online without going through the Mail Relays that would be fine. Everything needed to deliver mail to these types of destinations is already correct and no data or procedures need to be changed or added.

So mostly we need to worry about the configuration that Exchange Online gets (from Azure AD and therefore from the Yale local AD) about:

• Personal O365 mail accounts

• Personal Eliapps mail accounts

• Shared Eliapps mail accounts (ends in “@bulldogs.yale.edu” but is not the personal birthright primary mail account of a student)

• Everything else (the “Case 3” stuff described above).

A personal O365 Email Account is a “UserMailbox” that Exchange Online connects to the Azure AD User object created from the Local AD User object created from the Netid. Exchange Online has an Inbox for this User, so all mail sent to an address associated (by a matching Email Address in the ProxyAddresses list) with this account is delivered locally to that Inbox.

External Mail (student Eliapps accounts and all the other stuff) cannot be configured in any User object that is a UserMailbox and is therefore connected to an Exchange Inbox. As long as the AD User object doesn’t have any O365 mail account attached to it, then the MAILBOX value (first.last@bulldogs.yale.edu or any other Mail Address of an external system) can be stored in the TargetAddress field of the User object and then, just as in the previous case) all the Email Addresses associated with that MAILBOX (first.last@yale.edu) can go in the ProxyAddresses list.

O365 mailboxes must be associated with a User object (that has a password and can login). External mail that comes into Exchange, is matched to a ProxyAddress, and is then forwarded to the TargetAddress does not require a User object and can also be configured in a Contact.

It is a business decision that we store external mail forwarding information in the User object of students with Eliapps mail accounts, but store all other external mail forwarding information in Contact objects.

The term “Contact” was created decades ago to represent an object normally put in a directory of external people that you frequently send mail to. However, these Contact objects are stored in a separate OU and are not visible to anyone. Unlike real Contacts used for the original purpose, they will not show up in Outlook as someone you can add to your “To:” list in a new Email message. They exist only to configure Exchange Online with the information it needs to map every Email Alias (every “@yale.edu” address) to some external destination.

There is the AD Name, the Exchange Name, and the Yale Name

Unfortunately, the same thing has different names in different contexts.

...

AD

...

Exchange

...

Yale

...

User

...

UserMailbox

...

O365 User

...

User

...

MailUser

...

Eliapps User

...

Contact

...

MailContact

...

other alias mapping

...

ProxyAddresses

...

EmailAddresses

...

ALIAS_NAME@yale.edu
(plus some formal entries for O365 mail users)

...

TargetAddress

...

ExternalEmailAddress

...

MAILBOX

Contacts are created for Aliases that are not Exchange accounts and are not Primary Aliases of Eliapps students. It is not necessary to say what these accounts are, but in case you want to know, they are mostly:

• Eliapps accounts of people who also have an O365 mail account. These are mostly ITS people.

• Elilists (a type of mailing list managed by Eliapps instead of Exchange)

• Student groups (example: yale.spizzwinks@bulldogs.yale.edu)

• Departmental shared mailboxes (example: thechildlab@bulldogs.yale.edu)

• The 111 aliases of servicenow@bulldogs.yale.edu

• Mail for specific department servers (invest.yale.edu, aya.yale.edu)

• Everything else. Sometimes this is recognizable junk left over from machines that have not existed since 1995 (gopher.cis.yale.edu) but it is not necessary to clean this up and that is not part of this project.

Is It Right and Is It Complete

Yale Eliapps and other external (non-Exchange) mail addresses can be configured in a User object (a MailUser) or else a MailContact. Exchange doesn’t really care if you put external mail accounts in Users or Contacts, but a Yale we have decided to put aliases to personal student Eliapps mail accounts in the student’s User object, and put everything else in a Contact.

IAM has responsibility for User objects, whether the User has an O365 mail account or an Eliapps mail account. This information is affected by changes to the personal information that IAM manages. For example, when a student changes a First or Last name, this frequently changes the Primary Email Alias, and that in turn changes both the mail routing functions we are talking about here, but also the login values like UserPrincipalName presented by the user to get access to his O365 applications.

Contacts are generally created for accounts that are manually created on request. Sometimes they are associated with a specific identity of a real person known to IAM, but who for business reasons chooses not to use either the standard O365 or Eliapps mail systems. Sometimes there are special security requirements that require special accounts. Such a person will still have a Netid and an AD User object and a non-Mail O365 account. The Primary Email Alias will create a UPN and will be the “mail” attribute of the AD User object, so subject to privacy the user’s Email can appear in the directory. However, the routing information will be in a separate Contact object and we expect that the Contact object will be updated manually when the manually created Email account is manually changed. If these accounts are important enough to have their own mail system, IAM cannot assume they are subject to the ordinary behavior of student and regular staff accounts.

There is the AD Name, the Exchange Name, and the Yale Name

Unfortunately, the same thing has different names in different contexts.

Contacts are created for Aliases that are not Exchange accounts and are not Primary Aliases of Eliapps students. It is not necessary to say what these accounts are, but in case you want to know, they are mostly:

• Eliapps accounts of people who also have an O365 mail account. These are mostly ITS people.

• Elilists (a type of mailing list managed by Eliapps instead of Exchange)

• Student groups (example: yale.spizzwinks@bulldogs.yale.edu)

• Departmental shared mailboxes (example: thechildlab@bulldogs.yale.edu)

• The 111 aliases of servicenow@bulldogs.yale.edu

• Mail for specific department servers (invest.yale.edu, aya.yale.edu)

• Everything else. Sometimes this is recognizable junk left over from machines that have not existed since 1995 (gopher.cis.yale.edu) but it is not necessary to clean this up and that is not part of this project.

Is It Right and Is It Complete

Yale has an Email Alias database table. It has an ALIAS_NAME column and a MAILBOX column. The ALIAS_NAME is unique (it appears only once in the table).

...

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.

...