Azure Ad Connect High Availability
You set up azure ad connect high availability by running a second server in staging mode. This standby server reads directory changes without sending updates to the cloud. Teams build this pair so user logins keep working if the main server fails. Still, admins often grant broad local server and database roles during this setup. Broad permissions let anyone on the host read sensitive directory data or change sync rules. How azure ad connect high availability works in staging mode The sync too
Azure RBAC: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up azure ad connect high availability by running a second server in staging mode. This standby server reads directory changes without sending updates to the cloud. Teams build this pair so user logins keep working if the main server fails. Still, admins often grant broad local server and database roles during this setup. Broad permissions let anyone on the host read sensitive directory data or change sync rules.
How azure ad connect high availability works in staging mode
The sync tool does not use a traditional cluster or load balancer. Only one sync server can push changes to the cloud at any given time. If two servers push changes at once, they corrupt the cloud directory state. To prevent this, you set up a second server in staging mode. The staging server still imports data from your local domain controllers on a schedule. It also runs all your sync rules to build a local preview of changes. It stops right before exporting those changes to your cloud tenant. This design keeps the standby database warm and ready for a fast switch. You can also use the staging server to test new sync rules safely. Admins check the preview logs to see what will change before making it live. Teams often place the active and staging servers in separate data centers. This layout protects the identity sync flow if one site loses power or network links.
Planning a manual failover between active and staging servers
Staging mode does not switch servers by itself when an outage happens. Your team must watch server health and run the switch by hand. First, you turn on staging mode on the old primary server if it responds. If the primary machine is dead, you shut it down or block its network port. You must make sure the old server cannot wake up and push stale updates. Next, you log in to the standby server and turn off staging mode. The standby server becomes the active node right away and starts exporting queued changes. Both servers must share the exact same sync rules and filter settings. When an admin changes a rule on the active server, the standby server knows nothing. You must export the settings from the primary node and import them to the standby. If settings drift apart, a failover can delete cloud users or strip group roles.
What staging mode solves and the runtime gap it leaves
A staging server keeps your identity sync pipeline alive during hardware faults or maintenance. It makes sure new hires get cloud accounts and disabled users lose login rights fast. Still, high availability only solves uptime and decides who can log in to servers. It does not control what an admin does inside an active server session. To run a failover or check sync state, engineers log in to Windows hosts. They also run queries against the local database that stores identity records. Native roles decide who gets onto the machine, not what commands they run next. An admin fixing a sync error could run a broad script that alters many users. Standard server logs show that someone logged in, not the exact queries they ran. They also do not mask sensitive fields like emails, phone numbers, or national IDs. Teams need a way to inspect every command and query in flight.
Azure RBAC: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits beside the service as an open-source proxy, a sidecar for your database or API.
Before a query runs, hoop.dev guardrails check the statement against your rules. An AI Analyzer you configure can score intent or hold risky calls for human review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
Can two sync servers export changes at the same time?
No, only one server can export changes to the cloud tenant at a time. Running two active servers causes sync conflicts and breaks user account states.
Does a staging server switch over by itself during an outage?
No, staging mode requires an admin to run the switch by hand. You must demote or isolate the broken server before promoting the standby server.
How do you keep settings matched across both sync servers?
Admins export the sync settings file from the active server after any rule change. They then import that file onto the staging server so both nodes match.