uncheck this. ... View more

That would certainly allow running stats on the former portion of the field. I will begin looking for documentation or perhaps a tutorial on how one does that. These are summary fields from a ticketing system. So each "type" of ticket (the above being 1 example) has something that makes it unique (incident number, vuln assessment tag, internal team that initiated it) Fortunately, these unique portions of each summary appear in the same position and have a distinct format, so writing regex for each type of field should be straight forward once I learn how to perform that "separation" at index time. It will be a bit time consuming, as there are 3-4 hundred summary "templates". Once done tho, the obligatory maintenance as new types of tickets are added and old types are deprecated shouldn't be unbearable. Thanks much.. Mark ... View more

Send email to education_AMER@splunk.com with your request. They should be able to answer your question. ... View more

Configuration files are cumulative. Meaning you can have 5 inputs.conf files defined within different app contexts, and they all will be applied. The way this reflects in the GUI is which app context you are currently in when you click to settings and make the configuration changes. This is by design, so that apps can import their own configurations easily and automatically. Using btool with --debug will enable you to track down which file the configurations are being read and added from. So to answer 2, you should define a company app standard (this is based on our best practices recommendations.) So, as an example, have an app : my_company_windows_inputs. Within this app context you can have a default/inputs.conf (or in local/) which defines your inputs and scripts. Then make sure no one adds any further inputs or outputs for your clients. You can further this by using a deployment server to unify and manage these configurations. ... View more