It’s been a little over two months since the last blog. Given the length of that last one, I figured you all needed a bit of a break.  

As I mentioned in my Azure AD Connect – Step by Step blog, I mentioned that the next blog was going to be a deeper dive into Azure AD Connect – Staging Mode. 

So, if you haven’t read the previous blog, I’d recommend popping over there and going over that. This blog will dive into components and steps that are covered in more detail on that blog. Not to mention, this content in a certain respect is covered on the MS-100: Microsoft 365 Identity and Services examination (it’s incorporated into the synchronization content covered on the examination).  

So, what exactly is staging mode? 

To explain this simply, staging mode is a means to providing additional availability, testing, and modernization options to your Azure AD Connect server architecture. Think of it like this, the minimum requirements are a single Azure AD Connect server to provide the synchronization between Azure AD and your on-prem AD. This obviously creates challenges and issues with regards to high availability, testing, and modernization of your Azure AD Connect environment. Staging mode adds that architecture so you can achieve this through the addition of a server to your Azure AD Connect environment, through the configuration wizard, you can select these additional server(s) to be Staging Mode servers. 

Knowing the difference between the main Azure AD Connect server and the staging mode server 

There are a few things to note regarding the setup of a Staging Mode server in Azure AD Connect. When you add a Staging Mode server into the environment, it will be active for imports and synchronization, but it won’t run any exports. You can however force this using the synchronization service manager.  

Additionally, it’s important to note that if you have Azure AD Connect with Password Hash Sync (PHS) enabled with staging mode enabled, the server will stop synchronizing password changes from the on-prem AD. Only when you disable staging mode, will the server resume those password change synchronizations from where it left off. So be sure to have a server not in staging mode maintaining those syncs. Details on this information can be found here from Microsoft’s doc library on Staging Mode (which to be fair a lot of the content of this blog will be referencing).  

Lastly, any server in staging mode will continue to receive changes from Active Directory on-prem and Azure AD and can quickly take over any responsibilities from another server in the event of a failure. However, don’t make changes to the primary server without also making changes to the staging mode server as this could disrupt the continuity of your architecture.  

So how do I do this? – Let’s go through the steps of enabling a server in staging mode 

As with most installation wizards are concerned, we’re going to go back into the Azure AD Connect wizard and we’re going to make some different changes that we didn’t select in the step-by-step blog. 

As with any new architecture or server we add, we need to verify its setup and meets all requirements. As such, if you didn’t read the roadmap that I linked in my previous blog, I’d recommend you hop over to Microsoft’s site and check it out. It breaks down the steps in order. Not to mention, it’s a required study item for the MS-100 examination. 

Since we’ve done this already, we’re going to go into the wizard here and we’re going to deselect the Start the synchronization process and we’re going to select the Enable staging mode box for the new server we’re putting into staging mode 

With regards to any customized configuration changes to the primary server that were made, and you want to ensure that those same changes are applied to the staging server, then you’ll want to review the Azure AD Connect Configuration Documenter toolset that is hosted on GitHub. 

Next, we’re going to want to perform similar import and synchronize steps as we did with the primary server on the staging server. The below steps are captured in detail here 

Select Connectors and select the first Connector with the type of Active Directory Domain Services. Click Run, select Full import, and OK. Do these steps for all Connectors of this type. 

Select the Connector with type Azure Active Directory (Microsoft). Click Run, select Full import, and OK. 

Make sure the tab Connectors is still selected. For each Connector with type Active Directory Domain Services, click Run, select Delta Synchronization, and OK. 

Select the Connector with type Azure Active Directory (Microsoft). Click Run, select Delta Synchronization, and OK. 

(Source: Import and Synchronize) 

Now we need to verify and inspect our changes before we do any exports to the directories. 

Using a command prompt (cmd.exe) we’re going to navigate to  %ProgramFiles%\Microsoft Azure AD Sync\bin 

Run: csexport “Name of Connector” %temp%\export.xml /f:x where the name of the Connector can be found in the Synchronization Service. It will have a name like “domain.com – Azure AD”  

From there run: CSExportAnalyzer %temp\export.xml > %temp%\export.csv – This allows you to use Excel and examine the changes that are about to be exported 

Make any adjustments needed to the data or configuration and repeat the above steps until you can confirm that the changes that are about to be exported are as you would expect them. 

If you want to simplify the process of analyzing any of the changes, you can also use a PowerShell cmdlet called CSAnalyzer and create a file called csanalyzer.ps1 (or really whatever you want frankly). If you followed the script from the CSAnalyzer link, you should be able to run .\csanalyzer.ps1 -xmltoimport %temp%\export.xml which then creates a csv file called processedusers1.csv that can similarly be examined in Excel. 

