Lesson 28 — Microsoft Entra Cloud Sync
Microsoft Entra Cloud Sync is a cloud-managed hybrid identity synchronisation service that uses lightweight provisioning agents installed in the on-premises environment.
Unlike Microsoft Entra Connect Sync, most configuration and orchestration occurs in Microsoft Entra, while the provisioning agents provide secure outbound connectivity to Active Directory.
This lesson explains Cloud Sync architecture, agent pools, configuration scope, attribute mappings, accidental-delete protection, high availability, monitoring, troubleshooting, migration and operational security.
What you will learn
This lesson explains how Microsoft Entra Cloud Sync securely provisions hybrid identities through cloud-managed configurations and resilient on-premises agents.
Learning objectives
After completing this lesson, you should be able to design, operate and troubleshoot Microsoft Entra Cloud Sync.
- Explain the Cloud Sync architecture and data flow.
- Understand provisioning agents and agent groups.
- Configure scope, filters and attribute mappings.
- Describe high availability with multiple active agents.
- Monitor provisioning status, logs and agent health.
- Investigate common synchronisation failures.
- Plan coexistence or migration from Connect Sync.
The problem this solves
Traditional hybrid synchronisation places more configuration and processing on a dedicated synchronisation server.
Cloud Sync moves orchestration into Microsoft Entra and uses lightweight on-premises agents, making distributed forests and resilient agent deployment easier to operate.
Microsoft Entra Cloud Sync architecture
What is Cloud Sync?
Microsoft Entra Cloud Sync synchronises selected identities between on-premises Active Directory and Microsoft Entra ID using the Microsoft Entra provisioning agent.
Configuration is created and managed in the Microsoft Entra admin centre rather than primarily on the local server.
Cloud-managed orchestration
The Microsoft Entra provisioning service evaluates scope, mappings and synchronisation logic in the cloud.
The local agent securely performs directory operations without requiring inbound firewall ports from Microsoft Entra.
Core components
| Component | Purpose | Operational question |
|---|---|---|
| Cloud Sync configuration | Defines directory, scope, mappings and provisioning behaviour. | Is the correct configuration enabled and scoped? |
| Provisioning agent | Connects Microsoft Entra provisioning services to Active Directory. | Is the agent active and communicating? |
| Agent group | Groups agents that service the same directory connection. | Are enough healthy agents available? |
| gMSA | Provides managed credentials for directory operations. | Does the account have required permissions? |
| Provisioning service | Evaluates objects and executes cloud-managed synchronisation. | Are cycles completing successfully? |
| Provisioning logs | Record object-level actions, skips and failures. | What happened to each identity? |
The provisioning agent
The agent is lightweight compared with a full Microsoft Entra Connect Sync deployment.
It maintains secure outbound communication and performs Active Directory operations requested by the Microsoft Entra provisioning service.
Agent server placement
- Use a supported Windows Server version.
- Ensure reliable connectivity to domain controllers.
- Provide outbound HTTPS access.
- Protect the server as identity infrastructure.
- Avoid unnecessary applications and roles.
- Monitor service, CPU, memory and disk health.
Agent communication model
No inbound firewall rule
The service uses outbound connectivity from the agent to Microsoft Entra services.
This simplifies network exposure, but proxy, TLS inspection, DNS and firewall controls can still interrupt communication.
Agent status
Review the Agents page and confirm every expected agent is active.
An installed Windows service is not enough—the agent must also be registered and visible in Microsoft Entra.
High availability with agent pools
Multiple active provisioning agents can be installed for the same environment. Microsoft Entra selects an available agent, providing resilience without a traditional active-passive server design.
| Design | Behaviour | Operational effect |
|---|---|---|
| One agent | All provisioning depends on one server. | Simple but creates a single point of failure. |
| Multiple active agents | Agents participate in the same pool. | Provisioning can continue if one agent fails. |
| Separated failure domains | Agents run on different servers or infrastructure. | Reduces shared host and maintenance risk. |
| Consistent network access | Every agent can reach required domain controllers and cloud endpoints. | Avoids partial failover. |
High availability is not just installation
Additional agents only improve resilience when they are active, current and able to reach the same required directory resources.
Test service continuity by safely taking one agent offline during a maintenance exercise.
Patch agents independently
Use multiple agents to allow staged maintenance.
Confirm remaining agents are healthy before stopping or upgrading another agent.
Cloud Sync configuration workflow
Configuration scope
Scope determines which users, groups or organisational units are processed.
Start with a controlled pilot group and expand only after verifying object matching, attributes and application impact.
One source of synchronisation
An object should not be managed by both Connect Sync and Cloud Sync for the same synchronisation responsibility.
Overlapping scope can cause confusing ownership, matching and deletion behaviour.
Scoping methods
| Method | Use | Risk |
|---|---|---|
| Organisational unit scope | Select identities by directory location. | Object moves can unexpectedly change scope. |
| Group-based scope | Use membership to control pilot or production populations. | Membership changes affect synchronisation. |
| Attribute filters | Include or exclude objects based on data. | Incorrect or missing values can skip identities. |
| All eligible objects | Broad production deployment. | Large blast radius if mappings are wrong. |
Test provisioning
Use test provisioning to preview how a selected object will be evaluated.
Confirm scope, matching, source attributes, target attributes and the expected action before enabling broad synchronisation.
Scope changes are security changes
Adding an organisational unit or group can provision many identities.
Require change approval, peer review and post-change validation.
Attribute mapping
| Mapping concept | Purpose | Example |
|---|---|---|
| Direct mapping | Copies a source value to a target attribute. | displayName to displayName. |
| Expression mapping | Builds or transforms a target value. | Constructing a cloud user principal name. |
| Matching attribute | Links an on-premises object to an existing cloud object. | Object identifiers or supported matching values. |
| Constant value | Applies the same value to all scoped objects. | Usage location for a controlled population. |
| Null handling | Controls behaviour when the source value is absent. | Preserve or clear the target value. |
Mapping safety
Do not change mappings without understanding which system owns the target attribute.
Test with representative users, including names, locations and attributes that contain unusual characters or null values.
Object matching
Matching determines whether Cloud Sync updates an existing cloud identity or creates a new one.
Incorrect matching can produce duplicates, failed provisioning or unintended object ownership.
Accidental-delete protection
Why deletion thresholds matter
A small scoping mistake can otherwise remove many cloud identities from synchronisation.
Set a threshold appropriate to the environment and investigate every threshold breach before overriding it.
Quarantine
Provisioning can enter quarantine after repeated failures or potentially dangerous conditions.
Do not restart repeatedly without identifying the underlying error and affected object scope.
Provisioning status
| Status area | What to review | Concern |
|---|---|---|
| Current cycle | Whether provisioning is active, paused or quarantined. | Unexpected inactivity. |
| Last successful cycle | Most recent completed processing. | Stale synchronisation. |
| Objects processed | Created, updated, skipped and failed counts. | Sudden volume change. |
| Agent status | Active agents in the selected group. | Single remaining agent or no active agents. |
| Error summary | Repeated object or connector failures. | Widespread identity impact. |
Restart sync
Restart sync can trigger processing without waiting for the next scheduled cycle.
Use it after a validated configuration correction—not as a substitute for understanding repeated failures.
Disable before major edits
For significant scope or mapping changes, consider disabling the configuration, testing carefully and then re-enabling it through change control.
Document the expected object counts before and after the change.
Provisioning logs
Provisioning logs provide the most important object-level evidence for Cloud Sync investigations.
| Field | Use | Investigation question |
|---|---|---|
| Action | Create, update, delete, skip or other operation. | What did Cloud Sync attempt? |
| Status | Success, failure or skipped. | Did the action complete? |
| Source identity | Identifies the Active Directory object. | Which on-premises identity was evaluated? |
| Target identity | Identifies the Microsoft Entra object. | Which cloud identity was affected? |
| Modified properties | Shows attribute changes. | Which values were written? |
| Error details | Provides reason and remediation context. | Why did provisioning fail? |
Audit logs
Audit logs record administrative changes to Cloud Sync configurations and related identity settings.
Use them to correlate failures with scope changes, mapping edits, agent registration and configuration enablement.
Baseline object counts
Track normal create, update, skip and failure counts.
A sudden drop to zero or unexpected increase in deletes should trigger investigation.
Common troubleshooting areas
| Symptom | Likely area | First checks |
|---|---|---|
| Agent not detected | Registration, service or outbound connectivity | Agent status, service, proxy, DNS and TLS. |
| Configuration not running | Disabled, quarantined or no active agent | Status page, agent group and provisioning logs. |
| User skipped | Scope or filter evaluation | Group membership, OU and test provisioning. |
| Duplicate user created | Object matching | Matching attributes and existing cloud identity. |
| Attribute not updated | Mapping or source data | Modified properties and mapping expression. |
| Many deletions pending | Scope change | Recent configuration edits and delete threshold. |
Agent registration failures
- PowerShell execution policy interference.
- Proxy or firewall restrictions.
- Unsupported TLS configuration.
- Insufficient installation permissions.
- Missing prerequisites.
- Tenant authentication or role problems.
Agent service failures
Confirm the Microsoft Entra Connect Provisioning Agent service is running and review its local logs.
Repeated service restarts without diagnosis can hide a dependency or certificate problem.
Agent Foskett investigation: “The agent was active…”
Evidence to preserve
- Configuration status and quarantine reason.
- Provisioning log records.
- Agent status and version.
- Recent audit log changes.
- Scope and attribute mapping screenshots.
- Expected and actual object counts.
- Change record for the directory modification.
Validate recovery
- Run test provisioning for representative users.
- Confirm delete count returns to normal.
- Restart provisioning.
- Confirm create and update actions succeed.
- Confirm no duplicate cloud identities appear.
- Monitor the next complete cycle.
Cloud Sync and Connect Sync
| Area | Cloud Sync | Connect Sync |
|---|---|---|
| Configuration location | Primarily Microsoft Entra admin centre | Primarily local Connect server |
| On-premises component | Lightweight provisioning agent | Full synchronisation engine and database |
| High availability | Multiple active agents in a pool | Active server with staging server |
| Processing model | Cloud-orchestrated provisioning | Local synchronisation engine |
| Distributed forests | Agent-based deployment close to each forest | Central connectivity to configured forests |
| Feature suitability | Evaluate supported Cloud Sync scenarios | Use where required capabilities are not yet suitable for Cloud Sync |
Choose by requirements
Cloud Sync is not selected only because it is newer or simpler.
Compare required topology, writeback, filtering, attribute and hybrid application scenarios against current supported capabilities.
Current feature verification
Cloud Sync capabilities continue to expand.
Use current Microsoft documentation and pilot testing rather than relying on an old feature comparison.
Coexistence and migration
Pilot safely
Use a representative group that includes ordinary users, privileged users, groups and edge-case attributes.
Do not pilot with only simple test identities if production contains complex matching or application dependencies.
Document ownership
During coexistence, record which engine owns each forest, organisational unit, group and object population.
Ambiguous ownership is a common source of duplicate or missing identities.
Daily operational review
| Review | Question | Evidence |
|---|---|---|
| Agent health | Are expected agents active? | Agents page and local service monitoring. |
| Provisioning status | Is the configuration running normally? | Current cycle and last successful cycle. |
| Object outcomes | Are failures or skips increasing? | Provisioning logs and status counts. |
| Deletion safety | Are delete counts expected? | Deletion threshold and pending actions. |
| Scope | Are intended users and groups still included? | Configuration and test provisioning. |
| Changes | Were mappings or configuration edited? | Audit logs and change records. |
Weekly review
- Review failed and skipped object trends.
- Confirm all agents are current.
- Review recurring quarantine events.
- Test representative objects.
- Review scope membership changes.
- Confirm support ownership.
Monthly review
- Test agent failover.
- Review deletion threshold suitability.
- Review attribute mapping ownership.
- Review agent server hardening.
- Compare Cloud Sync features with future requirements.
- Update migration or coexistence documentation.
Common mistakes
| Mistake | Impact | Better practice |
|---|---|---|
| Deploying only one agent | Agent maintenance stops synchronisation. | Use multiple active agents across failure domains. |
| Overlapping Connect and Cloud Sync scope | Object ownership and matching conflicts. | Assign each object to one synchronisation path. |
| Skipping test provisioning | Mapping and scope errors reach production. | Test representative objects before enablement. |
| Ignoring quarantine | Provisioning remains stopped. | Investigate the reason and correct the source condition. |
| Overriding deletion protection immediately | Large unintended deletion can proceed. | Validate scope and change history first. |
| Checking only agent status | A healthy agent can coexist with a failed configuration. | Review status, logs and object outcomes together. |
| Using old comparison guidance | Design decisions miss current capabilities. | Verify current Microsoft documentation. |
Security best practices
- Treat agent servers as privileged identity infrastructure.
- Restrict local and remote administration.
- Use gMSA and least-privilege directory permissions.
- Monitor agent registration and configuration changes.
- Protect outbound connectivity without breaking required endpoints.
- Keep agents and Windows Server supported.
- Review unexpected scope and delete changes immediately.
Operational checklist
- Multiple active agents deployed.
- Agent versions current.
- Configuration enabled and healthy.
- Scope documented.
- Mappings reviewed.
- Deletion threshold configured.
- Provisioning logs monitored.
- Test provisioning validated.
- Migration ownership documented.
Key takeaways
- Microsoft Entra Cloud Sync uses cloud-managed configurations and lightweight on-premises provisioning agents.
- The agents use secure outbound communication and do not require inbound cloud connections.
- Multiple active agents provide high availability without a traditional active-passive design.
- Scope, object matching and attribute mappings determine which identities are created or updated.
- Accidental-delete protection can stop a destructive scope change before widespread deletion.
- Provisioning logs provide object-level evidence for creates, updates, skips, failures and deletions.
- A healthy agent does not prove that a Cloud Sync configuration is processing successfully.
- Cloud Sync and Connect Sync can coexist only with carefully separated object scope.
- Migration should use controlled pilots, clear ownership and current capability verification.
- Monitor agents, configuration status, object outcomes and audit changes together.
Related Agent Foskett resources
Continue learning
Microsoft Entra Cloud Sync
Microsoft Entra Cloud Sync provides cloud-managed hybrid identity synchronisation using lightweight on-premises provisioning agents, secure outbound connectivity and resilient agent pools.
Microsoft Entra Academy Lesson 28 — Cloud Sync
This Agent Foskett lesson explains Cloud Sync architecture, provisioning agents, high availability, scope, attribute mappings, accidental-delete protection, provisioning logs, troubleshooting and migration planning.
