This discussion has been locked. The information referenced herein may be inaccurate due to age, software updates, or external references.
You can no longer post new replies to this discussion. If you have a similar question you can start a new discussion in this forum.

Domain Controller Events/Logs vs SEM agent

I would like to know if SolarWinds SEM has a best practice guide for domain controllers that also have a SEM agent and connectors on them.

Our agency uses our DC as the central logging point for all host to forward their event logs too (system, application, and security). Our DC picks these logs up and stores them for X time. Well the DC also has a SEM agent on the machine with the the windows connectors: system, application, security, NT DS, and NT DNS. 

We are experiencing so much chatter and I can only think that the SEM agent on the DC is sending back the same logs that the host are sending to the DC. Each host with the SEM agent are forwarding their logs back to the SEM console too. So by doing so, we might be receiving duplicates logs of just about everything. 

I am wondering what best practice is. I want to make sure that we are getting system, application, and security logs from the DC but i want to exclude all those logs that are being forwarded to the DC from our host and only allow the SEM agent and connectors local to that host forward those logs to the SEM console.

Ideas? thanks in advance

Mbaker_wv

Parents Reply Children
  • True. If STIG is the standard you're implementing then this needs to be enabled. In that case, prepare for a barrage of object access events and increased agent resource consumption. Add at the very least 2 additional cores and 2 extra gigs of memory to the monitored DCs. Double that if you have Sysmon running as well.

  • Yep I keep my database at around 2.5TB so I can keep enough data to make SEM usable over at least a year.  I keep physical RAW logs for windows, linux, and solaris but forward them directly to a NAS for keeping long term ie. now 5 years minimum.

    Bill