Automating Enable Remote Mailbox and Entra License assignment in hybrid Exchange with ~30 min AD-to-Entra sync

Identity Security Cloud (ISC) ISC Discussion and Questions
, , ,
1

Hi All

I’m implementing a Hybrid Exchange + SailPoint ISC setup and need to orchestrate the following workflow:

  1. Create user in on-prem Active Directory via SailPoint ISC (AD birthright).

  2. Wait for AD Connect to sync the user to Entra ID (my sync interval is ~30 minutes).

  3. Enable remote mailbox on-prem using Enable-RemoteMailbox, but only after the user exists in Entra ID. (After ~30 minutes)

  4. Assign Exchange Online license groups in Entra ID from RBAC role in SailPoint ISC (group-based licensing) after the On-Prem to Entra ID account sync.

Challenges & constraints:

  • SailPoint’s provisioningTimeout on the AD source maxes out at 600 seconds (10 minutes), which is too short for a ~30–45 minute sync delay, there is no way to increase it beyond that (as per my understanding)

  • I need a reliable way to delay or poll until the Entra ID account appears before proceeding.

  • I want to avoid race conditions—e.g., triggering Enable-RemoteMailbox too early or license provisioning before the mailbox attributes are replicated.

What I’d like help with:

  • Has anyone built a workflow or After-Create rule that handles this delayed provisioning effectively in SailPoint ISC?

  • Are there recommended best practices, sample PowerShell logic, or SailPoint configurations for handling a ~30 minute delay between AD account creation and Entra ID provisioning?

  • Any advice on working around the provisioningTimeout limitation or on ensuring the remote mailbox attributes are synchronized correctly before assigning licenses?

Note : I have onboarded AD VA based source and Entra ID SaaS connector based source on SailPoint ISC. AD for account creation and Entra ID SaaS for license group assignment.

Thanks in advance for any guidance or examples you can share!

Regards,

Arshad.

2

Hi @Arshad there is no need to delay the enable-remotemailbox PS. I, personally, would use an on-prem sync-ed group for the license assignment as well.

3

Hey Arshad,
We have similar setup, We are using Before Modify rule in a Role to trigger the enable remote mailbox.
We created a dummy group called Enable remote mailbox, with assignment criteria to have an AD account and the 0365 Group license group.

4

@j_place Thanks for your response.

Could you please clarify how the Enable-RemoteMailbox script would be executed in this scenario? From what I understand, you’re suggesting that an on-prem AD group be created corresponding to each O365 Entra license group, and that this AD group be assigned during the initial AD account creation.

Given that this is a hybrid Exchange environment, I’m curious how the Enable-RemoteMailbox step would be handled, especially since it typically needs to run prior to assigning the license group. How would that sequencing work in this setup?

5

Use an after create rule on the AD connector to run the enable-remoteMailbox PS cmd. This adds the attributes to the AD object, which when sync-ed to Entra tell Exchange Online what kind of mailbox to create (a remote user mailbox in this case).

Yes an on-prem synced group for each Entra license group. Group sync does not happen at the same time as user sync, so if the group sync occurs before the user is created it wont have it as a member, and when it is sync-ed after user is created it will have it as a member.

2 Likes
6

@j_place I’m not an Exchange expert, so please correct me if I’m wrong here, but in a Hybrid Exchange setup, isn’t it important to make sure the AD account is fully synced and visible to the on-prem Exchange server before running certain commands, like Enable-RemoteMailbox?

Also, just wondering, doesn’t SailPoint ISC have a default provisioningTimeout of 600 seconds (10 minutes)? From what I understand, that’s a hard limit for how long SailPoint will wait for a provisioning task to complete before marking it as failed. So if it takes ~30 minutes for the AD account to become visible to Exchange for whatever reason, any provisioning step that depends on that visibility wouldn’t be able to complete within the same SailPoint provisioning transaction. Does that sound accurate?

Happy to be corrected but just trying to understand the timing dependencies better.

7

Hi @Arshad enable-remoteMailbox doesn’t actually do anything Exchange related; on-prem exchange only talks to exchange online though AD attributes and relies on AADC or Entra connect to pass the attributes on the user object. So, no you don’t need to wait for the object to be synchronised before running enable-remoteMailbox i have done a number of deployments with the implementation as I describe and I would say you can trust me on this, but obviously you would want to try it out for yourself. I could even talk you through how to do it without enable-remoteMailbox, but that gets quite involved.

1 Like
8

Agreed with all the points what @j_place mentioned. If you still want to execute the enableMailbox command after the EntraID sync-up, below might be a work around.

  1. Create a dummy group in AD.
  2. Create a role with the criteria to check the account existence in Azure along with other active account criteria and assign the group to the role.
  3. When the EntraID account is created and correlated into an identity, it will assign the role and automatically.
  4. Add a condition in the AfterModify PS script to execute EnableMailbox when the dummy group is added.
9

Hi @suresh4iam With all due respect, if you agree with my points, then surely you must agree this is pointless over-engineering? However, you are right, if @Arshad wants to do this, then that is up to him, and I will step away from the conversation.

1 Like
10

Hello @Arshad,

You can use the following solution.

  1. Create user in on-prem Active Directory via SailPoint ISC (AD birthright).

–> Using the AD BirthRight Role and Access Profile, provision the User to On-Prem AD source. No need to increase vthe timeout to 600 seconds but make sure that provisioningTimeout is set as per your post AD create activities

  1. Wait for AD Connect to sync the user to Entra ID (my sync interval is ~30 minutes).

