<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=1678611822423757&amp;ev=PageView&amp;noscript=1">
Defrag This

| Read. Reflect. Reboot.

Provide High Availability for Azure AD Connect

Tim Warner| October 16 2019

| IT insights, PowerShell, Azure, Active Directory

provide-high-availability-for-azure-ad-connect

Once you start rolling with Azure AD Connect and hybrid identity between local Active Directory and Azure Active Directory, one of your first thoughts is, "What happens if my Azure AD Connect server goes offline?"

That's a good question indeed, and while Microsoft doesn't have an excellent answer, they at least have something we can do to add some resiliency to your identity synchronization infrastructure.

The High-level Workflow

Microsoft's suggested method for defining a highly available Azure AD Connect infrastructure is to deploy at least one other Azure AD Connect server in your on-premises Active Directory Domain Services (AD DS) environment, but put that secondary server in staging mode.

An Azure AD Connect server running in staging mode has its synchronization service ready for action but does not perform any identity data exports. For planned maintenance on your primary server, you can place it in staging mode, take the secondary out of staging mode, and the secondary will resume identity synchronization.

If the primary server goes offline unexpectedly, you still can make the staging mode server active and it will pick up where the primary server left off. Let me show you how to do this work.

Step 1: Obtain Your Primary Azure AD Connect Server's Configuration

Sadly, Microsoft provides no easy way to export your Azure AD Connect configuration data from your primary server. The best option you have is to run the Azure AD Connect wizard on the primary, click View current configuration, and take a screenshot (!) of the results. I show you the interface in Figure 1.

Figure1

Figure 1. Getting Azure AD Connect configuration data.

If you've customized your Azure AD Connect synchronization topology, then I suggest you use Microsoft's open-source Azure AD Connect Configuration Documenter utility to print out those metaverse-level details.

Step 2: Install Azure AD Connect on the Secondary Server and Enable Staging Mode

Yes, you need to install and manually configure Azure AD Connect on your secondary server. The key difference, however, lies on the last Azure AD Connect wizard screen, shown in Figure 2.

Figure2

Figure 2. Putting your secondary server in staging mode.

Make sure to enable both the "Start the synchronization process" and "Enable staging mode" options here. It may seem counter-intuitive to select the first option, but do it anyway.

Step 3: Put Your Primary Server in Staging Mode

The best case scenario is you know in advance that you need to take your primary Azure AD Connect server offline for planned maintenance or whatever. This way you can re-run the Azure AD Connect wizard, select Configure staging mode from the Additional tasks screen (Figure 3), authenticate to your Azure AD tenant, and complete the configuration change (Figure 4).

Figure3

Figure 3. The Azure AD Connect Additional Tasks screen.

Figure4

Figure 4. Enabling staging mode.

You'll notice that the ADSync service remains running; this is by design, and it's important that you not stop it. Also, you can force an export operation on the secondary server at any time by using the Synchronization Service Manager tool or by running the following PowerShell command:

Start-ADSyncCycle -PolicyType Delta -Verbose

Step 4: Take Your Secondary Server Out of Staging Mode

No surprises here--taking an Azure AD Connect server out of staging mode follows the exact procedure as placing a server into staging mode.

Takeaways

Recall that Azure AD Connect uses SQL Server Express LocalDB as its back-end by default. If you chose to use a full SQL Server instance instead, don't forget to consider high availability for the data tier as well.

There you have it! Now you understand how to provide a level of fault tolerance for your Azure AD Connect identity synchronization infrastructure.

Topics: IT insights, PowerShell, Azure, Active Directory

Leave a Reply

Your email address will not be published. Required fields are marked *

THIS POST WAS WRITTEN BY Tim Warner

Tim Warner is a Microsoft MVP, Microsoft Press/Wiley author, and Azure solution architect based in Nashville, TN. Contact Tim at Twitter (@TechTrainerTim) or his website, techtrainertim.com.

Free Trials

Getting started has never been easier. Download a trial today.

Download Free Trials

Contact Us

Let us know how we can help you. Focus on what matters. 

Send us a note

Subscribe to our Blog

Let’s stay in touch! Register to receive our blog updates.