2
Windows Eventlogs unzuverlässig?
Moin Kollegen.
Edit - weitere Erkenntnisse brachten mich dazu, den Fragetext zu ändern
Ich arbeite häufig und gern mit von Events getriggerten Tasks - seit Jahren ohne Probleme.
Nach all dieser Zeit sehe ich jetzt zum ersten Mal ein Problem und kann es mir nicht erklären:
Ein Konto im AD wird gesperrt (Kennwortfehleingabe) und das Sperrevent (ID 4740 im Sicherheitseventlog) taucht weder auf dem einen, noch auf dem anderen DC auf.
Somit wird auch der Benachrichtigungstask nicht getriggert.
Frage: wer hat beim Logging schon ähnlich haarsträubende Erfahrungen gemacht, dahingehend, dass Events nicht im Log ankommen?
(hier getestet auf Server 2019 und Server 2016 1607)
Edit - weitere Erkenntnisse brachten mich dazu, den Fragetext zu ändern
Ich arbeite häufig und gern mit von Events getriggerten Tasks - seit Jahren ohne Probleme.
Nach all dieser Zeit sehe ich jetzt zum ersten Mal ein Problem und kann es mir nicht erklären:
Ein Konto im AD wird gesperrt (Kennwortfehleingabe) und das Sperrevent (ID 4740 im Sicherheitseventlog) taucht weder auf dem einen, noch auf dem anderen DC auf.
Somit wird auch der Benachrichtigungstask nicht getriggert.
Frage: wer hat beim Logging schon ähnlich haarsträubende Erfahrungen gemacht, dahingehend, dass Events nicht im Log ankommen?
(hier getestet auf Server 2019 und Server 2016 1607)
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 621101
Url: https://administrator.de/forum/windows-eventlogs-unzuverlaessig-621101.html
Ausgedruckt am: 12.03.2025 um 04:03 Uhr
2 Kommentare
Neuester Kommentar
Ich habe gerade festgestellt, dass die Server loggingtechnisch evtl. überlastet waren (alleine 1 GB Security-Log pro Tag) und habe dies nun weniger scharf eigestellt und werde beobachten, ob es ein Performanceproblem ist.
Die Sache ist wieder im Griff.
Auf den DCs (Server 2016) war noch die klassische Art der Überwachuing aktiv (und nicht die neueren "advanced audit policies").
Logge ich die selben Dinge mit den advanced audit policies, dann ist das Volumen des Geloggten wesentlich kleiner, ich bekomme auch nicht ständig, wie vorher, die verwirrende Meldung "Audit Policy changed" Hunderte von Malpro Stunde und das Problem ist auch nicht mehr reproduzierbar.
Ergo: Eventuell ist das klassische Auditing auf Server 2016/2019 buggy.
Auf den DCs (Server 2016) war noch die klassische Art der Überwachuing aktiv (und nicht die neueren "advanced audit policies").
Logge ich die selben Dinge mit den advanced audit policies, dann ist das Volumen des Geloggten wesentlich kleiner, ich bekomme auch nicht ständig, wie vorher, die verwirrende Meldung "Audit Policy changed" Hunderte von Malpro Stunde und das Problem ist auch nicht mehr reproduzierbar.
Ergo: Eventuell ist das klassische Auditing auf Server 2016/2019 buggy.