–> It means that User will be created in Entra ID through AD using BackEnd Sync. Therefore, what you can do is, you can enable Entra ID aggregation every 30mins to 1 hour depending upon the number of users and average aggregation time your Entra ID Saas connector takes. Also, create an Identity attribute named as “AzureAD UniqueID“ in respective identity profile which will store the UPN/MailNickName or any other unique attribute from Entra ID into identity profile.

Once the Entra ID account of the user is correlated to the identity in ISC post aggregation, this newly created identity attribute will be populated successfully.

2. Enable remote mailbox on-prem using Enable-RemoteMailbox, but only after the user exists in Entra ID. (After ~30 minutes)

–> Create a new attribute named as “AzureAD ID“ in Create Account Provisioning Policy/Profile of AD source and map it to “AzureAD UniqueID“ identity attribute. This will enable this “AzureAD ID“ attribute in attribute sync page and enable the attribute sync for this account attribute. Also, exclude the account attribute named as “AzureAD ID“ from provisioning in AD (We will use this attribute just to trigger a provisioning request in AD). Once the Modify Account request is triggered post update of “AzureAD UniqueID“ identity attribute, create a “After Modify Provisioning Connector Rule“ and write a powershell script which will call “Enable-RemoteMailbox“ command in on-prem AD to enable the remote mailbox. Call this powershell script from “After Modify Provisioning Connector Rule“ to respect the Async Architecture.

  1. Assign Exchange Online license groups in Entra ID from RBAC role in SailPoint ISC (group-based licensing) after the On-Prem to Entra ID account sync.

–> Create another identity attribute named as “AD Email“ which is mapped to FirstValid Transform where,

1st Priority –> mail attribute from AD

2nd Priority –> “Unknown“ static value

Post Mailbox is enabled, the mail attribute will be populated in AD with a legitimate value.

Create a role and assign respective EXCHANGE ONLINE LICENSE Group to the role. In the assignment criteria, make sure you are providing the criteria which says.

Identity Attribute - “AD Email“ - DOES NOT EQUALS - Unknown.

In this way, you can achieve the required. I know you have to create some set of extra identity attributes but this is a possible solution with existing architecture of SailPoint ISC.

Thank You,

Regards,

Rohit Wekhande,

11

Sharing my approach in case it’s helpful to others in the community. My solution involves two PowerShell scripts:

  • The first script generates a CSV file containing Active Directory records that need to be processed.

  • The second script reads from that CSV and executes remote mailbox management commands accordingly.

Approach :

  1. SailPoint ISC → Creates AD User → Adds entry to CSV queue using after create rule

    • When a new employee’s Active Directory (AD) account is provisioned, SailPoint triggers the afterCreate rule, which executes a PowerShell script. This script generates a CSV file and appends a new row containing the user’s details such as SamAccountName, email address, and other relevant attributes along with a status marked as Pending.

  2. Scheduled Another PS Script (every 30 mins or as configured) → Reads above CSV

    • The PowerShell script loads all rows from the CSV.

    • Filters rows with Status = Pending, sorted by creation time.

  3. Check AD for user existence

    • For each pending row, the script queries Active Directory to verify that the account exists.

    • If the AD account is not yet created, the row remains Pending and will be retried in the next run.

  4. Enable Remote Mailbox

    • If the user exists in AD: then it executes Enable-RemoteMailbox in Exchange.

  5. Update CSV queue with processing results

    • On successful mailbox enablement:

      • Status → Completed

    • On failure or verification error:

      • Status → Pending (retry) or Failed (permanent after max attempts)

  6. Next run / retry

    • Pending or failed rows remain in CSV for future scheduled runs until maximum attempts are reached or mailbox is successfully enabled.

Thanks,

Arshad.

2 Likes
12

I assume you’re not using the same CSV file for all requests as IQService has no problem running multiple instances of the AfterCreate Powershell script at the same time, which causes issues where one script would lock the file when another script wants to write to it, causing data loss. This is why some people use separate files or queue system like AWS SQS. Also, wanted to add that EntraID/AzureAD sources support AfterCreate rules as well: Before and after operations on source account Rule | SailPoint Developer Community

This however causes a delay due to how often you aggregate these sources. But as it was stated before, Enable-RemoteMailbox is for the onprem Exchange so it is not relevant whether the EntraID sync happened or not. Since AfterCreate runs after the account in AD is created, youre good to run Enable-RemoteMailbox. If you manage thousands of accounts, I recommend using a queue because IQService would trigger Enable-RemoteMailbox for multiple accounts at once, which can overload the server or cause the Exchange server to reject this many connections.

So a better system is:

  • create AD user through a role
  • license assignment through a role for onprem AD group, synced to EntraID - this way the account is added to the group when the AD account is created not after the aggregation of EntraID source runs
  • afterCreate script writes a file to a folder for each user
  • scheduled script that runs lets say every hour (which could be on another server), that reads the files in the folder and if not locked, processes and deletes the file. Or use AWS SQS as an alternative - AfterCreate scripts adds to the queue, Scheduled script removes from the equeue after processing
13

For anyone reading this in the future:

Although the OP asks how to delay the running of enable-remotemailbox and this has been answered - THERE IS NO NEED to delay the running of enable-remotemailbox. See Exchange Mailbox Provisioning - #5 by j_place

1 Like