Content Comparison

...

It will not be possible to exactly match the accidental quirks of current two tier mail routing. However, a person can continue to own both an O365 and Eliapps mail account and can continue to route mail addressed to his Primary Email address to the Eliapps account. You can even retain your Email address in Yale directories. However, to do this you need to create a Dependent Netid to own your O365 mailbox, and then someone has to swap your current AD User object (that is connected to your mailbox) for the Dependent Netid User object renaming the CN and SAMAccountName that connect the User object to the Netids. We may do this for a handful of important people, but that is all.

Both the current AD Daily Updater and the current Mail Relay configuration program get the same mail routing data from the Email Alias system (the SMART schema in ACS1, and in particular the SMART.DIR_ONLINE_INFO table). AD Daily Updater only uses the Exchange subset of the data, but this will change in the new code where the non-Exchange data will also be added to AD. The TargetAddress field is not used for Exchange mail accounts, but will point to the native email account address (the MAILBOX field of the Email Alias table) for non-Exchange AD objectsExcept for the problem described above, every current Email Alias entry should be routed through Exchange Online to the same destination that the current Email Alias table configures and the current Mail Relays implement. This is accomplished by one of four AD configurations:

1. If you have a Primary O365 mail account, your AD User object on premise and in Azure AD should be unchanged. Some minor adjustments to unimportant fields may be made in anticipation of the decommissioning of the on premise Exchange.
2. If you have a Primary Eliapps account, then your AD User object will be configured so there is a ProxyAddresses entry for every Email Alias that points to that Eliapps account, and a TargetAddress that holds the native "@bulldogs.yale.edu" address of the account in the Google G Suite cloud.
3. If you have both a Primary O365 account and a Secondary Eliapps account, then a new AD Contact object will be created with the Eliapps routing information. The AD User object will continue to have its current data. The Contact object will have the same ProxyAddresses and TargetAddress data that would be configured in the User object had this Secondary account been Primary.
4. Any additional entries in the Email Alias table will generate Contact objects, where the TargetAddress will be the MAILBOX value of the Alias table and the ProxyAddresses list will be the ALIAS_NAME values that share that MAILBOX value.

A given user can own special Alias entries, and therefore can have any number of Contacts generated by option 4 in addition to a User object and perhaps a special Contact object under one of the three options from 1 to 3. An O365 mail user can add a Secondary Eliapps account and go from option 1 to option 3, or drop an Eliapps account and go from 3 to 1. In the special case where someone with both an O365 and an Eliapps account decides to drop the O365 account and promotes Eliapps from Secondary to Primary, then option 3 changes to option 2, but this requires special handling to make sure the AD User object is first cleared of all data from the deleted O365 account before the routing fields can be moved from the Contact to the User object (and the Contact can be deleted).

Some cleanup of the Email Alias table will be required. For example, it has been a convention of the AD Daily Updater to create ProxyAddresses entries for both "Netid@connect.yale.edu" and "AliasName@connect.yale.edu". In a few cases there are Email Alias table entries for two aliases owned by the same person where one MAILBOX points to "Netid@connect" and the other mailbox points to "AliasName@connect". All the MAILBOX values for "AliasName@connect.yale.edu" must be corrected so the aliases can be collected and correlated to the Netid.

The Mail Relay configuration data was just a table that translated every Email Alias address ("@yale.edu") to a native address ("Netid@connect.yale.edu" for Exchange, "AccountName@bulldogs.yale.edu" for Eliapps). The AD Updater had to take the same data but assign Exchange users to an AD User object. You might think that this assignment would be done using the NETID column (the owner of the alias) but a few Netids directly own Aliases that point to Dependent Netids (including group accounts) where the mailbox is actually under a different AD User object. So the only reliable way of correlating Email Alias data to IIQ Identities (and AD User objects) is to group aliases that have the same MAILBOX value and look for the Netid as the value in front of the suffix "@connect.yale.edu". Mailboxes with other suffixes are Eliapps or legacy aliases, and for them the Netid that owns the Alias is information, but the correlation rule is more complicated and will be described later.

...