There is additional information on CSAnalyzer and the script which can be viewed here as well. 

Now once you’ve comfortably analyzed and confirmed everything that is going to be exported, you can now successfully perform steps like switch the active server (for high availability testing or necessity).  

This is as easy as going to the primary (active) server and turning off the server itself (this will stop any sync efforts obviously) or go into the Azure AD Connect installation wizard and set it to staging mode. You would then perform the same step on the server in staging mode and disable staging mode on that server so it could assume primary responsibilities.  

Disaster Recovery matters here 

So we’ve spent the last few minutes talking about the step by step on staging mode and the implications of this being a highly available solution but there’s other aspects to consider here too… Simply put, you need to conduct a risk assessment within your organization to determine failure tolerance.  

So, ask yourself a few questions like: 

• What is your tolerance for losing the ability to make changes to objects in Azure AD during a downtime?  

• If you use password sync, are the users okay and acceptable with using their old password in Azure AD in case they change it on-prem?

• Do you have a dependency on any real-time operations like password writeback?  

Now depending on how you answered the above questions, and how your organizations policy structure is governed, you can employ any one of the following strategies: 

• Rebuild when needed.  

• Have a server in staging mode 

• Leverage virtual machines 

Additionally, since each Azure AD Connect Server has a database associated with it, you could build a larger scale DBMS architecture running full editions of SQL Server as opposed to SQL Express. If you’re not a DBA or have an extensive background in SQL Server, I’d recommend you take a look at the SQL High Availability section covered on Microsoft’s doc site. If you do know how to beat your way out of a paper bag when it comes to SQL Server, I’d recommend looking at always on availability groups in SQL Server. Supportability for this was added to Azure AD Connect in version 1.1.524.0. However, you must enable always on availability before installing Azure AD Connect. The reason for this is because during the installation wizard, it detects whether the SQL instance you specify is enabled or not for always on.  

I don’t claim to be a SQL expert, but I did stay at a Holiday Inn Express last night…  

😊 So, let’s breakdown the strategies we just outlined a bit further. 

Rebuild when needed 

As it pertains to rebuilding when needed, this involves installing the sync engine and running an initial import and sync. Depending on the size of your organization, this can usually be completed within a few hours. If you don’t have a spare server available, you can temporarily use a DC to host the sync engine. However, in my honest opinion, I wouldn’t recommend this unless you don’t have a choice. I have a pretty specific stance on on-prem domain controller maintenance and I personally believe that you shouldn’t put too much on your DCs as this can cause strain/load and increase risk to your identity environment as a whole. Simply put, keep it simple and spin up a VM if you can and run the wizard. 

Have a server in Staging Mode 

Do what we just covered in the above step-by-step. I personally recommend this in combination with your SQL architecture. If you want a fully fault tolerant or highly available solution. You’d do this and have instances in different data centers/facilities to ensure that you don’t have a single point of failure in your DB architecture or your Azure AD Connect architecture as well. Take a similar approach to how you’d deploy global catalogs on-prem. You wouldn’t put all your DCs in one facility (unless you don’t have any other option or choice).  

Leverage Virtual Machines 

You may do this in combination with the above strategies too. With a lot of organizations using virtualization technologies or other forms of converged/hyper-converged infrastructures (HCI), there’s a strong possibility that you’ll have compute/storage resources available to easily spin up servers in rapid succession for Azure AD Connect instances in staging mode. Depending on your platform, this is generally very easy to move between hardware hosts and provide another layer of high availability and resource monitoring on the server itself. It’s also a commonly supported mechanism that the Azure AD Connect sync engine supports.  

Ladies and gentlemen, just like that we’ve covered the details of Azure AD Connect Server staging mode, it’s purpose, intent, uses, and the steps necessary to deploy it in your environment. A comprehensive Microsoft doc on what we’ve covered today can be found here: Azure AD Connect: Staging server and disaster recovery. 

If you want to learn more specifics on the synchronization process, you can refer to my previous blog(s) on Azure AD or you’re welcome to review this article on the matter as well.  

If you are completely new to this space, I can’t speak highly enough about Refactored M365 coursework. Okay I’m a little biased as I built the courses but don’t take my word for them, check them out (and the reviews) for yourself. Most of the content we’ve covered in this blog is covered on the MS-100 Certification Course: M365 Identity and Services examination. 

Should you have any questions, please don’t hesitate to reach out to Refactored about your study needs for your next Microsoft certification examination. Thank you again for taking the time in reading today’s blog. Stay safe, stay healthy, and happy holidays!