Microsoft’s current staging-server and disaster-recovery guidance supports fault tolerance, testing configuration changes, and replacing an old server. A staging server imports and synchronizes data but does not export to Microsoft Entra ID or on-premises Active Directory. Password hash synchronization and password writeback also do not run while that server remains in staging mode. Microsoft is explicit: Entra Connect Sync supports active-passive high availability, not active-active, and only one server may actively export changes.
\r\nA staging server still receives directory changes and maintains its own database. Microsoft recommends keeping its scheduler enabled and its synchronization recent. Before a role switch, run an initial cycle when rules or scope changed, confirm accidental-delete protection, and inspect pending exports. If the former active server is unreachable, it must be shut down or isolated so it cannot unexpectedly resume exporting.
\r\nDisabling staging mode starts exports, password synchronization, and password writeback. Microsoft warns that password hash sync resumes from the staging server’s last recorded watermark. A server left staged for an extended period can have a large backlog; new password changes might not work in Microsoft Entra ID until catch-up completes. Microsoft advises monitoring the application event log during catch-up and not restarting synchronization services, because a restart can make processing resume from an earlier watermark. Password writeback can also be disrupted if two servers are active.
\r\nMicrosoft describes rebuild-on-demand as a viable disaster-recovery model. The sync engine can rebuild its object state from Active Directory and Microsoft Entra ID, using the sourceAnchor to join existing on-premises and cloud objects. What must be preserved is the applied configuration, including filters and synchronization rules. The companion configuration import and export guidance says wizard changes create time-stamped JSON files under the Entra Connect program-data location; changes made with PowerShell, Synchronization Service Manager, or Synchronization Rules Editor require an on-demand export.
\r\nThe exported JSON must not be hand-edited. Import deliberately starts the new server in staging mode, but it is not a complete machine clone. Microsoft lists settings that may require manual reapplication, including device writeback, selected object types or attributes, custom run profiles, provisioning hierarchy, and parts of federated sign-in configuration. Post-installation comparison of the imported settings with a new export is an essential verification step.
\r\nDSE recommends an explicit decision between rebuild-on-demand and a warm staging server. Base it on tolerated delay in directory changes, password synchronization, and real-time writeback—not simply server uptime. A straightforward environment with a tested configuration package may accept rebuild time. Complex filters, rules, multiple forests, writeback, or a short recovery objective favor a maintained staging server.
\r\nIn either model, treat the Windows host as replaceable and the configuration plus procedure as the durable asset. Keep a protected copy of the latest supported export away from the sync server. Maintain a separate register of Entra Connect version, sourceAnchor choice, forests and connectors, sign-in method, OU and attribute scope, custom rules and precedence, writeback features, scheduler state, service and connector account requirements, network dependencies, and every setting the export does not restore.
\r\nThis DSE playbook is an operational interpretation of Microsoft’s supported models. It does not replace environment-specific change approval. Its purpose is to prove that Entra Connect can be replaced without creating two writers or exporting an unreviewed directory change.
\r\n