Azure AD Connect sync: operational tasks and considerations - Microsoft Entra (2023)

A staging server allows you to make configuration changes and preview the changes before activating the server. You can also run a full import and full sync to verify that all changes are expected before making those changes in your production environment.

Staging-Modus

Staging mode can be used for several scenarios including:

• High availability.
• Test and implement new configuration changes.
• Introduce a new server and decommission the old one.

During the installation you can choose the server you want to be onstaging mode. This action enables the server for import and synchronization, but does not run any exports. A server in staging mode does not perform password synchronization or password writeback, even if you chose these features during installation. When you disable staging mode, the server starts exporting, enables password synchronization, and password writeback.

You can still force an export using the Synchronization Service Manager.

A server in staging mode continues to receive changes from Active Directory and Azure AD and can quickly take over from another server in the event of a failure. If you make configuration changes to your primary server, it is your responsibility to make the same changes to the server in staging mode.

For those of you who are familiar with older sync technologies, the staging mode is different as the server has its own SQL database. This architecture allows the server to be located in a different data center in staging mode.

Check the configuration of a server

To use this method, follow these steps:

1. Prepare
2. Construction
3. Import and sync
4. To verify
5. Change active server

Prepare

1. Install Azure AD Connect, selectstaging mode, and deselectStart synchronizationon the last page of the installation wizard. In this mode, you can run the synchronization engine manually.
2. Sign out/Sign in and select in the start menusynchronization service.

Construction

If you have made custom changes to the primary server and want to compare the configuration to the staging server, useAzure AD Connect-Konfigurationsdokumentierer.

Import and sync

1. Chooseconnections, and select the first connector with the typeActive Directory Domain Services. clickTo run, SelectFull import, andOK. Follow these steps for all connectors of this type.
2. Select the connector with typeAzure Active Directory (Microsoft). clickTo run, SelectFull import, andOK.
3. Make sure the Connectors tab is still selected. For each connector with typeActive Directory Domain Services, clickTo run, SelectDelta-Synchronisation, andOK.
4. Select the connector with typeAzure Active Directory (Microsoft). clickTo run, SelectDelta-Synchronisation, andOK.

You've now staged export changes to Azure AD and on-premises AD (if using Exchange hybrid deployment). In the next steps you can check what will change before actually starting the export to the directories.

To verify

1. Start a cmd prompt and go to%ProgramFiles%\Microsoft Azure AD Sync\bin
2. To run:csexport "Name des Konnektors" %temp%\export.xml /f:xYou can find the name of the connector in Synchronization Service. The name is similar to "contoso.com - Azure AD" for Azure AD.
3. To run:CSExportAnalyzer %temp%\export.xml > %temp%\export.csvYou have a file in %temp% named export.csv that can be examined in Microsoft Excel. This file contains all changes to be exported.
4. Make the required changes to the data or configuration and repeat these steps (import and sync and verify) until the changes to be exported are expected.

Understanding the export.csv file

Most of the file is self-explanatory. Some shortcuts to understand the content:

• OMODT - Object Modification Type. Indicates whether the object-level operation is an add, update, or delete.
• AMODT - Attribute Change Type. Indicates whether the attribute-level operation is an add, update, or delete.

Get common identifiers

The export.csv file contains all changes to be exported. Each row corresponds to a change for an object in the connector space, and the object is identified by the DN attribute. The DN attribute is a unique identifier assigned to an object in the connector space. If you need to analyze many rows/changes in export.csv, you may find it difficult to find out which objects the changes apply to based on the DN attribute alone. To simplify the process of analyzing the changes, use thecsanalyzer.ps1PowerShell script. The script retrieves common identifiers (e.g. displayName, userPrincipalName) of the objects. How to use the script:

1. Copy the PowerShell script from the sectionCSAnalyzerto a file namedcsanalyzer.ps1.
2. Open a PowerShell window and navigate to the folder where you created the PowerShell script.
3. To run:.\csanalyzer.ps1 -xmltoimport %temp%\export.xml.
4. You now have a file namedprocesses users1.csvwhich can be examined in Microsoft Excel. Note that the file provides a mapping from the DN attribute to common identifiers (such as displayName and userPrincipalName). It currently does not contain the actual attribute changes to be exported.

Change active server

Azure AD Connect can be set up in an active-passive high-availability setup, where a server actively pushes changes to the synced AD objects to Azure AD, and the passive server provides those changes in case it needs to adopt them.

For more information on setting up an Azure AD Connect sync server in staging mode, seestaging mode

You may need to fail over the sync servers for a variety of reasons, such as updating the version of Azure AD Connect or getting an alert that the sync service health service is not getting the latest information. In these cases, you can attempt a failover of the sync servers by following the steps below.

requirements

• A currently active Azure AD Connect sync server
• A staging Azure AD Connect sync server

Change the current Active Sync Server to staging mode

We need to ensure that only one sync server is syncing changes at any given time during this process. If the current Active Sync server is reachable, you can follow the steps below to move it to staging mode. If it is unreachable, ensure that the server or VM does not regain access unexpectedly, either by shutting down the server or isolating it from outbound connections, and continue with the steps to change the current staging sync server to the active mode.

