Microsoft Entra Cloud Sync - Simply Explained

Hello everyone and welcome to another episode of Microsoft Knowledge Nuggets here on M365. FM, Eau, TMNM, Mirko Peters. What exactly is Microsoft Entra Cloud Sync? Is it just another name for Entra Connect or does it solve a different problem? Many companies still keep employee accounts in Active Directory inside their own network. Yet employees work in Microsoft 365. They need Teams, Exchange Online Email, OneDrive Files and Cloud Apps. That creates two places where identity matters. Without a link between them, someone might exist in Active Directory but not in Entra ID, the Cloud Reception Desk for Microsoft 365. passwords don't automatically match. Access arrives late. IT ends up doing the same work twice. Entra Connect became the familiar local tool for linking those two places. Cloud Sync takes a different path. With more of the sync work handled in Microsoft Entra. By the end, you would know what it does, why it exists and what changed in 2026. But one boundary still decides whether it fits your company. My identity sync needs a simpler model. Start with a new employee, HR tells IT that Maya starts on Monday. Someone creates my out-temiz account in Active Directory, which many companies still use as the local start filing cabinet. Her name, work email, department, manager, group membership and password details all begin there. But Maya does not make work only inside the company network. She needs to sign into Teams from home. She needs her Exchange Online mailbox. Her team stores files in SharePoint and she may need access to payroll, CRM, training or other cloud apps before her first day ends. One person needs one working identity. That identity needs to appear in both places while still referring to the same Maya. Her sign-in name needs to match. Her group information needs to reach the cloud. When her password changes in Active Directory, Microsoft 365 needs a safe way to confirm that password too. That opens the job of Identity Sync. Think of Active Directory as the filing cabinet in the basement of an office building. It holds the staff records the company already trusts. Entra ID sits at reception upstairs, deciding who can enter Microsoft 365 and which rooms they can use. If the filing cabinet and reception desk, Donau, Temt, Share information, Maya gets stopped at the door. 20 years ago, that gap caused a lot of manual work, an IT team might create one account locally, then create another account in a cloud service. When Maya changed her name, changed Teams, or left the company, somebody needed to remember every place where her details lived. People forget. That u-tems-wise, thinking identity changed daily IT work. A change in Active Directory could flow into Entra ID, so the cloud account followed the local account instead of becoming a second separate record. For a long time, Entra Connect handles that work. Entra Connect runs on a server inside the company network. It reads Active Directory, applies local sync rules, keeps its own local data store, and sends approved changes to Entra ID. It can do a lot, especially when a company needs deep control over how data moves. That flexibility comes with responsibility. Someone needs to look after the server, someone needs to patch it. Someone needs to understand the local rules if a user does notemptet sync as expected. And if the main sync server stops working, changes can stop reaching Microsoft 365 until IT fixes the issue, or follows a recovery plan. For Maya, that might mean her account waits. For a company with hundreds or thousands of people, it can mean new starters, Dona Will Demd, appear in cloud apps, disabled accounts take longer to lose access, and support calls start piling up. The problem is now that Entra Connect failed as a product. It outtoms that every local engine brings local work with it. Many companies want fewer moving parts on their own servers. Cloud Sync follows that idea. Instead of placing the large sync engine, detailed processing, and most of the rules inside your network, Microsoft Entra handles much of that work in the cloud. Your local network keeps a smaller connection point that can read Active Directory and safely communicate outward. The filing cabinet stays where it is. The processing moves closer to the reception desk that can reduce the amount of local software your team needs to manage, while keeping Active Directory as the place where employee details begin. It also changes how you think about recovery, especially when a company has more than one office, more than one directory, or a recent merger to deal with. So if the main sync work runs in the cloud, what exactly stays inside your company network? But what Microsoft Entra Cloud Sync actually is? Microsoft Entra Cloud Sync is a cloud-managed way to copy selected people, groups, and contacts from Active Directory into Entra ID. Think of it as a secure career service. Your Active Directory holds the staff records inside your network. Active Directory ID needs the approved parts of those records so people can sign into Microsoft 365. Cloud Sync puts a small career called the provisioning agent inside your network to carry that information safely between the two. The career does now and it holds a second filing system. It reads the directory information you approve, encrypts it, and sends it through an outbound connection to Microsoft Entra. An outbound connection means the agent starts the conversation with the cloud. You don't need to open your network and wait for an unknown connection to come in. That UTIMS are useful security detail. The agent can reach Active Directory because it sits inside your network. Microsoft Entra can process the data because the agent sends it securely to the cloud. The two sides can work together without placing the full sync engine on your own server. Behind the scenes, Entra handles the larger part of the job. It checks whether a person already exists in Entra ID. It applies your chosen scope. It follows the field mappings you set. Then it creates or updates the cloud object when the information matches your rules. You manage those choices in the Entra portal. This is a big change if you know Entra Connect. With Entra Connect, much of the logic and troubleshooting work happens on the server that runs the sync tool. With Cloud Sync, you create a configuration in the portal, choose what should sync, map the fields, and check the results in one cloud location. The local agent stays small. There opens no large local sync engine with a local SQL database for Cloud Sync. You are now TM, T, opening a local rule editor every time you need to check a basic mapping. Microsoft handles updates to the agent while your team focuses on the identity rules that matter to the business. That does not invite team in you lose control. You still choose the people and groups that can enter Entra ID. You can choose fields such as display name, department, phone number, or manager. A mapping simply answers a plain question. Rich label on the Active Directory record should fill which label in Entra ID. For many companies, the default mappings cover normal staff accounts. If your Active Directory display name says Maya Patel, Entra ID can receive Maya Patel. If her department changes from sales to customer success, that update can reach her cloud account. If her group membership gives her access to a Microsoft 365 resource, the group information can sync to. Some setups need small changes. Cloud Sync includes simple expressions for cases where you need to adjust a value as it moves. Maybe a company wants a suffix added to a display name for a certain set of accounts. You can set that in the cloud configuration rather than building a deep set of local sync rules. Keep that distinction in mind. Cloud Sync gives you sensible control for common identity work. It is now demand designed to copy every advanced customization that a long running Entra Connect setup may contain. We will come back to that decision later because it can save you from choosing the tool just because I do TMones newer. Passwords cause the most questions. Cloud Sync can use password hash synchronization. That phrase sounds more alarming than it is. The readable password does now TMRT get sent to Microsoft Entra. Instead Active Directory creates protected password verification information and Entra ID uses that information to check a person's mouse to TMRT sign in safely. So Maya can use her company password for Microsoft 365. Her password still begins in Active Directory. When she changes it there, the updated verification information syncs to Entra ID. Microsoft 365 can then confirm her sign in without storing a readable copy of the password. One ownership rule keeps everything clear. When a user syncs from Active Directory, Active Directory remains the place where you added the syncs details. If MayaoTemps department or drop title needs to change, you change it in Active Directory, then Cloud Sync carries that change to Entra ID. You will often see those Cloud fields locked for editing. That is no-term it a problem. It tells you where the account comes from. You can change that ownership later through a planned source of authority change, but Cloud Sync does now attempt silently turn local accounts into Cloud Managed accounts. The agent explains why Cloud Sync feels lighter, but the next part explains why it can also keep working when one server drops offline. How Cloud Sync keeps working when a server fails? A Sync tool only helps while it can reach Active Directory. Picture a Monday morning when a server needs an urgent restart, or it's disk fails without warning. A manager creates a new starter in Active Directory, but that person does not empty appear in Microsoft 365. Someone disables an employee who has left, but the Cloud account waits for the change. Those delays create real work for IT. With a traditional Entra Connect setup, companies often run one Active Sync server and keep another server in staging mode as a backup. That backup needs planning, testing, and a clear process for taking over when the Active server fails. Cloud Sync takes a different route. You can install more than one provisioning agent in the same Active Directory domain. Each agent connects to the same Cloud Sync configuration in Microsoft Entra, and each one can read the same directory information. You don't know TNT. You need to treat one agent like the permanent boss. Microsoft Entra watches the available agents. If one agent goes offline, the Cloud service can use another healthy agent to continue the work. That is built in high availability, which simply means you avoid having one server become a single point of failure. Think of two help desks using the same staff directory. If one desk closes for the day, the other desk can still take calls and check people in. The people in the company don't know TNT need to know which desk handled their request. They just need their access to work. That utems the practical benefit. Instead of building a manual failover plan around a large local Sync engine, you install more than one lightweight agent and let Entra use the agents that are online. You should still monitor agent health, keep the server supported and test your recovery plan. Built in failover does not timet, remove the need for responsible IT. It does remove some of the pressure from one machine. Cloud Sync also helps when a company has separate Active Directory forests. A forest is a separate Active Directory environment. You might have one because your company bought another business. The two companies may use different domains, different networks, and separate local directories that can now TNT directly talk to each other. That outtems common after a merger. With Cloud Sync, you can install an agent near each forest. Each agent reads its own local Active Directory, then connects outward to the same Microsoft Entra tenant. The cloud becomes the shared destination, even when the local directories remain apart. No direct network pass between the forest is required for that setup. Imagine a company in London acquires a business in Toronto. Both teams need to use the same Microsoft 365 tenant, but connecting their old directory networks would take months and raise security questions. An agent in London can sync London accounts while an agent in Toronto syncs Toronto accounts. Both sets of users can arrive in the same Entra ID that can give a time to plan the larger directory work without blocking people from accessing teams, email and cloud apps. There are still practical requirements. Each agent needs a reliable connection to its local Active Directory. It also needs outbound access through your firewall or proxy to Microsoft UTMS cloud services. You don't know if T plays the agent on a random computer in hope for the best. Put it on supported servers, give it the right local access and install more than one agent for a production setup. Availability keeps the connection alive. But deciding which accounts should travel across that connection matters just as much. What gets synced and how you stay in control? Before cloud sync starts moving accounts into Entra ID, decide exactly who belongs in the syncs scope. Scope means the part of Active Directory cloud sync is allowed to read and copy. You can choose all supported objects in a domain that may suit a small company with one clean directory and one clear set of employee accounts. Large companies usually need more care because Active Directory can contain all test users, service accounts, training accounts and groups that nobody expects to see in Microsoft 365. A narrow starter void surprises cloud sync lets you limit the scope by organizational unit, often called an OU or by security group. An OU is like a labeled folder inside Active Directory. You might have one called O employees, O another called AU contractors, O and another called AU IT test accounts. A O. If only the employees OU should reach Microsoft 365, you can select that OU. Group-based scope gives you another option. Instead of selecting a whole folder, you choose a security group and add only the people you want to test. This works well when you want a small pilot without moving accounts around your directory. Start with a test group. Pick a few known users who can safely appear in Entra ID. Check their sign-in names, department details and group memberships. Confirm that the right accounts appear, then expand the scope when you trust the result. That small check can save a very long cleanup job. After you decide who can sync you decide which details travel with them. This is called attribute mapping, but it means something simple. Which field on an Active Directory account fills which field on the Entra ID account? A user record may include a first name, last name, display name, phone number, office, manager and department. Cloud sync includes default mappings for common setups. In many cases you should leave those defaults alone at first. They cover the normal fields most companies need and they make it easier to understand what changed if a result looks wrong. You can adjust a mapping when their O-tems are clear business reason. For example, a company might store a phone number in a local field that does know, "Tem match the Entra field it wants to fill." Cloud sync can map that field. It also supports simple expressions for small changes to a value without building a large set of local rules. But don't automate turn a clean setup into a puzzle. If your identity process depends on deep, unusual logic, write down that requirement before changing mappings. For normal accounts, clear defaults beat clever rules that nobody understands six months later. Cloud sync gives you a safe way to test before you enable a broad sync. It out to mappings called provision on demand. You choose one user and ask Cloud sync, "Oh, what would you do with this account?" A, A, O, the result shows whether the agent found the user, whether the user falls inside your scope, whether Entra ID found a matching account, and whether Cloud sync would create or update it. You can see the decision before it affects everyone else. Imagine an IT team builds a pilot group called O Cloud sync test. A, O, someone accidentally adds a larger group inside it, and that larger group contains hundreds of employees. Provision on demand exposes the scope problem while the team tests one person, rather than after hundreds of accounts appear in the tenant, that o-tim is the sort of mistake you want to find early. Cloud sync also includes accidental deletion protection. If a configuration suddenly tries to remove a large number of users or groups, the service can stop the run and place the configuration into quarantine instead of copying that damage straight into Entra ID. Humans receive an alert and can investigate. The Entra portal also gives you provisioning logs. Search for a user and you can see what happened. Whether the object matched, whether a field caused an error, whether the agent connected, and whether the configuration remains healthy, when identity sync works well, it feels quiet. When something goes wrong, those logs tell you where to look instead of leaving you to guess. Cloud sync now covers a wider range of needs, but it still does not meant replace every Entra Connect setup. Cloud sync versus Entra Connect and the 2026 shift. So should every company move from Entra Connect to Cloud sync? No, Cloud sync is newer but newer does not automatically mean it fits your setup. The right choice depends on what your identity system needs to do today, not on which product sounds more modern. Cloud sync suits companies that want a simpler local setup and cloud managed sync settings. It works well when you mainly need users, groups and contacts from Active Directory to appear in Entra ID. It also fits companies with separate forests, where each location can connect to the same Entra tenant without first joining all those local networks together. It gives you group-based scoping too. That can be helpful when you want to bring in one business unit, one new office or a small set of users first. You can keep the sync settings in the Entra portal, monitor the agents there, and avoid running a larger sync engine on one central server. Entra Connect still has a place. Some companies rely on sign-in methods that Cloud sync does now attempt support in the same way, such as pass through authentication or federation. Pass through authentication checks a password against Active Directory at the moment a user signs in. federation sends the sign-in request to another identity system, often one the company already uses, those setups need careful planning. Entra Connect can also suit companies with advanced local sync rules. Maybe they combine data from unusual fields, apply detailed filtering logic, or depend on old custom rules that took years to build, replacing that setup with a simpler tool, without checking every rule, can create problems. Exchange hybrid can also affect the choice. A company may still run parts of Exchange locally while using Exchange Online. Some Exchange tasks need details written back into Active Directory. So Microsoft 365 and the local Exchange Setup keep agreeing about mail-related information. Your exact Exchange Setup decides whether Cloud Sync supports what you need. That decision changed in 2026. Cloud Sync now includes Device Sync for Hybrid Entra ID join. That matters when company Windows devices still belong to local Active Directory, but also need an identity and Entra ID for Cloud Access and Management. For many companies, Device Sync kept Entra Connect in place. Now Cloud Sync can cover that need too, which removes one reason some teams could not attempt to consider it. You still need to check your device setup, your Windows plans, and how you use Intune, but the choice is no longer only about users and groups. Microsoft also added Exchange Hybrid attribute right back in public preview. In plain English, Cloud Sync can now send certain Exchange-related details from the Cloud back into Active Directory. Public preview means Microsoft is still gathering real world use and feedback before calling the feature fully released, so treat it with more care than a long established feature. So note them to move and Exchange setup based on one sentence in a product update. Read the current Microsoft documentation, test with non-production accounts, and confirm the exact attributes your company needs. Exchange can be unforgiving when identity details don't know the team match. Cloud Sync also brings familiar safety controls into the portal. You can use password hash sync, you can set notifications, so the right people hear about a problem, you can set accidental deletion protection. You can manage the configuration from Entra instead of treating the local Sync server as the center of everything. The tools are getting closer in coverage. Still, Cloud Sync is now a tamter replacement for Entra Connect in every company. Think of the choice like choosing a vehicle. A small van may suit a local delivery route because it out TME says easy to run and easy to park. A heavy truck suits a different job because it carries loads the van can out and neither choice is wrong. Ask a few direct questions before you decide. Do you have one Active Directory forest or several disconnected forests? Do you need Hybrid Device Sync? Do you rely on advanced custom rules? Which sign in method do you use? Does Exchange need right back? And if the current sync service fails, how quickly can you recover? Write down the answers. The final decision should note them. Start with an all at once migration. It should start with a small control test that proves Cloud Sync can handle your actual accounts and your actual requirements. A safe first move for your company. Start by drawing a simple identity map. List every Active Directory forest and domain. Note whether you already run Entra Connect which users sync today which devices need Hybrid identity and where your mail system still depends on local Active Directory. Keep it plain. Then compare your needs against current Cloud Sync support. Check your sign in method first. Check Exchange requirements. Check devices right back and any custom mappings that someone added years ago and nobody has looked at since. That list can expose hidden dependencies if Cloud Sync fits install at least two provisioning agents for production. One agent may work in a lab, but production identity sync should note MET, the rest on one server if you can avoid it. Build a narrow configuration next. Choose a test organizational unit or small security group. Use the default mappings unless you have a clear reason to change them. Then choose a known user and run provision on demand before you enable regular syncing. Read the result carefully. Check whether Entra finds the right person, creates the expected account and sends the expected fields. Look at the portal logs too because a green status alone does know Tim, Tim, the prove your business rules work. One warning matters during a move. So no Tim, let Entra connect and Cloud Sync manage the same objects without a documented migration plan. Two sync tools trying to control one account can create conflicts unexpected changes or deleted accounts. With a careful pilot you can reduce local maintenance, see the sync status in Entra and bring in a new office or newly acquired company without rushing the larger identity work in those. Put the right bridge in place. Cloud Sync moves much of the identity processing into Microsoft Entra while small local agents keep active directory connected to the cloud. That gives many companies a lighter setup built in agent failover support for disconnected forests and broader hybrid identity coverage in 2026. Before changing anything write down one Entra connect feature your company uses today. Then compare that feature with current Cloud Sync support including the release status and limits. Don't know Tim, T gas especially with sign-in methods, devices or exchange. A follow-up episode will compare Entra connect and Cloud Sync in more detail including how to plan a safe move between them. These sync decides who can enter Microsoft 365 so test the bridge with a small group before you open it to everyone.