This worked as you say for the second message, but also unable to pinpoint exactly where the first one comes into play, other than getting some more details. And even setting the server logging via the GUI for "AuthStorageManagerConf" to DEBUG does not do anything to increase the logging to try and figure out where it is coming from at all... I would also note that "AuthStorageManagerConf" does not appear as a category in "$SPLUNK_HOME/etc/log.cfg". Finding another channel that has a similar name of "AuthStorageManagerWithCache" and setting it to DEBUG as well from WARN now getting some more details alongside the other... DEBUG AuthStorageManagerWithCache [123456 TcpChannelThread] - Backend operation get() failed in component=AuthStorageManagerWithCache. Error=Config entry not found. key=client_<username>, operation=GET  Maybe the AuthStorageManagerConf message is also meant to be on log level DEBUG until they implement whatever new feature, they are trying? So, temporary you could change the default value of "AuthStorageManagerConf" from WARN to ERROR to prevent the logs, seeing as I have not seen a single log on this channel other than this one pop-up, until the next release. Or raise a support case and see if you get a response 🙂  ... View more

This looks like it would work. If you're not quite sure and you want to make sure it is correct before the data goes into the index, then you could set up a sandbox index and use crcSalt to stop the logs from being registered as indexed already. In terms of billing, you would be paying for all logs, sandboxed or not, but it would avoid the annoyance of deleting wrongly-indexed data in your production indexes. E.g. [monitor://D:\Exchange Server\TransportRoles\Logs\*\ProtocolLog\SmtpReceive] whitelist=\.log$|\.LOG$ time_before_close = 0 sourcetype=MSExchange:2019:SmtpReceive queue=parsingQueue index=sandbox disabled=false crcSalt = "testing" (then remove or modify the crcSalt when the logs look good in the sandbox and are ready for production.) ... View more

Hi @sgabriel1962 ,  What changes did you make, and how did you deploy them? Did you deploy a bundle from your cluster manager? Try running this on cluster manager:  ./bin/splunk validate cluster-bundle ... View more

Hi @sgabriel1962  As you noticed yourself, you're responding to an old thread regarding a relatively old and unsupported version of Splunk. So even if your problem seems similar, it is quite likely that it's caused by different thing (especially that original one was supposed to be due to a but which should have been patched long ago). Instead of digging up an old thread, it's better to create a new one with a detailed description of your problem (and possibly a link to the old thread as a reference to something you'd found while looking for solutions but what may not be applicable to your situation). ... View more

For daily count > 4 per user, do this index=* action=fail* OR action=block* (source=win*security OR sourcetype=linux_secure OR tag=authentication) user=* user!="" user!="*@domanname" user!="USX*" user!="sec-gsa-scan" user!="host/WS Authentication" user!=USERNAME | regex user="[^\"]+@[^\"]+" | bucket _time span=1d | stats count by user src _time | where count > 4 | stats sum(count) as count by user | sort – count ... View more