Azure AD Connect: Mellanlagringsserver och haveriberedskap

Artikel
03/17/2023
11 minuter för att läsa

Med en server i mellanlagringsläge kan du göra ändringar i konfigurationen och förhandsgranska ändringarna innan du gör servern aktiv. Du kan också köra fullständig import och fullständig synkronisering för att kontrollera att alla ändringar uppfyller förväntningarna innan du gör dessa ändringar i produktionsmiljön.

Mellanlagringsläge

Mellanlagringsläget kan användas för flera scenarier, inklusive:

Hög tillgänglighet.
Testa och distribuera nya konfigurationsändringar.
Introducera en ny server och inaktivera den gamla.

Under installationen kan du välja den server som ska vara i mellanlagringsläge. Den här åtgärden gör servern aktiv för import och synkronisering, men den kör inga exporter. En server i mellanlagringsläge kör inte lösenordssynkronisering eller tillbakaskrivning av lösenord, även om du valde dessa funktioner under installationen. När du inaktiverar mellanlagringsläget börjar servern exportera, aktiverar lösenordssynkronisering och aktiverar tillbakaskrivning av lösenord.

Anteckning

Anta att du har en Azure AD Funktionen Anslut med synkronisering av lösenordshash är aktiverad. När du aktiverar mellanlagringsläge slutar servern synkronisera lösenordsändringar från lokal AD. När du inaktiverar mellanlagringsläget återupptar servern synkroniseringen av lösenordsändringar där den senast slutade. Om servern lämnas i mellanlagringsläge under en längre tid kan det ta en stund för servern att synkronisera alla lösenordsändringar som inträffat under tidsperioden.

Du kan fortfarande tvinga fram en export med hjälp av synkroniseringstjänsthanteraren.

En server i mellanlagringsläge fortsätter att ta emot ändringar från Active Directory och Azure AD och kan snabbt ta över ansvaret för en annan server i händelse av ett fel. Om du gör konfigurationsändringar på den primära servern är det ditt ansvar att göra samma ändringar på servern i mellanlagringsläge.

För dig med kunskap om äldre synkroniseringstekniker är mellanlagringsläget annorlunda eftersom servern har en egen SQL-databas. Med den här arkitekturen kan mellanlagringslägesservern finnas i ett annat datacenter.

Verifiera konfigurationen för en server

Följ dessa steg för att tillämpa den här metoden:

Förbereda
Konfiguration
Importera och synkronisera
Verifiera
Växla aktiv server

Förbereda

Installera Azure AD Anslut, välj mellanlagringsläge och avmarkera startsynkronisering på den sista sidan i installationsguiden. Med det här läget kan du köra synkroniseringsmotorn manuellt.
Logga ut/logga in och välj Synkroniseringstjänst på Start-menyn.

Konfiguration

Om du har gjort anpassade ändringar på den primära servern och vill jämföra konfigurationen med mellanlagringsservern använder du Azure AD Connect-konfigurationsdokumentatorn.

Importera och synkronisera

Välj Anslutningsappar och välj den första anslutningsappen med typen Active Directory Domain Services. Klicka på Kör, välj Fullständig import och OK. Utför de här stegen för alla anslutningsappar av den här typen.
Välj anslutningsappen med typen Azure Active Directory (Microsoft). Klicka på Kör, välj Fullständig import och OK.
Kontrollera att fliken Anslutningsappar fortfarande är markerad. För varje anslutningsprogram med typen Active Directory Domain Services klickar du på Kör, väljer Deltasynkronisering och OK.
Välj anslutningsappen med typen Azure Active Directory (Microsoft). Klicka på Kör, välj Deltasynkronisering och OK.

Nu har du mellanlagrat exportändringar till Azure AD och lokal AD (om du använder Exchange Hybrid-distribution). Med nästa steg kan du kontrollera vad som håller på att ändras innan du påbörjar exporten till katalogerna.

Verifiera

Starta en cmd-prompt och gå till %ProgramFiles%\Microsoft Azure AD Sync\bin
Kör: csexport "Name of Connector" %temp%\export.xml /f:x Namnet på anslutningsappen finns i synkroniseringstjänsten. Det har ett namn som liknar "contoso.com – Azure AD" för Azure AD.
Kör: CSExportAnalyzer %temp%\export.xml > %temp%\export.csv Du har en fil i %temp% med namnet export.csv som kan undersökas i Microsoft Excel. Den här filen innehåller alla ändringar som ska exporteras.
Gör nödvändiga ändringar i data eller konfiguration och kör de här stegen igen (Importera och synkronisera och verifiera) tills de ändringar som ska exporteras förväntas.

