ADSync Monitoring

Wer den DirSync/ADSync mit Office 365 oder einer anderen Cloud-Lösung einsetzt, wird bei der Einrichtung natürlich kontrollieren, dass alles funktioniert. Sie dürfen aber nicht vergessen, dass der Sync ab sofort auch dauerhaft fehlerfrei arbeiten muss. Daher ist eine "Überwachung" erforderlich.

Microsoft Empfehlung

Rhoderick Milne von Microsoft hat eine sehr gute Beschreibung als Vorlage geliefert, was Sie bezüglich der Verzeichnissynchronisation im täglichen Betrieb beachten sollten:

Seine wesentlichen Punkte sind:

  • IDFIX nutzen
    Auch wenn IDFix nicht alle Probleme im lokalen AD findet, so erkennen Sie sehr schnell Inkonsistenzen, die ADSync stören. Leider gibt es IDFIX nicht als PowerShell-Script, welches unattended laufen kann
  • ADSync immer aktuell halten
    Microsoft erweiterte Office 365 Funktionen und dazu wird auch ADSync immer wieder verändert oder erweitert. ADSync kann sich sogar selbst aktualisieren. Kontrollieren Sie ab und an, ob ADSync noch aktuell genug ist
  • Windows Updates einspielen
    Die gleiche Anforderung gilt natürlich für das Betriebssystem. Das ADSync Konto hat durchaus umfangreiche Rechte und eine Malware auf dem ADSyncServer möchten Sie nicht haben
  • Server monitoren (Ping, Disk, Eventlog)
    Wenn ADSync ausfällt, dan merken Sie es in der Regel nicht sofort sondern schleichend. Sie sollte zumindest prüfen, ob der Server und die Dienste laufen. Mehr ist natürlich besser
  • Technical Contact Mail im Tenant eintragen (bekommt Alarme)
    Pflegen Sie in ihrem Tenant die Mailadresse des "Technical Contact". An diese Adresse werden Mails bei Problemem mit dem DirSync gesendet.
  • Alarmmeldungen NICHT ignorieren
    Wenn Sie dann Mails bekommen, dann sollten Sie keine Regel anlegen, um die Mails zu löschen oder zu verschieben. Lösen Sie die Ursache, ansonsten wird es nur schlimmer
  • Finger weg vom Dienstkonto
    ADSync hat bei der Installation sowohl im lokalen AD als auch in ihrem Tenant Dienstkonten angelegt. Es gibt nur einen Satz dazu: Finger weg von den Konten, d.h. keine Kennworte zurücksetzen, Mitgliedschaften ändern o.ä.
  • Backup/Restore/Recovere-Plan ausarbeiten
    Der Server mit ADSync kann ausfallen und auch ein Update kann schief gehen. Es gibt unterschiedliche Strategien, z.B. "Backup/Restore der VM" oder "Neuinstallation mit Konfigurationsanpassung" oder einen "Staging Server im Background" u.a. Wichtig ist, dass Sie einen Plan haben. Denn der Tag wird kommen.
  • AV-Produkte konfigurieren
    ADSync nutzt einen SQL-Server und es wäre nicht das erste mal, dass ein Virenscanner den Dateizugriff stört. Pflegen Sie die Ausschlussverzeichnisse entsprechend.

Auf einige der Punkte gehe ich nun noch genauer ein.

Office 365 ADSync Status im Admin Center

Wer tatsächlich ab uns an per Webbrowser sich am Office 365 Portal anmeldet, kann auf der Übersicht der aktiven Benutzer direkt sehen, wann der DirSync das letzte mal erfolgreich gelaufen ist.

Es ist gut zu sehen, dass der DirSync vor weniger als einer Stunde erfolgt ist. Bis zu 3h sind "normal". Mit AADConnect hat Microsoft die Zeit auf 30Min reduziert.

ADSync Status per Powershell

Gerade für eine automatische Überwachung ist die PowerShell natürlich besser einzusetzen. Zwar muss sich das Programm zuerst mit der Cloud verbinden, aber dann ist die Abfrage einfach.

# Anmelden mit Office 365 Credentials
PS C:\> Connect-MsolService
PS C:\> Get-MsolCompanyInformation


