How to configure a standby Azure AD Connect server
Organizations often use Azure AD Connect to maintain the relationship between their on-premises Active Directory and their Office 365/Azure cloud instance, and it is important that they build in redundancy for business continuity.
Recently, our organization attempted to make two meaningful changes to their sync relationship:
- Set up an AD Connect server that is not a domain controller
- Configure the existing sync server as a standby for failover in case of problems with the primary server
Only one active sync server should be the authority on data synced from on-premises to the cloud at any given time.
It is possible to install AD Connect on domain controllers, and that’s exactly what we did with our initial, on-premises AD Connect server, Server A. However, in most cases it is recommended to use a dedicated server to avoid conflicts between the two roles. It also makes it easier to isolate problems that arise and perform maintenance on one service without affecting the other. (Any server that has AD Connect installed must be local to your environment.)
So our team made Server A the standby server and created a new server (Server B) and gave it the sole purpose of being the primary AD sync server.
The change only takes a few steps, but we think it’s important to pay attention to which server you’re making changes on and export the existing sync server settings to the new server. Note: The servers do not automatically go into or out of staging mode; this must be done manually. That means if the active AD Connect server goes down for some reason, someone has to take the secondary server out of staging mode to activate it.
We set up Server B with Windows Server 2019 and connected it to our domain, but before installing AD Connect we exported the settings to Server A using the following steps:
- On Server A, we opened the Microsoft Azure Active Directory Connect application and selected Configure.
- We selected the option “View or export current configuration” and then “Next”.
- Under “Review Your Solution” we clicked on “Export Settings” and then on “Exit”.
- At this point, the program will ask for a “location” to save the .json file to be exported with all the configuration settings.
After exporting Server A’s configuration file, we proceeded to configure Server B, but at this point we did not put Server A into standby mode. This must be done immediately before Server B is activated to minimize the time when there is no active sync server.
Next we navigated to Server B, installed AD Connect and launched the Azure AD Connect wizard. After accepting the license agreement, we were prompted to use express settings or custom setup. We clicked Customize.
We checked Import Sync Settings, browsed to the location of Server A’s exported configuration file, and clicked Install. Importing this file does not automatically make Server B active; that comes later.
The next screen was for user login options and these are preselected based on the configuration of your first AD Connect server (Server A in our case). We use the pass-through authentication option for single sign-on (SSO). (AD Connect servers are pass-through authentication agents by default, but you can set up multiple agents that aren’t AD Connect servers. More on that later.) We clicked Next to move to the next screen.
In order to connect our Azure instance, we needed to provide credentials that belong to the Azure Global Administrator role. We entered that and clicked “Next”.
You will be prompted to either create a new AD account or use an existing one. The AD account essentially serves as a service account to query on-prem AD and perform the synchronization tasks. The easier and recommended method is to create a new account with each AD Connect server to avoid problems. We chose to have the account auto-generated, so we provided company admin credentials on my domain. We clicked “OK” when we were done.
The following screen will ask for your local directory type and the Active Directory domain or forest information to connect to.
We chose “Active Directory” as the directory type because we are a Windows domain shop. We provided my forest directory in the form of domain.local and clicked Next.
The next screen confirmed the configuration and provided hints about it, e.g. B. that the AD recycle bin is not active and the device write-back settings. You can go back and follow Microsoft’s recommended configurations after this is done, which we did and clicked ‘finish’ to continue.
Since we opted for SSO earlier in the installation, we had to enter domain admin credentials to configure AD for this part. We did it and clicked next. Finished!
When Server B is configured, Server A can be staged and Server B can be de-staged to make it the active AD Connect Sync server. Only one of these servers should be active at a time to avoid synchronization conflicts.
Check if the sync is working
To verify that syncing is working from the Azure side, contact the Azure Active Directory admin center. Navigate to Azure Active Directory -> Azure AD Connect -> Azure AD Connect Health. From there you can access both ‘Sync Errors’ and ‘Sync Services’ which should give you a good idea of the state of sync between your on-premises environment and your Azure instance.
If you are using pass-through authentication, go to the Pass-through authentication page (Azure Active Directory -> Azure AD Connect -> Pass-through authentication). Here you should at least see the two AD Connect servers you have as agents and you can add additional agents without AD Connect by clicking the Download button at the top of the page. In our environment, we’ve also made all active domain controllers pass-through authentication agents, leaving only those servers tasked with allowing authentication for SSO.
Copyright © 2022 IDG Communications, Inc.