Förstå export.csv-filen

Merparten av filen är självförklarande. Några förkortningar för att förstå innehållet:

OMODT – objektändringstyp. Anger om åtgärden på objektnivå är lägg till, uppdatera eller ta bort.
AMODT – Typ av attributändring. Anger om åtgärden på attributnivå är lägg till, uppdatera eller ta bort.

Hämta vanliga identifierare

Filen export.csv innehåller alla ändringar som ska exporteras. Varje rad motsvarar en ändring för ett objekt i kopplingsutrymmet och objektet identifieras av DN-attributet. DN-attributet är en unik identifierare som tilldelats ett objekt i anslutningsutrymmet. När du har många rader/ändringar i export.csv att analysera kan det vara svårt för dig att ta reda på vilka objekt som ändringarna är till för enbart baserat på DN-attributet. Om du vill förenkla processen med att analysera ändringarna använder du csanalyzer.ps1 PowerShell-skriptet. Skriptet hämtar vanliga identifierare (till exempel displayName, userPrincipalName) för objekten. Så här använder du skriptet:

Kopiera PowerShell-skriptet från avsnittet CSAnalyzer till en fil med namnet csanalyzer.ps1.
Öppna ett PowerShell-fönster och bläddra till mappen där du skapade PowerShell-skriptet.
Kör: .\csanalyzer.ps1 -xmltoimport %temp%\export.xml.
Nu har du en fil med namnet processedusers1.csv som kan undersökas i Microsoft Excel. Observera att filen tillhandahåller en mappning från DN-attributet till vanliga identifierare (till exempel displayName och userPrincipalName). Den innehåller för närvarande inte de faktiska attributändringar som ska exporteras.

Växla aktiv server

Azure AD Connect kan konfigureras i en Active-Passive hög tillgänglighetskonfiguration, där en server aktivt skickar ändringar till de synkroniserade AD-objekten till Azure AD och den passiva servern mellanlagra dessa ändringar om den skulle behöva ta över.

Anteckning

Du kan inte konfigurera Azure AD Anslut i en Active-Active konfiguration. Den måste vara aktiv-passiv. Se till att endast 1 Azure AD Connect-servern synkroniserar ändringar aktivt.

Mer information om hur du konfigurerar en Azure AD Connect-synkroniseringsserver i mellanlagringsläge finns i mellanlagringsläge

Du kan behöva utföra en redundansväxling av synkroniseringsservrarna av flera orsaker, till exempel att uppgradera versionen av Azure AD Connect eller få en avisering om att synkroniseringstjänstens hälsotjänst inte får uppdaterad information. I dessa händelser kan du försöka redundansväxling av synkroniseringsservrarna genom att följa stegen nedan.

Förutsättningar

En aktiv Azure AD Anslut synkroniseringsserver
En mellanlagringsserver Azure AD Connect Sync Server

Ändra aktiv synkroniseringsserver till mellanlagringsläge

Vi måste se till att endast en synkroniseringsserver synkroniserar ändringar vid en viss tidpunkt under hela den här processen. Om den aktiva synkroniseringsservern för närvarande kan nås kan du utföra stegen nedan för att flytta den till mellanlagringsläge. Om den inte kan nås kontrollerar du att servern eller den virtuella datorn inte återfår åtkomst oväntat, antingen genom att stänga av servern eller isolera den från utgående anslutningar och gå vidare till stegen för hur du ändrar den för närvarande mellanlagringssynkroniseringsservern till aktivt läge.

Öppna Azure AD Connect-konsolen för den aktiva Azure AD Connect-servern och klicka på Konfigurera mellanlagringsläge och sedan på Nästa:
Du måste logga in på Azure AD med autentiseringsuppgifterna global administratör eller hybrididentitet Admin:
Markera kryssrutan för Mellanlagringsläge och klicka på Nästa:
Azure AD Connect-servern söker efter installerade komponenter och frågar sedan om du vill starta synkroniseringsprocessen:

Eftersom servern kommer att vara i mellanlagringsläge kommer den inte att skriva ändringar i Azure AD, utan behålla alla ändringar i AD i dess anslutningsutrymme, redo att skriva dem.
Vi rekommenderar att du lämnar synkroniseringsprocessen på för servern i mellanlagringsläge, så om den blir aktiv tar den snabbt över och behöver inte göra en stor synkronisering för att komma ikapp det aktuella tillståndet för AD/Azure AD-synkroniseringen.

