...
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
Every Email address Exchange Online is configured to process is a “MailRecipient”. Anyone with a Netid can find all the MailRecipients known to Exchange by installing the ExchangeOnlineManagement Powershell module and entering the Powershell statement:
...
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:
Every Email Alias of a personal O365 mail account must be in the ProxyAddresses list of the AD object associated with that account.
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.
A given Alias must be unique in the AD (it must be in only one ProxyAddresses list of one object).
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 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).
Every ALIAS_NAME has to be configured so that Exchange Online delivers mail to a local mailbox or else forwards mail to the correct external mailbox.
The first rule is that there should not be duplicate ProxyAddresses entries in more than one AD object. At this time, there are some duplicate ProxyAddresses for some SharedMailbox objects, but although incorrect this is not a problem that has to be solved in order to replace the Mail Relays since SharedMailboxes and all the other room and group resources manage by Exchange are already configured and removing the Mail Relays does not affect them. At some time in the future we should fix this.
Currently, if a secondary ALIAS_NAME is associated with an O365 personal mail account (that is, if the MAILBOX value is “netid@connect.yale.edu” or “first.last@connect.yale.edu”) and because of an error in our systems there is no ProxyAddress in the User object for that Netid matching the ALIAS_NAME, then Exchange sends the mail to the Mail Relays who look up the Alias in the table to find the MAILBOX and then send the mail back to Exchange with the MAILBOX information. Exchange delivers the mail correctly today but would not deliver it if the Mail Relays did not correct the configuration error. So we must make sure that all Aliases that match a “@connect.yale.edu” MAILBOX are in the ProxyAddresses list. This requires fixing or replacing the AD Updater process (work in progress now).
Students with a Primary Email Alias whose MAILBOX value ends in “@bulldogs.yale.edu” have an AD User object whose TargetAddress is the MAILBOX value and must have in the ProxyAddresses list all the ALIAS_NAMES that had the same MAILBOX value as the Primary Alias MAILBOX.
Once you remove the previous three cases (Aliases of SharedMailboxes, of Personal O365 accounts, or of Personal Eliapps accounts) then all remaining ALIAS_NAMES must be a ProxyAddress of a Contact whose TargetAddress is the MAILBOX value of that Alias. We could have created a Contact for every Alias (there is no requirement that TargetAddresses be unique) but it is convenient to collect all Aliases of the same MAILBOX in the same Contact.
At this point, every Alias has been mapped, and it should be mapped to its MAILBOX.
Up to this point, we have verified the configuration in terms of the local AD, which is the mechanism we have to configure Exchange Online. We can doublecheck the configuration from the Exchange Online point of view. This gives us a separate validation, but through a Read-Only mechanism. If we find a problem, we have to go back to the AD and figure out how to fix it.
Remember the Powershell command:
$recipients=get-exorecipient -ResultSize unlimited -Properties ExternalEmailAddress
This gives you a set of objects that includes all the recipients (SharedMailboxes, O365 accounts, Eliapps users, and Contacts) from the point of view of Exchange Online. Remember, we configure Local AD, which is then used to configure Azure AD, which is then used to configure Exchange Online. So now we skip to the final end result and see if the stuff we put in at the beginning ended up where we wanted it to be.
Each Recipient object has an EmailAddresses list. Every Email Alias should be found in one EmailAddresses entry of one Recipient object. 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.
AD | Exchange | Yale |
|---|---|---|
User | UserMailbox | O365 User |
User | MailUser | Eliapps User |
Contact | MailContact | other alias mapping |
ProxyAddresses | EmailAddresses | ALIAS_NAME@yale.edu |
TargetAddress | ExternalEmailAddress | MAILBOX |
MailNickName | Alias | Primary ALIAS_NAME (first.last) |
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).
Every ALIAS_NAME has to be configured so that Exchange Online delivers mail to a local mailbox or else forwards mail to the correct external mailbox.
The first rule is that there should not be duplicate ProxyAddresses entries in more than one AD object. At this time, there are some duplicate ProxyAddresses for some SharedMailbox objects, but although incorrect this is not a problem that has to be solved in order to replace the Mail Relays since SharedMailboxes and all the other room and group resources manage by Exchange are already configured and removing the Mail Relays does not affect them. At some time in the future we should fix this.
Currently, if a secondary ALIAS_NAME is associated with an O365 personal mail account (that is, if the MAILBOX value is “netid@connect.yale.edu” or “first.last@connect.yale.edu”) and because of an error in our systems there is no ProxyAddress in the User object for that Netid matching the ALIAS_NAME, then Exchange sends the mail to the Mail Relays who look up the Alias in the table to find the MAILBOX and then send the mail back to Exchange with the MAILBOX information. Exchange delivers the mail correctly today but would not deliver it if the Mail Relays did not correct the configuration error. So we must make sure that all Aliases that match a “@connect.yale.edu” MAILBOX are in the ProxyAddresses list. This requires fixing or replacing the AD Updater process (work in progress now).
Students with a Primary Email Alias whose MAILBOX value ends in “@bulldogs.yale.edu” have an AD User object whose TargetAddress is the MAILBOX value and must have in the ProxyAddresses list all the ALIAS_NAMES that had the same MAILBOX value as the Primary Alias MAILBOX.
Once you remove the previous three cases (Aliases of SharedMailboxes, of Personal O365 accounts, or of Personal Eliapps accounts) then all remaining ALIAS_NAMES must be a ProxyAddress of a Contact whose TargetAddress is the MAILBOX value of that Alias. We could have created a Contact for every Alias (there is no requirement that TargetAddresses be unique) but it is convenient to collect all Aliases of the same MAILBOX in the same Contact.
At this point, every Alias has been mapped, and it should be mapped to its MAILBOX.
Up to this point, we have verified the configuration in terms of the local AD, which is the mechanism we have to configure Exchange Online. We can doublecheck the configuration from the Exchange Online point of view. This gives us a separate validation, but through a Read-Only mechanism. If we find a problem, we have to go back to the AD and figure out how to fix it.
Remember the Powershell command:
$recipients=get-exorecipient -ResultSize unlimited -Properties ExternalEmailAddress
This gives you a set of objects that includes all the recipients (SharedMailboxes, O365 accounts, Eliapps users, and Contacts) from the point of view of Exchange Online. Remember, we configure Local AD, which is then used to configure Azure AD, which is then used to configure Exchange Online. So now we skip to the final end result and see if the stuff we put in at the beginning ended up where we wanted it to be.
Each Recipient object has an EmailAddresses list. Every Email Alias should be found in one EmailAddresses entry of one Recipient object. The advantage of this check is that you don’t have to distinguish different types of users or mail or aliases. Every ALIAS_NAME should match one Recipient and the ExternalEmailAddress should match the MAILBOX value.
...
If we replace the Mail Relays with Exchange Online, then the previous step doesn’t happen. We change the original MX record for “yale.edu” to point to “connect-yale-edu.mail.protection.outlook.com” and we take the teas and dump them in Boston harbor (we can have a party to celebrate the success of the project, but dressing up as native Americans is no longer appropriate because it is “cultural appropriation”).
Exchange Online will behave the same whether mail is sent to it directly or comes through the Mail Relays. So any mail that Exchange already processes correctly will work the same and we do not need to make changes.
The largest block of mail that will be processed differently are the student Eliapps accounts. Previously they would be sent from the Mail Relay to Google directly. Now the mail goes to Exchange. Because Exchange believes that it is “@yale.edu”, it initially expects that mail addressed to a user named “john.doe@yale.edu” is a personal O365 mailbox or a group object named “gravitywaveastronomy@yale.edu” is a shared mailbox or distribution list. However, it will find that the Azure AD User object for “john.doe@yale.edu” has no O365 account and will find no configured DL named “gravitywaveastronomy@yale.edu”.
It has always been possible to add configurations to Exchange and AD for mail accounts that belong to a university or company but which are hosted on another mail system. Originally Microsoft designed this when each department in a company had its own departmental mail server, but it works with any kind of server.
We already have the information we need in the Alias Table. Just as the current system uses the Alias Table to generate configuration for the Mail Relays, we can generate configuration in AD that Exchange will recognize as a pointer to a Yale University mail account on an external server. There has to be an AD object. The AD object cannot be a User with an O365 account (or the mail would be delivered to that mailbox). The object must be have a TargetAddress property.
The value of TargetAddress is essentially the MAILBOX column value in the Alias Table.
The AD Object can be a User or a Contact. Since every student with an Eliapps account already has an AD User object (and Yale Policy is that Eliapps mail users don’t also have an O365 mailbox), we have adopted the simplifying rule to put a TargetAddress in the existing User object for these students, but create a Contact for shared mailbox groups and everyone else.
The ALIAS_NAME must match one entry in the ProxyAddresses list property for the AD Object.
If we do this, then Exchange Online has the information it needs to forward mail for every Alias in the Alias Table that does not have an “@connect.yale.edu” MAILBOX, and therefore it can replace the existing Mail Relay function.
Exchange does not care how many objects you scatter into the AD, but it would certainly be a bad idea to create extra objects for the secondary Aliases of a student Eliapps account. So the student’s AD User object should contain ProxyAddresses for both the Primary Alias name and all secondary Alias names that point to the same “bulldogs” MAILBOX account.
We propose to also group Contact objects by MAILBOX value. More that one Alias can point to the same MAILBOX value, but if we group by MAILBOX value, we can then generate one Contact object for that value and add a ProxyAddresses entry for every ALIAS_NAME in the table with that MAILBOX.
Alias names change if a person chooses to change their First or Last name or if they enable and disable privacy. This is an IAM function.
Currently the old AD Daily Updater generates ProxyAddresses from Primary and Secondary Aliases of Exchange (@connect.yale.edu) MAILBOX values, although the old code gets confused unless the Netid owning the Alias is also the netid in the “netid@connect.yale.edu” value (which isn’t always true). The replacement code in IIQ (which has been written and tested but has not gone into production) fixes the incorrect assumptions by ignoring alias ownership, and it also generates the correct ProxyAddresses entries for primary and secondary Eliapps accounts (@bulldogs.yale.edu).
However, to address the “Canvas Contact” problem we have created ProxyAddresses and TargetAddress fields in the AD and Azure AD User objects of current students with Eliapps accounts. This is done only when the mailbox is created, so if a student generates Secondary Aliases or changes the Primary Alias, the ProxyAddresses list would have to be changed manually.
Done: Populate the ProxyAddresses list of student Eliapps users with any Secondary Aliases that have a MAILBOX that points to their Eliapps account.
Done: There may be Eliapps accounts that are the Primary Email Alias of people who are not current students and were not configured as part of the student class distribution list fix. Their Primary and Secondary aliases should be configured in their User objects if possible, or in a Contact if they also have an O365 account occupying the User object.
Done: All remaining Email Aliases (excluding aliases pointing to some sort of Exchange account or a Primary Eliapps account) get turned into Contacts. We do not create or look for User objects for them. A new Contact is created in some new OU, and the MAILBOX becomes its TargetAddress and all the ALIAS_NAMEs with that MAILBOX value become entries in its ProxyAddresses list.
Decision Point: The personal O365 and Eliapps accounts are plausibly related to IAM, although we are not in the business of creating Secondary Aliases. It may be decided that it is useful to continue to audit the Alias Table and the ProxyAddresses list to see if somehow personal Alias changes slipped in without generating the required ProxyAddress changes. However, the creation and modification of shared mailboxes and departmental accounts is not an IAM function and because these objects have no information in Identity tables, we are not in a position to audit them properly. We should consider this a one time conversion of Alias information into AD objects and properties that configure Exchange Online. Going forward, all scripts, tools, and procedures used to generate departmental accounts and create their aliases should also manage their Contacts with the mail routing information.
Cleanup: If tools are created or converted to manage non-personal mail accounts, then we should consider establishing some proper rules and converting existing entries to match these rules. In particular, the practice of creating an Email Alias and a Dependent Netid and assigning ownership of the Alias to the person who owns the dependent Netid causes serious problems. People leave the university without transferring both the alias and the Dependent Netid to someone else. Then when their personal mail gets deprovisioned, the Secondary Alias for the group account remains attached to the inactive AD User object. The correct thing to do is the assign ownership of the Alias to the Dependent Netid that represents the shared mail account. The account can then stand alone, and if the owner fails to transfer the Dependent Netid to someone else, well the Dependent Netid is still active even if the former owner is inactive. This fix is not technically part of the Mail Relay project, but if we are fixing all the tools for this type of account we should fix this at the same time.
...
receive the original address in the mail without any translation through the Alias table. This means that Exchange has to understand “howard.gilbert@yale.edu”, while if the Mail Relays had preprocessed this alias they would have forwarded it as “gilbert@connect.yale.edu”.
In practice, this means that every Alias name has to be mapped to a Recipient (as explained above). In the past, some Aliases were not recognized by Exchange, so it would forward that message to the Mail Relays who in turn would translate the alias to a MAILBOX value and send it back. To get rid of the Mail Relays, Exchange has to recognize every alias immediately.
Done: Populate the ProxyAddresses list of student Eliapps users with any Secondary Aliases that have a MAILBOX that points to their Eliapps account.
Done: There may be Eliapps accounts that are the Primary Email Alias of people who are not current students and were not configured as part of the student class distribution list fix. Their Primary and Secondary aliases should be configured in their User objects if possible, or in a Contact if they also have an O365 account occupying the User object.
Done: All remaining Email Aliases (excluding aliases pointing to some sort of Exchange account or a Primary Eliapps account) get turned into Contacts. We do not create or look for User objects for them. A new Contact is created in some new OU, and the MAILBOX becomes its TargetAddress and all the ALIAS_NAMEs with that MAILBOX value become entries in its ProxyAddresses list.
ToDo: The Legacy ADDailyUpdater is deleting Secondary Email Aliases from the ProxyAddresses list. This must be fixed.
Decision Point: The personal O365 and Eliapps accounts are plausibly related to IAM, although we are not in the business of creating Secondary Aliases. It may be decided that it is useful to continue to audit the Alias Table and the ProxyAddresses list to see if somehow personal Alias changes slipped in without generating the required ProxyAddress changes. However, the creation and modification of shared mailboxes and departmental accounts is not an IAM function and because these objects have no information in Identity tables, we are not in a position to audit them properly. We should consider this a one time conversion of Alias information into AD objects and properties that configure Exchange Online. Going forward, all scripts, tools, and procedures used to generate departmental accounts and create their aliases should also manage their Contacts with the mail routing information.
Cleanup: If tools are created or converted to manage non-personal mail accounts, then we should consider establishing some proper rules and converting existing entries to match these rules. In particular, the practice of creating an Email Alias and a Dependent Netid and assigning ownership of the Alias to the person who owns the dependent Netid causes serious problems. People leave the university without transferring both the alias and the Dependent Netid to someone else. Then when their personal mail gets deprovisioned, the Secondary Alias for the group account remains attached to the inactive AD User object. The correct thing to do is the assign ownership of the Alias to the Dependent Netid that represents the shared mail account. The account can then stand alone, and if the owner fails to transfer the Dependent Netid to someone else, well the Dependent Netid is still active even if the former owner is inactive. This fix is not technically part of the Mail Relay project, but if we are fixing all the tools for this type of account we should fix this at the same time.
People with an Eliapps Primary Alias and a Personal O365 Secondary Alias
A Personal O365 Email Alias has a MAILBOX of “netid@connect.yale.edu”. 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.
| Code Block |
|---|
ALIAS_NAME TYPE MAILBOX NETID ---------- ---- ------- ----- morrow.long person morrow.long@bulldogs.yale.edu long jason.ignatius person jason.ignatius@bulldogs.yale.edu jsi3 kcm.campbell person kcm.campbell@bulldogs.yale.edu cjc243 (not a UserMailbox) stuart.teal person stuart.teal@bulldogs.yale.edu sbt3 yanick-noelle.aigbedion person yanick-noelle.aigbedion@bulldogs.yale.edu yoa4 (not a UserMailbox) samira.ataei person samira.ataei@bulldogs.yale.edu fa292 jeff.mandell person jeff.mandell@bulldogs.yale.edu jm3353 sam.seiff person sam.seiff@bulldogs.yale.edu sbs79 (delete alias samantha.seiff) bernardo.eilerttrevisan person bernardo.eilerttrevisan@bulldogs.yale.edu be244 (not a UserMailbox) elena.adasheva-klein person elena.adasheva-klein@bulldogs.yale.edu ea479 (not a UserMailbox) georgios.vasilopoulos person georgios.vasilopoulos@bulldogs.yale.edu vg284 |
...
georgios.vasilopoulos@bulldogs.yale.edu vg284 (not a UserMailbox) |
People with Eliapps Primary Alias, No O365 Secondary Alias, but are “UserMailbox” Recipents (have a mailbox) in Exchange
Exchange reported on the day the list was created that the following users have an O365 mailbox (their Recipient Type was “UserMailbox”). However, no Alias points to this mailbox. The Alias instead points to their Eliapps account.
Lets take cav7. The Primary Alias is claudia.villano with a MAILBOX of claudia.villano@bulldogs.yale.edu. Current affiliation is Staff, but you only get Eliapps if you were a student, so this is a former student who became Staff and was given an O365 account manually but the alias was never changed. Delivery here is the same as for Morrow. The Relays follow the Alias and deliver external mail to Eliapps, while O365 discovers that SMTP:claudia.villano@yale.edu is a ProxyAddress of a UserMailbox Recipient and delvers mail with the same address to O365. When the Mail Relays go away, external mail will start being delivered to O365.
This list is a lot longer than the five people with aliases, and each account has to be examined manually if we are to provide exact notification. Alternately, we could just bulk mail all the @bulldogs.yale.edu mailbox addresses in the list and tell the user that after the Mail Relay retirement date, all their mail will start arriving in O365 and if they don’t want that they should contact the Help Desk to delete their O365 account.
| Code Block |
|---|
ALIAS_NAME TYPE MAILBOX NETID ---------- ---- ------- ----- travis.zadeh person travis.zadeh@bulldogs.yale.edu tz237 thomas.langford person thomas.langford@bulldogs.yale.edu tl397 ben.kiernan person ben.kiernan@bulldogs.yale.edu magpie carol.hwang person carol.hwang@bulldogs.yale.edu chwang cynthia.farrar person cynthia.farrar@bulldogs.yale.edu cfarrar albert.laguna person albert.laguna@bulldogs.yale.edu al757 wayne.zhang person wayne.zhang@bulldogs.yale.edu wwz3 mark.gerstein person mark.gerstein@bulldogs.yale.edu mg269 richard.lalli person richard.lalli@bulldogs.yale.edu rl3 ivan.szelenyi person ivan.szelenyi@bulldogs.yale.edu is66 kusal.samarasinghe person kusal.samarasinghe@bulldogs.yale.edu kts34 victoria.misenti person victoria.misenti@bulldogs.yale.edu vlg8 william.hawkins person william.hawkins@bulldogs.yale.edu wbh24 richard.walser person richard.walser@bulldogs.yale.edu rwalser keith.corbino person keith.corbino@bulldogs.yale.edu kac64 jesus.yanez person jesus.yanez@bulldogs.yale.edu jy384 yong.xiong person yong.xiong@bulldogs.yale.edu yx44 wasim.sayyad person wasim.sayyad@bulldogs.yale.edu was35 rohan.gurram person rohan.gurram@bulldogs.yale.edu rkg33 nirag.kadakia person nirag.kadakia@bulldogs.yale.edu nk479 aman.khanuja person aman.khanuja@bulldogs.yale.edu ak2385 nicholas.ryan person nicholas.ryan@bulldogs.yale.edu njr33 j.zhang person j.zhang@bulldogs.yale.edu jz435 claudia.villano person claudia.villano@bulldogs.yale.edu cav7 kyle.vanderwerf person kyle.vanderwerf@bulldogs.yale.edu krv8 paul.wolfram person paul.wolfram@bulldogs.yale.edu pw379 kas.tebbetts person kas.tebbetts@bulldogs.yale.edu kt522 soumya.james person soumya.james@bulldogs.yale.edu sj484 megan.eckerle person megan.eckerle@bulldogs.yale.edu mme28 ronald.tricoche person ronald.tricoche@bulldogs.yale.edu rt347 craig.luekens person craig.luekens@bulldogs.yale.edu cal65 andrea.darif person andrea.darif@bulldogs.yale.edu ad566 saul.jaime-figueroa person saul.jaime-figueroa@bulldogs.yale.edu sj396 omer.mano person omer.mano@bulldogs.yale.edu om55 xinglin.lu person xinglin.lu@bulldogs.yale.edu xl294 mahmut.demir person mahmut.demir@bulldogs.yale.edu md762 andrew.currie person andrew.currie@bulldogs.yale.edu ajc82 libby.didomizio person libby.didomizio@bulldogs.yale.edu eed37 nathan.chang person nathan.chang@bulldogs.yale.edu nac53 ting.zhou person ting.zhou@bulldogs.yale.edu tz232 debra.houle person debra.houle@bulldogs.yale.edu dh462 daifeng.wang person daifeng.wang@bulldogs.yale.edu dw396 yotam.hadar person yotam.hadar@bulldogs.yale.edu ymh4 paul.berkowitz person paul.berkowitz@bulldogs.yale.edu phb8 fatih.celikbas person fatih.celikbas@bulldogs.yale.edu fc359 luyao.jiang person luyao.jiang@bulldogs.yale.edu lj275 michelle.yuen person michelle.yuen@bulldogs.yale.edu mcy6 jonathan.warrell person jonathan.warrell@bulldogs.yale.edu jw2394 timur.galeev person timur.galeev@bulldogs.yale.edu tg397 sara.smith person sara.smith@bulldogs.yale.edu sks25 melissa.lu person melissa.lu@bulldogs.yale.edu ml2453 jaeeun.song person jaeeun.song@bulldogs.yale.edu js2894 vishal.patel person vishal.patel@bulldogs.yale.edu vp276 wenjun.hu person wenjun.hu@bulldogs.yale.edu wh288 j.zhuang person j.zhuang@bulldogs.yale.edu jz472 tianliuyun.gao person tianliuyun.gao@bulldogs.yale.edu tg344 nat.irwin person nat.irwin@bulldogs.yale.edu nsi4 declan.clarke person declan.clarke@bulldogs.yale.edu dc547 arthur.lau person arthur.lau@bulldogs.yale.edu ajl74 kevin.lopez person kevin.lopez@bulldogs.yale.edu kl533 raymond.simpson person raymond.simpson@bulldogs.yale.edu rgs45 roger.desravines person roger.desravines@bulldogs.yale.edu rd557 rachel.renne person rachel.renne@bulldogs.yale.edu rr687 claudia.valeggia person claudia.valeggia@bulldogs.yale.edu crv7 eduardo.fernandez-duque person eduardo.fernandez-duque@bulldogs.yale.edu ef344 farren.isaacs person farren.isaacs@bulldogs.yale.edu fji2 sahand.negahban person sahand.negahban@bulldogs.yale.edu snn7 karihenkelmann.keyl person karihenkelmann.keyl@bulldogs.yale.edu kk544 john.henderson person john.henderson@bulldogs.yale.edu jh925 antonio.fonseca person antonio.fonseca@bulldogs.yale.edu ahf38 xing.wu person xing.wu@bulldogs.yale.edu xw358 tianxiao.li person tianxiao.li@bulldogs.yale.edu tl444 clinton.wang person clinton.wang@bulldogs.yale.edu cjw46 hatice.erten person hatice.erten@bulldogs.yale.edu hne2 lewis.golove person lewis.golove@bulldogs.yale.edu lg432 laurel.german person laurel.german@bulldogs.yale.edu lag48 mela.toro person mela.toro@bulldogs.yale.edu at549 andres.munozrojas person andres.munozrojas@bulldogs.yale.edu arm92 alberto.urcia person alberto.urcia@bulldogs.yale.edu au45 clare.staib-kaufman person clare.staib-kaufman@bulldogs.yale.edu cs2528 damon.clark person damon.clark@bulldogs.yale.edu dac77 jennifer.wu person jennifer.wu@bulldogs.yale.edu jw2282 jennifer.raab person jennifer.raab@bulldogs.yale.edu jcr42 marcus.alexander person marcus.alexander@bulldogs.yale.edu mam96 noah.planavsky person noah.planavsky@bulldogs.yale.edu np363 dhanusha.nalawansha person dhanusha.nalawansha@bulldogs.yale.edu dan44 leonidas.salichos person leonidas.salichos@bulldogs.yale.edu ls926 isaac.nakhimovsky person isaac.nakhimovsky@bulldogs.yale.edu isn2 chitra.ramalingam person chitra.ramalingam@bulldogs.yale.edu cr537 robyn.creswell person robyn.creswell@bulldogs.yale.edu rc698 basile.njei person basile.njei@bulldogs.yale.edu bn72 jacqueline.kisa person jacqueline.kisa@bulldogs.yale.edu jkk35 benjamin.schwartz person benjamin.schwartz@bulldogs.yale.edu bs843 shaoke.lou person shaoke.lou@bulldogs.yale.edu sl2373 steven.chou person steven.chou@bulldogs.yale.edu sc2493 sarah.luckart person sarah.luckart@bulldogs.yale.edu srl54 jacob.e.miller person jacob.e.miller@bulldogs.yale.edu jem263 joseph.goode person joseph.goode@bulldogs.yale.edu jbg66 ran.gu person ran.gu@bulldogs.yale.edu rg684 marilyn.mossien person marilyn.mossien@bulldogs.yale.edu mrm95 nikhil.malvankar person nikhil.malvankar@bulldogs.yale.edu nm563 terence.renaud person terence.renaud@bulldogs.yale.edu tr369 test2.infoed.ti7 person test2.infoed.ti7@bulldogs.yale.edu ti7 david.breslow person david.breslow@bulldogs.yale.edu dkb27 yannick.jacob person yannick.jacob@bulldogs.yale.edu yj242 susan.choi person susan.choi@bulldogs.yale.edu sc385 alyssa.dechiaro person alyssa.dechiaro@bulldogs.yale.edu ad949 imad.rizvi person ir99@bulldogs.yale.edu ir99 yat.wong person yat.wong@bulldogs.yale.edu yw629 xinyi.zhang.xz476 person xinyi.zhang.xz476@bulldogs.yale.edu xz476 rachael.roettenbacher person rachael.roettenbacher@bulldogs.yale.edu rmr79 killian.mcloughlin person killian.mcloughlin@bulldogs.yale.edu km2345 jennifer.nulsen person jennifer.nulsen@bulldogs.yale.edu jn535 a.scott person a.scott@bulldogs.yale.edu aas228 chenziyi.mi person chenziyi.mi@bulldogs.yale.edu cm2523 sebastian.lordadumont person sebastian.lordadumont@bulldogs.yale.edu ssl57 haoran.cao person haoran.cao@bulldogs.yale.edu hc685 jack.berry person jack.berry@bulldogs.yale.edu jrb248 mark.lisi person mark.lisi@bulldogs.yale.edu ml2622 brian.koopman person brian.koopman@bulldogs.yale.edu bjk49 avi.cohen person avi.cohen@bulldogs.yale.edu ajc259 ishan.negi person ishan.negi@bulldogs.yale.edu in49 yinan.chen person yinan.chen@bulldogs.yale.edu yc778 pranavateja.surukuchi person pranavateja.surukuchi@bulldogs.yale.edu ps938 yue.hu person yue.hu@bulldogs.yale.edu yh567 gabe.petrov person gabe.petrov@bulldogs.yale.edu gpp8 haven.herrin person haven.herrin@bulldogs.yale.edu hmh47 yixuan.tan person yixuan.tan@bulldogs.yale.edu yt355 yakun.zhou person yakun.zhou@bulldogs.yale.edu yz883 jacques.saarbach person jacques.saarbach@bulldogs.yale.edu js3973 emma.mckinney person emma.mckinney@bulldogs.yale.edu em873 michael.rader person michael.rader@bulldogs.yale.edu mr2542 ashley.arthur person ashley.arthur@bulldogs.yale.edu ala72 andy.knauer person ajk83@bulldogs.yale.edu ajk83 xiangyu.zhang person xiangyu.zhang@bulldogs.yale.edu xz527 ben.crair person ben.crair@bulldogs.yale.edu bec32 nicolas.maffey person nicolas.maffey@bulldogs.yale.edu nam87 charalampos.papamanthou person charalampos.papamanthou@bulldogs.yale.edu cp936 xuqiang.qin person xuqiang.qin@bulldogs.yale.edu xq43 sunny.yang person sunny.yang@bulldogs.yale.edu gy88 alison.sweeney person alison.sweeney@bulldogs.yale.edu as3822 chungsuk.choi person chungsuk.choi@bulldogs.yale.edu cc2858 makenna.hamilton person makenna.hamilton@bulldogs.yale.edu mh2539 chaofan.xu person chaofan.xu@bulldogs.yale.edu cx78 david.goerger person david.goerger@bulldogs.yale.edu deg38 ruifeng.sun person ruifeng.sun@bulldogs.yale.edu rs2623 juan.gambetta person juan.gambetta@bulldogs.yale.edu jpg68 caroline.chen person caroline.chen@bulldogs.yale.edu cc2766 junqi.wang person junqi.wang@bulldogs.yale.edu jw2675 fl428 person fl428@bulldogs.yale.edu fl428 ar2483 person ar2483@bulldogs.yale.edu ar2483 |
AD Daily Updater Bug Entries
There are around 1700 users who have only Eliapps Email aliases and who are regarded by Exchange Online as only MailUsers (that is, they are not UserMailbox entries and therefore have no Exchange mail account). The Legacy AD Daily Updater may have added incorrect smtp:netid@connect.yale.edu and smtp:first.last@connect.yale.edu proxyaddresses and values for msexchversion and three other msexch* fields. These should be removed, although they create no problems for the Mail Relay retirement project and are just incorrect data that should be cleaned up when the Legacy AD Daily Updater is retriedThe Legacy ADDailyUpdater code adds two ProxyAddresses “netid@connect.yale.edu” and “first.last@connect.yale.edu” to the 17,000 student Primary Eliapps User objects. These entries are misleading when viewed, but they have no affect on any actual mail processing and do not have to be fixed.
Exchange Online first looks at the type of User before looking at the ProxyAddresses. It discovers these users are of type “MailUser” (meaning they have no O365 mailbox and so mail passes through Exchange and is forwarded to what Exchange calls the ExternalEmailAddress (called a TargetAddress in AD).
This only confuses administrators and any Powershell script that makes decisions based on the presence of a “connect.yale.edu” ProxyAddress in the AD. We have had this problem for over a month and no ITS staff have noticed and complained, so it doesn’t have to be fixed now.
This cannot be fixed while the Legacy ADDailyUpdater is running because it will just put the bad data back in. After it is fixed or retired, a one time Powershell script should delete all these unnecessary ProxyAddresses.