...
Enable-RemoteMailbox which updates the Local AD and Azure AD object, sets the UPN, mail, MailNickName, and some ProxyAddresses values in Azure.
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.
The UnDead
Having said this, it is now necessary to look at the consequences of our broken Identity lifecycle.
Birthright Email processing was written to assign mail to new users. It works flawlessly for new identities with new Netids and no prior AD or Google entries.
...
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 will not enter Birthright processing.
If 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, which will fail if there was an old Eliapps account. It will then set the Email Alias Mailbox to Eliapps. However, since Exchange Online now handles all “@yale.edu” incoming mail, it will look first for an O365 mailbox on the AD User object, and if it finds one (which we did not see because we did not look for it) Exchange will try to deliver the mail to it (without regard for the Alias Mailbox value). 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 be do an Enable-RemoteMailbox. This will fail if the AD User object already has an O365 account. It 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.
If the user was deprovisioned, however, other changes will have been made to the account that block mail delivery. These setting have to be manually cleared with a script. To address this a report is generated each morning at 8:30 listing the users who were processed for Birthright Email. The report include a flag set when someone is deprovisionedWhen 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. This 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 Powershell script on anyone it identifies as previously deprovisionedflags. This will work the same for any new SI or Affiliate people who also get processed.
The new behavior of IIQ when a request is made to assign mail to an SI will be exactly the same as its current behavior should the same person have entered Birthright processing as an employee (except that we may decide not to try and create a NoMail Eliapps account for an SI).
...