If your hybrid identity synchronisation is slow, throwing errors, or you’ve simply inherited a Microsoft Entra Connect Sync server and want to know whether it’s healthy, there’s one thing worth checking before anything else.
Your version.
Microsoft set a minimum supported version of 2.5.79.0, effective 30 September 2026. Below that, synchronisation stops working until the installation is upgraded.
That matters whether you’re reading this before or after the date. If sync has stopped and you’re trying to work out why, the version is the first thing to rule in or out. If it’s still running, you want to confirm you’re not sitting on a version that’s about to fall out of support anyway, because Microsoft retires older Connect Sync releases on a rolling basis.
The current releases are listed in the Microsoft Entra Connect version release history.
The rest of this article covers how to check that version properly, how to work out what your sync engine is actually doing, the filtering and rule changes worth making, the ones that will bite you, and whether you should be running Connect Sync at all.
Check your Entra Connect Sync version first
Before changing the scheduler, filtering objects or modifying synchronisation rules, find out what version you’re actually running.
The simplest way is Control Panel → Programs and Features on the Entra Connect server, looking for Microsoft Entra Connect Sync.
You can also check from PowerShell on the Connect Sync server:
Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*" |
Where-Object {
$_.DisplayName -like "*Entra Connect*" -or
$_.DisplayName -like "*Azure AD Connect*"
} |
Select-Object DisplayName, DisplayVersion
That approach works regardless of which product name the installed version uses.
It’s also worth checking the version recorded in the synchronisation configuration, because the installed application version and the configured version can differ after an interrupted or incomplete upgrade:
Import-Module ADSync
(Get-ADSyncGlobalSettings).Parameters |
Where-Object { $_.Name -eq "Microsoft.Synchronize.ServerConfigurationVersion" } |
Select-Object Name, Value
If the two don’t match, resolve that before doing anything else. Microsoft covers this in its upgrade guidance.
If you’re below 2.5.79.0, you need to upgrade before 30 September 2026.
I’d go further than simply installing 2.5.79.0, though. Upgrade to the latest supported version available for your environment. Microsoft has continued releasing newer versions since then, and the version history page lists what’s current.
Upgrading properly
If you’re below the minimum, the upgrade isn’t optional and it isn’t something to schedule for next quarter. Synchronisation stops until it’s done.
The installation package is now provided through the Microsoft Entra admin centre rather than the old Download Centre process. Current requirements include .NET Framework 4.7.2 and TLS 1.2.
If you’re doing the upgrade this week, treat it as a normal production change:
- Check the current version.
- Confirm the current synchronisation configuration.
- Check whether you have a staging server.
- Make sure you have a current configuration backup.
- Upgrade the active server.
- Confirm the installed and configured versions match.
- Verify that synchronisation resumes normally.
Don’t make unrelated synchronisation-rule changes at the same time. If something goes wrong, you want to know what caused it.
Should you still be using Entra Connect Sync?
This is the other question I’d ask before spending much time tuning an existing installation.
Microsoft Entra Cloud Sync is the newer provisioning architecture. Instead of running the full synchronisation engine on your own server, Cloud Sync uses the Microsoft Entra provisioning agent and manages much of the configuration from Microsoft Entra.
Microsoft’s current guidance positions Cloud Sync as the longer-term direction and provides a comparison of the supported scenarios for deciding which tool suits an environment.
That doesn’t mean every existing Connect Sync deployment should be ripped out immediately.
There are still scenarios where Connect Sync is the better fit, particularly where an environment depends on functionality that isn’t available or equivalent in Cloud Sync.
So I’d treat Cloud Sync as something to evaluate, rather than automatically replacing a working Connect Sync installation.
The sensible order is:
- Make sure your existing Connect Sync installation is supported.
- Understand what it currently does.
- Document any custom synchronisation rules and filtering.
- Check whether Cloud Sync supports those requirements.
- Decide whether migration makes sense.
That is a much safer approach than changing a working identity platform simply because Microsoft has introduced a newer product.
Understand what the sync engine is actually doing
Microsoft Entra Connect Sync takes objects from on-premises Active Directory, processes them through its synchronisation rules and exports the resulting changes to Microsoft Entra ID.
At a high level, the process is:
- Import changes from Active Directory
- Process objects through the synchronisation engine
- Apply synchronisation rules and attribute flows
- Export changes to Microsoft Entra ID
The sync engine isn’t simply copying every AD attribute into Microsoft Entra ID.
The synchronisation rules determine which objects are in scope, how objects are joined, and which attributes flow between the connected systems.
That becomes important when you’re trying to optimise the environment.
Check the scheduler before changing it
Microsoft Entra Connect Sync normally runs a synchronisation cycle every 30 minutes.
Check the current configuration with:
Get-ADSyncScheduler
You’ll see information such as:
- Whether the scheduler is enabled
- The configured sync interval
- The next sync cycle
- Whether a sync is currently running
- The last sync cycle
For most environments, I’d leave the scheduler at its default interval.
You’ll often see a 15-minute interval suggested as a way of making changes appear in Microsoft Entra ID faster.
That won’t work. The supported minimum synchronisation interval is 30 minutes.
If you have a legitimate reason to run synchronisation less frequently, you can increase the interval. For example:
Set-ADSyncScheduler -CustomizedSyncCycleInterval 01:00:00
That configures a one-hour interval.
For most organisations, though, changing the scheduler isn’t where I’d start when looking for performance improvements.
Run a delta sync when you actually need one
If you’ve just created or changed an object and don’t want to wait for the next scheduled cycle, you can trigger a delta synchronisation:
Start-ADSyncSyncCycle -PolicyType Delta
This is the command I’d use for a normal “I changed something in AD and need it in Entra ID” situation.
A delta cycle processes changes since the previous synchronisation rather than reprocessing the entire directory.
Check the scheduler before doing this:
Get-ADSyncScheduler
If another synchronisation is already running, don’t keep firing off additional commands. Find out what’s currently happening first.
Be very careful with an Initial sync
You’ll sometimes see this command recommended when troubleshooting:
Start-ADSyncSyncCycle -PolicyType Initial
This is not simply a larger delta sync.
An Initial synchronisation causes the synchronisation engine to perform the more comprehensive processing required after configuration changes. On a large environment, that can take considerably longer than a normal delta cycle.
I wouldn’t run it simply because a user hasn’t appeared in Microsoft Entra ID yet.
First find out why the object isn’t synchronising.
If you’ve changed synchronisation rules or scope, an Initial sync may be required, but that’s a different situation from forcing a normal synchronisation cycle.
Reduce the number of objects in scope
One of the more useful optimisation techniques is making sure you’re only synchronising objects that actually need to exist in Microsoft Entra ID.
If you’ve got years of legacy Active Directory objects sitting in the directory, there is little benefit in automatically putting every one of them into the cloud.
Microsoft Entra Connect provides several filtering mechanisms, including:
- Domain filtering
- OU filtering
- Group-based filtering for pilot scenarios
- Rule-based filtering
For a normal production environment, OU and domain filtering are often the simplest places to start.
For example, you might have:
OU=Users
OU=Service Accounts
OU=Computers
OU=Legacy
OU=Disabled
If Legacy contains objects that have no business in Microsoft Entra ID, excluding that OU is preferable to synchronising everything and trying to clean it up afterwards.
Microsoft documents OU and domain filtering as ways to control the synchronisation scope.
Be very careful when removing objects from scope
This is one of the areas where “optimising” can create a much bigger problem.
If an object is already synchronised and you remove it from scope, Microsoft Entra Connect can process that as a deletion from the cloud directory.
That can have knock-on effects, including changes to group memberships and access.
So don’t make a large OU-filtering change on a production server simply because an OU contains objects you don’t think you need.
Before changing the scope, understand:
- Which objects are currently synchronised
- Which objects will leave the scope
- What those objects are used for
- Whether they are members of synchronised groups
- Whether applications depend on them
- What exports the change will generate
This is exactly where a staging server becomes useful. A scope change is much easier to reason about when you can see what the synchronisation engine intends to do before it becomes a production export.
Don’t edit the built-in synchronisation rules
You’ll often hear that unnecessary attribute flows should simply be disabled to reduce synchronisation overhead.
Be careful with that advice.
Microsoft Entra Connect contains built-in synchronisation rules that Microsoft can update between product versions. Don’t modify those built-in rules directly.
If you need to customise attribute flow or object processing, use the supported custom-rule approach through the Synchronization Rules Editor rather than modifying Microsoft’s rules in place.
This matters for more than supportability.
Imagine you modify one of Microsoft’s standard rules because you don’t need a particular attribute. Six months later, you upgrade Connect Sync and Microsoft has changed that rule to support a new feature or fix a problem.
Your modified version doesn’t necessarily receive that change in the same way.
If you have custom rules, document them.
I’d also review them before an upgrade rather than discovering afterwards that a synchronisation rule from three years ago is responsible for the behaviour you’re seeing.
Staging mode is worth having
If identity synchronisation is important to your organisation, having a second Entra Connect server in staging mode is worth considering.
A staging server imports and processes synchronisation data but doesn’t export changes to Microsoft Entra ID.
That gives you a useful safety net when:
- Upgrading Entra Connect
- Testing configuration changes
- Testing synchronisation rules
- Recovering from a failed primary server
- Preparing for configuration changes
The staging server isn’t an active load-balancing server. Its value is primarily in high availability and controlled change management.
It also gives you somewhere to validate significant changes before putting them onto the active synchronisation server.
For filtering and synchronisation-rule changes, this can be particularly valuable because a mistake in scope can result in objects being removed from Microsoft Entra ID.
Check sync health properly
When someone says “Entra Connect is broken”, there are several different things that could actually be wrong.
Start with the scheduler:
Get-ADSyncScheduler
Then look at the Synchronization Service Manager on the Connect Sync server.
The Operations tab is particularly useful because it shows the actual import, synchronisation and export runs.
Look for:
- Failed runs
- Large increases in processing time
- Large numbers of adds or deletes
- Export errors
- Objects repeatedly failing
- A connector that hasn’t completed successfully
Get-ADSyncConnectorRunStatus can tell you whether a connector operation is currently running, but it isn’t a general health check.
For troubleshooting, I’d use the scheduler, Synchronization Service Manager and the actual connector errors together.
The errors I’d investigate first
Duplicate proxyAddresses
Duplicate SMTP addresses are a common reason for objects failing to synchronise.
For example, if two AD objects contain:
SMTP:user@company.com
Microsoft Entra ID can’t represent both objects with the same unique address.
Find the conflicting objects in Active Directory before changing synchronisation rules.
Duplicate or incorrect UPNs
The user’s userPrincipalName also needs to make sense for the Microsoft Entra environment.
A user might exist in AD with:
user@company.local
while the intended cloud sign-in is:
user@company.com
The solution isn’t necessarily to change Entra Connect. Sometimes the underlying AD attribute is simply wrong.
Objects outside the synchronisation scope
If a user isn’t appearing in Microsoft Entra ID, check whether the object is actually inside the configured scope.
OU filtering is an obvious place to check.
The Synchronization Service Manager can also show whether the object exists in the connector space and whether it has been filtered.
Objects stuck in the connector space
If an object has been imported but isn’t making it through to the metaverse or Microsoft Entra ID, inspect that object’s path through the synchronisation engine.
The Synchronization Service Manager is particularly useful here because you can inspect the connector space and metaverse information for an individual object.
That is generally much more useful than simply running another sync and hoping the problem disappears.
Optimisation isn’t always about making sync faster
If your synchronisation cycle takes 45 minutes, the answer isn’t automatically to change the scheduler.
First ask why it takes 45 minutes.
You might have:
- Too many objects in scope
- An unusually large number of changes
- A synchronisation-rule problem
- Export errors causing repeated processing
- A configuration change requiring more extensive processing
- An ageing or undersized server
- A problem with the connected directory
- A large number of unnecessary objects
Reducing the number of objects that genuinely need to synchronise can be useful.
But changing the scheduler doesn’t make the synchronisation engine itself faster.
A sensible approach to an existing environment
If I inherited an existing Microsoft Entra Connect Sync server, I’d work through it in roughly this order.
1. Check the version
Make sure it’s at least 2.5.79.0, and preferably move to the latest supported release.
2. Understand the current scope
Find out which domains and OUs are synchronised.
Don’t change anything yet.
3. Check the scheduler
Run:
Get-ADSyncScheduler
Make sure you’re not dealing with a custom schedule that somebody configured years ago and forgot about.
4. Look at actual sync operations
Open Synchronization Service Manager and look at recent operations.
Look for errors, unusually long runs and unexpected volumes of changes.
5. Investigate recurring errors
A single failed object isn’t necessarily a performance problem.
Hundreds of repeated export or attribute errors are worth investigating.
6. Review filtering
Look for legacy OUs and other objects that genuinely don’t need to exist in Microsoft Entra ID.
Don’t remove objects from scope without understanding the consequences.
7. Review custom synchronisation rules
Document what has been customised.
If someone has modified built-in rules directly, that’s something I’d want to understand before performing the next upgrade.
8. Consider Cloud Sync
Once you understand what the current environment actually depends on, compare those requirements with Microsoft Entra Cloud Sync.
That gives you a much better basis for deciding whether to optimise Connect Sync or start planning a migration.
The bigger question
There was a time when an article about optimising Azure AD Connect could reasonably focus almost entirely on making the synchronisation engine faster.
That’s no longer the whole story.
If you’re still running Microsoft Entra Connect Sync, there are two questions worth answering.
Is the current installation supported and healthy?
And:
Is Connect Sync still the right synchronisation platform for this environment?
The first has a clear answer. You need to be on at least 2.5.79.0, and realistically on the latest release available to you, or synchronisation doesn’t run.
The second requires more investigation. Microsoft Entra Cloud Sync is the longer-term direction, but that doesn’t mean every Connect Sync deployment can or should be migrated immediately. The right choice depends on the features and topology your environment actually uses.
So before spending hours trying to shave a few minutes off a synchronisation cycle, I’d first make sure you’re running a supported version, understand what is actually taking the time, and check whether you’re optimising a platform you ultimately want to replace.
That’s a much more useful starting point than simply changing the sync schedule and hoping things get faster.
From my early days on the helpdesk through roles as a service desk manager, systems administrator, and network engineer, I’ve spent more than 25 years in the IT world. As I transition into cyber security, my goal is to make tech a little less confusing by sharing what I’ve learned and helping others wherever I can.