ADSync Staging Mode

ADSync ist im Grund eine unkritische Komponente, denn sie repliziert in festen Intervallen (30 Min) die lokalen AD-Objekt mit dem AzureAD. Dennoch kann gerade in großen Firmen ein Neuaufbau des kompletten Metaverse beim einem Verlust oder bei einem Updates länger dauern und eine Lösung ist ein zweiter ADSync Server, der nur keinen Export macht.

Einsatzbereich

Es gibt mehrere Gründe einen zweiten ADSync Server vorzuhalten.

  • Verfügbarkeit bei Ausfall
    Sollte der erste Server ausfallen, dann kann der Rebuild eines neuen Servers mit der gleichen Konfiguration durchaus einige Stunden dauern. Wenn das Active Directory größer ist, dann kann auch der Full-Sync durchaus länger dauern. All diese Schritte können Sie mit einem Staging-Server ohne Zeitdruck schon vorher erledigt haben und müssen nur den Export aktivieren. Ihre "Downtime" hinsichtlich der Anlage neuer Benutzer, Aktualisierungen von Gruppenmitgliedern, Synchronisation von Kennworten etc. ist deutlich reduziert
  • Verfügbarkeit beim ADSync Update
    Eine Aktualisierung von ADSync kann man planen und dauert meist nur kurze Zeit. Sollte dann aber ein FullSync erforderlich werden, dann kann bei einem großen Active Directory dies auch wieder Stunden dauern, in denen keine Updates übertragen werden. Ein Staging Server wird aber in der Regel nicht genutzt, um z.B. die Unterbrechung bei Windows Updates zu reduzieren.
  • Migration auf Server
    Wenn ihr ADSync-Server schon einige Jahre läuft, dann könnte die Hardware aber auch das eingesetzte Betriebssystem an das Supportende kommen. In dem Fall können Sie auch einen Staging-Server auf einer neuen Plattform mit dem aktuellen Betriebssystem aufbauen und nach der Funktionskontrolle aktivieren und den alten Server deprovisionieren.
  • Funktionstests
    Nicht jede Firme betreibt ein "Testfeld" mit eigener Domain, ADSync-Instanz und eigenem Tenant. Ein StagingServer kann für viele Tests genutzt werden, die z.B. Änderungen an den Regeln betrifft. Sie können nämlich, mit Ausnahme des Exports, alle Aktionen erkennen und nachvollziehen.

Dennoch bedeutet ein weiterer ADSync-Server natürlich nicht nur den Betrieb eines weiteren Servers sondern auch das Wissen um diese besondere Paarung. Ein Staging Server wird auch nie alleine eine Funktion "übernehmen". Es ist kein Cluster sondern "nur" ein "Warm Standby Server", der die Konfiguration und Daten alle schon parallel identisch aktualisiert aber nichts schreibt.

Installation und Konfiguration

Die Eirichtung des ADSync-Servers unterscheidet sich in eigentlich nicht vom produktiven Server. Sie müssen "nur" darauf achten, dass Sie die identischen Einstellungen vornehmen. und beim letzten Schritt die Checkbox für den Staging Mode aktivieren:

Leider hat das Setup keine Option eine bereit installierte Instanz nach deren Konfiguration zu befragen und ADSync macht auch kein "Backup" der Konfiguration in die Cloud

Es gibt kein manuelles "Clone Configuration"-Modul oder gar einen automatischen Abgleich. Aber es gibt mittlerweile eine Preview für "Export/Import"

Wann immer Sie eine Konfigurationsänderung über den AzureAD Connect Assistenten machen, wird eine JSON Datei angelegt, die aber nur allgemeinen Konfigurationseinstellungen des ADSync enthält, aber keine Synchronization Rules.

Pfad: %ProgramData%\AADConnect
Name Applied-SynchronizationPolicy-*.JSON

Bei jeder Konfigurationsänderung über den Azure AD Connect-Assistenten wird automatisch eine neue JSON-Einstellungsdatei mit Zeitstempel in  %ProgramData%\AADConnect exportiert. Der Name der Einstellungsdatei weist das Format Applied-SynchronizationPolicy-*.JSON auf, wobei der letzte Teil des Dateinamens ein Zeitstempel ist.

Die Datei enthält viele Einstellungen zu den Connectoren, die ihnen aber nicht weiterhelfen. Allerdings stehen hier auch OU-Ausschlüsse und Einschlüsse und die verwendeten Dienstkonten, natürlich ohne Kennwort, drin. Wenn bei einem Kunden also ein ADSync-Server ausgefallen ist und Sie zumindest ein Dateibackup haben, können sie die Basiseinstellungen schon übernehmen. Dazu passt dann bei der Installation von ADSync die neue Funktion, eben diese Datei zu importieren:

