...
Provisioning Strategy (Email Routing fields)
The While the Email Alias table is converted by a SQL View into a result with one row ("Account" in IIQ terms) per MAILBOX value. The SQL generates flags to indicate Primary or Secondary status for the mailbox and whether an Eliapps mailbox is preempted because there is also an O365 mail account for this Netid. These accounts correlate to the Netid Identity (and the AD User object) or to a Contact Identity (and an AD Mail Routing Contact).
The calculation of the three Email Routing variables (ADMailNickName, ADProxyAddresses, ADTargetAddress) is the same for Netid and Contact Identities. Netid Identities provision the User object while Contact Identities provision the Contact object.
Contact Identities exist solely for the purpose of holding Email Routing information. We create them when we get a new MAILBOX we have not seen, and we delete them when that MAILBOX disappears from the Email Alias table. In IIQ terms, the subset of data read in from the Email Aliases that relates to Eliapps and Junk Contacts should be "authoritative" (creating an Identity object if no existing Identity exists).
Netid Identities already exist in IIQ and are created by a Source of Identity. Once they exist, AD User objects correlate to them, and Mail Alias Email Routing information correlates to them, and then the Email Alias data populates the three Identity Variables and provisions the AD User object. For this subset of the data it appears to be a really bad idea to create a new Netid Identity because of something that appeared in the Email Alias table before we see the really authoritative information from an SOI or from the Dependent Netid system.
The SQL View that creates the data for the Email Alias Email Routing Application will filter out O365 alias data for a non-Netid O365 account (mostly resources like rooms, lists, etc.). It will only present data for Netids that are in the Netids table. However, Mail Routing data has to be directly aggregated from the database with the Email Alias and Netid systems, while SOI information comes through the StagingDB populated by Talend jobs and could in theory lag slightly behind.
Therefore, it seems safest to wait until the Netid Identity is created by the current SOI logic and only process Mail Routing data for Netid Identities (for AD User objects) after those identities are created, while Mail Routing data for Contact Identities are processed immediately.
To make this work in IIQ, we need two different Applications. One Application gets in the subset of Mail Routing data that should correlated to Netid Identities and it will be flagged as non-authoritative, where the data is discarded until the Identity is created by the existing logic (SOI aggregation). The other Application gets the rest of the Mail Routing data that should correlate to Contacts, and it will be an "authoritative" application that immediately creates Contact Identities if none exists (because there is nothing else that will create them).
If we do not split this up, there will be in theory a short period of time when the Identity Cube held what claimed to be a Netid Identity with no SOI and with most of its data missing, and checking the existing code for some resulting regression error would be an intolerable amount of work. The two Application solution makes this kind of error impossible, which is better than the plausible argument that the timing of identity creation means that this theoretical chase condition is highly unlikely or almost impossible.
So in summary:
Netid Identities are created by the existing IIQ process from SOI or IDRIdentities. After the existing process creates a Netid Identity, the LocalAD User object can correlate to it and the Email Routing data that the SQL View has classified as related to the User object can be correlated. Once the Email Routing data has been read we populate the three Email Routing Identity Variables, and once the AD User object account correlates it will be updated with the values from the three fields.
Contact identities are created or deleted solely based on Email Routing data that the SQL View has flagged as relating to a Contact. Unlike Netid User objects (which can be created by Grouper and other programs), the Contact objects we provision exist only in our own OU and are never created by any other process. Contact Mail Routing data is aggregated, correlated to an existing Contact Identity or creating a new Contact Identity, and then existing Contact objects in AD are updated or new Contact objects in AD are created using standard IIQ AD provisioning.
Because the ADProxyAddresses field is multivalued, we will add code to make sure that it does not get reprovisioned if the same set of values is presented in a different order (this may be unnecessary if IIQ is already doing it). usually viewed by the Netid of the alias owner, provisioning has to go into an AD object associated with the mail account (the MAILBOX value). So this code develops views that group aliases and produce one row for each MAILBOX value. In this approach, the O365 account for a Netid is the row with MAILBOX value "Netid@connect.yale.edu". Rows with a non-Netid before "@connect.yale.edu" a distribution lists, rooms, and other resources that are currently out of scope.
The Eliapps accounts do not have a Netid, so here there is a different rule. If a Netid owns a Primary Email alias pointing to an Eliapps account ("@bulldogs.yale.edu") and there are no other aliases pointing to a "Netid@connect.yale.edu" account, then this is a pure Eliapps user and the mail routing fields can go in the AD User object associated with the Primary Alias owner. Here we have a bit more freedom, because while routing for an O365 account MUST go into the AD User object to which the account is tied, an Eliapps account can be described by either an AD User or Contact object, and our decision here to use the otherwise unused User object is simply an optimization.
Therefore, any Eliapps account that fails the tests to put it in the User object will end up in a Contact, along with Departmental Eliapps accounts and Legacy "junk" alias to neither O365 or Eliapps.
The SQL converts the entries for all Aliases that point to the same mailbox to a string of AliasNames. By sorting the Primary Alias first (if it exists) and setting the first name to have an "SMTP:" prefix and the subsequent aliases to have an "smtp:" prefix, we satisfy the rule that every ProxyAddresses string must have one primary (capitalized) entry and it should be the Primary if one exists. By doing this work in the database, where sorting rows is easy, we avoid the problem of dealing with multiple account records from the same application, which IIQ can handle but which greatly complicates the coding.
There are three database views. One returns the O365 Netid mail routing data. A second returns the Primary Eliapps mail routing for non-O365 Users (which also goes in the User object). The last view returns routing data for Contact objects. The first two views provide the SAMAccountName of the User object to which the data should be attached, while the last returns only the MAILBOX and not a Netid, because Contacts are generated and managed relative to the MAILBOX name.
The MailNickName is used by Exchange Online to route mail, but we do not set it based on its routing properties. Rather, the MailNickName is by Yale Policy set to the Primary ALIAS_NAME, which is also the prefix (before "@yale.edu") of the UserPrincipalName. That policy effectively makes MailNickName a "biographical" field because it is set by biographical rules. However, because of Exchange algorithms, we only want to set MailNickName in the User objects of Email users. So while the value is calculated biographically, the biographical value is only copied to the ADMailNickName field if we have O365 or Eliapps-in-User-Object mail routing view data for that SAMAccountName.
Contact objects are created and deleted for the sole purpose of holding Mail Routing data. So the Application that reads from the Contact view is "authoritative", creating new Contact Identities when a new Contact MAILBOX value appears, and deleting Contacts that are no longer supported by any linked Account. However, User objects are already created by other processes, and since the User object must exist for an O365 account to exist, it makes no sense to create a User object for the purpose of putting in Mail Routing for an O365 account that cannot exist because there is no User object. So the application that feeds Mail Routing information (for both O365 and Eliapps) is not authoritative and waits for the User object to be created by the Identity Management IIQ instance before the data is linked to the Netid Identity object and the fields are provisioned. The difference between authoritative and non-authoritative behavior is the main reason for splitting the Email Routing data into two IIQ Applications.
So in summary:
Netid Identities are created by the existing Identity Management IIQ process from SOI or in Email Provisioning from IDR Identities.
In Identity Managment, the LCM "Joiner" workflow assigns a Netid and UPI to the identity, and a Role Assignment Rule grants the Identity an Entitlement that will cause the AD User object to be created. When the LocalAD is next aggregated, the AD User object is read in and linked to the Identity.
When the Email Provisioning IIQ instance creates the Identity when it gets a new Netid from IDRIdentities. At that point it can correlate the LocalAD User object and the MailRouting-In-UserObject account with a matching SAMAccountName.
It doesn't matter if the MailRouting data arrives before or after the LocalAD User object is aggregated. IIQ will wait until there is a LocalAD object before provisioing the ADXXX Identity Variables to their target properties.
Meanwhile, Contact Identities will be created based on the aggregation of the Contact Mail Routing Application. A Contact Identity automatically gets an Entitlement that creates the Contact Object in AD, and then the Mail Routing variables are synched in.
The view presents ProxyAddresses in an order, Primary Alias first, then Secondary Aliases in alphabetical order. We will test for and write code to prevent any unnecessary reprovisioning of the ProxyAddresses if the calculated and aggregated values contain the same values, but the "smtp:" values are in a different order (unless IIQ variable synchronziation already does this).
Mail Relay Replacement
Currently all mail with an address ending in "@yale.edu" is processed by the Mail Relay machines at Yale. They are configured (once an hour) from the data in the Mail Alias system, where is unique MailAliasName+"@yale.edu" is resolved to a native Mail system address (the Mailbox). If the Mailbox is "netid@connect.yale.edu" then this is an O365 address to be processed by Exchange Online. If it is "@bulldogs.yale.edu" then it is an Eliapps account to be processed by Google. In all other cases, the Mailbox address substitutes for the original "@yale.edu" and is processed through SMTP.
...