Best Practices for Enabling a Remote Mailbox for Existing AD Accounts

Identity Security Cloud (ISC) ISC Discussion and Questions
1

Hi everyone,

I’m working on a use case where, during the Joiner process for external identities managed by NERM, a hybrid account is created: the user is provisioned in on-prem AD and then synced to Entra ID.

At this initial stage, a mailbox is not required, but it may be requested later, once the AD account already exists. To enable the mailbox, we plan to use the Enable-RemoteMailbox command, but I have some questions about attribute handling and the correct sequence of operations.

Based on what I’ve read in the SailPoint forum, the expected flow should be:

  1. Create the AD account (without mailbox)

  2. Use an After Modify rule to trigger a PowerShell script that runs Enable-RemoteMailbox

  3. Assign the on-prem AD group that grants the M365 license

However, I have a few questions:

1) Which attributes should be calculated before calling Enable-RemoteMailbox?

For example:

  • mail

  • targetAddress

  • mailNickname

  • any others that should be prepared?

2) When the mailbox is requested later, do we need to recalculate the UPN?

The initial UPN of the user is different from the one we intend to use as the primary SMTP/mailbox.
So is it necessary to:

  • update the UPN before enabling the mailbox
    or

  • keep the existing UPN and only calculate the mail and/or targetAddress attributes?

3) If the UPN and/or mail-related attributes must be recalculated, where is it better to do this?

  • directly inside SailPoint before invoking the script
    or

  • inside the PowerShell script that runs Enable-RemoteMailbox?

Request for Best Practices

Do you have any best practices for:

  • enabling a Remote Mailbox on an AD account that already exists

  • handling the recalculation of the UPN and mail attributes

  • ensuring attribute consistency (mail, mailNickname, targetAddress) between AD and Entra ID?

Any suggestions or implementation examples (either in SailPoint or PowerShell) would be greatly appreciated.

Thanks

Best regards

Antonio

2

Hi!

  • enabling a Remote Mailbox on an AD account that already exists

    • If the acount is correlatted use a PS script to enabled it.
      • there’s alot of of nuances in it, for example, does the mailbox is licensed? it has litigation. But the enablement should be enough

  • handling the recalculation of the UPN and mail attributes

    • This is the trick part, you can always add more addresses in the ProxyAddresses field, but some powershell can also help you with it.
      • Rememeber that the email field must be the primary , upn etc etc

  • ensuring attribute consistency (mail, mailNickname, targetAddress) between AD and Entra ID?

    • When recaulculating you just need to be sure you’re sending everything to AD i gues.
1 Like
3

Hi Antonio

I put some notes down here Exchange Mailbox Provisioning - #5 by j_place

1 Like
4

Hi Jeremy,

thanks again for the very useful explanations.
I still have a few doubts regarding the handling of mail, UPN, externalEmailAddress and about the correct trigger for the After Modify rule that runs the PowerShell script.

Scenario

  • The AD account is first created without mailbox.

  • At creation time, the UPN uses a different pattern (e.g., sAMAccountName@domain.it) which is not the final SMTP address, and the mail field is empty

  • The mailbox may be requested later, and when this happens the mail attribute must follow the company SMTP policy (e.g., firstname.lastname@domain.it).

  • The final step in the process is adding the user to an on-prem AD group which assigns the M365 license.

How should I calculate the mail attribute, since Attribute Generator cannot be used (the account on AD is already created)?

A) calculate mail inside SailPoint (for example in an After Modify rule),
and let the PowerShell script only run Enable-RemoteMailbox,

or

B) calculate the SMTP address inside the PowerShell script before calling Enable-RemoteMailbox?

Which approach is considered best practice for this scenario?

UPN alignment after mailbox creation

Once the mailbox is enabled, our policy requires that the UPN must match the mail value.

Given that the initial UPN pattern is different, should I:

  • update the UPN before running Enable-RemoteMailbox,
    or

  • enable the mailbox first, and only then update the UPN?

Is there any recommended order to avoid AD Connect sync issues?

externalEmailAddress / targetAddress handling

For example:
SMTP:sAMAccountName@domain.mail.onmicrosoft.com

Do I need to set this attribute manually (via provisioning / script),
or does Enable-RemoteMailbox automatically populate externalEmailAddress, proxyAddresses and the other Exchange-related attributes?

If it is automatically populated, it would be better not to set it manually.

Best practice sequence for enabling the Remote Mailbox

Is the following the correct recommended flow?

  1. Calculate mail (and optionally mailNickname)

  2. Run Enable-RemoteMailbox

  3. Add the user to the on-prem group that grants the M365 license

  4. Update the UPN afterwards

Please confirm if this sequence is correct or if any adjustment is needed.

How should the PowerShell script be triggered? (After Modify)

Here is where we have a doubt:
the assignment to the on-prem AD group is the final step of the process, and it happens after the mailbox should already have been enabled.

For this reason, we cannot use the “group membership change” as the trigger condition for the After Modify rule, because the mailbox must exist before adding the user to the licensing group.

So our question is: what is the correct way to trigger the After Modify rule at the moment the mailbox is requested, but before the user is added to the licensing group?

We want to avoid running the script on every modify operation, and instead trigger it only when the mailbox is actually requested.

Any recommendation or example on how to design the After Modify trigger condition is very welcome.

Thanks a lot for your help and guidance!

Regards

Antonio

5

Hi Antonio

I’m going to begin with the scheduling of the EXO License Group membership. I have to be honest, this is not tested, as all of my implementations have been as part of account create, so provided here for disucssion:

Option 1: Entra Entitlement for the EXO license. Not sure if you’ve got an Entra connector, but if so, you could utilise an extension attribute to represent a Boolean as to whether enable-remotemailbox has been run and then do a Dynamic assignment of the Entra Group. Include the extension attribute update in the PowerShell script so it enables the remote mailbox and then sets the flag when complete.

Option 2: AD Group for the EXO license. If you don’t have an Entra connector you could run the enable-remotemailbox via a Before Modify Rule. You shouldn’t get into a scheduling problem as the remote-mailbox will be enabled before the Entra Group is added via Entra Connect. The enable-remotemailbox simply adds attributes to the AD object, so the Entra User update is instantaneous on sync, whereas the license assignment from group membership is not immediate.

As for filtering the Rule, I would use a filter as described in IDN : AD After modify rule Query - #5 by ipobeidi to only trigger with specific payload in the request.

6

Hi Ivan,

Thank you so much for your advice!

Regards

Antonio

1 Like