Allerdings steht im gleichen Dokument auch die deutliche Warnung:

Nur von Azure AD Connect vorgenommene Änderungen werden automatisch exportiert. Alle mit PowerShell, Synchronization Service Manager oder dem Synchronisierungsregel-Editor vorgenommenen Änderungen müssen nach Bedarf exportiert werden, um eine aktuelle Kopie zu erhalten. Der Export nach Bedarf kann auch verwendet werden, um eine Kopie der Einstellungen zur Notfallwiederherstellung an einem sicheren Ort aufzubewahren.
Quelle: https://docs.microsoft.com/de-de/azure/active-directory/hybrid/how-to-connect-import-export-config

Insofern ist die nur komplett, wenn Sie keine manuellen Anpassungen in den Regeln durchgeführt haben.

Ich kann ihnen daher nur empfehlen, alle manuellen Änderungen an Regeln u.a. gut zu dokumentieren und auf dem Staging-Server zeitnah nachzupflegen oder nahe am Standard zu bleiben.

Einstellungen migrieren

Während der Installation können Sie nur "grundlegende" Einstellungen des ADSync importieren. Sie können aber per Powershell sehr wohl einige Einstellungen exportieren. Bei jeder halbwegs aktuellen ADSync-Installation gibt es ein "MigrateSettings.ps1" im Verzeichnis "C:\Program Files\Microsoft Azure Active Directory Connect\Tools". Im Feb 2021 konnte die Funktion aber noch nicht mit PowerShell 7 genutzt werden, da das Skript sich auf ADSync Commandlets stützt.

Message: The term 'Get-ADSyncServerConfiguration' is not recognized as the name of a cmdlet, function, script file, or operable program.

Mit der PowerShell 5.1 konnte die Konfiguration dann exportiert werden:

Das Verzeichnis enthält die globale Konfiguration, Informationen zu den Connectoren aber auch alle Synchronisierungsregeln

Diese Einstellungen können Sie bei der Installation des ADSync ebenfalls importieren. Dazu müssen Sie bei der Installation von ADSync über "Import Synchronization settings" die Datei "„MigratedPolicy.json" im Stammordner auswählen.

Ich habe noch keine Weg gefunden, wie ich die Regeln in einen bestehende ADSync-Installation importieren kann. Aktuell scheint dies nur bei der Installation von ADSync möglich zu sein.

Im Feb 2021 war diese Funktion noch Preview. Sie hat in meinem kleinen "sauberen" Testlab funktioniert. Dennoch sollten Sie die Ergebnisse direkt überprüfen.

Staging Sync

Beim ersten Start macht auch der Staging-Server einen "Initial Sync", bei dem er alle Objekte aus dem lokalen Active Directory und dem AzureAD in den jeweiligen Connectorspace überträgt. Dies kann je nach Größe ihrer Umgebung und Performance des SQL-Services etwas dauern. Danach werden über ein "Full Sync" die Daten aus dem jeweiligen Connectorspace in das Metaverse und den anderen Connectorspace übertragen. Aber dann stoppt der Staging-Server. Ein Export in die Zielsysteme darf nicht passieren, da sich dann eine Überschneidung mit dem aktiven Server ergeben würde.

Achtung: Es gibt keinen Prozess, mit dem ADSync automatisch erkennt, in welcher Betriebsart andere ADSync-Server konfiguriert sind.

Nach dem initialen Sync sehen Sie im Scheduler aber nur noch die "Delta Import" und "Delta Synchronization"-Durchläufe:

Das ist auch das normale Verhalten, da ADSync damit seine lokale SQL-Datenbank immer schön aktuell hält. Sie ist maximal einen Abgleich-Zyklus hinter dem produktiven Server.

Validierung

Wer sich besonders absichern will, kann natürlich die Objekt aus ADSync exportieren und mit anderen Instanzen vergleichen. Bislang habe ich mich aber die visuelle Kontrolle des Sync beschränkt. Dennoch möchte ich den Weg nicht unterschlagen, den Microsoft dazu beschreibt.

Staging umstellen

Einen bestehenden Server können Sie recht einfach zwischen der Funktion "Staging" und "Aktiv" einfach über die GUI umstellen. Es gibt einen extra Menüpunkt dafür:

Sie müssen dann ihre Legitimation durch gültige Anmeldedaten für das verbundene AzureAD nachweisen um dann die Checkbox nutzen zu können.

