Ok. That's interesting because the SplunkUniversalForwarder app is an app which indeed as @gcusello pointed out comes with your UF installation but it typically does not contain the local directory. As far as I remember the configurations you make with CLI splunk commands (like splunk add monitor) land in etc/system/local directory so they should not be there either. While technically you can make changes to the default apps you shouldn't do so because in case of upgrade you'll overwrite the changes in apps that come with the installation package with your own versions again which might be undesirable. So you should not touch the default apps. So I'd try to see where did those settings come from - either someone configured them manually (which is the "least bad" case here because on upgrade the "default" directory should get overwritten but "local" should should stay untouched) or your DS is serving this app (in which case you might want to check where it is being pushed to). Anyway, if it's been done manually, you can always just do your favourite configuration automation software (ansible?) and just remove the file from your UFs. Or you can just deploy an app with a higher precedence which will override the settings from the problematic config. See https://docs.splunk.com/Documentation/Splunk/9.1.1/Admin/Wheretofindtheconfigurationfiles

One additional remark about time manipulation - don't render it to a string unless you are absolutely sure you won't be doing anything else with it. And even better - don't render the _value_ to a string - leave the value in an epoch timestamp but use fieldformat command to only display it rendered to a string.

Don't know about the provider but the database is updated only on Splunk upgrades. You can do manual updates but they will be overwritten when you upgrade your Splunk installation unless you set a custom path to the database file.

There is more than one way to do it but they all boil down to the same thing - categorize your data into two sets and then count them. <your_initial_search> | eval account=if(account=="verified","verified","unverified") | stats count by account

Hello Rich, "Furthermore, Splunk recently changed geo-ip providers and no longer ships with a MaxMind database." What company is now the Splunk geo-ip DB provider, in 2023, since Splunk no longer ships with a MaxMind database as you mentioned? Also, what is the new DB file name, what directory is it located in, and does the new iplocation DB get updated after the initial SE installation, or not ? Best regards, Dennis  

Similar has happened to me for my last 2 upgrades (9.0.5 and 9.1.0.2).  In both cases after the upgrade, some conf files end up with root:root ownership.  Before the upgrade they were splunk:splunk. Offending files (plus 1 .pyc file and migration.log in var/log/splunk): etc/system/local/eventtypes.conf etc/system/local/web-features.conf etc/system/local/authorize.conf Primary concern are the conf files.  The upgrade is by .tgz file run as splunk:splunk.  The initial start is run by root cuz it needs root permissions to create the systemd boot-start file.  Is this just going to keep happening since I need to run "splunk enable boot-start . . . " as root? It's not a big deal to run chown to fix everything, but it is a manually step when is sometimes forgotten.