1. For the currently active Azure AD Connect server, open the Azure AD Connect console and click Configure staging mode, then click Next:

   (Video) How To Install and Configure Azure AD Connect

   

2. You must sign in to Azure AD with global admin or hybrid identity admin credentials:

   

3. Check the Staging Mode checkbox and click Next:

   

4. The Azure AD Connect server looks for installed components and then asks if you want to start the synchronization process:

   

Because the server is in staging mode, it doesn't write changes to Azure AD, but keeps all changes to AD in its connector space, ready to write them.
It is recommended to leave the server sync process enabled in staging mode so that it quickly takes over when it becomes active and does not need to do a large sync to catch up with the current state of AD/Azure AD sync.

5. After you choose whether to start or stop the sync process and click Configure, the Azure AD Connect server will configure itself in staging mode.
   When this is complete, you will be prompted with a screen confirming that staging mode is enabled.
   You can click Finish to end this.

6. You can confirm that the server is successfully in staging mode by opening the Synchronization Service console.
   From here there should be no more export jobs as the change and full and delta imports are appended with "(Stage Only)" as below:

   

Change the current Staging Sync server to active mode

At this point, all of our Azure AD Connect sync servers should be in staging mode and not exporting any changes. We can now move our staging sync server to active mode and actively sync changes.

1. Now go to the Azure AD Connect server that was originally in staging mode and open the Azure AD Connect console.

   (Video) 5- Azure AD Connect Sync : Duplicate Identities troubleshooting Scenario-1 : IT Admin Series

   Click "Configure staging mode" and click Next:

   

   The message at the bottom of the console indicates that this server is in staging mode.

2. Sign in to Azure AD and then go to the Staging Mode screen.

   Uncheck Staging mode and click Next

   

   As per the warning on this page, it is important to ensure that no other Azure AD Connect server is actively syncing.

   There should only be one active Azure AD Connect sync server at a time.

3. When prompted to start the sync process, check this box and click Configure:

   

4. Once the process is complete, you should get the following confirmation screen where you can click Finish to exit:

   

5. You can confirm again that this is working by opening the Sync Service console and checking if export jobs are running:

   (Video) Fix Azure AD Sync Service not Running

   

disaster recovery

Part of the implementation design is planning what to do if there is a disaster where you lose the sync server. There are different models that can be used and which model to use depends on several factors including:

• What is your tolerance for not being able to make changes to objects in Azure AD during downtime?
• When using password synchronization, do users accept that they have to use the old password in Azure AD in case they change it locally?
• Do you depend on real-time operations like password writeback?

Depending on the answers to these questions and your organization's policies, one of the following strategies can be implemented:

• Modify if necessary.
• Do you have a spare standby server known asstaging mode.
• Use virtual machines.

If you are not using the built-in SQL Express database, you should check that as wellSQL high availabilitySection.

Modify if necessary

A viable strategy is to plan for a server rebuild if necessary. Typically, the sync engine installation and initial import and sync can be completed within a few hours. If no backup server is available, it is possible to temporarily use a domain controller to host the synchronization engine.

The sync engine server does not store state of the objects, so the database can be rebuilt from the data in Active Directory and Azure AD. theQuelleAnkerattribute is used to merge the objects from on-premises and cloud. If you rebuild the server with existing objects on-premises and in the cloud, the sync engine reconciles those objects during reinstallation. What you need to document and save are the configuration changes made to the server, e.g. B. Filter and synchronization rules. These custom configurations must be reapplied before you start syncing.

Have a spare standby server - staging mode

If you have a more complex environment, it is recommended to have one or more standby servers. During installation you can activate a serverstaging mode.

For more information, seestaging mode.

Use virtual machines

A common and supported method is to run the sync engine in a virtual machine. If the host has a problem, the image can be migrated to another server using the sync engine server.

SQL high availability

If you are not using the SQL Server Express that comes with Azure AD Connect, you should also consider high availability for SQL Server. Supported high availability solutions include SQL clustering and AOA (Always On Availability Groups). Unsupported solutions include mirroring.

Support for SQL AOA was added to Azure AD Connect in version 1.1.524.0. You must enable SQL AOA before installing Azure AD Connect. During installation, Azure AD Connect detects whether the provided SQL instance is SQL AOA enabled or not. If SQL AOA is enabled, Azure AD Connect further determines whether SQL AOA is configured to use synchronous replication or asynchronous replication. When setting up the availability group listener, the RegisterAllProvidersIP property must be set to 0. This is because Azure AD Connect currently uses SQL Native Client to connect to SQL and SQL Native Client does not support using the MultiSubNetFailover property.

Appendix CSAnalyzer

See the sectionto verifyto use this script.