Ob ein ADSync im StagingMode läuft, kann mit "Get-ADSyncGlobalSettingsParameter" ermittelt werden.

PS C:\> (Get-ADSyncGlobalSettingsParameter | ? {$_.name -eq "Microsoft.Synchronize.StagingMode"}).value
False
PS C:\> ((Get-ADSyncGlobalSettings).Parameters | ? {$_.name -eq "Microsoft.Synchronize.StagingMode"}).value
False

Hier gäbe es dann auch ein "Set-ADSyncGlobalSettings", was ich aber bislang nicht eingesetzt habe.

Zudem gibt es auch mit "get-ADSyncScheduler" eine Ausgabe zum Staging-Mode:

PS C:\> Get-ADSyncScheduler

AllowedSyncCycleInterval            : 00:30:00
CurrentlyEffectiveSyncCycleInterval : 00:30:00
CustomizedSyncCycleInterval         :
NextSyncCyclePolicyType             : Delta
NextSyncCycleStartTimeInUTC         : 18.02.2021 14:43:23
PurgeRunHistoryInterval             : 7.00:00:00
SyncCycleEnabled                    : True
MaintenanceEnabled                  : True
StagingModeEnabled                  : False
SchedulerSuspended                  : False
SyncCycleInProgress                 : False

Allerdings lässt sich der hier nicht mit "Set-ADSyncScheduler" anpassen. Wobei der Staging-Mode technisch ja wirklich nur auf den "Export" verzichtet.

Es gibt sicher einen Weg, den Staging-Mode per PowerShell umzuschalten. Aber vielleicht ist es sogar besser, wenn man dies bewusst und nicht automatisch macht.

Update Einstellung

Der Staging-Server ist ein passiver "StandBy"-Server", den Sie eigentlich nur brauchen, wenn der aktive Server ausgefallen ist oder Sie ein Update ausführen wollen. Gerade bei einem ADSync-Update können Veränderungen an Regeln dazu führen, dass ein "FullSync" erforderlich ist und das kann dauern. Daher ist ein "Rolling Update" eine wichtige Funktion.

  1. Sie aktualisieren erst den Staging Server, damit sie zum einen das Update testen
  2. Beim folgenden "Full Sync" werden alle Änderungen in die Connectorspaces und das Metaverse übertragen
  3. Sie kontrollieren die Einstellungen
  4. Sie stufen dann den bislang aktiven Servern zum Staging Server
  5. Der bisherige Staging Server wird zum aktiven Server
    Der muss dann nur noch die Änderungen "Exportieren", was viel schneller gehen sollte
  6. Sie aktualisieren den bisherigen Server, der nun Staging Server ist
    Das muss nicht mehr "schnell" erfolgen, da er ja nur Staging Server ist

Das funktioniert so geplant natürlich nur, wenn Sie die "AutoUpdateFunktion" auf den ADSync-Servern deaktiviert haben.

Set-ADSyncAutoUpgrade -AutoUpgradeState Disabled

Monitoring

Der Staging-Server ist ein passiver "StandBy"-Server", den Sie eigentlich nur brauchen, wenn der aktive Server ausgefallen ist oder Sie ein Update ausführen wollen. Sie merken aber auch nicht, wenn der Server vielleicht nicht mehr läuft. Der Staging-Server muss also genauso überwacht werden wie der aktive Server.

Allerdings sollten Sie keinen Alarm generieren, weil er nicht mehr "Exportiert". Das ist in dem Fall nämlich normal.

Fehlerfall: zwei aktive ADSync Server

Wenn ich schon mal einen Test-Forest mit zwei ADSync-Instanzen habe, dann habe ich einfach mal beide auf "Aktiv" gestellt.

Diese Betriebsart nicht nicht supportet. Ich wollte aber dennoch sehen, was im Extremfall passiert. Die Ergebnisse sind nur eine Momentaufnahme

Wie nicht anders zu erwarten sind die Import-Läufe und Sync-Läufe unkritisch. Der Export in die Cloud ist aber die Herausforderung, da der erste ADSync ein Objekt anlegt oder löscht und der andere ADSync etwas später das ja auch machen wollte. Die spätere ADSync-Instanz hat sich natürlich beschwert, dass er den "Export" in die Zielumgebung nicht machen konnte aber beim nächsten Import hat er die vom ersten ADSync schon geschriebenen Änderungen wieder eingelesen und dann war zumindest in meinem Testfeld "Ruhe"

Drauf verlassen würde ich mich aber nichts.

Weitere Links