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 are important from a system point of view, except for UPN which is an identifier to login to services.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). , but AD information is displayed in the Outlook mail client.
2. 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). This is a subset of the Mail Relay data currently affecting only O365 mail accounts, but while the Mail Relays 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 To accomplish this

1. This project will provision the same biographical fields

...

1. with the same data, only it will source this data from the

...

1. new IDR instead of the

...

1. old Oracle ACS1 database.

...

We have to plan ahead for expected changes that do not currently have a schedule:

...

1. We use this opportunity to alter certain business practices, such as excluding certain fields for SOM users from central administration.
2. This project will also create the same mail routing fields for current O365 users in the Local AD, although the current code was originally designed for On Premise Exchange and certain obsolete features will not be duplicated.

When this project goes live, it will begin to provide features that the old AD Updater did not have, in preparation for changes that are anticipated but do not currently have a target date.

• We currently have an On Premise Exchange system that serves no business purpose, but exists to not disturb incidental behavior required by various tools, including the old AD Updater. For example, the old updater did not believe you were an Exchange user unless the msExchVersion field in the AD was set to a non-null value, and that was controlled by the On Premise Exchange. The new code will ignore On Premise Exchange, which can the be decommissioned once other tool are updated.
• The Email Alias system generated configuration files for what are called the Mail Relay machines that sort incoming Email and forward it to Exchange Online (O365) or Eliapps. The new code will create a second set of configuration objects in AD (and Azure AD) that would allow Exchange Online to forward Eliapps mail to Google. After that, we can consider decommissioning the Mail Relays and transfer that function to Exchange Online. This project will enable but will not depend on the Mail Relay replacement.
• 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.

...

• may move to a SQL Server so we can eliminate our Oracle license costs.

The Email Alias system builds a table that says that "john.doe@yale.edu" is a mail address for O365 (designated as "jd234@connect.yale.edu") while "jane.doe@yale.edu" is a mail address for Eliapps (designated "jd235@bulldogs.yale.edu"). This information is used to configure the Mail Relays, who receive all mail first. They look up mail for "john.doe", find a pointer to "connect", and send it to Microsoft. They look up "jane.doe", find a pointer to "bulldogs", and send it to Google.

The AD User object for Netid "jd234" has to be provisioned with the email addresses associated with John Doe's Inbox. This has been and will remain an Updater function, and the new Updater will do exactly the same thing as the old updater for normal personal mail accounts. Previously Eliapps mail information existed in the Alias Table and the Mail Relays, but it was not put in the AD. This project will build in the AD User object of Eliapps users the same data structures to identify their Email addresses, but as long as the Mail Relays are still functioning, this data will not be used to route incoming mail. When the Mail Relay function is transferred to Microsoft, then these latent data structures will become active and will be used to send mail through Exchange Online to Eliapps.

One difference is that the Mail Relays treat O365 and Eliapps equally. Exchange Online, however, is mostly a system to deliver mail to its own mail accounts, although it will forward mail to Eliapps or other external mail 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 itdelivers mail to an O365 Inbox if it can, and only forwards it to Eliapps if that is not possible. Because of poor configuration practices and a failure to follow Yale policy, there is data in the current Mail system that is ambiguous. For example, Exchange Online has certain built in Email Addresses that cannot be turned off, particularly those associated with the Primary Email AliasName. The Mail Relays would send mail to Eliapps if the Alias Table pointed to it, but in some cases Exchange Online will match one of these built in mail addresses and deliver the mail to O365 instead. Some users will have to reconfigure their Aliases to preserver current behavior. This is an Exchange issue we cannot control, so the Updater code will ignore these problems and they will have to be addressed by the subsequent "Retire the Mail Relays" project.

There are a set of Yale and Exchange rules. We can't change the Microsoft rules, and we are not prepared to change Yale rules established long ago. Enumerating the rules explains exactly how and why certain mail routing will change.

...