When IIQ Birthright Email Provisioning was written there was a long sequence of tests and steps that were required. Over the last five years, however, some of the tests have been relaxed and some processing has been moved elsewhere.
The Identity Management IIQ (which shares Java code with Email Provisioning) now calls some of the code written for Email Provisioning when it assigns a new Netid. Specifically, it creates an AD User object and it reserves an Email Alias.
The Azure AD Connector (“directory synchronization”) process now assigns required information in new Azure AD objects that were previously ignored.
Licenses are now assigned by “group-based provisioning” managed by Grouper.
Email Provisioning IIQ now has to update Email routing fields of AD, so it now aggregates identity data with affiliations MEMBER and AFFILIATE in addition to the previous affiliations entitled to Brighright mail (STUDENT, FACULTY, STAFF, and EMPLOYEE).
After these changes, the Email Provisioning instance of IIQ can be easily changed to assign O365 Email to new SIs and Academic Affiliates based on setting some flag in a database or directory.
Birthright Email processing was written to assume it processes new users. Subsequently we have discovered that it can be fooled by old users who leave the university for a while and then return. Although this was not part of the original design, Birthright processing is robust enough to handle these cases.
When an Identity has no current affiliation (except ALUM), it drops out of the IDRIdentitiesView and is deleted from the Email Provisioning Identity Cube. If the same person then gets a new Affiliation they appear to be a new user and are evaluated for Birthright mail.
If the user previously had an O365 mail account and it is still active, then Birthright processing will clean up any missing attribute values and reuse the old account.
If the user previously had Eliapps mail but now is entitled to O365, then an O365 account is created. The old Eliapps account is left alone.
If the user was deprovisioned then Birthright Email has no logic to undo that processing. It generates a report of processed users and displays the deprovisioned flag in AD. The reports are retained for a week, so I can read them and manually run a Powershell script to fix anything that normal Birthright process does not correct itself.
This is not changed if we modify Birthright processing for people with Sponsored Identity or Academic Affiliate Affiliations. If they were never previous Yale users then they get Email cleanly. If they previously had mail, even if that mail was deprovisioned, then any new Birthright processing we create for an AFFILIATE or MEMBER who has some sort of residual mail account is the same as Birthright processing we already do today had the same person returned as an employee.
If a former STUDENT graduates and someone is using SI to extend their grace period, they should not be given the proposed new special mail processing. They already have mail. If you give them the proposed new processing, then an Eliapps student will be given O365 mail and will stop receiving mail in their Eliapps account.
Changes
The 5:30 AM Sequential Task
This job aggregates IDRIdentitiesView, the LocalAD, and the Email aliases in StagingDB. Today the IDRIdentitiesView selects all identities whose PrimaryAffiliation is not NULL or ALUM. The aggregations do not need to be changed unless the flag that triggers special processing for SIs and Affiliates is in a new source not currently being aggregated.
It then runs a refresh task that executes the “Netid” Role Selector Rule against all Identities. This Selector Rule assigns the “Netid” Role to identities entitled to Birthright mail, but only for the period of time while some preliminary requirements are being met.
However, all the requirements are now being handled somewhere else. In particular, a new Netid Role was added to the Identity Management IIQ to reserve a Primary Email Alias and create an AD User object. Any Identity that could be processed at 5:30 AM will have been created by or before the midnight Full Aggregation in the other IIQ. So by the time this task runs the alias is already reserved, the AD object is created, and the Azure AD object was synchronized.
The Netid Role processing is therefore redundant, but it has not been removed. It should find nothing to do, but it is still useful to verify that all the prerequisites are met and initialize a few fields in the current Identity.
This Rule needs to be changed so it does not reject someone with Affiliation of MEMBER or ASSOCIATE when some flag is set indicating this Identity requires special processing.
The 7:30 AM Sequential Task
This job runs two hours after the first job to allow time for changes to the AD to be synchronized out to Azure AD. In current practice, this will probably have happened already sometime after midnight.
The EmailTypeRoleSelector Rule evaluates Identities that are members of an IIQ Population (essentially a query against the Identities). The Population query can be adjusted to include MEMBER or ASSOCIATE uses who have the special processing flag set. The code does not check Affiliation because it relies on the Population to filter users who need processing.
Now that Licenses are being assigned based on AD Group membership, this task does two things:
Enable-RemoteMailbox for anyone entitled to O365 Mail.
Create an Eliapps account (Mail or NoMail) for undergrads and grad students in schools that use Eliapps.
Since the existing code assigns O365 mail to anyone who is not a STUDENT with an appropriate School Code, nothing needs to be done to give MEMBER or ASSOCIATE an O365 mail account.