...
Provisioning Strategy (Email Routing fields)
The Email Routing ADXXXX variables are calculated from the Account generated by aggregating the Full Email Alias table , an application that is only defined in the Email Provisioning instance. They also only have Target definitions and only update the LocalAD in that instance. The same variables have neither a source nor a target in Identity Management.
Because ADProxyAddresses is a multivalued field, we want to avoid updating it if the only difference between the current value in AD and the calculated correct value from the Email Alias table is to list the same values in a different order.
Dependent Netids and Contacts can own or describe Email accounts, so they do have ADMailNickName, ADProxyAddresses, and ADTargetAddress fields that must be calculated and, if necessary, provisioned.
However, correlating the Email Alias data to the right Identity cannot be done on the fly in IIQ. We rely on a database view to present the data in the right order. So most of the work is done in the database, and a little work may be done in the correlation rule.
Unlike the previous AD Daily Updater Java program, IIQ will create AD User objects for Identities that need them.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).
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.
...