Entra Connect or Cloud Sync: which one suits your organisation?

Cloud Sync sounds like the obvious modern choice, but your existing setup and exceptions can matter more than which technology is newer.

Microsoft Entra Connect Sync is the successor to Azure AD Connect and DirSync. You install it on a dedicated Windows server, with a sync engine, a database and a Synchronization Rules Editor in which you can customise everything. If that server stops, the sync stops; a second server can only run alongside in staging mode.

Microsoft Entra Cloud Sync works differently. The Microsoft Entra provisioning agent runs on one or more servers in your network, a domain controller included. It only makes outbound connections and is updated automatically. The configuration, the scheduling and the processing sit in the cloud, and you manage everything from the Entra admin center. Several agents are active at the same time, so if one fails, the sync carries on.

When do you stay with Connect Sync? If you have more than 150,000 objects per domain, groups with more than 50,000 members, complex custom sync rules, merge attributes from several forests, or manage pass-through authentication and AD FS from the sync. For most organisations with one forest and a few thousand accounts, Cloud Sync fits. Microsoft has a migration tool and a decision guide for the move.

For IT, half an hour is often fine. For an employee who cannot sign in on their first day, it feels very different.

With Connect Sync a synchronisation cycle runs every 30 minutes by default. You can make that interval longer; shorter than Microsoft allows is not possible. Microsoft does require a cycle to run at least once every seven days; otherwise you need a full synchronisation to get back on track. To push a change through immediately, start a delta cycle yourself on the Connect server:

Import-Module ADSync

# The current schedule and the next run time
Get-ADSyncScheduler

# Push only the changes through now
Start-ADSyncSyncCycle -PolicyType Delta

# Full cycle, needed after changing sync rules or filters
Start-ADSyncSyncCycle -PolicyType Initial

With Cloud Sync no cmdlet is needed. The sync runs every two minutes, and for a single user you can choose Provision on demand under the configuration in the Entra admin center. You then see step by step what happens to the object, which is also the quickest way to find a mapping error.

If you started with accounts in the cloud and only turn on a sync afterwards, or you rebuild a user in AD, Entra ID has to know whether the incoming AD object is the same as an account that already exists. That is called matching, and there are two kinds:

• Accounts with an administrator role are not matched by default. Microsoft advises against linking AD accounts to existing administrator accounts in the cloud.
• `AttributeValueMustBeUnique` appears when a new AD object has the same primary email address or the same SID as an existing account, but a different sourceAnchor. Usually the user has been recreated in AD. The fix is to set the AD object's mS-DS-ConsistencyGuid equal to the cloud account's ImmutableId, so a hard match follows.
• Turning matching off is possible per tenant, and Microsoft recommends it once you no longer need it. With BlockSoftMatchEnabled and BlockCloudObjectTakeoverThroughHardMatchEnabled you prevent an AD object from accidentally taking over a cloud account.

Connect-MgGraph -Scopes "OnPremDirectorySynchronization.ReadWrite.All"

$sync = Get-MgDirectoryOnPremiseSynchronization
$sync.Features.BlockSoftMatchEnabled = $true
Update-MgDirectoryOnPremiseSynchronization `
  -OnPremisesDirectorySynchronizationId $sync.Id `
  -Features $sync.Features

Moving a synchronised account to the cloud used to be cumbersome. Now you can do it per user. With the isCloudManaged property on onPremisesSyncBehavior you move the source of authority (SOA) of a single user to Entra ID. From then on the sync ignores changes from AD for that account, and you manage it in the cloud.

• You need the Hybrid Administrator role and the User-OnPremisesSyncBehavior.ReadWrite.All permission. No extra licence is needed.
• The sync has to support it: Connect Sync from version 2.5.76.0, or the Cloud Sync agent from 1.1.1370.0.
• The change appears in the audit logs as "Change Source of Authority from AD to cloud".
• If the account still needs access to on-premises resources, such as a file server, you have to keep the on-premises attributes (such as onPremisesSamAccountName and onPremisesSecurityIdentifier) up to date yourself.
• You can roll it back by setting isCloudManaged to false. It only takes effect after the next sync cycle.

Connect-MgGraph -Scopes "User-OnPremisesSyncBehavior.ReadWrite.All"

$id = (Get-MgUser -UserId "jan.jansen@bedrijf.nl").Id
Update-MgUserOnPremiseSyncBehavior -UserId $id -BodyParameter @{ isCloudManaged = $true }

# Check
Invoke-MgGraphRequest -Method GET `
  -Uri "https://graph.microsoft.com/v1.0/users/$id/onPremisesSyncBehavior?`$select=isCloudManaged"

Many synchronisation problems start with incorrect data or with changes made in the wrong place.

• Changing the account in the cloud. For a synchronised user, name, department, job title and the extension attributes are read-only in Entra ID. Change them in AD. Which fields matter is covered in user attributes in Entra ID.
• Leaving the wizard open. As long as the Connect Sync installation wizard is open, the scheduler is paused and nothing is synchronised.
• A second active Connect server. Only one may be active; a second runs in staging mode, and you have to switch it over deliberately if the first one fails.
• Disabled in AD, but active in the cloud. If you use a sync interval of an hour or longer, a leaver can still get into Microsoft 365 for a while after being disabled in AD. For an urgent departure, revoke the sessions as well.
• An OU outside the scope. If you move a user to an OU that is not synchronised, the sync treats that as a deletion, and the account in Entra ID goes to the recycle bin.