Organizations often use Azure AD Connect to maintain the relationship between their on-premises Active Directory and their Office 365/Azure cloud instance, and in doing so, it’s important that they build in redundancy with business continuity in mind.
Recently, our organization sought to make two significant changes to its sync relationship:
- configure a non-domain controller AD Connect server
- configure the existing sync server as a backup for failover in the event of a problem with the primary server
There should only be one sync server active at any given time to serve as the authority over data synced on-premises to the cloud.
It is possible to install AD Connect on domain controllers, and this is what we did with our initial on-premises AD Connect server, Server A. But in most cases it is better to use a dedicated server to avoid conflicts between the two roles. . It also makes it easier to isolate problems as they arise and to perform maintenance on one service without affecting the other. (Any server with AD Connect installed must be on-premises in your environment.)
So our team made service A the standby server and created a new server (server B) and gave it the sole purpose of being the primary AD sync server.
Changing only takes a few steps, but we’ve found it’s important to know which server you’re making changes to and export the existing sync server settings to the new server. Note: Servers do not automatically enter or exit staging mode; this must be done manually. This means that if the active AD Connect server is down for some reason, someone will need to take the secondary server out of staging mode to make it active.
We configured Server B with Windows Server 2019 and joined it to our domain, but before installing AD Connect, we exported the settings to Server A by doing the following:
- On Server A, we opened the Microsoft Azure Active Directory Connect application and selected “Configure”.
- We selected the option “View or export the current configuration” and then “Next”.
- Under ‘Review your solution’, we clicked ‘Export settings’ and then ‘Exit’.
- At this point the program asked for a “save location” to save the .json file to export with all configuration settings.
After exporting Server A’s configuration file, we moved on to Server B’s configuration, but at this point we haven’t put Server A to sleep. This should be done immediately before activating Server B to minimize the time there is no sync server active.
Next, we navigated to Server B, installed AD Connect, and started the Azure AD Connect wizard. After accepting the license agreement, we were prompted to use express settings or custom configuration. We clicked on “Customize”.
We checked “Import synchronization settings”, navigated to the location of the configuration file exported from Server A and clicked “Install”. Importing this file does not automatically make server B active; it comes later.
The next screen was for user sign-in options, and these are pre-selected based on how your first AD Connect server was configured (Server A in our case). We use single sign-on option for single sign-on (SSO). (AD Connect servers are automatically Passthrough Authentication agents, but you can configure multiple agents that aren’t 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 provide credentials belonging to the “Global Administrator” role in Azure. We entered it and clicked “Next”.
You will be prompted to create a new AD account or use an existing one. The AD account basically serves as a service account to query on-premises AD and perform synchronization tasks. The easiest and recommended method is to create a new account with each AD Connect server to avoid issues. We chose to auto-generate the account, so we provided the credentials of an enterprise administrator from my domain. We clicked “OK” when we were done.
The next screen asks for your on-premises directory type and Active Directory domain or forest information to connect to.
We chose “Active Directory” as the directory type because we are a Windows domain store. We provided my forest directory as domain.local, and pressed “Next”.
The next screen confirmed the configuration and provided notes about it, such as AD Recycle Bin not active and device writeback settings. You can go back and follow Microsoft’s recommended configurations once this is complete, which we did and clicked “Exit” to continue.
Since we chose SSO earlier in the installation, we had to enter domain administrator credentials to configure AD for this room. We did it and clicked “Next”. Do!
When Server B is configured, Server A can be placed in staging mode and Server B removed from staging mode to make it the active AD Connect synchronization server. Only one of these servers should be active at a time to avoid synchronization conflicts.
Check that the synchronization is working
To verify that synchronization is working on the Azure side, see the Azure Active Directory admin center. Navigate to Azure Active Directory -> Azure AD Connect -> Azure AD Connect Health. From here you can access both “Sync Errors” and “Sync Services”, which should give you a good idea of the status of the sync between your on-premises environment and your Azure instance.
If you’re using pass-through authentication, navigate to the Pass-through Authentication page (Azure Active Directory -> Azure AD Connect -> Pass-through Authentication). Here you should see at least the two AD Connect servers you have as agents, and you can add additional non-AD connection agents by clicking the “Download” button at the top of the page. In our environment, we have also made sure that all active domain controllers pass through authentication agents, so that only these servers have the task of authorizing authentication for SSO.
Copyright © 2022 IDG Communications, Inc.
Comments are closed.