My big focus for Azure at Microsoft is in administration and identity. This includes a lot of heavy Azure AD work. I regularly help customers assess their Azure AD implementations and plans, which puts me in the unique position to hear about customer woes directly.
One of the bigger pain points I hear from customers A LOT – and the thing that keeps them awake at night – is Azure AD Connect and specifically when there’s no discernible plan for backup and failover in the event sync fails or disaster happens.
Obviously, we have some work to do to ensure customers are hearing about Azure AD Connect implementations that supply backup and redundancy, but we do have guidance on this.
As a best practice, consider installing a second Azure AD Connect server, but instead of making it active, install it as a Standby server so that the Azure AD Connect implementation looks like the following:
You put the Azure AD Connect server into Staging Mode during installation as shown in the next screen capture (and use the same process to change a server to standby and back again).
Installing the Azure AD Connect server in this mode causes it to be active for import and synchronization, but it is prohibited from doing the actual exports that the primary sync server is performing. Essentially, this “backup server” is constantly doing collection of your on-premises Active Directory objects, mirroring what your active sync server is capturing. Doing this, you have a backup copy of your AD objects and should disaster strike, you can take the active sync server offline and quickly enable the backup server to become the master.
Also rest assured, when a server is in Standby mode, no exports occur to your on-premise Active Directory, no exports occur to Azure Active Directory, and Password synchronization and password write-back are disabled – even if the features are selected during installation. When staging mode is disabled and the backup server becomes the primary, the server immediately starts exporting, enables password sync, and enables password writeback.
Also, keep in mind that if the server is left in staging mode for an extended period of time, it can take a while for the server to synchronize all password changes that had occurred during the time period.
Additionally, for even better protection and failover, consider putting the Primary and Standby servers in different data centers if that option is available.
For help setting up and configuring a Standby server, see: Azure AD Connect: Staging server and disaster recovery
You must log in to post a comment.