DisplayName                              : Frank Carius IT Dienstleistungen
PreferredLanguage                        : de
Street                                   : Glockenblumenweg 9
City                                     : Hövelhof
State                                    : NRW
PostalCode                               : 33161
Country                                  :
CountryLetterCode                        : DE
TelephoneNumber                          : +49 52579388082
MarketingNotificationEmails              : {}
TechnicalNotificationEmails              : {frank@carius.de}
SelfServePasswordResetEnabled            : True 
UsersPermissionToCreateGroupsEnabled     : True 
UsersPermissionToCreateLOBAppsEnabled    : True 
UsersPermissionToReadOtherUsersEnabled   : True 
UsersPermissionToUserConsentToAppEnabled : True
DirectorySynchronizationEnabled          : True
DirSyncServiceAccount                    : Sync_DCUser_20b512fdfadd@carius.onmicrosoft.com
LastDirSyncTime                          : 19.03.2016 11:46:46
LastPasswordSyncTime                     : 19.03.2016 11:53:07
PasswordSynchronizationEnabled           : True
DirSyncApplicationType                   : 1651564e-7ce4-4d99-88be-0a65050d8dc3
DirSyncClientVersion                     : 1.1.110.0
DirSyncClientMachineName                 : DCUser

Interessant ist hier dann die "LastDirSyncTime" und optional die "LastPasswordSyncTime" die als DateTime natürlich auch berechnet werden kann.

PS C:\> ((get-date) - (Get-MsolCompanyInformation).lastDirSynctime ).totalminutes -ge 360
False

Es ist so natürlich relativ einfach, in der Cloud den Status abzufragen, den Office 365 von diesem Tenant kennt.

Get-ADSyncConnectorStatistics

Microsoft erweitert die Funktion der ADSync-PowerShell um immer neue Befehle. So gibt es mittlerweile auch den Get-ADSyncConnectorStatistics.

PS C:\> Get-ADSyncConnector | %{Get-ADSyncConnectorStatistics $_.name }

ExportAdds ExportUpdates ExportDeletes TotalConnectors
---------- ------------- ------------- ---------------
         0             1             4               9
         0             1             0              12

Leider gibt es im Feb 2021 noch keine Dokumentation dazu.

Get-ADSyncConnector

Eher zufällig habe ich das Commandlet "Get-ADSyncConnector" im Zusammenhang mit dem Monitoring entdeckt. Jeder Connector hat hier eine "Versionsnummer", die sich bei jedem Synchronisationslauf erhöht. Da ADSync beim normalen Betrieb einen Connector erst über den Import und noch mal über den Export anspricht, wird der Wert immer zweimal erhöht.

PS C:\> Get-ADSyncConnector | ft name,type,version,ConnectorTypeName

Name                          Type        Version ConnectorTypeName
----                          ----        ------- -----------------
msxfaq.onmicrosoft.com - AAD  Extensible2      48 Extensible2
UCLABOR.DE                    AD            19420 AD
DOM2016.msxfaq.de             AD               26 AD

Daraus sollte man aber nicht ableiten, dass eine gerade Zahl gut und eine ungerade Zahl einen aktiven Lauf anzeigt. Ich kann ja auch manuell nur eine Richtung starten. Aber ich kann natürlich prüfen, ob sich die Version ca. alle 15 Minuten erhöht oder "hängen" bleibt. Allerdings erhöht sich die Nummer auch, wenn ein Fehler mit einem einzelnen Objekt vorliegt.

Azure AD Connect Health Sync-Dienste

Eine wesentliche Änderung gibt es aber doch gegenüber den früheren Versionen. Früher wurde der DirSync als "geplanter Task" installiert und vom Scheduler alle 3 Stunden gestartet. Diese Logik ist nun wohl in einen eigenen Dienst gewandert

Auch ein eigener Dienst für die Überwachung ist dazu gekommen. Diese Dienste melden die "Gesundheit" an ein Azure AD Health Portal, in dem Sie dann den Status und mehr Details erhalten können. Microsoft hat das schön beschrieben und ich sparte mir aktuell eine Dokumentation. Ich nehme an, dass hier noch einige Änderungen anstehen. Der Zugriff ist möglich, wenn Sie ein Azure Konto haben und auf diese URL zugreifen.

