I recently had a request come in where our UC team want to move mailbox provisioning off our legacy automation process and move it into ISC. Has anyone done this before and if so what were some things that were not obvious when you started the process that we should keep in mind?
Current state:
New user is created in ISC.
ISC create new ServiceNow account
ISC creates new AD account
ServiceNow run a provisioning script to assign the user a mailbox
AD is synced with Azure AD
The current back in script has over a codes in it to assign a license to users. Any time this information changes it needs to be updated manually in the script. This scripts does not always run when it should limitation with ServiceNow to handle rehires.
In all my years working with connectors I have learned that there is always more to setting it up then just plugging in the values on the Connector Config screen. I am wondering what the hidden things are that are not easy to spot until you are hands on in the config and testing.
The most common pattern I see with this is using the AD After Create rule to run a PS script to get the mailbox set up
In hybrid exchange environments, most people are running the Enable-RemoteMailbox command so that the account is “stamped” with the attributes needed for M365 to get the mailbox fully provisioned.
I would imagine that the existing automation script is already doing this, so you might not have to change much.
As far as licenses are concerned, most people I encounter use on-prem AD groups that are linked to the respective M365 license, and those are assigned by SailPoint roles. In fact, it’s often qualification for these roles in SailPoint that kicks off the AD account creation in the first place.
Are these typically requested or applied automatically based on certain conditions?
Either way, you can choose to utilize on-prem AD groups mapped to these licenses or if you use the Entra connector, they are made available as entitlements that can be applied to the account.
If they’re done automatically based on conditions, you can likely build a SailPoint role to assign them. If requested, you can either make the entitlement directly requestable or wrap it in an access profile with more “user friendly” wording in the name and description
As @mcheek said, usually 365 licensing can be given by groups in AD or Azure!
About the mailbox creation, you can go with afterCreate rules in AD and as Mark said, it is the most common pattern. But in my newest implementations that have hybrid O365 environments, I’m choosing to go with PTA(Privileged Task Automation) for creating on-prem mailboxes and applying 365 policies. It’s easier to notify errors and will not impact the provisioning directly! But licensing is always through AD or Entra groups!