In our Production, the Account Aggregation for the source "Azure AD " has been running normally, typically completing within 1.5 hours.
The Entitlement Aggregation for the same source is also completing successfully and has not experienced any issues.
This issue relates specifically to the Account Aggregation issue.
Observations from Aggregation History
7 September 2026, 10:00:02 – The Account Aggregation encountered the following error:
Error occurred while processing aggregation :: Failed to perform delta aggregation sailpoint.connector.ConnectorException: Error occurred in delta aggregation sailpoint.connector.ConnectorException: Exception occurred in processReadRequest. Error - Response Code - 400 Error - 400 Badly formed token
The aggregation subsequently recovered automatically and completed/recovered around 7 September 2026, 11:00:03.
8 September 2026, 08:00:05 – The same “400 Badly formed token” error was observed again.
8 September 2026, 14:00:02 – The Account Aggregation had been running for more than 18 hours, which is significantly outside the normal runtime. As this did not appear normal, I cancelled the aggregation. The remaining scheduled aggregations were also did not run as above was still running.
Configuration Changes
There were no configuration changes made prior to the aggregation delay observed on 8 September.
As a side note, I have also enabled Account Deletion with a threshold of 40%. However, this configuration change was not made when the issue initially started and therefore does not appear to correlate with the start of the problem.
Current Status
A new Account Aggregation was started today from a fresh run. It has now been running for more than three hours, whereas historically the aggregation has normally completed within this timeframe.
In particular, it would be helpful to understand:
Why the aggregation, which has historically completed in less than one hour, is now taking significantly longer considering no source changes with respect to accounts as well.
Whether there are any known issues with the connector, source, or backend service that could explain this behaviour.
The Account and Entitlement Aggregations for this source had been operating normally prior to this issue, so we would appreciate assistance in identifying what has changed or what may be causing the current degradation and any steps to troubleshoot or fix. Also checked the VA cluster and memory and CPU all normal.
Hi @lalithajay - Delta’s can be finnicky with Azure. Sounds like the DeltaLink used by Graph may have been corrupted on the Azure side leading to the errors you got.
When you created a new aggregation task it will do a Full Aggregation in order to be able to generate the delta’s next time.
Once it finishes, let us know if you see a significant improvement in run time for the delta or if there are still issues.
Hi @ryan_toornburg thanks for your answers, by looks, the token got some issue and Azure rejected and that kick off a Full Aggregation
we also have Azure AD account creation event triggers configured, which can trigger emails and other downstream business functionality for end users. Therefore, a prolonged aggregation has the potential to impact these business processes.
Do you have any recommendations/configurations or optimisations that we could make to our current setup to:
Avoid or reduce the likelihood of these token-related issues occurring.
Prevent a token issue from resulting in a full aggregation that could potentially run for more than 18 hours.
Improve the recovery process so that, if a token issue does occur, the aggregation can recover within a reasonable timeframe.
My main concern is that if a token issue can cause the aggregation to fall back to a full aggregation, and that aggregation can subsequently take 18+ hours, it could have a significant impact on our downstream business functionality.
Secondly, I cannot see any percentage progress or other indication of how far the aggregation has progressed. Is there any way to determine whether the aggregation is progressing normally, for example, the number of accounts processed or an estimated remaining time? At the moment, it is difficult to determine whether the aggregation is actively progressing or effectively stalled.
Currently, the latest aggregation has been running for more than 6 hours and is still showing 0% / Pending.
Any guidance on both the token issue/recovery and how we can better monitor aggregation progress would be greatly appreciated.
Our latest observation is that the full aggregation runs for several hours and then fails with the warning below, after which it starts again, resulting in what appears to be a never-ending cycle:
“Connector failed to complete aggregation. Connector may not be sending responses. This aggregation will be retried in case this was a temporary issue.”
We subsequently reduced the aggregation page size to 100 in the aggregation settings. However, even with this change, the aggregation still runs for many hours before eventually failing with the same warning.
Considering we have not yet completed the cutover and almost all Azure accounts are currently in an uncorrelated state, I was wondering whether resetting the source might help. This is purely a consideration, as we have deleted a large number of Azure accounts separately since the source was initially configured.
Could you please let us know your thoughts on whether resetting the source would be worthwhile, or if there are any other aggregation/connector settings we should try?
We would really appreciate your guidance on this so that we can identify a way to successfully complete the full aggregation.
Hello Lalitha. I would hold off on resetting the source for now. A full reset removes the aggregated accounts and entitlements and deletes the related access profiles, so I would troubleshoot the connector issue first.
For the long-running full aggregation:
If Manage Exchange Online is enabled, check IQServiceResponseTimeout. Aggregation can get stuck when IQService does not respond because the default timeout is 0. The documented example is 7200.
If the account schema contains groups, roles, or servicePrincipals, increase max-thread-account-membership. The default is 4; SailPoint recommends 6, 8, or 10 for slow full aggregations.
Remove any unused account schema attributes.
For progress, Aggregation History → Account Aggregations shows the status and number of accounts scanned. I would check whether that value is increasing; 0% / Pending alone does not confirm whether the connector is progressing.
For the original 400 Badly formed token, Ryan’s explanation is possible, but I would not treat DeltaLink corruption as confirmed. SailPoint documents the expired-token case specifically as “DeltaLink older than 30 days is not supported.”
If the issue continues, I would open a SailPoint Support case.
The connector is an Azure AD connector and is going through the Azure VA cluster, so there is nothing configured under the IQService settings. There is also nothing configured for Manage Exchange Online.
The Account Schema is also very limited. It does contain groups; however, I cannot find an entry for max-thread-account-membership in the source file when checking it via VS Code.
Overall, the Account Schema contains only a small number of entries.
Regarding the aggregation history, it remains at 0% completion, and the number of accounts does not appear to be changing. For example, the current aggregation is:
Status: In Progress
Started: 14 Sep 2026, 01:08:51
Duration: 17 hours 54 minutes 26 seconds
Accounts Aggregated: In Progress
Accounts to Aggregate: In Progress
Percent Complete: 0%
Also, as noted previously, entitlement aggregation is working successfully.
As a side note, I created a dummy Azure AD connector (read-only) and started a fresh full aggregation. Interestingly, for this connector I can see the number of accounts increasing as the aggregation progresses.
Regarding the source reset, for Production, we have not yet performed the trusted source aggregation. Therefore, all the Azure accounts are currently in an uncorrelated state.
Given this, could you please advise whether a source reset would still be recommended, or whether there are any other checks/configuration changes you would suggest before proceeding?
Thanks, Lalitha. Since the dummy source through the same VA cluster is aggregating normally, this may point to something specific to the existing source. Before resetting, I would run Peek against both sources and compare the results:
POST /sources/v1/{sourceId}/connector/peek-resource-objects
{
"objectType": "account",
"maxCount": 25
}
If Peek behaves differently, that gives a useful isolation point. I would also compare the account schema, filters, aggregation settings, connectorAttributes, and app registration/credentials.
Not seeing max-thread-account-membership is expected unless it has been added, the default is 4. I would treat it as secondary here. I would hold off on a full reset and remove-accounts unless Support recommends it.
I tried peek against both the sources with above body,
both fails in identical error msg
Could not send request**Cloud Agent Error**:Request is taking longer than 30 seconds to fulfill. Use another agent to send a request without time limitations.
Thanks, Lalitha. The Peek result looks to be hitting the Postman Cloud Agent timeout rather than giving us a connector result. If convenient, I would rerun Peek using the Postman Desktop Agent or curl.
On the two In Progress entries, I would not assume they are two concurrent connector runs. ISC disables starting another aggregation while one is running, and your earlier warning shows this aggregation is being retried. With both rows sharing the same start time, this may be related to the retry/task state.
Given that the dummy source continues to progress while this one remains stuck, I would hold off on further tuning, reset, or remove-accounts and have SailPoint Support check the aggregation/retry state for this source.
I’ve provided the logs to SailPoint Support, and they are currently looking into the issue. We’re waiting for their findings.
I fully agree that we should understand the root cause, particularly because we need to know what could happen if this occurs again after cutover.
Either way, I’ll share the findings once we receive them so everyone has a better understanding of what happened.
As a side note, I can see that the account count has now almost caught up with what is currently in Azure. Yesterday, there was a difference of around 500K accounts. I’m also fairly certain this wasn’t a gradual decline, as the numbers remained almost unchanged for several days. So, it looks like something has happened in the background, although the aggregation jobs are still running without completing.
@lalithajay We also ran into similar issue, and based on the thread dumps we found that Server threads were on hold due to other aggregations where it was holding the thread while target app was preparing the response and it was taking many hours to generate and send the response back.
Please try taking the thread dumps to see if you also have the similar issue.
Considering we have ISC , would you be able to provide us with some specific steps to try, including where we should look to identify and clear the bottleneck?
Were you able to overcome this issue in your testing? If so, could you please share the steps or configuration changes you carried out to resolve it?
I’m also wondering whether the post below could be related to the same issue. Could you please have a look and let us know your thoughts?
@lalithajay We are still coordinating with target application team to figure out why is it taking longer. Basically we need to fine tune the aggregation calls or have partitioning enabled, so target app can start sending the response relatively quicker.
After further investigation found out the issue is because of below issue (MFA attribute throttling) raised before
to reduce the throttling issue/errors, connection param “max-thread-mfa-attributes”: “2” added because the default is 4 but issue still continues. I also have doubts whether sailpoint really treat the header Retry-After and act accordingly ( Microsoft Graph throttling guidance - Microsoft Graph | Microsoft Learn )
I think this is a common issue for MFA attributes,
Just curious how others overcome this issue, as it looks common need, because after the full aggregation done, any time due to token issue, it can fire the full aggregation again from delta aggregation. Let us know your thoughts, fully agree resetting the source is not the answer
I thought I would share a summary of our experience, as it may help someone else who encounters a similar issue.
We tried several adjustments, including:
Reducing max-thread-mfa-attributes to 2.
Increasing the Java heap size via /home/sailpoint/ccg/java_overwrites.yaml.
Trying different page-size configurations.
After several days, the full Azure AD aggregation eventually completed. Following this, the delta aggregations returned to normal processing times.
However, we do not have clear evidence that any of the above changes resolved the underlying issue. Based on our observations, the MFA attribute calls appear to be heavily rate-limited, regardless of these configuration changes.
Considering the above, we decided to remove the MFA attributes from the Azure AD Connector schema and retain only the basic account information. We have implemented the synchronisation of MFA attributes from the trusted source to Entra ID outside of SailPoint.
We have also determined that, due to the reliability concerns observed with the Azure AD Connector, we cannot rely on it for certain event-handler-driven processes.
Since removing the MFA attributes, the Azure AD aggregations have been completing within the expected timeframes.
Although we were not able to identify a definitive fix for the underlying issue, I hope sharing our findings and approach will be useful to others experiencing similar Azure AD aggregation issues.