Aktuell braucht es dazu aber wohl noch eine Azure AD Premium Subscription:

Dann können Sie aber auch den Status in AzureAD sehen und bekommen entsprechende Warnungen und Auflösungen per Mail

Die Mails sind noch um einiges länger und mit Hinweisen zur Fehlersuche versehen, z.B. welche URLS die beiden Dienste ausgehende erreichen müssen und wie Sie lokal den Check durchführen

Test-AzureADConnectHealthConnectivity -Role Sync

Kontrolle der Benutzer mit "Error"

Wenn Sie schon im Portal sind, dann können Sie bei den Benutzern eine Ansicht aktivieren, die alle Objekte mit einem "Error" anzeigen.

Dies ist aber immer noch keine 100-prozentige Garantie, dass alles richtig ist. Denn in meinem Beispiel gibt es z.B.: keine "Problembenutzer. Da ich aber absichtlich z.B.: dem lokalen DirSync die Rechte auf Benutzer in einer "Geschäftsführung"-OU per AD-Rechte nicht vererbt habe, landen diese besonderen Benutzer meiner TestUmgebung gar nicht in der Cloud und können hier daher nicht als Problem erkannt werden.

Diese Liste im Admin Center können Sie natürlich auch per PowerShell abfragen:

# Check für Benutzer
Get-MsolUser -HasErrorsOnly

# Check für Gruppen
Get-MsolGroup -Has# Check für Gruppen
Get-MsolGroup -HasErrorsOnly

Der gleiche Check ist natürlich auch für Gruppen möglich und sinnvoll.

PS C:\> Get-Msolgroup | select displayname,DirSyncProvisioningErrors,LastDirSyncTime,grouptype

DisplayName                   DirSyncProvisioningErrors     LastDirSyncTime                                   GroupType
-----------                   -------------------------     ---------------                                   ---------
Familie                                                                                                        Security
HelpdeskAgents                                                                                                 Security
AdminAgents                                                                                                    Security
ADSyncBrowse                                                25.04.2015 22:06:15                                Security
ADSyncPasswordSet                                           25.04.2015 22:06:15                                Security
ADSyncAdmins                                                25.04.2015 22:06:15                                Security
ADSyncOperators                                             25.04.2015 22:06:15                                Security
WinRMRemoteWMIUsers__                                       25.04.2015 22:06:15                                Security
DnsAdmins                                                   25.04.2015 22:06:15                                Security
DnsUpdateProxy                                              25.04.2015 22:06:15                                Security
O365Gruppe1                                                                                            DistributionList
o365-SG                                                                                             MailEnabledSecurity
o365-DL                                                                                                DistributionList
AD-LSG                                                      09.06.2015 08:36:53                     MailEnabledSecurity
AD-GDG                                                      09.06.2015 08:36:53                        DistributionList
AD-USG2                                                     09.06.2015 08:36:53                     MailEnabledSecurity
AD-GSG                                                      09.06.2015 08:36:53                     MailEnabledSecurity
AD-LDG                                                      09.06.2015 08:36:53                        DistributionList
AD-UDG                                                      09.06.2015 08:36:53                        DistributionList
AD-USG                                                      09.06.2015 08:36:53                     MailEnabledSecurity
ADSyncPasswordSet                                           10.03.2016 21:26:28                                Security
ADSyncAdmins                                                10.03.2016 21:26:28                                Security
ADSyncOperators                                             10.03.2016 21:26:28                                Security
ADSyncBrowse                                                10.03.2016 21:26:28                                Security

Es ist gut zu sehen, welche Gruppen repliziert sind. In meinem Fall hat keine Gruppe "DirSyncProvisioningErrors"

DirSync Fehlerreport im Admin Center

Daneben gibt es noch eine weitere Ansicht

s

Auch hier könnten problematische Objekte aufgelistet sein. Das sollte auch per Powershell gehen, da jedes Objekte auch ein Property "dirsyncprovisioningerrors" hat:

get-MsolUser 
   | where {$_.dirsyncprovisioningerrors}

DirSync/ADSync-Client