När du har valt om du vill starta eller stoppa synkroniseringsprocessen och klicka på Konfigurera konfigurerar Azure AD Connect-servern sig själv i mellanlagringsläge.
När detta är klart uppmanas du att ange en skärm som bekräftar att mellanlagringsläget är aktiverat.
Du kan klicka på Avsluta för att slutföra detta.
Du kan bekräfta att servern är i mellanlagringsläge genom att öppna konsolen Synkroniseringstjänst.
Härifrån bör det inte finnas några fler exportjobb eftersom ändringen och Fullständig & deltaimport kommer att vara suffixet "(Endast steg)" som nedan:

Ändra aktuell server för mellanlagringssynkronisering till aktivt läge

Nu bör alla våra Azure AD Connect Sync-servrar vara i mellanlagringsläge och inte exportera ändringar. Nu kan vi flytta vår synkroniseringsserver för mellanlagring till aktivt läge och aktivt synkronisera ändringar.

Gå nu till Azure AD Connect-servern som ursprungligen var i mellanlagringsläge och öppna Azure AD Connect-konsolen.

Klicka på "Konfigurera mellanlagringsläge" och klicka på Nästa:

Meddelandet längst ned i konsolen anger att servern är i mellanlagringsläge.
Logga in på Azure AD och gå sedan till skärmen Mellanlagringsläge.

Avmarkera rutan för mellanlagringsläge och klicka på Nästa

Enligt varningen på den här sidan är det viktigt att se till att inga andra Azure AD Connect-servern synkroniseras aktivt.

Det bör bara finnas en aktiv Azure AD Anslut synkroniseringsserver när som helst.
När du uppmanas att starta synkroniseringsprocessen markerar du den här rutan och klickar på Konfigurera:
När processen är klar bör du få bekräftelseskärmen nedan där du kan klicka på Avsluta för att slutföra:
Du kan återigen bekräfta att detta fungerar genom att öppna synkroniseringstjänstkonsolen och kontrollera om Exportjobb körs:

Haveriberedskap

En del av implementeringsdesignen är att planera för vad du ska göra om det skulle inträffa en katastrof där du förlorar synkroniseringsservern. Det finns olika modeller att använda och vilken som ska användas beror på flera faktorer, bland annat:

Vilken tolerans har du för att inte kunna göra ändringar i objekt i Azure AD under avbrottet?
Om du använder lösenordssynkronisering, accepterar användarna att de måste använda det gamla lösenordet i Azure AD om de ändrar det lokalt?
Är du beroende av realtidsåtgärder, till exempel tillbakaskrivning av lösenord?

Beroende på svaren på dessa frågor och organisationens policy kan en av följande strategier implementeras:

Återskapa när det behövs.
Ha en reservserver i vänteläge, så kallat mellanlagringsläge.
Använd virtuella datorer.

Om du inte använder den inbyggda SQL Express-databasen bör du även läsa avsnittet SQL-hög tillgänglighet .

Återskapa när det behövs

En genomförbar strategi är att planera för en server som återskapas när det behövs. Vanligtvis kan installationen av synkroniseringsmotorn och den inledande importen och synkroniseringen slutföras inom några timmar. Om det inte finns någon extra server tillgänglig är det möjligt att tillfälligt använda en domänkontrollant som värd för synkroniseringsmotorn.

Synkroniseringsmotorservern lagrar inte något tillstånd om objekten så databasen kan återskapas från data i Active Directory och Azure AD. Attributet sourceAnchor används för att koppla objekten från den lokala miljön och molnet. Om du återskapar servern med befintliga objekt lokalt och molnet matchar synkroniseringsmotorn dessa objekt igen vid ominstallationen. Det du behöver dokumentera och spara är de konfigurationsändringar som görs på servern, till exempel filtrerings- och synkroniseringsregler. Dessa anpassade konfigurationer måste tillämpas på nytt innan du börjar synkronisera.

Ha en reserv standby-server – mellanlagringsläge

Om du har en mer komplex miljö rekommenderar vi att du har en eller flera standby-servrar. Under installationen kan du aktivera en server i mellanlagringsläge.

Mer information finns i mellanlagringsläge.

Använda virtuella datorer

En vanlig metod som stöds är att köra synkroniseringsmotorn på en virtuell dator. Om värden har problem kan avbildningen med synkroniseringsmotorservern migreras till en annan server.

HÖG TILLGÄNGLIGHET för SQL

