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:
- Managing Directory Synchronisation – Notes From The Field
https://docs.microsoft.com/de-de/archive/blogs/rmilne/managing-directory-synchronisation-notes-from-the-field
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.
https://ms.portal.azure.com/#blade/Microsoft_Azure_ADHybridHealth/HybridHealthBlade
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
- Überwachen Ihrer lokalen
Identitätsinfrastruktur und Synchronisierung
von Diensten in der Cloud
https://azure.microsoft.com/de-de/documentation/articles/active-directory-aadconnect-health/ - Understanding Alerts in Azure AD Connect
Health
http://blogs.msdn.com/b/samueld/archive/2015/09/25/understanding-alerts-in-azure-ad-connect-health.aspx - Sync Insights now available in Azure AD Connect Health
- http://blogs.msdn.com/b/samueld/archive/2015/12/13/sync-insights-now-available-in-azure-ad-connect-health.aspx
- Azure AD Connect Health for sync is now
in Public Preview!
https://blogs.technet.microsoft.com/ad/2015/11/05/azure-ad-connect-health-for-sync-is-now-in-public-preview/
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"
- Identity synchronization and duplicate
attribute resiliency
https://azure.microsoft.com/en-us/documentation/articles/active-directory-aadconnectsync-duplicate-attribute-resiliency/
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.
- Pass-Through Authentifizierung (PTA)
- An overview of Azure AD Connect’s PowerShell Modules and Cmdlets
https://dirteam.com/sander/2020/06/08/an-overview-of-azure-ad-connects-powershell-modules-and-cmdlets/ - Local AD check for Azure AD Synchronization
https://exchange.nagios.org/directory/Plug-ins/Cloud/Local-AD-check-for-Azure-AD-Synchronization/details
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"}
- How to use Powershell to Export the FIM
Sync Run History to a CSV File
http://social.technet.microsoft.com/wiki/contents/articles/15400.how-to-use-powershell-to-export-the-fim-sync-run-history-to-a-csv-file.aspx -
Support-Info: (RUN HISTORY): How to use the
MIIS_RunHistory WMI Class
https://blogs.technet.microsoft.com/iamsupport/2016/08/02/info-how-to-use-the-miis_runhistory-wmi-class/ - http://blog.kloud.com.au/2014/10/23/adsync-cmdlets/
-
User Profile Synchronization reporting
script
https://www.sptrenches.com/2014/06/user-profile-synchronization-reporting.html - Forefront Identify Manager
Cmdlets in Windows PowerShell
https://technet.microsoft.com/en-us/library/ff394179.aspx - Querying FIM WMI metrics with PowerShell
http://www.wapshere.com/missmiis/querying-fim-wmi-metrics-with-powershell
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:
- Problembehandlung bei der
Verzeichnissynchronisierung
http://onlinehelp.microsoft.co2m/de-de/office365-enterprises/ff652550.aspx#BKMK_ExceededAllowedLength - Identity synchronization and
duplicate attribute resiliency
https://azure.microsoft.com/en-us/documentation/articles/active-directory-aadconnectsync-duplicate-attribute-resiliency/
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
- Office 365 Status
- Office 365: ADSync Eventlog
- Office 365:DirSync Setup
- ADSync:Sonderfälle
- Verify directory
synchronization
http://onlinehelp.microsoft.com/en-us/Office365-enterprises/ff652541.aspx - Field Notes: Azure Active
Directory Connect –
Troubleshooting Task Overview
https://azurecloudai.blog/2019/09/24/field-notes-azure-active-directory-troubleshooting-task-overview/