Office 365 - Hybrid - Remote Mailbox provisioning from On-Prem Exchange servers

[Sai Kumar Valluri]

We have a requirement to provision mailboxes both in Hybrid environment, Exchange On-Prem (20%) and Online (80%).
We need to be able to provision remote mailbox from the on-prem exchange so that all the objects on-prem will showup in EXO as well.
Going through the O365 connector it appears when Hybrid mode is selected, connector does provision mailboxes on O365, but not essentially from On-prem exchange.

Looking for other community members for some suggestions or any similar implementation that may be done.

Thanks,
Sai

[Kenneth Verrastro]

Please take a look at the following communities post which may be useful:

https://community.broadcom.com/enterprisesoftware/communities/community-home/digestviewer/viewthread?GroupId=1717&MessageKey=3fec33c6-6610-49d1-8684-06fdfe0f6f2c&CommunityKey=783a8a1e-bb2b-473a-a0c3-7be7b1d92c60&tab=digestviewer

[Pete Williams]

Hi Sai,

We ran into a similar problem when we first did our migration to O365 a couple years back.  As far as I am aware, and believe it is confirmed by Kenny's post, this isn't something that the O365 connector is capable of handling, and think it would be something hard for it to do.  I say this because the problem that you are going to face is going to be around how long it takes for an on premise AD account to sync the to Azure, using us as an example, it can take up to 4 hours for one of our users to sync to Azure.

In the end we setup and external process composed of a DB Staging Table, IDM, Kettle PDI, and PowerShell.  While I know this may sound like a bit of overkill, we do a little more than just mailbox processing with it, but ultimately this works extremely well for what we need it to do. I can certainly provide more information around this process if you are interested, just let me know.

Also, while this does not make it any better, other I have talked with have had the same problems and have taken similar approaches, and those are not just people who utilize IDM.

Thanks,
Pete Williams

[Sai Kumar Valluri]

Hi Pete,

Can't disagree with you. Great to see your approach and willingness to share information. 

I will send you a note. 

Regards,

Sai

[Pete Williams]

Hey Sai,

Since others may find this useful, I am going to continue to update then thread.  Also, I won't be going into deep details, as it will be up to you to determine how to approach the situation.  Below you can find an overview of our process from a high level.

Preface
Utilizing PDI is not a requirement.  We used this because of the volume of data we process through, and a strong familiarity with it.  We also had requirements for Skype provisioning and Licensing, so it helped manage those additional tasks as well.  This same thing can be accomplished with pure PowerShell, or in another process you feel comfortable with, but it at least gives an idea of how we manage the process as a whole.

Prerequisites

• DB Staging Table setup to hold Processing Data.
• PDI Environment
• PowerShell with MSOnline installed

Identity Manager Processing

On all Create User tasks, whether this is a New Hire or Re-Hire, we insert a record into our DB Staging Table.  The most important thing we insert are the %USER_ID% of the user, and the initial Execution State.  This is done via a PX on Task Completed.

PDI Script Processing
A combination of PDI Jobs and Transformations were created to perform the following tasks:

1. Setup Windows Scheduled Task to execute the PDI Script on a regular cadence (we run every 30 minutes).
2. The PDI Script will pull a specified number of rows from the DB Staging Table (i.e. value for %USER_ID% and Execution State).
3. The PDI Script will query the IM User Directory to pull back the values that are the sAMAccountName and mail values in AD.
4. The PDI script will evaluate the Execution State, and base on the State, it will do the following
   1. Check if Execution State equals Check Azure for Account If so, execute PowerShell script to check if Account has synced to Azure.  If the account is found, then it will update the Execution State.  If account is not found, Execution State will remain the same.
   2. Check if Execution State equals Enable Mailbox If so, execute PowerShell script to run Enable-Remotemailbox commands.  If the mailbox has been successfully provisioned Execution State will be updated.  If mailbox fails to provision, do not update Execution State.
5. End Script

PowerShell Processing

PowerShell scripts were leveraged to execute the following commands:

Check if Account Exists in Azure:
Get-MsolUser -UserPrincipalName $_adUpn -ErrorAction SilentlyContinue

Enable Remote Mailbox Command:
Enable-RemoteMailbox -Identity $Using:adUpn -RemoteRoutingAddress $Using:targetAddress -PrimarySmtpAddress $Using:primarySMTP

You may need to update these a bit for your needs, but this should help you get going.

Thanks,
Pete