Here are some tips and tricks for creating redundant Azure AD Connect server that can help keep business running if the primary server fails.
Organizations often use Azure AD Connect to maintain the relationship between their on-prem active directory and their Office 365/Azure cloud instance, and when doing this, it’s important that they build in redundancy with business continuity in mind.
Recently our organization sought to make two meaningful changes to its sync relationship:
- set up a non-domain-controller AD Connect server
- configure the existing sync server as a standby for failover in the event of problems with the primary server
There should only ever be one active sync server at any given time to serve as an authority on the data that is synced from on-prem to the cloud.
It’s possible to install AD Connect on domain controllers, and that’s what we had done with our initial, on-prem AD Connect server, Server A. But in most cases, it’s best practice to use a dedicated server to avoid conflicts between the two roles. It also makes it easier to isolate issues as they arise and to perform maintenance on one service without affecting the other. (Any server that has AD Connect installed on it must be on-prem within your environment.)
So our team made Serve A the standby and created a new server (Server B) and gave it the sole purpose of being the primary AD sync server.
Making the change takes just a few steps, but we found it’s important to be mindful of which server you are making changes to and to export the existing sync-server settings to the new server. Note: The servers don’t go into or out of staging mode automatically; this must be done manually. That means if the active AD Connect server is down for any reason, someone will have to take the secondary server out of staging mode to make it active.
We set up Server B with Windows Server 2019, and joined it to our domain, but before installing AD Connect, we exported the settings on Server A using the following steps:
- On Server A, we opened the Microsoft Azure Active Directory Connect application and selected “Configure”.
- We selected the “View or export the current configuration” option then “Next”.
- Under “Review Your Solution” we clicked “Export Settings”, then “Exit”.
- At this point, the program prompted for a “save location” to save the .json file to be exported with all the configuration settings.
After exporting the Server A configuration file, we moved on to configuring Server B, but at this point we didn’t place Server A in standby. That needs to be done immediately before making Server B active to minimize the time there is no active sync server.
Next, we navigated to Server B, installed AD Connect, and started the Azure AD Connect wizard. After accepting the licensing agreement, we were prompted to use express settings or custom setup. We clicked “Customize”.
We checked “Import synchronization settings,” browsed to the location of the exported configuration file from Server A, and clicked “Install”. Importing this file does not automatically make Server B active; that comes later.
The next screen was for user sign-in options, and these are pre-selected 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 automatically Passthrough Authentication agents, but you can have multiple agents set up that are not AD Connect servers. More on that later.) We clicked “Next” to move on to the next screen.
To connect our Azure instance, we needed to supply credentials that belong to the “Global Administrator” role in Azure. We entered that and clicked “Next”.
You will be asked to either create a new AD account or use an existing one. The AD account basically serves as a service account to query on-prem AD and perform the sync tasks. The easier and recommended way is to create a new account with every AD Connect server to prevent issues. We chose to have the account auto-generated, so we provided the credentials of an enterprise admin in my domain. We clicked “OK” when done.
The screen that follows asks for your directory type on-prem and the Active Directory domain or forest information to connect to.
We chose “Active Directory” as directory type because we are a Windows domain shop. We provided my forest directory in the form of domain.local, and pressed “Next”.
The next screen confirmed the configuration and provided notes about it, such as the AD recycle bin not being active and device writeback settings. You can go back and follow Microsoft’s recommended configurations after this is complete, which is what we did and clicked “Exit” to move on.
Because we chose SSO earlier on in the installation, we needed to enter domain admin credentials to configure AD for that piece. We did and clicked “Next”. Done!
When Server B is configured, Server A can be placed in staging mode, and Server B taken out of staging mode to make it the active AD Connect Sync Server. Only one of these servers should be active at one time to prevent sync conflicts.
Check that the syncing is working
To verify that syncing is working from the Azure side, check with the Azure Active Directory admin center. Navigate 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 health of the sync between your on-prem environment and your Azure instance.
If you are using passthrough authentication, go to the Passthrough Authentication page (Azure Active Directory -> Azure AD Connect -> Pass-through authentication). Here you should see at the very least the two AD Connect servers you have as agents, and you can add additional, non-AD connect agents by clicking on the “Download” button at the top of the page. In our environment, we have made all active domain controllers passthrough authentication agents as well, so only those servers have the task of allowing authentication for SSO.
