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"
- Importieren und Exportieren von Azure AD
Connect-Konfigurationseinstellungen
https://docs.microsoft.com/de-de/azure/active-directory/hybrid/how-to-connect-import-export-config
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.
- Importieren und Exportieren von Azure AD
Connect-Konfigurationseinstellungen
https://docs.microsoft.com/de-de/azure/active-directory/hybrid/how-to-connect-import-export-config#migrate-settings-from-an-existing-server
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.
- Appendix CSAnalyzer
https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-sync-staging-server#appendix-csanalyzer - Azure AD Connect Staging Mode
https://www.rebeladmin.com/2017/09/azure-ad-connect-staging-mode/
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. Dazu müssen die "GlobalSettings" ändern:
#StagingMode aktivieren $ADSyncSettings=Get-ADSyncGlobalSettings ($ADSyncSettings.parameters | Where-Object {$_.name -eq "Microsoft.Synchronize.StagingMode"}).value="True" Set-ADSyncGlobalSettings $ADSyncSettings
Und die Umstellung auf "Live" ist dann:
#StagingMode aktivieren $ADSyncSettings=Get-ADSyncGlobalSettings ($ADSyncSettings.parameters | Where-Object {$_.name -eq "Microsoft.Synchronize.StagingMode"}).value="True" Set-ADSyncGlobalSettings $ADSyncSettings
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.
-
Azure AD Connect
funktioniert nach einem
automatischen Upgrade nicht
ordnungsgemäß
https://docs.microsoft.com/de-de/troubleshoot/azure/active-directory/cannot-work-automatic-upgrade -
Azure AD Connect Global
Settings
https://www.integrationtrench.com/azure-ad-connect-global-settings/ -
AZURE AD CONNECT POWERSHELL
CMDLETS
https://mikecrowley.us/2015/10/11/azure-ad-connect-powershell-cmdlets/ -
Set Azure AD Connect Staging
Mode via PowerShell
https://diecknet.de/en/2022/07/21/Azure-AD-Connect-Staging-mode-PowerShell/
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.
- Sie aktualisieren erst den Staging Server, damit sie zum einen das Update testen
- Beim folgenden "Full Sync" werden alle Änderungen in die Connectorspaces und das Metaverse übertragen
- Sie kontrollieren die Einstellungen
- Sie stufen dann den bislang aktiven Servern zum Staging Server
- Der bisherige Staging Server wird zum
aktiven Server
Der muss dann nur noch die Änderungen "Exportieren", was viel schneller gehen sollte - 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
- Azure AD Connect: Automatic upgrade
https://docs.microsoft.com/de-de/azure/active-directory/hybrid/how-to-connect-install-automatic-upgrade
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
- ADSync
- ADSync Bidirektional
- ADSync Monitoring
- Azure AD Connect: Staging server and disaster recovery
https://docs.microsoft.com/de-de/azure/active-directory/hybrid/how-to-connect-sync-staging-server - Azure AD Connect: Automatic upgrade
https://docs.microsoft.com/de-de/azure/active-directory/hybrid/how-to-connect-install-automatic-upgrade - Azure AD Connect Staging Mode
https://www.rebeladmin.com/2017/09/azure-ad-connect-staging-mode/ - Migration AAD Connect to new Server with Staging Mode
http://blog.icewolf.ch/archive/2019/06/06/migration-aad-connect-to-new-server-with-staging-mode.aspx