Param([Parameter(Mandatory=$true, HelpMessage="Must be a file generated with csexport 'Name of Connector' export.xml /f:x)")][string]$xmltoimport="%temp%\ exportedStage1a.xml ",[Parameter(Mandatory=$false, HelpMessage="Maximum number of users per output file")][int]$batchsize=1000,[Parameter(Mandatory=$false, HelpMessage="Show console output")][ bool ]$showOutput=$false)#LINQ won't load automatically, so force it[Reflection.Assembly]::Load("System.Xml.Linq, Version=3.5.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089") | Out-Null[int]$count=1[int]$outputfilecount=1[array]$objOutputUsers=@()#XML must be generated with "csexport "Name of Connector" export.xml /f:x"write-host "Importing XML" -ForegroundColor Yellow#XmlReader.Create does not properly resolve the file location,#expand and then resolve$resolvedXMLtoimport=Resolve-Path -Path ([Environment]::ExpandEnvironmentVariables($xmltoimport))#use an XmlReader for handling large files$result=$reader=[System.Xml.XmlReader]::Create($resolvedXMLtoimport)$result=$reader.ReadToDescendant('cs-object')if($result){do{# Create the object placeholder #If you add them here we can enforce consistency -Value ""Add-Member -inputobject $objOutputUser -MemberType NoteProperty -Name DN -Value ""Add-Member -inputobject $objOutputUser -MemberType NoteProperty -Name Operation -Value " "Add-Member -inputobject $objOutputUser -MemberType NoteProperty -Name UPN -Value ""Add-Member -inputobject $objOutputUser -MemberType NoteProperty -Name displayName -Value ""Add-Member -inputobject $objOutputUser -MemberType NoteProperty -Name sourceAnchor -Value ""Add-Member -inputobject $objOutputUser -MemberType NoteProperty -Name alias -Value ""Add-Member -inputobject $objOutputUser -MemberType NoteProperty - Name primarySMTP -Value ""Add-Member -inputobject $objOutputUser -MemberType NoteProperty -Name onPremisesSamAccountName -Value ""Add-Member -inputobject $objOutputUser -MemberType NoteProperty -Name mail -Value ""$user = [System.Xml.Linq. XElement]::ReadFrom($reader)if ​​($showOutput) { WriteHost found an exported object... -ForegroundColor Green}#object id$outID=$user.Attribute('id').Valueif ( $showOutput) {Write-Host ID: $outID}$objOutputUser.ID=$outID# ObjectType$outType=$user.Attribute('object-type').Valueif ($showOutput) {Write-Host Type: $outType} $objOutputUser.Typ e=$outType#dn$outDN= $user.Element('unapplied-export').Element('delta').Attribute('dn').Valueif ($showOutput) {Write-Host DN: $outDN}$objOutputUse r.DN=$outDN#operation$outOperation= $user.Element('unapplied-export').Element('delta').Attribute('operation').Valueif ($showOutput) {Write-Host Operation: $outOperation }$objOutputUser.operation=$outOperation#Now that we have the basics, get the details for each ($attr in $user.Element('unapplied-export-hologram').Element('entry').Elements ("attr" )){$attrvalue=$attr.Attribute('name').Value$internalvalue= $attr.Element('value').Valueswitch ($attrvalue){"userPrincipalName"{if ($showOutput) { Write-Host UPN : $internalvalue}$objOutputUser.UPN=$internalvalue}"displayName"{if ($showOutput) {Write-Host displayName: $internalvalue}$objOutputUser.displayName=$internalvalue}"sourceAnchor"{if ($showOutput ) {Write-Host sourceAnchor: $internalvalue}$objOutputUser.sourceAnchor=$internalvalue}"alias"{if ($showOutput) {Write-Host alias: $internalvalue}$objOutputUser.alias=$internalvalue}"proxyAddresses"{if ($showOutput) {Write-Host primarySMTP: ($internalvalue -replace "SMTP:","") }$objOutputUser.primarySMTP=$internalvalue -replace "SMTP:", ""}}}$objOutputUsers += $objOutputUserWrite-Progress -activity "Processing ${xmltoimport} in batches of ${batchsize}" -status "Batch $ {outputfilecount}: " -percentComplete (($objOutputUsers.Count / $batchsize ) * 100)#every now and then output the processed users in case we explode somewhere if ($count % $batchsize -eq 0){Write-Host Hit the maximum user processed without completion... -ForegroundColor Yellow#Export collection of users as CSVWrite host Writing processed users${outputfilecount}.csv -ForegroundColor Yellow$objOutputUsers | Export-Csv -Path processedUsers${outputfilecount}.csv -NoTypeInformation#Increase output file count$outputfilecount+=1#Reset collection and user counts$objOutputUsers = $null$count=0}$count+=1#must be deducted from the loop when there are no more users to process if ($reader.NodeType -eq [System.Xml.XmlNodeType]::EndElement){break}} while ($reader.Read)# need to write out any users who didn't fetch in a batch of 1000 # Export the collection of users as a CSVWrite host Writing Processed Users ${outputfilecount}.csv - ForegroundColor Yellow $objOutputUsers | Export-Csv -Path processedUsers${outputfilecount}.csv -NoTypeInformation}else{ Write-Host "Imported XML file is empty. No work required." -foreground color red}

Next Steps

overview topics

• Azure AD Connect sync: Understand and customize sync
• Integrate your on-premises identities with Azure Active Directory