Slow Account Aggregation in Microsoft Entra ID Source

Identity Security Cloud (ISC) ISC Discussion and Questions
1

Hello,

We are experiencing slow account aggregation in our Microsoft Entra ID source in SailPoint Identity Security Cloud.

The environment contains approximately 600,000 accounts, and a full aggregation is taking between 4 and 5 hours to complete.

We have already configured a user filter to reduce the number of accounts being aggregated, but the execution time remains high.

We would like to confirm:

  1. Whether the filter is applied directly in the Microsoft Entra ID query or only after the connector scans the entire user base.
  2. Whether there are any recommended configurations for environments with a large number of accounts.
  3. Whether parameters such as userAggregationBatchSize, Page Size, or Delta Aggregation can improve performance.
  4. Whether there are any known limitations in the current connector for environments of this size.

We would appreciate your support in analyzing the cause of the delay and recommending the best configuration to optimize the aggregation process.

Thank you.

2

the filter is applied in the graph query not after a full scan.

I dont think the response time is bad, in my env, aggregating 25000 takes 30min. what page size you are using, default or higher than 500?

do you have delta aggregation and partitioning?

Also, what features have you enabled under feature management?

3

Hello Sunny,

The page size is currently set to 250. Is there a maximum supported value?

For Delta Aggregation, I only enabled the option in the source configuration.

I also enabled resources the following options:

  • Manage Microsoft 365 groups
  • Enable Teams governance

Could these settings be affecting the aggregation time?

Thank you.

4

Hello Henrique. @sunnyajmera is right that the filter runs server-side in the Graph query, not after a full scan.

How many accounts(600k) are actually coming through after the filter? You mentioned you set a user filter but the runtime is still high, so it would help to know if the filter is cutting the count meaningfully.

On page size, you are at 250 and the Microsoft Graph /users endpoint supports up to 999. Bumping it up can help, but I would go gradually since Graph throttling can eat up the benefit at higher values.

userAggregationBatchSize is a separate setting that controls how many records the connector processes in parallel, but that one is documented for the Entra ID SaaS connector. If you are on the VA-based connector, that won’t apply and partitioning is the parallel-processing option instead.

Delta Aggregation won’t make your full aggregation faster. It’s meant for regular scheduled runs after the baseline is built, where only a smaller set of changes get picked up.

Manage Microsoft 365 Groups and Teams Governance both pull extra Graph calls per account for group membership and channel data, so they’re adding real time to your run. If Teams channel governance isn’t something you actually need in ISC, turning it off should help.

5

If you are on the VA-based Entra ID connector, partitioning is where the real gains come from. Split the user base into filtered chunks (alphabetical on displayName works well) and set Number of Partitioning Threads to your VA core count times 2. Before turning it on though, check if PIM is enabled on this source. SailPoint’s docs call out that partitioning with PIM forces the connector into individual per-user API calls for PIM memberships instead of using its caching mechanism, so it can end up slower, not faster. If you are on the SaaS connector, userAggregationBatchSize is your parallel-processing option.

Either way, combining that with bumping page size gradually and pulling Teams governance out if you don’t need it should bring the runtime down.

6

Hello Harish,

Thanks for the explanations; you really cleared up my questions about how the connector works!

I’m going to test userAggregationBatchSize to see if it works.