Content Comparison

...

1. The AD Daily Updater, a Java program driven by the Oracle ACS1 database, which populated a select set of "biographical" fields (firstname, lastname, job title) in the AD for non-private people. None of these fields were important from a system point of view, except for UPN which is an identifier to login to services.
2. The Mail Relay configuration, which maps Yale Email Aliases (where all the mail ends in "@yale.edu") to a "native" Email system suffix that distinguishes the specific mail system for that account  (ending in "@connect.yale.edu" for O365 or "@bulldogs.yale.edu" for Eliapps). 
3. The A separate function embedded in the AD Daily Updater Java jar file that enforces a standard set of Exchange mail routing fields in AD (MailNickName and ProxyAddresses). Once This is a subset of the Mail Relay data currently affecting only O365 mail accounts, but while the Mail Relays sent mail to Exchange/O365, each piece of mail had to be delivered to a specific Inbox. Microsoft mail configuration is stored in the AD, and these two fields determine all the different email addresses that might be delivered to the same Inbox.

...

1. answer the question "What Mailbox does this Mail Alias point to", the Exchange Mail Routing is provisioned with the equivalent reverse answer "What Aliases are delivered to this Mailbox".

The new code will provision the same biographical fields of AD, but they will now gets get the data from IIQ the newer IDR instead of the old older Oracle database. It prepares for the retirement of the Mail Relay system by populating the Email Routing fields in AD with data for both O365 and Eliapps instead of just O365.

...

• The on premise Exchange system exists only to support system tools that use it. The old AD Updater depended on it and is one of the things that had to change before we could decomission something that performs no real business service.
• The Mail Relay machines will at some point be decommissioned and the Exchanged Online function in the Azure Cloud will take over routing all mail addressed to an "@yale.edu" Alias. Since Exchange Online is configured by Azure AD in essentially the same way that on premise Exchange was configured by on premise AD, we have to add ProxyAddresses to some AD object (User or Contact) for Email Aliases that point to Eliapps (and a few legacy departmental servers)departmental servers).
• The Email Alias system is currently one table (SMART.DIR_ONLINE_INFO) and a Package of code in the SMART schema of the Oracle ACS1 database. At some time this function may move to a SQL Server so we can eliminate our Oracle license costs.

The Mail Relays translate any given "@yale.edu" Email address to some system specific address. They are even handed and treat O365 and Eliapps equally. Exchange Online, however, is mostly a mail delivery system that system to deliver mail to its own mail accounts, although it will forward mail to Eliapps or some other external mail system systems, but only in the event that it cannot be delivered to any internal O365 mailbox. When a user has both O365 and Eliapps accounts, the "bias" that Exchange Online has toward O365 will result in some mail being delivered to the O365 Inbox that the Mail Relays would previously have been delivered to Eliapps. There is a structural feature of the Microsoft system and we cannot work around it. Other than this limitation, we design the new code so that every piece of mail will be delivered by the new system to the same location where the old system sent it.

...

• It is an AD rule that every User must have a unique UserPrincipalName. The UPN can be used to login to Windows and must be used to login to Azure.
• It is a Yale rule that for Users with a mail account, the Primary Email Alias (first.last@yale.edu) is also the UserPrincipalName. The ALIAS_NAME (before the "@") is the MailNickName (first.last). For Users marked Private the ALIAS_NAME is the Netid, and for old accounts after the date where they are supposed to be deleted, the ALIAS_NAME is also set to Netid to free the first.last for new people .It is a Yale rule that everyone with an ITS mail account (O365 or Eliapps) must have a Mail Alias that points to that account. As a result, the Email Alias table provides a complete list of Yale mail accounts in both systemswho happen to have the same name.
• It is an Exchange Online rule that for Users with an O365 mail account, the UPN has to be a deliverable Email address to that account. With Mail Relays, the UPN can point to either O365 or Eliapps, but if Exchange Online does all the mail routing, any mail addressed to the Primary Email Alias (which is also the UPN) will go to O365 if there is an O365 mailbox even though the Email Alias table points the Primary Email Alias to an Eliapps account.
• It is an Exchange Online rule that the same Email address cannot be in two ProxyAddress lists of two Azure AD objects. So if we create a Contact object for the Eliapps account, we cannot add the Primary Email Alias to it, and if that is the only alias that points to the account, we cannot meaningfully create the Contact in the first place.

Yale policy is to give users either O365 or Eliapps mail but not both, but exceptions are allowed. Yale policy is that when a user has both O365 and Eliapps mail, the O365 account is Primary. So if we followed our own rules there would be no problem. Unfortunately, either because accounts were "grandfathered" in from previous systems or because someone important asked for an exception, there are a handful of about 5 cases where the Primary Email Alias points to Eliapps but that address will begin to deliver outside mail to O365 after we decommission the Mail Relaysand there is a secondary alias pointing to an existing O365 account. We will have to remediate these users.

This is not an AD Updater problem. It is a Mail System restriction that we cannot program around and will be ignored by the coding. We will do what we can do. There are ways to change the Email Aliases with Dependent Netids that can work around the problem, but that again is an Email System trick and not part of this project. However, understanding how mail delivery is done and how it changes is important to understanding the design, and this particular glitch is a useful example to motivate a description of the environment to which this code must be designed.

...