Addressing logged errors

Off Topic
1

Is it just me? I feel that no logged error should go unaddressed.

I’m not saying that every error needs to have it’s root cause determined and actions taken to prevent it from happening again (when preventable). But when the same error is regularly logged, and it is determined that it’s not causing any issues, some folks just choose to ignore it.

For example, the Server Manager on our App server shows:

image

Now that only shows as 3 “different” errors

106 instances of CDPUserSvc_[various id #'s] Stopped Automatic
106 instances of OneSyncSvc_[same ID] Stopped Automatic (Delayed Start)
1 instance of “Volume Shadow Copy” VSS Stopped Automatic

This server also host the client for people connecting via RD apps. And I’ve been told that thoe errors are related to the RD connections, and are nothing to worry about.

Shouldn’t someone determine what isn’t right that is causing these?

I don’t mean just hiding the error like this:
image

If I check the Event Viewer on the App Server, The Applications log shows 31 Error level events in the last 24 hours. Most of these happen every day. Things like:

Activation of app Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy!App failed with error: This app can't be activated by the Built-in Administrator. See the Microsoft-Windows-TWinUI/Operational log for additional information.

Am I being to picky, and should let sleeping dogs lie?

2

Best practice is to address exceptions. I think the Target breach a few years ago was in part due to ignoring logged exceptions.
We are looking in a SEIM solution potentially to aggregate and analyze logs of all types, but what could potentially be an outcome is that there will be a “normal” level of noise that can be established while truly anomalous events should raise a red flag. Hard to do it if it’s just you popping into a server periodically and looking at event logs though

2 Likes
3

If the error is not security-related, won’t affect availability, and users are not affected, I would let it be.

Event logs can be littered with errors that are caused by bugs in MS code, laggy RDP connections, and unused/irrelevant services. Attempting to have a clean error log could end up causing more issues than it’s worth.

That said, if you have plenty of time on your hands, you could address each and every error.
Time, and Sanity.

1 Like