Recently I’ve spoken to a few companies using Office 365, and when doing so asked them about their AD Connect. Specifically, how they back it up. Robustly, they’ve answered, we use “XYZ Product” to take VSS backups at “XYZ” intervals. Great! But, that isn’t quite right and may not give your AD Connect server very much protection at all.
AD Connect is a very streamline version of Microsoft Identity Manager, which is hugely complex. Those complexities run deep into the core of AD Connect and as such, it needs to be treated a little differently to your other critical servers (If AD Connect isn’t in your Server Tier 0, already, move it there!)
Why Azure AD Connect is Different
Azure AD Connect regularly exports password information to Azure AD, (usually every 2 minutes) and user, group and device information (by default) every 30 minutes. This is customizable by editing your sync cycle. The issue with backing up such a busy server is, there’s no good time to take a snapshot. Furthermore, should you capture your backup part way through a sync cycle, you end up with inconsistent objects.
Microsoft make no secret that your Office 365 data isn’t backed up, that’s your businesses responsibility to sort out. However, it is very highly available across multiple regions and datacentres. To protect Azure AD Connect, the same mentality is required.
Bare in mind that Azure AD Connect is effectively a stateless server; no user or device or other persistent data resides on the server, other than the sync rules and the SQL database containing the metaverse. Both the config and the database can easily be repopulated, which opens us up to exploring a different backup strategy.
To protect AD Connect you need to deploy a secondary server elsewhere in your infrastructure, away from your primary AD Connect server. The Azure Cloud is an ideal location for this, if you don’t already have a viable alternative. Be sure to use the recommended VM specs and don’t skimp on the compute power.
How to Keep the Two Servers in Sync
This is an unfortunate quirk of Azure AD Connect, currently in 2020 there isn’t a way to synchronise any customised sync schedules, rules, etc. between servers. However, all is not lost; rulesets can be exported from the server and imported again. This process can be automated using Powershell and a couple of other tools, but is outside the scope of this blog post.
How do I Configure my Back Up / DR Azure AD Connect Server?
- First, check your current version of AD Connect. If it is several versions behind, seek assistance prior to the installation of the staging mode server
- Identify an installation location in a physically separate location to your primary server
- Configure an appropriately sized Windows server
- Download and install AD Connect
- Run through the configuration wizard. Connect to Azure AD, set the server to STAGING MODE. DO NOT ALLOW THE SERVER TO EXPORT
- Export the sync rules from your existing AD Connect server
- Import the sync rules into your new secondary server
- Run a Full Import cycle
- Run a Full Sync cycle
- Configure the Azure AD Connect Health agent (optional)
I’ve said it once, I’ll say it again… DO NOT RUN AN EXPORT!
At this point I check the two sync schedules and set them to 15 minutes apart. This helps reduce the load on your AD Domain Controllers when the AD Connect servers are importing data. it’s the little things. This step is entirely optional.
Ongoing Maintenance
Generally speaking, there’s little business need to make alterations to Azure AD Connect. However, if your rulesets do need to change, remember you’ll need to make changes to both of the Azure AD Connect servers, else they’ll end up out of sync and when you fail over to your secondary server, you end up in trouble.
This tool helps evaluate both server configs and keep you in the loop if they become mismatched:
https://github.com/microsoft/AADConnectConfigDocumenter
Some Powershell automation can be wrapped around this to make it less user intensive, but for many admins setting a calendar reminder to check the configs once a month is good enough.
Wrap Up
I hope this blog post is useful for you, whether you’re a sysadmin needing to protect AD Connect, or a business leader wanting to know the right questions to ask, this article should give you the tools to go forward and protect your AD Connect workload. A brief footnote, is that Microsoft in very small, tiny writing do say IF you’re using the MS SQL VSS provider in your backup software, in theory you *could* backup AD Connect in a traditional manner. However, the DR method I’ve outlined in my post is the recommended, best practice approach, and the one I recommend my clients adopt.