Aber auch On-Premises können Sie natürlich den Status überwachen. Auch wenn Microsoft mit ADSync die Installation und Konfiguration in einen eigenen Assistenten ausgelagert hat. Dennoch ist natürlich die vollständige GUI noch installiert und kann auch aufgerufen werden. ist ist gut zu sehen, wann welche Jobs wie gelaufen sind. Sie müssen dazu den MMISClient.exe starten.

Idealerweise laufen da alle Tasks mit "Success".

So können Sie ohne Kommandozeile einen ersten Überblick bekommen.

Get-ADSyncPartitionPasswordSyncState

Auf dem lokalen ADSync-Server finden sich in neueren Versionen von ADSync auch immer mal wieder ein paar neue Commandlets, die für das Monitoring herangezogen werden können, z.B.

Interessanterweise ist der Check auch schon in einem Nagios-Modul eingebaut während ich auch im Feb 2021 noch keine Beschreibung zu dem Befehl bei Microsoft gefunden habe. Allerdings ist die Ausgabe nicht sonderlich schwer zu interpretieren, wenn Sie PasswordHashSync aktiviert haben.

DirSync/ADSync-History per WMI

Eine direkte Abfrage per PowerShell ist anscheinend (noch) nicht möglich. Aber da dahinter ja eh nur ein "FIM" steckt, gibt es immer noch die passende WMI Abfrage, um die History zu ermitteln. Interessant sind hier natürlich nicht alle jemals gelaufenen Jobs, sondern vielleicht nur der letzte Tag:

$StartTime="RunStartTime >'"+(Get-Date (Get-Date).AddDays(-1) -Format d) +"'" 
$FimRunHistory = Get-WmiObject -class "MIIS_RunHistory" -namespace root\MicrosoftIdentityintegrationServer -Filter $StartTime 

PS C:\> $FimRunHistory.Count
2025
PS C:\> $FimRunHistory[0]

__GENUS : 2
__CLASS : MIIS_RunHistory
__SUPERCLASS :
__DYNASTY : MIIS_RunHistory
__RELPATH : MIIS_RunHistory.key="{B891884F-051E-4A83-95AF-2544101C9083}-1240"
__PROPERTY_COUNT : 8
__DERIVATION : {}
__SERVER : DCUser
__NAMESPACE : root\MicrosoftIdentityintegrationServer
__PATH : \\DCUser\root\MicrosoftIdentityintegrationServer:MIIS_RunHistory.key="{B891884F-051E-4A83-95AF-25441
01C9083}-1240"
key : {B891884F-051E-4A83-95AF-2544101C9083}-1240
MaGuid : {B891884F-051E-4A83-95AF-2544101C9083}
MaName : carius.onmicrosoft.com - AAD
RunEndTime : 2016-03-19 10:06:35.343
RunNumber : 1240
RunProfile : Export
RunStartTime : 2016-03-19 10:06:30.173
RunStatus : success
PSComputerName : DCUser

Hier sehen Sie auch den "RunStatus" und können natürlich auch darauf filtern, die Einträge zählen und entsprechend lokal überwachen.

$FimRunHistory | where {$_.Runstatus -ne "success"}

Eventlog

ADSync und der DirSync hinterlassen auch Meldungen im Eventlog, die für eine Überwachung sehr nützlich sind. Beachten Sie dazu die eigene Seite auf

Taskplaner

Achtung: Seit AADConnect gibt es keinen geplanten Task mehr. Dafür ist "Get-ADSyncSscheduler"

Der DirSync wird per Default alle 3h Stunden gestartet.  Mit AADConnect hat Microsoft die Zeit auf 30Min reduziert. Beim alten DirSync konnten sie dies noch als Task sehen und anpassen. für eine Überwachung ist hier die "Last Run Time" interessant und der Statuscode.

Automatisch können Sie diese Daten auch per PowerShell ermitteln:

Leider war in meinen Tests der ResultCode immer 0, selbst wenn ich absichtlich falsche Anmeldedaten o.ä. hinterlegt habe. Das Skript wurde also immer erfolgreich gestartet um den DirSync anzutriggern aber ist kein Hinweise über den Erfolg oder Misserfolg

