Entra ID Connect Service: How To Find Out Which Objects Take Longest To Synchronize

Shih, Michael 20 Reputation points
2025-12-08T22:17:21.22+00:00

Entra ID Connect (AKA: Azure Active Directory Connect); v2.5.190.0:

We recently had a Full Synchronization and it took almost double the normal amount of time.

I can use Sync Services Manager (miisclient.exe) to tell me what state my synchronization is at, the amount of updates, and all of the objects that are being processed. However, there is no dashboard in Entra or a way for me to tell how long each object takes to synchronize.

Anyone know of a way to help create a list of objects being updated with the time it takes to update said objects?

Windows for business | Windows Server | Directory services | Other
0 comments
Answer accepted by question author
VPHAN 47,435 Reputation points Independent Advisor
2025-12-08T23:58:21.3666667+00:00

Hi Shih, Michael,

Actually, there is no native feature or log that provides a "stopwatch" per object.

The Entra ID Connect sync engine (based on MIM/FIM) processes objects in multi-threaded batches (pipelines), not serially. Therefore, it doesn't calculate a "duration" for UserA vs UserB. It loads a batch of 50 or 100 objects into memory, applies synchronization rules to the batch, and commits the batch to the SQL database or the target connector.

Since you can't get a per-object timestamp, you must determine if your slowdown is due to Data Volume (processing too many changes) or Processing Latency (system/rule bottlenecks).

1. Isolate the Bottleneck Phase

In miisclient.exe, click the Operations tab and look at the recent "Full Synchronization" profile history. A sync run has multiple steps; knowing which one was slow tells you where to look:

Import (from AD) was slow: The issue is reading from your on-prem Domain Controller (network latency or unindexed AD queries).

Synchronization was slow: This is the most common cause for "double duration." It implies SQL performance issues (fragmentation) or a new/inefficient Synchronization Rule (e.g., a rule with complex RegEx or joining logic).

Export (to Entra ID) was slow: This indicates Azure throttling or internet bandwidth issues.

2. Check for "Attribute Churn" (The "List" you asked for)

If the Synchronization step was slow, it’s possible a massive number of objects were flagged for update due to a single attribute change (e.g., an HR system updated extensionAttribute1 for 50,000 users).

To see the list of objects that actually changed (rather than just being evaluated):

In miisclient.exe > Operations, click the slow run profile.

In the bottom left "Step" pane, select the Synchronization step.

In the bottom right, look at the "Outbound Synchronization Statistics".

Click the number next to "Updates" or "Adds".

This opens a window listing every specific object that had a pending change calculated.

Note: You cannot see "time taken," but if you see 10,000 objects here when you usually see 50, you have found your root cause. Double-click any object to see exactly which attribute triggered the update.

3. Analyze SQL Performance (The likely technical culprit)

If the number of updates in Step 2 is low/normal, but the time is double, your LocalDB (or SQL) is struggling.

Fragmentation: Even in v2.5, the ADSync database can get fragmented after massive deletions or full syncs.

Ensure the server has enough RAM (SQL caches the DB in RAM). If you are using the default LocalDB (SQL Express) and your database is approaching 10GB, performance falls off a cliff.

I hope you've found something useful here. If it helps you get more insight into the issue, it's appreciated to ACCEPT ANSWER. Should you have more questions, feel free to leave a message. Have a nice day!

VP

Was this answer helpful?

1 person found this answer helpful.
0 comments

3 additional answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. VPHAN 47,435 Reputation points Independent Advisor
    2025-12-09T23:05:21.1366667+00:00

    Hi Shih, Michael,

    The interface you are seeing is indeed the standard Synchronization Service Manager (miisclient), but based on your screenshot and description, you are looking at a statistic that confirms exactly why your sync time doubled.

    The "smoking gun" is right there "Connectors with Flow Updates: 1,903,019".

    In a standard Delta Sync, this number is usually small (e.g., 50–500), representing only the users who actually changed. In your situation, the number 1,903,019 means that during this specific Full Synchronization, the engine had to recalculate the attribute rules for 1.9 million objects.

    Even if the final "Export" (updates sent to Azure) was small, your server had to spend CPU and SQL cycles processing almost 2 million items in memory to determine if they needed updating. That massive processing volume is why the duration doubled.

    You mentioned the "Changes" column showed "none." This is because "Connectors with Flow Updates" often means a re-evaluation of the rules rather than a net change in values (e.g., if a rule was modified, every user is re-evaluated against it, even if the result is the same).

    To verify what attribute or rule triggered this:

    Click the blue number link 1,903,019 (from your screenshot).

    A huge list of objects will open. Double-click any random object in that list.

    Select the Lineage tab in the window that appears.

    Look at the table to see which Synchronization Rule is listed at the top or flagged as "Applied."

    This usually happens when an administrator modifies a Sync Rule or refreshes the Directory Schema, forcing the engine to "re-read" the entire database during the next cycle.

    I hope you've found something useful here. If it helps you get more insight into the issue, it's appreciated to accept the answer. Should you have more questions, feel free to leave a message. Have a nice day!

    VPHAN

    Was this answer helpful?

    1 person found this answer helpful.
    0 comments
  2. VPHAN 47,435 Reputation points Independent Advisor
    2025-12-16T06:43:16.5766667+00:00

    Hello, I'm writing to follow up on the finding from your screenshot. The 1.9 million "Connectors with Flow Updates" is definitely the root cause of the delay; the sync engine was forced to process rule logic for every single one of those objects in memory, which consumes significant CPU and SQL resources, even if the resulting data remained identical (hence "Changes: none").

    To close the loop on why this happened, checking the Lineage tab on a few of those objects is the final step. It will identify exactly which Synchronization Rule or schema change forced this full re-evaluation.

    If the issue has been successfully resolved, please consider accepting the answer as it helps other people sharing the same question benefit too. Thank you!

    VP

    Was this answer helpful?

    0 comments
  3. VPHAN 47,435 Reputation points Independent Advisor
    2025-12-09T20:32:52.8833333+00:00

    Hi,

    I'm just checking in to see if you were able to review the Operations tab statistics in miisclient.exe to pinpoint the latency source. Determining whether the delay occurred during the Import phase (indicating network or disk I/O constraints) or the Synchronization phase (indicating SQL or CPU processing limits) is the critical differentiator here; a high duration combined with a standard or low "Updates" count almost invariably points to local SQL Express contention or memory pressure on the host server rather than a specific problematic user object causing the hang.

    If the explanation regarding the multi-threaded batch architecture cleared up why per-object timing isn't natively available and helped you focus your troubleshooting on the server's resource performance instead, please consider accepting the solution. Should you need more assistance, feel free to reach out.

    VPHAN

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.