...
The Netid and Email Alias are now created by Java code in the Identity Management IIQ instead of Oracle stored procedure calls. In both cases uniqueness of the identifier is guaranteed by a unique key constraint on the database table, with a retry for another identifier if an error indicates a duplicate value.
There is a rule that an O365 account cannot be created until the Azure AD User is assigned a region (of the world) in which to store the mail. The Windows AD Connector was changed to set the region of all users to “US” when the Azure AD User object is first created from the Local AD object.
O365 Licenses are now assigned by “group-based provisioning” managed by Grouper.
The Email Provisioning IIQ creates identities from a view on the IDRIdentities. Originally that view only included affiliations entitled to Birthright mail (STUDENT, FACULTY, STAFF, and EMPLOYEE). However, when the AD Daily Updater was replaced it became necessary to extend the view to include the other affiliations (MEMBER and AFFILIATE) that might have a mail account. So today there is already an Identity object in that IIQ instance for everyone who might request a mail account.
As a result of these changes, all the preparations are already coded, and all that needs to be changed now is to define an indication that an Email account be created for a MEMBER or AFFILIATE and then to assign the IIQ Role that creates an O365 account.
The Email Provisioning instance of IIQ still double checks each prerequisite before processing a user, its daily reports and special reporting will show a user who has entered processing and not completed. This will alert IAM personnel to investigate and find out what is wrong.
Since SI and Academic Affiliate users are now in its identity database, all that is needed for IIQ to provision mail is an indicator that a request has been made and approved. This indicator could be a column in a StagingDB table that gets aggregated, or it could be a Global Variable in the IIQ identity object. This indicator is then added to the variables examined to decide which identities should be given mail accounts.
Email Provisioning is not a Workflow triggered by an event. It processes identities that evaluate to being mail-entitled but have not yet had a mail account created (as represented by the EmailAddress variable of the identity which is set when the Primary Email Alias has a Mailbox value). If a new request is created and approved, but when it arrives at Email Provisioning the user already has an EmailAddress then the identity will not enter processing in the first place and the request will be treated as complete without any processing.
No substantial new logic is required. The new processing for MEMBER or Affiliate requests will be the same as current process for a user who previously had no affiliation but has just become an EMPLOYEEAFFILIATE who requests mail is essentially the same as would be the case if instead that person was hired as an EMPLOYEE and received the mail account with the current processing, except that Yale may decide not to create a NoMail Eliapps account .If the user already has an active Email account represented by a Primary Email Alias with a non-null Mailbox pointer then, although nothing will be done, the request will be regarded as satisfiedfor MEMBER and AFFILIATE requests while such an account is always created for EMPLOYEEs.
Otherwise, IIQ will do two or possibly three things:
It will call Enable-RemoteMailbox on the Netid which updates the Local AD and Azure AD object, sets the UPN, mail, MailNickName, and some ProxyAddresses values in Azure. This operation can fail if the Mailbox already exists, but in this case there is nothing to do.
For Birthright Entitled users IIQ would create a NoMail Eliapps account. This processing may be skipped for these new requests depending on the requirements we are given.
It will change the reserved Email Alias to have a Mailbox of netid@connect.yale.edu and an EmailTo of aliasname@yale.edu which in turn will set the Email Address in IDR and the directories.
...