I was exchanging some emails with an account manager (Andy Walker) at Kloud and thought the exchange would be for some interesting reading. Here’s the outcome in an expanded and much more helpful (to you dear reader) format…
***
Background
When working with the Microsoft Cloud and in particular with identity, depending on some of the configuration options, it can be quite important to have Azure AD Connect highly available. Unfortunately for us, Microsoft has not developed AADConnect to be highly available. That’s not ideal in today’s 24/7/365 cloud-centric IT world.
When disaster strikes, and yes that was a deliberate use of the word WHEN, with email, files, real-time communication and everything in between now living up in the sky with those clouds, should your primary data centre be out of action, there is a high probability that a considerable chunk of functionality will be affected by your on-premises outage.
Azure AD Connect
AADConnect’s purpose, it’s only purpose, is to synchronise on-premises directories to Azure AD. There is no other option. You cannot sync an ADDS forest to another with Azure AD Connect. So this simple and lightweight tool only requires a single deployment in any given ADDS forest.
Even when working with multiple forests, you only need one. It can even be deployed on a domain controller; which can save on an instance when working with the cloud.
The case for two Azure AD Connect servers
As of Monday April 17th 2017, just 132 days from today (Tuesday December 6th), DirSync and Azure AD Sync, the predecessors to Azure AD Connect will be deprecated. This is good news. This means that there is an opportunity to review your existing synchronisation architecture to take advantage of a feature of AADConnect and deploy two servers.
Staging mode is fantastic. Yes, short and sweet and to the point. It’s fantastic. Enough said, blog done; use it and we’re all good here? Right?
Okay, I’ll elaborate. Staging mode allows for the following rapid fire benefits which greatly improves IT as a result:
1 – Redundancy and disaster recovery, not high availability
I’ve read in certain articles that staging mode offers high availability. I disagree and argue it offers redundancy and disaster recovery. High availability is putting into practice architecture and design around applications, systems or servers that keeps those operational and accessible as near as possible to 100% uptime, or always online, mostly through automated solutions.
I see staging mode as offering the ability to manually bring online a secondary AADConnect server should the primary be unavailable. This could be due to a disaster or a scheduled maintenance window. Therefore it makes sense to deploy a secondary server in an alternate data centre, site or geographic location to your primary server.
To do the manual update of the secondary AADConnect server config and bring it online, the following needs to take place:
- Run Azure AD Connect
- That is the AzureADConnect.exe which is usually located in the Microsoft Azure Active Directory Connect folder in Program Files
- Select Configure staging mode (current state: enabled), select next
- Validate credentials and connect to Azure AD
- Configure staging mode – un-tick
- Configure and complete the change over
- Once this has been run, run a full import/full sync process
This being a manual process which takes time and breaks service availability to complete (importantly: you can’t have two AADConnect servers synchronising to a single Azure AD tenant), it’s not highly available.
2 – Update and test management
AADConnect now offers (since February 2016) an in-place automatic upgrade feature. Updates are rolled out by Microsoft and installed automatically. Queue the alarm bells!
I’m going to take a stab at making an analogy here: you wouldn’t have your car serviced while it’s running and taking you from A to B, so why would you have a production directory synchronisation server upgraded while its running. A bit of a stretch, but, can you see where I was going there?
Having a secondary AADConnect server allows updates and or server upgrades without impacting the core functionality of directory synchronisation to Azure AD. While this seems trivial, it’s certainly not trivial in my books. I’d want my AADConnect server functioning correctly all the time with minimal downtime. Having the two servers can allow for a 15 min (depending on how fast you can click) managed change over from server to server.
3 – Improved management and less impact on production
Lastly, this is more of a stretch, but, I think it’s a good practice to not have user accounts assigned Domain Admin rights. The same applies to logging into production servers to do trivial tasks. Having a secondary AADConnect server allows for IT administrators or service desk engineers to complete troubleshooting of sync processes for the service or objects away from the production server. That, again in my books, is a better practice and just as efficient as using primary or production servers.
Final words
Staging mode is fantastic. I’ve said it again. Since I found out about staging mode around this time last year, I’ve recommended to every customer I’ve mentioned AADConnect too, to use two servers referencing the 3 core arguments listed above. I hope that’s enough to convince you dear reader to do so as well.
Best
The fun part comes if you have any custom rules. Whilst you can export them, you need to change the GUIDs to do a reimport into the standby server.
So basically, keeping the 2 AAD Connecters configuration in sync is a operational overhead, that can trip you up.
Its actually a pretty poor design in that regard.
So if you are planning on this, and haev any custom rules. may I strongly suggest you test the migration of those custom rules a few times
Hey Jonno, thats certainly a good point about custom rules.
I cant say that I agree though, so everyone’s cool to interpret things their own way.
I’ve not had too much difficulty replicating custom rules across servers as long as documentation and knowledge on what has been configured is maintained.
I see the benefits of the two servers outweigh the challenge of keeping a set of custom rules manually in sync.
Thanks for the feedback though!
I’m with you:)
it is a little pain in ass(custom rules and most of my customers have weird custom rules) but its usually a one time thing(they don’t change)
and its easier to flip servers then what we had before which is total rebuild and sync which in some places take 24h+
here you save that 24h sync overhead and just “let it loose” doing writes/exports which is basically nothing.
(running 2 servers was always possible before adconnect but never supported…)
awesome article