...
Any user can have Junk, so while each mail user Netid is either Case 1, 2, or 3, they can also have any number of Type 4 entries. Type 4 is grouped by MAILBOX and correlated to a Contact identified by the MAILBOX. It is not connected in any way to the Netid that owns the Alias. The junk aliases are spread across mailman, elilists, panlists, cs, som, aya, invest, med, physics, chem, geology, cmp, math, astro (all .yale.edu). Some of this is obsolete, but cleaning it up is future scope.
Users with an O365 or Eliapps account can delete it, and users with one type of account can get the other. So you can transition between Type 1 and 3, or 2 and 3. This is a delicate process because IIQ cannot directly move a field like ProxyAddresses from a User object to a Contact object in a single transaction (as would be possible with database SQL). This is, however, a manual process and becomes a function of the Mail System people. This code does not provide transition services but will provide documentation about how to make the transition correctly. There are 555 Primary Email Aliases in the Alias table where the MAILBOX is "first.last@connect
Once you understand the four possible "packages" of mail routing data, the mechanism for gathering the data and passing it to IIQ is relatively simple. A SQL query of the Alias table (DIR_ONLINE_INFO) groups rows by MAILBOX. The AliasNames of the same MAILBOX are concatenated together in a string field. If the MAILBOX is "@connect.yale.edu" instead of "netid@connect.yale.edu". These have to be fixed for the new code to work.There is bad data in the Alias table which will have to be cleaned up. For example, some O365 users have a MAILBOX value that is not "Netid@connect.yale.edu" and alternate names for that MAILBOX have to be changed to the proper value in order for the grouping to work correctly. Bad data that represents aliases to mailboxes that no longer exist may or may not be cleaned out (the mail would have bounced before and will bounce after, although the exact way it bounces may change)it is O365, if it is "@bulldogs.yale.edu" it is Eliapps, and if it is something else it is junk. The trick is then to create SQL clauses that flag primary accounts from secondary accounts, and distinguish Eliapps account that exist alone from Eliapps accounts belonging to someone who also has an O365 mailbox which have to be then assigned to a Contact. If we don't do this processing in SQL where it is easy, it becomes much more difficult in IIQ to know if an incoming Eliapps account record belongs to a Netid who also has an O365 record and therefore correlate it to or create a Contact Identity. If the SQL view has already done that analysis, IIQ can implement the correlation that the SQL has pre-processed.
There is some malformed, obsolete, or broken data in the Alias table. The code will be robust against data errors and not allow them to interfere with the mail delivery of properly configured addresses. However, if the Alias table currently contains an Alias that points to a non-existent email account, and the new code discards that alias because a bad MAILBOX value means there is no object to which the aliases can be attached, then mail to the same bad alias will still bounce, but it will just bounce differently.
We synchronize the on premise Local AD to the Azure AD. IIQ must provision changes to the Local AD and wait for the synchronization to occur within the next half hour. The only field in Azure AD that can be provisioned directly is UPN.There are 1800 Junk Email Aliases that do not resolve to O365 or Eliapps. They are spread across mailman, elilists, panlists, cs, som, aya, invest, med, physics, chem, geology, cmp, math, astro (all .yale.edu). Some of this is obsolete, but cleaning it up is future scopethe synchronization to occur within the next half hour. The only field in Azure AD that can be provisioned directly is UPN.
There are existing Contacts created in AD to make specific Eliapps users visible to Outlook. These "non-routing" Contacts have a biographical (non routing) "mail" attribute and not much else. We will not create or delete these objects, and we will attempt to make Routing Contact objects invisible to OutlookContacts tend to be in the Users container, they are named by the Primary Email Alias, they have "biographical" data, and they do not have anything in the three mail routing fields. The new Contacts we create will be in a special OU, will be named by the MAILBOX, will not have "biographical" fields, and they will have mail routing properties. A given Eliapps user may have one of each type of Contact, but this code only generates the Mail Routing Contact and ignores the other type.
Assignment of Functions to Instances
...