Bezüglich der Tauglichkeit für eine Erfolgskontrolle und Fehlerüberwachung können Sie beim Taskplaner nur den "LastRunTime"-Stempel heranziehen. Dann würde ich aber eher das Datum in der Cloud nutzen, welches zumindest die erfolgreiche Ansprache der API durch ihren On-Prem-Prozess belegt.

Office 365 sendet Warnungen per Mail

Parallel dazu überwacht Microsoft auch den DirSync. Sollte sich der DirSync nicht regelmäßig mit Office 365 verbinden, bekommen die Administratoren eine entsprechende Mail:

Kommt es bei einem Abgleich zu Probleme mit einzelnen Objekten, dann kann dies auch per Mail gemeldet werden. Hier ein etwas älteres Beispiel für ein defektes Objekt.

Dummerweise kommt diese Mail natürlich nur, wenn der lokale DirSync versucht hat, eine Information in die Cloud zu schreiben und diese hatte beim der Verarbeitung einen Fehler. Der Link verweist übrigens auf die generelle Hilfeseite:

In diesem Fall war eine Längenüberschreitung der Fall, das in der Hilfe leider lapidar auf die MSDN ( http://g.microsoftonline.com/0BD00de-de/435 bzw. http://msdn.microsoft.com/en-us/library/ms675090(v=VS.85).aspx) verwiesen hat. In dem Fall hilft dann vielleicht ein einfacher LDIF-Export des Objekts, um ein "überlanges" Feld zu erkennen. In diesem Fall war es ein Verteiler, der SEHR VIELE Proxyadressen hatte. Anscheinend noch eine "Altlast" eines Exchange 2003 RUS, der früher mal Amok gelaufen ist. Über folgenden PowerShell-Befehl auf Exchange können Sie sich schnell einen Überblick verschaffen.

Get-Recipient | ft name,@{label="count"; expression={$_.emailaddresses.count}}

Hier müssen Sie natürlich immer abgestimmt auf den Fehler eine eigene Suche durchführen.

Monitoring des Servers

Auch mit einem klassischem System Monitoring kann man schon einiges bewirken, wenn dann auf die Fehler auch reagiert wird. Die Grundlagen eines Servers sind immer wieder die gleichen:

  • Erreichbarkeit
    Der Server, auf dem ADSync läuft, muss natürlich "online" sein. Ein einfacher "Up-Test" mit einem ICMP-Ping ist billig und schnell durchgeführt, ehe sie weitere Checks ausführen
  • CPU
    Die CPU-Last sollte allein durch den DirSync Progress minimal sein. Wenn der Server nicht anderes macht, ist eine höhere Last nur beim Sync zu erwarten oder wenn wieder Windows Updates installiert werden.
  • Disk-Free
    Die freie Festplattenkapazität ist für die Funktion eines jeden Servers wichtig. Windows und andere Programme reagieren oft komisch, wenn zu wenig Platz auf den Festplatten sind und werden auch langsamer.
  • Netzwerk-Last
    DirSync gehört sicher nicht zu den Prozessen, die mit Megabit oder Gigabit arbeiten müssen. Wenn der Server "nur DirSync" macht und dennoch eine hohe Netzwerklast anliegt, dann sollten sie prüfen, welche eventuell unerwünschten Prozesse sich dort eingenistet haben.
  • Windows Update/Patchstatus
    Der Server ist normalerweise nicht aus dem Internet erreichbar und spricht nur mit den Office 365 Web Services als auch lokalen DCs und vielleicht etwas DNS und WSUS. Dennoch ist ein aktueller Patchstand für das Betriebssystem und installierte Dienste wichtig, denn der Server könnte durch seinen Zugang zum Internet durchaus als Sprungserver für Schadcode dienen
  • Erforderliche Dienste
    Alle Dienste, deren Startart auf "Automatisch" steht, sollten auch gestartet sein. Wenn andere Dienste erforderlich sind, die anderweitig gestartet werden, sollten diese auch überwacht werden.

Zumindest dies sollte einfach zu konfigurieren sein. Hier ist gut zu sehen, dass die beiden Dienste des DirSync (nicht ADSync) nicht gestartet sind.

Hier lohnt sich also auf jeden Fall ein Blick in die Eventlogs oder der Versucht eines Neustarts der Dienste oder des Servers.

Active Checks auf Applikationsebene

Wenn ein Benutzer On-Prem nicht in der Cloud repliziert wird, dann wird er sich spätestens dann melden, wenn er Dienste der Cloud nutzen soll und diese nicht nutzen kann. Er kann sich einfach nicht anmelden. Kniffliger sind Probleme, wenn der Anwender sich schon anmelden kann aber z.B. seine Stammdaten nicht korrekt sind. Letztlich kommen wir dann auf die Ebene der Anwendungen. Hier gibt es keine fertigen Lösungen aber wer darauf Wert legt, kann sich hier eine unabhängige Instanz schaffen. Denkbar ist z.B.

  • Verzeichnis-Check
    Ein Skript liest z.B. per GET-ADUser die gleiche Benutzerobjekte im lokalen Active Directory aus und vergleicht diese mit einer Liste, die es mit "Get-MSOLUser -Syncronized" bekommen hat. Die Anzahl der Objekte sollte hier gleich sein und wer noch die fraglichen Felder überprüft, kann so dem DirSync unabhängig auf die Finger schauen.
    Kniffliger wird es dann natürlich, wenn auch Gruppen und Mitgliedschaften geprüft werden sollen
  • Exchange GAL
    Gerade beim Einsatz des Exchange Hybrid Mode ist es interessant die Liste der Empfänger in der "Globalen Adressliste" zu kontrollieren. Das kann On-Prem und in der Cloud mit einem "Get-Recipient" erfolgen, bei dem die Ergebnisse verglichen werden. Wer keinen Zugriff auf die PowerShell nutzen möchte, könnte per EWS z.B.: die GAL in beiden Systemen auslesen
  • Skype für Business
    Was Exchange lieb ist, gilt auch für Skype für Business. Die Liste der Personen kann lokal und in der Cloud ausgelesen und verglichen werden.
  • "Change Check"
    Da eine Synchronisation in der Regel sequentiell" erfolgt, könnten Sie bei einem Objekt z.B.: die Beschreibung einfach immer wieder ändern und einige Zeit später (z.B. nach 3 Stunden) kontrollieren, ob diese Änderung im Ziel auch angekommen ist.

Weniger geeignet ist eine reine Abfrage des Feldes "LastDirSyncTime" in der Cloud mit:

Get-MsolUser -Synchronized | select UserPrincipalName,LastDirSyncTime

Die Ausgabe zeigt hier nur, wann welches Objekt zuletzt geändert wurde. Es kann also durchaus Objekte geben, die sehr lange nicht durch den DirSync angefasst wurden. Diese Momentaufnahme wurde am 28.5.2015 angefertigt.

Aktives Monitoring per Probe

Wer es aber noch genauer haben möchte, sollte sich ein Objekt On-Premises suchen, und dort einfach regelmäßig z.B. einen "Zeitstempel" in eine Feld ablegen. In einem zweiten Schritte kann die Überwachungssoftware dann das Objekt in der Cloud auslesen und dort den Wert des Felds mit der aktuellen Zeit vergleichen. Wenn der DirSync funktioniert, sollte der Zeitstempel nicht allzu weit in der Vergangenheit liegen.

Resümee

Wer einen DirSync betreibt, sollte ihn auch überwachen. für kleinere Firmen könnte man diese Aufgabe noch auf manuelle Stichproben per Browser oder im Fehlerfall beschränken. Je größer aber eine Firma wird, desto eher sollten Sie eine regelmäßige automatische Überwachung vorziehen, so dass Sie frühzeitig über Probleme informiert werden und nicht erst, wenn sich die Anzahl von Tickets im Helpdesk erhöhen, weil die Präsenz einiger Benutzer nicht sichtbar ist, falsche Stammdaten vorliegen oder Mitarbeiter nur einen Teil der Mails bekommen, weil z.B. die Gruppenmitgliedschaft nicht aktualisiert wurde.

Für die Überwachung der Replikation im lokalen Active Directory habe ich mit End2End-AD ein passendes Skript bereits erstellt. Nach dem gleichen Schema könnten Sie dann in der Cloud den Zeitstempel auslesen und ggfls. alarmieren.

Weitere Links