...
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 create store the mailboxmail. 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 change extend the view to include the other affiliations (MEMBER and AFFILIATE) that are associated with a source of identity and might have a mail account. So currently today there is already an Identity object in that IIQ instance for everyone who might request one of these special mail accounts.
So while there might have been a lot of work to do when the original Birthright code was written, today all the requirements are met and we already have all the data we need.
We must add some column to some Staging Database table to indicate users with a pending new request.
Assumption: If a user already has a personal email account (a non-reserved Primary Email Alias) then we do no processing.
Assumption: The a user already has a Remote Mailbox (in local AD) then we will set the Reserved Primary Email Alias to indicate an O365 account but otherwise do no more processing. This may be a deprovisioned user, but reversing a deprovisioning operation is a manual step now for current Birthright users (like employees) and these new users will be handled in the same way.
Assumption: These new requests will get an O365 mailbox. It is yet to be determined if a no-Mail Eliapps account will be created or nothing will be done in Eliapps.
Assumption: Grouper will be changed to put these users in a group that will receive the right type of O365 License.
IIQ will do the following things:
Enable-RemoteMailbox 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 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 EMPLOYEE, 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 satisfied.
Otherwise, IIQ will do two 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. Change This operation can fail if the Mailbox already exists, but in this case there is nothing to do.
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.
...
Even though the user lost affiliation, the old Email account may have remained active and the Email Alias still points to it. If that is true, then a new Identity object created from a new affiliation/SOI will already appear to have mail and user still has an Email Address. When a new affiliation is assigned to this Identity, it will not enter Birthright processing . If because the Email Address indicates there is no active Email Alias (with a Mailbox pointer), then Birthright begins processing. It decides if the user should get O365 or Eliapps based on the current affiliation before it looks for old accounts. Currently: If the new affiliation is STUDENT and the user would get Eliapps mail, then IIQ will try to provision that configuration. It will do nothing to O365 and try to create a new mail-enabled Eliapps account. It will then set the Email Alias Mailbox to Eliapps. If there is no O365 mail account, everything will work. However, if there is an O365 mailbox then Exchange Online will not allow the Email Alias change to have any effect. The Primary Email Alias is the UPN no matter what the alias points to. If an account has an O365 mailbox, Exchange won’t allow the UPN to point to any other mail account. Since it processes all mail coming into Yale, it will snag all mail for the user and put it in the O365 inbox no matter what the Alias Table sayswork do be done.
Without regard to the status of the mail account in O365 or Google, if the Primary Email Alias has a null Mailbox (the alias is “Reserved” rather than active) then Birthright processing begins as if the user has no mail. In some cases it will detect that a step has already been performed and skip it. In other cases it will perform a “create” operation that fails because there is already a duplicate account.
Since Birthright processing first assigns a type of mail based on affiliation, if the user is currently a student in a School that gets Eliapps, an attempt will be made to create a mail Enabled Eliapps Google account. Such an account will be named by the Primary Email Alias (firstname.lastname@yale.edu). NoMail Eliapps accounts would have been named netid@yale.edu and therefore may not be seen as a duplicate. However, now that the Mail Relays no longer exist and all incoming mail goes through Exchange Online, if the user has an O365 mailbox at all, then all mail will be delivered to O365 and the Eliapps account will never receive anything. The user will also have confusing directory entries. Exchange Online will insist that some Azure AD for Email Addresses be set to point to the UPN, which in turn is set to the Primary Email Alias. Therefore the Alias and Local AD entries will indicate Eliapps mail while the Azure AD and Exchange will indicate O365 mail. This user may now be broken and may need to be fixed by the Help Desk.
Current and New Behavior: If the user should have O365 mail based on the current affiliation, then IIQ will try to do an Enable-RemoteMailbox. IIQ will then set the Email Alias Mailbox to point to O365. Exchange Online will now try to deliver incoming mail to the O365 mailbox.
When a user is explicitly deprovisioned other changes are made to an O365 or Eliapps mail account to block mail delivery. For example, there is a “Don’t accept mail from anyone except: Elvis” list. These manual blocks have to be cleared by someone running a Powershell script. IIQ generates a report every day of people it processes for Email, and one of the columns in the report flag deprovisioned users. I read the report each day and run a script on anyone it flags. This will work the same for any new SI or Affiliate people who also get processed.
...