Om du inte använder den SQL Server Express som medföljer Azure AD Connect bör hög tillgänglighet för SQL Server också övervägas. De lösningar för hög tillgänglighet som stöds omfattar SQL-klustring och AOA (AlwaysOn-tillgänglighetsgrupper). Lösningar som inte stöds omfattar spegling.

Stöd för SQL AOA har lagts till i Azure AD Connect i version 1.1.524.0. Du måste aktivera SQL AOA innan du installerar Azure AD Connect. Under installationen identifierar Azure AD Connect om den angivna SQL-instansen är aktiverad för SQL AOA eller inte. Om SQL AOA är aktiverat tar Azure AD Connect ytterligare reda på om SQL AOA har konfigurerats att använda synkron replikering eller asynkron replikering. När du konfigurerar lyssnaren för tillgänglighetsgruppen måste egenskapen RegisterAllProvidersIP vara inställd på 0. Det beror på att Azure AD Connect för närvarande använder SQL Native Client för att ansluta till SQL och SQL Native Client inte stöder användning av egenskapen MultiSubNetFailover.

Bilaga CSAnalyzer

Se avsnittet verifiera hur du använder det här skriptet.

Param(
	[Parameter(Mandatory=$true, HelpMessage="Must be a file generated using 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 isn't loaded 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 using "csexport "Name of Connector" export.xml /f:x"
write-host "Importing XML" -ForegroundColor Yellow

#XmlReader.Create won't properly resolve the file location,
#so expand and then resolve it
$resolvedXMLtoimport=Resolve-Path -Path ([Environment]::ExpandEnvironmentVariables($xmltoimport))

#use an XmlReader to deal with even large files
$result=$reader = [System.Xml.XmlReader]::Create($resolvedXMLtoimport) 
$result=$reader.ReadToDescendant('cs-object')
if($result)
{
	do 
	{
		#create the object placeholder
		#adding them up here means we can enforce consistency
		$objOutputUser=New-Object psobject
		Add-Member -InputObject $objOutputUser -MemberType NoteProperty -Name ID -Value ""
		Add-Member -InputObject $objOutputUser -MemberType NoteProperty -Name Type -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) {Write-Host Found an exported object... -ForegroundColor Green}

		#object id
		$outID=$user.Attribute('id').Value
		if ($showOutput) {Write-Host ID: $outID}
		$objOutputUser.ID=$outID

		#object type
		$outType=$user.Attribute('object-type').Value
		if ($showOutput) {Write-Host Type: $outType}
		$objOutputUser.Type=$outType

		#dn
		$outDN= $user.Element('unapplied-export').Element('delta').Attribute('dn').Value
		if ($showOutput) {Write-Host DN: $outDN}
		$objOutputUser.DN=$outDN

		#operation
		$outOperation= $user.Element('unapplied-export').Element('delta').Attribute('operation').Value
		if ($showOutput) {Write-Host Operation: $outOperation}
		$objOutputUser.operation=$outOperation

		#now that we have the basics, go get the details

		foreach ($attr in $user.Element('unapplied-export-hologram').Element('entry').Elements("attr"))
		{
			$attrvalue=$attr.Attribute('name').Value
			$internalvalue= $attr.Element('value').Value

			switch ($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 += $objOutputUser

		Write-Progress -activity "Processing ${xmltoimport} in batches of ${batchsize}" -status "Batch ${outputfilecount}: " -percentComplete (($objOutputUsers.Count / $batchsize) * 100)

		#every so often, dump the processed users in case we blow up somewhere
		if ($count % $batchsize -eq 0)
		{
			Write-Host Hit the maximum users processed without completion... -ForegroundColor Yellow

			#export the collection of users as a CSV
			Write-Host Writing processedusers${outputfilecount}.csv -ForegroundColor Yellow
			$objOutputUsers | Export-Csv -path processedusers${outputfilecount}.csv -NoTypeInformation

			#increment the output file counter
			$outputfilecount+=1

			#reset the collection and the user counter
			$objOutputUsers = $null
			$count=0
		}

		$count+=1

		#need to bail out of the loop if no more users to process
		if ($reader.NodeType -eq [System.Xml.XmlNodeType]::EndElement)
		{
			break
		}

	} while ($reader.Read)

	#need to write out any users that didn't get picked up in a batch of 1000
	#export the collection of users as CSV
	Write-Host Writing processedusers${outputfilecount}.csv -ForegroundColor Yellow
	$objOutputUsers | Export-Csv -path processedusers${outputfilecount}.csv -NoTypeInformation
}
else
{
    Write-Host "Imported XML file is empty. No work to do." -ForegroundColor Red
}

Nästa steg

Översiktsavsnitt